[med-svn] r1975 - in trunk/packages: . med-doc med-doc/trunk med-doc/trunk/debian
tille at alioth.debian.org
tille at alioth.debian.org
Thu Jun 5 15:57:59 UTC 2008
Author: tille
Date: 2008-06-05 15:57:58 +0000 (Thu, 05 Jun 2008)
New Revision: 1975
Added:
trunk/packages/med-doc/
trunk/packages/med-doc/trunk/
trunk/packages/med-doc/trunk/Makefile
trunk/packages/med-doc/trunk/debian-med-faq.sgml
trunk/packages/med-doc/trunk/debian/
trunk/packages/med-doc/trunk/debian/README.Debian
trunk/packages/med-doc/trunk/debian/changelog
trunk/packages/med-doc/trunk/debian/compat
trunk/packages/med-doc/trunk/debian/control
trunk/packages/med-doc/trunk/debian/copyright
trunk/packages/med-doc/trunk/debian/dirs
trunk/packages/med-doc/trunk/debian/lintian.overrides
trunk/packages/med-doc/trunk/debian/med-doc.doc-base
trunk/packages/med-doc/trunk/debian/med-doc.docs
trunk/packages/med-doc/trunk/debian/menu
trunk/packages/med-doc/trunk/debian/rules
trunk/packages/med-doc/trunk/failure.htm
trunk/packages/med-doc/trunk/index.html
trunk/packages/med-doc/trunk/med-doc.css
trunk/packages/med-doc/trunk/medicalfreesource.html
Log:
Injected start of new packaging for med-doc
Added: trunk/packages/med-doc/trunk/Makefile
===================================================================
--- trunk/packages/med-doc/trunk/Makefile (rev 0)
+++ trunk/packages/med-doc/trunk/Makefile 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,36 @@
+#!/usr/bin/make -f
+# Makefile for formating the Debian-Med FAQ
+
+### HELP: I used a really dirty trick to get a real '&' into an url.
+### See below for the line
+### sed "s/\(?keywords=med-\)&\(subword=1\)/\1\&\2/"
+### Anybody knows how to do this right in SGML??
+
+faq=debian-med-faq
+
+all: html 05_biomed_bio
+
+html: $(faq).sgml
+ linuxdoc --backend=html $(faq).sgml
+# ln -s $(faq).html index.html
+ ## I like output with the same timestamp as the source
+ for html in `ls d*.html` ; do \
+ tmp=$${html}.$$ ; \
+ mv $${html} $${tmp} ; \
+ cat $${tmp} | \
+ sed "s?<TITLE>.*</TITLE>?&<link rel=\"stylesheet\" type=\"text/css\" href=\"med-doc.css\">?" | \
+ sed "s/\(?keywords=med-\)&\(subword=1\)/\1\&\2/" | \
+ cat > $${html} ; \
+ rm -f $${tmp} ; \
+ touch -r $(faq).sgml $${html} ; \
+ done
+
+05_biomed_bio: 05_biomed_bio.stamp
+05_biomed_bio.stamp:
+ cd 05_biomed_bio; make pdf; make html; cd ..
+ touch 05_biomed_bio.stamp
+
+clean:
+ rm -f $(faq)*.html
+ cd 05_biomed_bio; make distclean; cd ..
+ rm -f 05_biomed_bio.stamp
Added: trunk/packages/med-doc/trunk/debian/README.Debian
===================================================================
--- trunk/packages/med-doc/trunk/debian/README.Debian (rev 0)
+++ trunk/packages/med-doc/trunk/debian/README.Debian 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,18 @@
+med-doc is part of the Debian Med project
+-----------------------------------------
+
+The Debian Med project is a so called Custom Debian Distribution which
+means it is an effort to prepare Debian for people working in medical
+care. Despite the missleading name Debian Med is a completely internal
+project of Debian, i.e. if you obtained Debian you have everything which
+is needed for Debian Med.
+
+The Debian Med project prepares so called meta packages which have names
+starting with med- and are builded with cdd-dev toolkit.
+
+The med-doc package provides papers written about the Debian Med project
+and the most recent talk which were held about the project. If you want
+to know more about Custom Debian Distributions in general it is suggested
+to install the cdd-doc package and read the docs there.
+
+ -- Andreas Tille <tille at debian.org> Thu, 05 Jun 2008 16:46:28 +0200
Added: trunk/packages/med-doc/trunk/debian/changelog
===================================================================
--- trunk/packages/med-doc/trunk/debian/changelog (rev 0)
+++ trunk/packages/med-doc/trunk/debian/changelog 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,100 @@
+med-doc (0.6) unstable; urgency=low
+
+ * debian/control:
+ - Standards-Version: 3.8.0
+ - Debhelper >= 6.0.7 to make use of dh_lintian
+ - Suggests cdd-doc, don't suggest mgp any more
+ - Build-Depends / Suggests: texlive-latex-recommended instead of texlive-bin
+ - Depends -> Recommends
+ - Vcs fields
+ - Group maintenance by Debian packaging team
+ - DM-Upload-Allowed: yes
+ - Added myself as Uploaders
+ - Rewritten long description
+ * debian/compat: 4 -> 6
+ * Rewritten README.Debian
+ * debian/rules
+ - Removed outdated talks
+
+ -- Andreas Tille <tille at debian.org> Thu, 05 Jun 2008 16:46:28 +0200
+
+med-doc (0.5.3) unstable; urgency=low
+
+ * Standards-Version: 3.6.1.1
+ * Versioned build-depends on debhelper
+ * Removed dependency from med-common again
+ closes: #278956
+ * Use sensible-browser in menu and make package depend from debianutils
+
+ -- Andreas Tille <tille at debian.org> Sat, 30 Oct 2004 21:55:44 +0200
+
+med-doc (0.5-2) unstable; urgency=low
+
+
+ * The "I'm against war" release
+ Mankind must put an end to war before war puts an end to mankind.
+ -- John F. Kennedy
+ * Depends: med-common
+ closes: #189796
+ * Standards-Version: 3.5.9
+ * debian/compat now stores debhelper compatibility version
+
+ -- Andreas Tille <tille at debian.org> Mon, 21 Apr 2003 19:57:37 +0200
+
+med-doc (0.5-1) unstable; urgency=low
+
+ * Added two talks from LinuxDays Luxembourg in English and German
+ * Added missing med-common-dev to Build-Depends-Indep
+ closes: #165175
+
+ -- Andreas Tille <tille at debian.org> Fri, 18 Oct 2002 08:04:25 +0200
+
+med-doc (0.4-1) unstable; urgency=low
+
+ * Added further talk in German.
+ * Added document about Open-Source Medical Information Management
+ * Fixed some links.
+
+ -- Andreas Tille <tille at debian.org> Thu, 12 Sep 2002 18:12:05 +0200
+
+med-doc (0.3-1) unstable; urgency=low
+
+ * First attempt to use user menus unsing med-common package.
+ * Build-Depends-Indep med-common-dev to make building stuff more general
+ * Some additions to the FAQ
+ * Added talk about Debian Internal Projects at LinuxTag Karlsruhe
+ * Do not ship dvi for the talks. Include a script to build DVI and PDF
+ format instead.
+
+ -- Andreas Tille <tille at debian.org> Tue, 25 Jun 2002 19:36:24 +0200
+
+med-doc (0.2-1) unstable; urgency=low
+
+ * Introduced Med/Doc menu
+ In the current form it forces a lintian error because it introduces
+ a new root menu section. I just want to show this as a suggestion in
+ some talks and afterwards will follow the consensus which might be
+ result in a policy change.
+ * Depends www-browser
+ * Added doc-linux-text as alternative dependency
+ * Added failure.htm document.
+ * Included talk about Debian-Med at LinuxTag Magdeburg
+
+ -- Andreas Tille <tille at debian.org> Sat, 18 May 2002 21:35:30 +0200
+
+med-doc (0.1-2) unstable; urgency=low
+
+ * Do not include Medicine-HOWTO which will not be packaged separately
+ Just add a depencency from doc-linux-html which contains Medicine-Howto
+ closes: #132666
+ * Section moved to doc instead of misc.
+ * Added dependency from resmed-doc.
+
+ -- Andreas Tille <tille at debian.org> Wed, 27 Feb 2002 08:49:28 +0100
+
+med-doc (0.1-1) unstable; urgency=low
+
+ * Initial release
+ closes: #132670
+
+ -- Andreas Tille <tille at debian.org> Wed, 6 Feb 2002 20:56:59 +0100
Added: trunk/packages/med-doc/trunk/debian/compat
===================================================================
--- trunk/packages/med-doc/trunk/debian/compat (rev 0)
+++ trunk/packages/med-doc/trunk/debian/compat 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1 @@
+6
Added: trunk/packages/med-doc/trunk/debian/control
===================================================================
--- trunk/packages/med-doc/trunk/debian/control (rev 0)
+++ trunk/packages/med-doc/trunk/debian/control 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,19 @@
+Source: med-doc
+Section: doc
+Priority: optional
+Maintainer: Debian-Med Packaging Team <debian-med-packaging at lists.alioth.debian.org>
+DM-Upload-Allowed: yes
+Uploaders: Andreas Tille <tille at debian.org>
+Build-Depends-Indep: debhelper (>= 6.0.7), linuxdoc-tools, texlive-latex-recommended
+Standards-Version: 3.8.0
+Vcs-Browser: http://svn.debian.org/wsvn/debian-med/trunk/packages/med-doc/trunk/?rev=0&sc=0
+Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/med-doc/trunk/
+
+Package: med-doc
+Architecture: all
+Suggests: cdd-doc, linuxdoc-tools, texlive-latex-recommended
+Recommends: doc-linux-html | doc-linux-text, resmed-doc, debianutils (>= 2.8.4)
+Description: Debian Med documentation packages
+ This package will install papers written about and talks hold about
+ the Debian Med project as well as Debian packages with documentation
+ according to free software which might be relevant for medical care.
Added: trunk/packages/med-doc/trunk/debian/copyright
===================================================================
--- trunk/packages/med-doc/trunk/debian/copyright (rev 0)
+++ trunk/packages/med-doc/trunk/debian/copyright 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,12 @@
+This package is Copyright (C) 2002-2008 by Andreas Tille <tille at debian.org>
+
+This software is licensed under the GPL.
+
+The failure.htm document contained in this package was obtained from:
+
+ http://web.archive.org/web/20010520135245/http://members.aol.com/medinformaticsmd/failure.htm
+
+There is no explicite license of this document and it is now unavailable.
+So it is just conserved here.
+
+On Debian systems, the GPL can be found at /usr/share/common-licenses/GPL.
Added: trunk/packages/med-doc/trunk/debian/dirs
===================================================================
--- trunk/packages/med-doc/trunk/debian/dirs (rev 0)
+++ trunk/packages/med-doc/trunk/debian/dirs 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,2 @@
+usr/share/doc/med-doc/html
+usr/share/lintian/overrides
Added: trunk/packages/med-doc/trunk/debian/lintian.overrides
===================================================================
--- trunk/packages/med-doc/trunk/debian/lintian.overrides (rev 0)
+++ trunk/packages/med-doc/trunk/debian/lintian.overrides 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,4 @@
+med-doc: menu-command-not-in-package /usr/lib/menu/med-doc:4 sensible-browser
+med-doc: menu-command-not-in-package /usr/lib/menu/med-doc:8 sensible-browser
+med-doc: menu-command-not-in-package /usr/lib/menu/med-doc:12 sensible-browser
+med-doc: menu-command-not-in-package /usr/lib/menu/med-doc:16 sensible-browser
Added: trunk/packages/med-doc/trunk/debian/med-doc.doc-base
===================================================================
--- trunk/packages/med-doc/trunk/debian/med-doc.doc-base (rev 0)
+++ trunk/packages/med-doc/trunk/debian/med-doc.doc-base 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,13 @@
+Document: med-doc
+Title: Debian Med FAQ
+Author: Andreas Tille <tille at debian.org>
+Abstract: Debian-Med FAQ also containing an index of the medical
+ documentation stuff
+Section: Misc
+
+Format: HTML
+Index: /usr/share/doc/med-doc/html/index.html
+Files: /usr/share/doc/med-doc/html/*
+
+Format: linuxdoc-sgml
+Files: /usr/share/doc/med-doc/debian-med-faq.sgml.gz
Added: trunk/packages/med-doc/trunk/debian/med-doc.docs
===================================================================
--- trunk/packages/med-doc/trunk/debian/med-doc.docs (rev 0)
+++ trunk/packages/med-doc/trunk/debian/med-doc.docs 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1 @@
+debian-med-faq.sgml
Added: trunk/packages/med-doc/trunk/debian/menu
===================================================================
--- trunk/packages/med-doc/trunk/debian/menu (rev 0)
+++ trunk/packages/med-doc/trunk/debian/menu 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,16 @@
+?package(med-doc):needs="X11" section="Help/Med"\
+ title="Debian-Med"\
+ command="sensible-browser /usr/share/doc/med-doc/html/index.html"\
+ hints="General Debian-Med Documentation"
+?package(med-doc):needs="X11" section="Help/Med"\
+ title="Medicine HOWTO"\
+ command="sensible-browser /usr/share/doc/doc-linux-html/HOWTO/Medicine-HOWTO.html"\
+ hints="Linuxdoc.org Medicine HOWTO"
+?package(med-doc):needs="X11" section="Help/Med"\
+ title="Analysis document"\
+ command="sensible-browser /usr/share/doc/resmed-doc/html/index.html"\
+ hints="Resmedicinae Analysis of Software Requirements"
+?package(med-doc):needs="X11" section="Help/Med"\
+ title="Talks"\
+ command="sensible-browser /usr/share/doc/med-doc/talks/index.html"\
+ hints="Talks about Debian-Med"
Added: trunk/packages/med-doc/trunk/debian/rules
===================================================================
--- trunk/packages/med-doc/trunk/debian/rules (rev 0)
+++ trunk/packages/med-doc/trunk/debian/rules 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,60 @@
+#!/usr/bin/make -f
+# debian/rules for med-bio
+# This file is public domain software
+# Andreas Tille <tille at debian.org>
+#
+# Uncomment this to turn on verbose mode.
+#export DH_VERBOSE=1
+
+pkg=med-doc
+faq=debian-med-faq
+
+build: build-stamp
+build-stamp:
+ dh_testdir
+
+ make
+# Do not build DVI for the binary package
+# Use manually formated HTML because the mgp2html output is ugly
+
+ touch build-stamp
+
+clean:
+ dh_testdir
+ dh_testroot
+ rm -f build-stamp
+
+ make clean
+ dh_clean
+
+install: build
+ dh_testdir
+ dh_testroot
+ dh_clean -k
+ dh_installdirs
+
+ cp -a *.html f*.htm *.css `pwd`/debian/$(pkg)/usr/share/doc/$(pkg)/html
+
+# Build architecture-independent files here.
+binary-indep: build install
+ dh_testdir
+ dh_testroot
+ dh_installdocs
+ dh_installmenu
+# med_install_helper
+ dh_installchangelogs
+ cp -a debian/lintian.overrides debian/$(pkg)/usr/share/lintian/overrides/$(pkg)
+ dh_link
+ dh_compress
+ dh_fixperms
+ dh_installdeb
+ dh_gencontrol
+ dh_md5sums
+ dh_builddeb
+
+# Build architecture-dependent files here.
+binary-arch: build install
+# We have nothing to do by default.
+
+binary: binary-indep binary-arch
+.PHONY: build clean binary-indep binary-arch binary install
Property changes on: trunk/packages/med-doc/trunk/debian/rules
___________________________________________________________________
Name: svn:executable
+ *
Added: trunk/packages/med-doc/trunk/debian-med-faq.sgml
===================================================================
--- trunk/packages/med-doc/trunk/debian-med-faq.sgml (rev 0)
+++ trunk/packages/med-doc/trunk/debian-med-faq.sgml 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,137 @@
+<!doctype linuxdoc system>
+<article>
+<title>Debian Med FAQ
+<author>Andreas Tille <htmlurl url ="mailto:tille at debian.org" name="<tille at debian.org>">
+<date>v0.1 6 February 2002
+<abstract>
+FAQ of the Debian-Med project.
+<toc>
+
+<sect>General
+<p>
+Some general questions about the Debian-Med project.
+</p>
+
+<sect1>Why Debian-Med?
+<p>
+There are many free software projects for certain tasks in medical
+care. Some of them do quite the same job others are very
+different. The Debian operating system provides a rock solid base for
+applications which require security and confidence.
+</p><p>
+So Debian Med uses this base to collect all those fine free software
+for medical care in one place. At first glance it is just for the
+ease of installation and use of the Debian packaging system. But the
+projects also gain profit from the security system, the bug tracking
+system and the wide user base which makes the software popular.
+</p>
+
+<sect1>What is Debian-Med?
+<p>
+Debian-Med is an <htmlurl url="http://www.debian.org" name="Debian">
+internal project to support tasks of people in medical care. The goal
+of Debian-Med is a complete system for all tasks in medical care which
+is build completely on free software.
+</p><p>
+The general idea is adopted from the <htmlurl
+url="http://www.debian.org/devel/debian-jr" name="Debian Junior">
+project. So we provide a set of packages which have dependencies from
+Debian packages which help solving certain tasks.
+</p>
+
+<sect>Documentation
+<p>
+What about documentation in Debian-Med?
+
+<sect1>Which documents are included in Debian-Med?
+<p>
+<htmlurl url="http://localhost/doc/medicine-howto/html" name="Medicine HOWTO">
+</p>
+
+<sect1>What about translation?
+<p>
+Translation of documentation and application interfaces are a main
+goal of Debian-Med.
+</p>
+
+<sect>Sources of information
+
+<sect1>How to get an overview about all Debian-Med meta packages?
+<p>
+Just have a look at the
+<htmlurl
+url="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&ero;subword=1"
+name="packages search form">
+</p>
+
+<sect>Support
+<p>
+<sect1>How can I support Debian-Med?
+<p>
+Search the Web for useful applications and ask for packaging.
+</p><p>
+<sect1>How to ask for packaging?
+<p>
+At first please read the documentation about
+<htmlurl url="http://www.debian.org/devel/wnpp/"
+ name="Work-Needing and Prospective Packages">.
+</p><p>
+File a Request For Packaging (RFP) bug report against the Work Needing
+ans Prospective Packages (WNPP) package.
+</p><p>
+General rule to get something into Debian:
+<itemize>
+ <item>If there is some interest in a program which should be packaged
+ this interest has to be announced first.
+ <item>Two cases:
+ <enum>
+ <item> Request For Packaging (RFP)
+ if you just want to ask other developers to care for a package
+ <item> Intent To Package (ITP)
+ if you want to build the package yourself.
+ You can build the package even if you are not a Debian developer
+ but you have to find a sponsor
+ This is explained very detailed in the <htmlurl
+ url="http://www.debian.org/devel/join/newmaint"
+ name="Debians New Maintainers Guide"> which you should read in
+ any case before starting to build Debian packages.
+ </enum>
+ <item> One way:
+ Use reportbug to announce your RFP / ITP
+
+ <tscreen>
+ <verb>
+ ~> su
+ ~# apt-get install reportbug
+ ~> exit
+ ~> reportbug
+ ...
+ [file the bug against the package named 'wnpp']
+ </verb>
+ </tscreen>
+ <item> make sure you include at least upstream URL and license of the
+ program in the formular if you do not want to get flamed by
+ developers from the debian-devel list
+</itemize>
+
+<sect1>Is it hard to build Debian packages?
+<p>
+Short answer: No.
+</p><p>
+Longer answer: The first thing to read is the <htmlurl
+url="http://www.debian.org/devel/join/newmaint" name="Debians New
+Maintainers Guide"> which contains important information how to
+start. After reading this information a good point to start is
+<tt>dh_make</> which is part of the <tt>debhelper</> tools. Just have a look at
+<tt>man dh_make</>.
+</p>
+
+<sect1>Which software can be distributed by Debian?
+<p>
+Make sure that it has a license which complies with the
+<htmlurl url="http://www.debian.org/social_contract" name="Debian Free
+Software Guidelines (DFSG)">. If you are unsure about the license you
+can ask at the mailing list <htmlurl
+url="mailto:debian-legal at lists.debian.org" name="debian-legal">.
+</p>
+</article>
Added: trunk/packages/med-doc/trunk/failure.htm
===================================================================
--- trunk/packages/med-doc/trunk/failure.htm (rev 0)
+++ trunk/packages/med-doc/trunk/failure.htm 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,2365 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+
+<HEAD>
+
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="copyright" CONTENT="Copyright (c) 1999, Scot Silverstein, MD">
+ <META NAME="description" CONTENT="Typical examples of healthcare IT mismanagement">
+ <META NAME="distribution" CONTENT="Global">
+ <META NAME="keywords" CONTENT="failures,debacles,Informatics,medical informatics,medicine,MIS,clinical computing,management computing,financial computing,management information science,management information services,management information systems,healthcare IT,information technology,territorial issues,politics,organizational dysfunction,expertise,leadership,management,management fad,management mysticism,skill,ability,WWW">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.07 [en] (X11; I; Linux 2.0.36 i586) [Netscape]">
+ <TITLE>Typical examples of healthcare IT mismanagement</TITLE>
+<!-- MetaTags Created by: WebPromote http://metatag.webpromote.com/ -->
+</HEAD>
+
+<BODY text="black" bgcolor="white" link="0000FF" alink="FF0000" vlink="990099">
+
+<BR>
+<CENTER> <table width="95%" cellpadding="5" border="1" cellspacing="0" BGCOLOR="#F3F4E4">
+<tr valign="middle" align="center"><td>
+<FONT FACE="Impact" COLOR="black" SIZE=+2><B>Typical examples of healthcare IT mismanagement</B></FONT>
+</td></tr></table>
+<BR>
+
+<!-- Medical Informatics <A HREF="http://members.aol.com/medinformaticsmd/index.htm">home</A> -->
+
+<BR></CENTER>
+
+<HR><CENTER>
+<table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<BR><FONT FACE="arial">
+Examples of preventable, costly healthcare information technology failure
+<BR>
+<BR><FONT FACE="arial" size="-1">
+As healthcare information technology (IT) becomes increasingly more complex, and
+as it supports increasingly complex medical science and practices, the number of ways that failures
+and mishaps can occur from errors in judgment, inadequate knowledge, mismanagement,
+and related factors increases markedly. Competence, excellent management, logical
+decisionmaking, and the wide-angle view of true <I>cross-disciplinary expertise</I> have therefore
+become imperatives for leadership and success in this field.<BR>
+<BR>
+IT personnel in hospitals often believe that mastery of computers supersedes or actually
+renders unnecessary the mastery of medicine in leading and controlling implementation of clinical
+computing tools. Yet, mastery of applied IT is in large part mastery of process and <I>tedium</I>,
+as opposed to the practice of medicine, which requires mastery of <I>complexity</I>. In other words, applied IT is
+a field of a relatively small number of principles, a large number of arbitrary conventions and rules,
+and a narrow body of knowledge applied repetitively and
+programmatically, often without scientific rigor. This is evidenced by the fact
+that most areas of IT can actually be done well (and often are) by those with little or no formal training.<BR>
+<BR>
+Medicine, on the other hand, is a domain of many difficult, nonintuitive
+principles, experimentally-derived natural laws, and a large body of knowledge applied in a broad, interconnected manner, ideally
+with critical scientific rigor. It cannot be practiced successfully without significant exposure
+to a huge body of biomedical knowledge, and significant practical experience.<BR>
+<BR>
+The belief that
+mastery of IT process and tedium positions IT personnel to lead and control implementation and
+operationalization of tools in complex domains such as medicine (e.g., electronic medical records systems)
+is presumptuous and creates an environment <I>strongly misaligned with the business of healthcare delivery</I>.
+The belief often results in the exclusion or misutilization of medical informatics experts, appropriate clinicians,
+and other forms of mismanagement exemplified in the typical cases below.<BR>
+<BR>
+Unfortunately, there is often a whitewashed quality to publications about healthcare IT regarding these issues.
+I believe, however, that depth of understanding
+of any subject comes from the Hegelian dialectic of thesis and
+antithesis. If you don't consider the negative sides of a domain, you're not
+developing a deep understanding or accurate model of the domain.<BR>
+<BR>
+In addition, such publications commonly offer articles acclaiming the value of IT personnel <I>allowing clinicians
+to participate in clinical systems implementation</I>. Clinician involvement is so obviously necessary that such articles
+might be compared to the New England Journal of Medicine publishing articles on the value of employing anesthesia
+during surgery. A critical reader might question why articles about IT personnel needing to allow clinicians
+to participate in healthcare IT still appear in print.<BR>
+<BR>
+These familiar stories of healthcare IT failure and organizational
+discord reflect, as their root cause, basic <i>mismanagement</i> due to significant inadequacies in organizational
+thinking, structures and support of healthcare information technology. Such technology is vital to healthcare quality
+improvement and prevention of errors. As these stories illustrate, however, this technology is not always treated as such by healthcare
+leadership, including officers at the "C" level (CEO, COO, CIO etc.) and Boards of Directors.<BR>
+<BR>
+It should be remembered that failed healthcare IT projects are not caused by immutable organizational or political issues.
+Importantly, failures are caused by the <U>mismanagement</U> of the organizational and political issues
+and of the <U>people</U> who create the problems associated with these issues.<BR>
+<BR>
+The direct economic costs of such IT failures (often caused by a minority of
+personnel in an organization) is in the millions of dollars per year
+per healthcare organization. The resultant, less tangible costs of lost opportunity and
+are more difficult to quantify, but are probably much greater than the direct losses in the long term.<BR>
+<BR>
+Medical professionals are being held to increasingly stringent standards of quality and accountability at the same time
+they are becoming highly dependent on healthcare IT in taking care of patients. Those who are responsible for healthcare IT,
+including senior healthcare management, have not been held to the same standards of quality and accountability as the
+medical professionals dependent on this critical IT. This needs to change.<BR>
+<BR>
+These stories are dedicated to medical informaticists, whose personnel strive hard to utilize
+computers to improve the quality, science and art of medicine.</FONT><BR>
+<BR>
+
+</td></tr></table>
+<HR><BR>
+</CENTER>
+
+<center><table width="80%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<B><H3>INDEX:</H3></B>
+
+<UL><font face="Arial" size="-1"><B>
+<LI><A HREF="#cio">Problems of basic leadership: dangers of incorrect CIO choices</A>
+<BR><BR>
+<LI><A HREF="#cages">Serious clinical computing problems in the worst of places: an ICU</A>
+<BR><BR>
+<LI><A HREF="#mud">Muddled thinking: a major cause of healthcare's dangerous lag in Y2K remediation</A>
+<BR><BR>
+<LI><A HREF="#better">MIS inadequacies in tough clinical environments: an invasive cardiology example</A>
+<BR><BR>
+<LI><A HREF="#drg">Inadequate data modeling causes Medicare misallocation of billions</A>
+<BR><BR>
+<LI><A HREF="#morse">New technology under tinkerers: how one person can impair progress for entire organizations</A>
+<BR><BR>
+<LI><A HREF="#mac">Disrespect for the needs of clinicians: platform bias taken to an extreme</A>
+<BR><BR>
+<LI><A HREF="#eats">University mistreats its young informaticists, destroying clinical IT and causing an international fiasco</A>
+<BR><BR>
+<LI><A HREF="#emr">Chaos from MIS mismanagement of a clinical information system project</A>
+<BR><BR>
+<LI><A HREF="#lobotomy">Salesperson performs frontal lobotomy on industry healthcare group</A>
+<BR><BR>
+<LI><A HREF="#justice">Insufficient IT management depth results in Justice Dept. investigation</A>
+<BR><BR>
+<LI><A HREF="#trust">Who serves whom: physicians felt completely unnecessary in clinical IT decisions</A>
+<BR><BR>
+<LI><A HREF="#culture">Cultures of mismanagement: toxic to healthcare quality</A>
+<BR><BR>
+<LI><A HREF="#basic">Intranet server or rocket science? A hospital MIS dept. fails on basic tasks</A>
+<BR><BR>
+<LI><A HREF="#thousand">A thousand MIS personnel cannot merge two healthcare systems?</A>
+<BR><BR>
+<LI><A HREF="#nova">The cost of lost opportunity: Medical Informatics can't gain a foothold (4 stories)</A>
+<BR><BR>
+<LI><A HREF="http://home.earthlink.net/~austintxmd/Pages/bad0498c.html#PruRefer">Abusive IT: technology making clinical work more difficult</A>
+<BR><BR>
+<LI><A HREF="http://members.aol.com/scotsilv/0322srmc.htm">A single informaticist could have prevented this South Carolina clinical IT debacle</A>
+<BR><BR>
+<LI><A HREF="#biggest">Perhaps the most significant shortcoming</A>
+<BR><BR>
+<LI>More stories to come - please submit yours by <A HREF="mailto:scotsilv at aol.com">email</A>
+</B></FONT>
+</UL>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="cio"><FONT COLOR="brown"><H3><B>Problems of basic leadership: dangers of incorrect CIO choices</B></H3></FONT></A>
+<P>
+<P><FONT COLOR="black">
+A large hospital in the United States hired a new president who had quite limited knowledge
+of computers. This hospital had previously tried unsuccessfully to implement a hospital
+information system (HIS). The new president set the HIS area as a top priority and hired
+a friend and former colleague whom he trusted as his chief information officer (CIO).
+A flamboyant character to say the least, this new CIO swept into the organization,
+loudly announcing that he had come to bring enlightenment to the technological barbarians.
+<P>
+At the more personal level, he often lamented loudly and long to anyone who would listen
+about the horrors of living amid provincials, far from his beloved and sophisticated home.
+<P>
+After considerable deliberation, the CIO selected a system from a new division of an
+established older company that had no experience in the health care industry.
+Further, the decision was made with little or no user input and with limited
+inputs from the managers of the other major systems with which the HIS had to connect.
+<P>
+The hospital president strongly supported his CIO's choice, and millions of
+dollars were spent on the new system. The systems people were never able to
+get this system to work. One disastrous crash followed another. Finally,
+the hardware was sold for pennies on the dollar, and the CIO rode off into
+the sunrise toward his beloved home.
+<P>
+Incidentally, the same hospital then selected another person to head its computer
+efforts and settled for much more modest goals. Instead of an HIS, the hospital
+implemented a basic hospital accounting system that satisfied its administrative
+needs. However, the clinical staff, with hopes raised by previous wild promises,
+was left unsatisfied and frustrated.<BR>[from <U>Organizational Aspects of Health Informatics</U>,
+Nancy Lorenzi and Robert Riley, Springer-Verlag, 1995.]
+<P>
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+<A NAME="cages"><FONT COLOR="brown"><H3><B>Serious clinical computing problems in the worst of places: an ICU</B></H3></FONT></A>
+<P>
+<P><FONT COLOR="black">
+In an East Coast (USA) tertiary hospital intensive care unit, an electronic patient record and physiologic monitoring
+system was desired by the medical and nursing staff to save time and improve care.
+The MIS department was put in charge of software and hardware
+selection and configuration.
+<P>
+The MIS department by policy only used Compaq computers. Any other computer manufacturer's computer was
+deemed "risky." There were stories of a bug in a model of Macintosh causing
+packet storms and taking down a network. Other computer brands might also have compatibility
+problems and require special drivers (not that this was ever tested). Therefore, Compaq PC's
+were the "one shoe" that would "fit all" needs in the organization.
+<P>
+The ICU rooms were very small. In order to fit the standard-issue Compaq desktop computer into
+such rooms, along with a standard CRT monitor, custom (expensive) cages were designed and ordered so that the
+machines could be <I>bolted to the ceiling</I> of each room. Special custom poles and cabling harnesses were also designed, ordered and
+installed, custom-made to fit each room at great expense. On each pole was mounted a standard computer CRT monitor, keyboard and ordinary computer mouse.
+<P>
+Issues such as air filtration, maintenance, and contaminant circulation from the power supply fans of each machine, heat
+generation from the CRT's, dirt accumulating on the mouse and keyboard, and other ergonomic and medical issues
+were not considered.
+<P>
+Industrial form factor computers (small, convection-cooled or low-air-circulation, and boltable to a wall),
+flat-screen LCD monitors (compact, low-power-consumption, low-heat-producing), easily-cleanable trackpads, and other ergonomically
+better-suited solutions were immediately dismissed with the refrain "we don't support them".
+No such technology was purchased for evaluation. In fact, as it turned out, the MIS system architects had actually never before seen
+a combination keyboard/trackpad that had been off-the-shelf available for a number of years from nearby CompUSA outlets (for about $50 retail).
+<P>
+The ICU system had problems. A clinician hit his head on one ceiling-mounted computer. A monitor
+nearly toppled and caused an injury. Redesign and relocation of the hardware mounting cages and poles had to be
+performed at more expense. The ICU room crowding and tight workstation ergonomics were not appreciated by busy
+ICU personnel.
+<P>
+The system was also repeatedly crashing and an informaticist was finally consulted. The informaticist
+noted the ergonomic problems and recommended solutions, but was resented since the technology
+being suggested (e.g., industrial/clinical computing form factors, track pads instead of mice, and flat screens from a number of
+non-Compaq vendors) were "not supported by I.S."
+<P>
+The informaticist noted portable x-ray machines in
+frequent use in patient rooms, as happens in ICUs, and realized x-ray scatter could be a cause of PC crashes. MIS personnel,
+on the other hand, thought insufficient RAM might be causing the crashes (empirically - there was no
+actual evidence for this) and were set to spend a large amount of money to upgrade each machine.
+<P>
+When the informaticist inquired if the
+computers used parity-checked RAM as a precaution against memory errors caused by x-ray radiation or other factors (a reasonable
+question for an ICU setting), it became apparent to him that the MIS personnel, including the MIS director, did
+not know if the computers were so-equipped, and worse, <I>did not know what parity checking memory was</I> or why it
+might be needed in such a setting.
+<P>
+After this basic question and a lack of response, the informaticist reported the potential problem
+to the head of the ICU. The response of the MIS personnel was to shun the informaticist and say
+non-complimentary things to administration about the informaticist's role and beliefs. The MIS
+personnel assured administration that all computers had the parity feature, and that is was not very
+important anyway since only "satellites in Earth orbit" needed protection from x-rays.
+<P>
+The informaticist pulled a memory module from a machine and found it was an 8 bit, not a 9 bit, module
+and therefore did not support parity checking. However, administration did not believe the informaticist's concerns about
+ergonomics or technical issues such as this, after the assurances and spin from MIS.
+<P>
+It later turned out that neither x-ray scatter nor memory quantity was
+causing these particular crashes. In fact, a vendor software design
+deficiency was found to be causing the crashes. The vendor had designed the system so
+that each individual client workstation was responsible for initiating
+printing of periodic reports on the patient in its room, rather than centralizing this function
+at the server. This introduced a manifold increase in potential points
+of failure and was found to be the major source of the trouble. Significant modifications
+to make the reporting function server-based solved the problem.
+<P>
+This was a design deficiency that the informaticist, who had
+developed significant software in the past, would have
+recognized quickly as suboptimal for a critical care setting such as an ICU in the first place.
+Also, the informaticist still recommended parity memory for any critical care setting as a
+relatively inexpensive legal due diligence. This advice was not heeded.
+<P>
+The informaticist's credibility with administration had been tarnished by MIS.
+The informaticist's concerns about the technical abilities of the MIS department to
+support equipment so closely involved in this critical patient care setting were also
+resented by administration.
+<P>
+Meanwhile, the system proved more costly to support than MIS had predicted, requiring extensive development and customization (over and above
+the inflated costs of the fancy mounting accouterments), since it was immature, not entirely reliable, and user-unfriendly.
+One very valuable system feature, the severity scoring system,
+was never enabled. That feature might have allowed patients to be transferred out of the ICU earlier, saving
+a significant amount of money.
+<P>
+The system struggled with proving a return on investment, was nearly canceled
+after a year, and was given a "try-it-for-one-more-year-but-prove-the-ROI" reprieve only after
+a large degree of pleading and politicking by key personnel (including the informaticist). Its future
+is uncertain, plans to spread the technology to other ICU's in the organization were canceled, and
+administration has been needlessly "turned off" to this type of technology.
+<P>
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="mud"><FONT COLOR="brown"><H3><B>Muddled thinking: a major cause of healthcare's dangerous lag in Y2K remediation</B></H3></FONT></A>
+<P>
+<P><FONT COLOR="black">
+An overworked, understaffed hospital MIS department suffering from generally low morale was trying to gear
+up to fix the organization's Y2K problems, well-aware of the berating being done by the government
+(e.g., Sen. Dodd of the special Senate Subcommittee on Y2K) about the unpreparedness and liability in healthcare.
+<P>
+An informaticist who was concerned about the MIS department's ability to handle this challenge alone suggested
+at a meeting that bringing in an IT consulting company such as CSC, EDS, or the like who've formed Y2K divisions
+would be very prudent. Several industry senior CIO's also acting as consultants in IT to the organization agreed
+with this at the meeting. The response from the senior executive overseeing MIS in this hospital (himself having no
+background in information technology whatsoever) was that "We know how to handle these things best ourselves,
+consultants will only slow us down" and "I'm not enthusiastic about fixing the Y2K problem, since it will utilize
+resources and detract from our mission to serve the community." (?!?)
+<P>
+The top executives were informed by the informaticist that such attitudes were potentially reckless
+or even catastrophic in view of dire, almost daily warnings from many sources about healthcare's
+unpreparedness in Y2K, risk to the community, liability that could extend into the hundreds of
+billions of dollars, and other factors. The informaticist also told them of a number of "train
+wrecks" he'd <I>personally</I> seen that occurred due to similar attitudes. Somewhat like noncompliant
+patients ignoring a physician's expert advice, however, the top executives were
+concerned mainly about whether the "proper process" had occurred at the meeting and did not revisit the
+meeting's decisions, e.g., concerning Y2K consultants.
+<P>
+The Ivy League-trained informaticist was frightened by the disdain of the leadership
+towards such matters. Further, the informaticist realized that there was a literal abyss between the
+thinking in informatics about rigor, science, and best engineering practices, and the cavalier thinking of this
+organization's management towards information technology. The informaticist left this organization shortly thereafter.
+<P>
+Many months later, this organization now finds itself so starved for resources and scrambling to accomplish Y2K remediation by itself, that
+virtually all other computing projects, especially clinical computing projects serving clinician's needs, have been halted or
+postponed. Even minor improvements to existing clinical applications have been stopped so that "MIS can devote all its efforts
+to Y2K." In an unfortunate illustration of cascading dangers that occur when critical healthcare IT issues are mismanaged by
+technology-unlettered executives, clinicians at this organization no longer have expert informatics assistance,
+their clinical IT projects have lost significant momentum and have been marginalized, and their needs are being neglected.
+<P>
+Needless to say, all of this has not helped the morale and image of the MIS department.
+<P>
+<U>Postscript</U>:<BR>
+The company that produces this organization's HIS (hospital information system) and other critical
+information systems has just been sued for securities fraud involving the misreporting of finances.
+The company has also been named as defendant in a multitude of shareholder
+<A HREF="http://biz.yahoo.com/n/m/mck.html">class-action lawsuits</A>. This may diminish the company's ability to assist its
+clients with its HIS and other information systems.
+<P>
+It should probably be noted that the people responsible for the financial problems at the company are business and financial people,
+the same occupational background as those at this hospital who decided to ignore the informaticist on bringing
+in outside help on Y2K remediation as early as possible. (The informaticist believed in a rigorous
+approach to critical, unpredictable problems such as Y2K, and in optimizing resources to guard against unexpected contingencies.)
+The scenario just mentioned could have become a spectacular example all-around of the wrong people making the wrong decisions
+for healthcare at an <U><I>exceptionally</I></U> wrong time.
+<P>
+Now that January 2000 has come without apparent major interruptions in computer services,
+the news media is reporting the Y2K bug "squashed" and appear to be insinuating that the problem was
+severely exaggerated. This is being done even in the face of hundreds of billions of dollars having been spent
+in remediation of important systems known to harbor flaws. The flaws would have made important applications
+such as financial systems or HIS's (hospital information systems) inoperative or erroneous.
+<P>
+The Loma Linda (Calif.) Medical Center offers a different perspective. An experiment conducted there after Jan. 1
+is illuminating. Out of curiosity, IT personnel at this 653-bed hospital did nothing to upgrade
+an existing billing system that was being phased out. After the Y2K transition, financial transactions
+were fed into the old system. "Everything it produced was wrong; it had gotten completely confused,"
+said CIO Bob Blades. "We're just grateful we upgraded everything else" (Modern Healthcare, 1/31/2000, p. 40).
+<P>
+This bizarre conclusion ("on the basis of not having experienced problems, we conclude there never was a problem")
+is a sad commentary on the ability of many to think rationally and make sound judgments on
+complex technological issues.
+<P>
+In another footnote, the organization that is the subject of this story also survived the Y2K transition,
+but at the cost of several years' needless delayed progress in clinical computing initiatives. Yet, the administration
+of this organization has been touting the Y2K effort as "a clear example of Unsurpassed Excellence." This statement comes
+at the very time the U.S. Government is considering legislation on the medical errors problem, which will undoubtedly
+result in the need for significant advancements in clinical IT.
+Such puffery, <I>word hyperinflation</I> and blind self-aggrandizement are characteristic of many hospital and MIS bureaucracies.
+<P>
+</td></tr></table></center>
+
+<HR>
+
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="better"><FONT COLOR="brown"><H3><B>MIS inadequacies in tough clinical environments: an invasive cardiology example</B></H3></FONT></A>
+<P>
+<P><FONT COLOR="black">
+The chief and clinical staff of a busy invasive cardiology (cardiac catheterization) lab at a large American tertiary care hospital, responsible for a significant
+percentage of the hospital's revenues, desired a data collection system to
+improve performance and outcomes, perform benchmarking, reduce dictation, increase efficiency of clinical communications, and
+end expensive inventory spoilage or risky shortages. The hospital's MIS department was
+engaged to assist the cardiac catheterization lab in this information technology need.
+<P>
+From the very start, the project suffered from severe mismanagement by MIS and by senior hospital executives.
+<P>
+The MIS deparment spent almost two years going through analysis, market investigation, K-T decision grids, and other business "process"
+before deciding on a product to purchase. What they were doing during this time is unclear, as there are
+very few vendors offering products for this environment. In-house development was ruled out by MIS as unnecessary
+and not consistent with an MIS policy of "turnkey solutions only," despite several senior cardiologists feeling
+that customization would be critical. Such <I>one shoe fits all</I>, business computing-oriented thinking is
+symptomatic of the shallow understanding of clinical medicine that's often found in healthcare MIS departments.
+<P>
+After purchase, the vendor product sat unused for almost a year before operationalization was
+considered by MIS. When it was finally decided to implement the package, muddled thinking and gross underestimation of the resources
+needed resulted in only 0.75 FTE's assigned. Even worse, the MIS person chosen had no experience working in
+tough, high-volume, critical care areas.
+<P>
+A Steering Committee was initiated, led by a new, very competent cardiac administrator who was unfamiliar
+with information technology. It soon became apparent that the MIS personnel did not understand
+the clinical environment and culture of a cardiac catheterization laboratory. MIS was adamant that
+the vendor product should not be modified, an "appliance operator" mentality, even
+though the clinicians wanted the data and workflow components of the package to be adjusted to their
+busy clinical environment and customs (rather than the other way around).
+<P>
+Conflicts began. The MIS department began to blame the physicians for being "non-cooperative" with them,
+stubborn, unable to finalize decisions about the package, and responsible for lack of project progress.
+The cardiac administrator was blamed for "not controlling the doctors", representative of this organization's
+somewhat unreasoning attitudes towards its life blood, its clinicians. (Unfortunately, to use a medical metaphor,
+while this genre of negative behavior by a healthcare organization towards its clinicians may "feel good"
+to executives in the short term, in the long term the consequences are usually deleterious to organizational health.) MIS insisted that
+the cardiac administrator take "ownership" for the project, and assume the role of clinical champion.
+The cardiac administrator tried to understand the issues, but without expertise in information
+technology was highly dependent on the MIS personnel for guidance on any technical issue. MIS itself
+could not provide significant guidance as they were in over their heads in such a clinical setting.
+<P>
+The clinicians began to realize that MIS had greatly understaffed the project, and that MIS resources, skills, and understanding of the environment were inadequate for
+the job. Further, their requests for MIS to perform customizations of the application to match their culture and
+environment were met with jargon-heavy reasons why it "couldn't be done".
+<P>
+The attempted install in the cath lab went so poorly, and was so misaligned with needs,
+expectations, work flow, and the tremendous patient responsibilities, that the demoralized and frustrated cath lab staff
+demanded in a hostile tone that the MIS people "GOMCL" (get out of my cath lab!)
+<P>
+Blame for the project paralysis and failure was shifted by MIS to the cardiac administrator and clinicians,
+using convincing-sounding language about process, ownership, nurturing, mentoring, feelings, and other impressive-sounding
+but shallow and almost mystical <I>puffery</I> and <I>rhetoric</I>. This made the clinicians, used to directness
+and action, even angrier. An outside consultant was brought in for several days,
+but could not resolve the difficulties between MIS and the clinical staff.
+<P>
+An informaticist was then hired as an "internal consultant" (instead of as leader, itself symptomatic of a "control pathology" existing
+in this organization's executive team), after a senior executive found out about the existence of such
+specialized personnel. The informaticist asked to see what had been installed in the cath lab by MIS.
+The informaticist found workstations running the application under Windows 3.1, an unreliable platform
+especially unsuited for critical care environments, because "Windows NT and other OS's such as UNIX were not supported by MIS."
+When shown a short demo of data entry by a nurse after a cardiac cath case, the workstation
+crashed, displayed a "general protection fault" error and hexadecimal debugging data. It had to be rebooted, with resultant time and data loss.
+<P>
+The informaticist asked the nurse about the crash and was told it happened frequently, up to several times
+per day per workstation. When the informaticist asked if MIS had requested a detailed log be kept of the crashes and
+error messages to help resolve the problem, the answer was no. MIS felt diagnosis and repair was the vendor's responsibility.
+When the informaticist asked the nurse exactly what had been explained to clinicians about the crashes, the nurse replied that cath
+lab staff had been told by MIS "<I>don't worry about it, you can't understand it, we'll make it better</I>."
+<P>
+The informaticist remembered, from medical school and residency, being told never to say such a thing
+to patients as it was considered inappropriate and too paternalistic in the modern age of medicine,
+especially with the elderly. This was an ironic and somewhat bizarre scenario, the informaticist thought.
+<P>
+The informaticist set out to correct the problems, although the path ahead proved challenging even with informatics skills.
+Workstations were asked to be changed to NT to ensure reliability. The informaticist was first told that the application
+would probably not run under NT, and that it also needed "RAID disks" (an intimidating buzzword to must physicians) to run. The informaticist
+replied that RAID, a hardware-based continuity and disaster recovery measure, was an operating system issue, not an application issue, and that testing the
+application under NT would be easy. Testing would end the need for speculation and debate, he also said. The informaticist requested that two ordinary business PC's be set up
+in a test environment on a table, one PC to run the server, and the other to run the client under NT to test compatibility.
+<P>
+Upon realizing that this doctor was technically knowledgeable, MIS moved the production application to NT in a few days
+and thereafter it ran quite reliably. Under the informaticist's insistence, against political resistance from MIS and operations
+who seemed more concerned with appearances and "process" then with supporting the cardiologists ("results"), the staffing was increased.
+Four had been requested, and a compromise of three was reached. The informaticist was able to hire a new MIS manager based on the informaticist's
+beliefs about proper abilities, skill set, insights, and personality fit (e.g., a "can-do, when do you want it?" attitude)
+in the dynamic cath lab environment. This new manager had leeway to act independently to a large degree from the corporate MIS department.
+The new MIS staff in the cath lab were able to function as a decentralized, more flexible, local "island" of MIS support for the cardiologists.
+<P>
+The informaticist first created a collaborative and <I>participatory</I> work environment between the new MIS cath lab personnel, the cardiac
+administrator, and the cardiologists, a non-traditional methodology in MIS but <b>crucial</b> for clinical computing settings
+(see <A HREF="http://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query?uid=9524350&form=6&db=m&Dopt=b">Participatory Design of Information Systems in Healthcare</A>,
+Sjoberg C, Timpka T: Journal of the Amer. Medical Informatics Assoc. 1998;2:177-183).
+<P>
+Next, the informaticist jettisoned the customary, stale MIS approach of viewing a person's skills
+in using a specific database application (e.g., Oracle) as a critical factor. The informaticist
+identified as crucial the data modeling process for the cardiologist's needs. This process
+has <I>very little to do with software or computer science and much to do with medical informatics</I>.
+The finest technical expert in the world in database development systems such as Oracle, client-server tools, etc. is not very useful in
+such a function, since it is a high-level cognitive function requiring clinical experience combined with medical data modeling expertise,
+<I>not</I> computer or MIS expertise. The lack of recognition of the need to partition high-level, cognitive informatics functions such as healthcare data modeling from more
+mundane, low-level programming and implementation tasks in clinical projects inhibits progress in healthcare and biomedical IT.
+<P>
+<B>It is with amazement that informaticists such as the one in this story observe a blindness to this issue in
+biomedicine</B>, including healthcare and pharmaceuticals. The <I>highest</I> levels of informatics expertise should
+be sought for any clinical initiative in busy clinical settings. In such settings, the data development and customization
+process is an essential competence.
+<P>
+Once the critical cardiology data set and data definition issues were on the mend with the informaticist's expert assistance, the group was then able to customize the application data set and work flow components, and
+within several months, regular and reliable data collection and reporting had begun. In fact, the cath
+lab staff began to get more involved in the customization process and the designing of reports, and started to find
+the process intellectually challenging, educational, and sometimes even fun.
+<P>
+Perhaps even more importantly, the informaticist re-framed this project from one that could be perceived solely as a negative "report-card"
+system about the cardiologists, to one that would enable them to meet their own data needs and interests (e.g., for
+research, domain-specific and new-device specialty areas, education, and other topics). In doing so, the standard vendor-supplied package
+was only used as a 'vehicle' or starting point for the project, while dataset customizations almost completely replaced
+the supplied vendor "internals". In modeling the data of such a complex field in an optimal manner, the value of
+the medical informatics discipline was very apparent.
+<P>
+Further, in operationalizing the system, the informaticist made sure that a large degree of effort went into creating tools
+to allow replacement of dictation, often a time-consuming process in invasive cardiology, with
+a computer-generated case report. A very creative, intelligent, computer science-minded programmer was carefully selected by the informaticist
+to code the tools to create this capability. (The informaticist here did not believe all programmers were created equal.
+As author Bob Lewis points out in his book <U>IS Survival Guide</U>, Sams Publishing, 1999, p. 247, three decades ago Harold Sackman researched the
+performance gap between programmers. He found that the best ones were able to write programs 16 times faster
+and debug then 28 times faster than those created by "average" programmers, and when they were done their
+programs were six times more compact and ran five times faster.) In a field as critical and complex as medicine,
+the need for star performers is especially acute. This is hard to detect from a resume. Informaticists who
+know both medicine and computing are often especially good at identifying such programmer qualities, for example through
+interviews.
+<P>
+Medical Records and transcription were also strongly involved to
+enhance the cardiology computer system so that addendums, if needed, could be flexibly
+dictated and added to the computer-generated report on a section-by-section
+basis. Another area requiring significant effort was automation for FAXing computer-generated reports on a timely basis to referring clinicians
+and to electronically send reports to a central clinical data repository for viewing at workstations
+in the medical center. This "value added" approach to the project, strongly supported by the cardiac administrator, proved crucial. It helped win physician support,
+since it had the potential to save them significant time and labor while increasing their accuracy and timely
+communications with referring colleagues.
+<P>
+The cardiac administrator, an extremely capable and forward-thinking individual, learned a lot
+about medical informatics and its value as a specialty, and many fine points about the innocuous-sounding but unprecedentedly difficult
+task of defining precise, fine-grained data to model an area as complex as invasive cardiology. Unfortunately, in the opinion of the
+informaticist, the cardiac administrator had become somewhat of a "scapegoat" for deficiencies of MIS and senior executives in
+understanding clinical computing issues, and had lost a bonus (and much peace of mind) as part of the lesson.
+<P>
+<U>Postscript:</U><BR>
+This heart center information system in its first two years of operation has allowed this organization to save well over a
+million dollars in cath lab operating costs, through stronger contracting, efficient equipment stocking and utilization, etc.
+<P>
+Despite this, in an unfortunate example of the suboptimal management that can result from unqualified decisionmaking
+in a discipline as complex as healthcare computing, the senior executive assigned to oversee both
+clinical operations and IT (despite lack of a background in IT) now refuses
+to allow the chief of cardiology at this hospital to sit on the organization's
+strategic information technology committee because the cardiologist is "uncooperative and an obstructionist" (i.e., he
+thinks critically and does not simply follow orders from the non-medical executive in question).
+<P>
+This accusation and exclusionary decision was made despite the cardiologist's now probably being the most informatics-savvy in the organization after
+intensive collaboration with the informaticist, who has since moved on. This has once again infuriated
+the cardiology staff, who are one of the largest revenue-generators for the organization amidst a sea
+of potential competitors and declining revenues due to recent government regulation cutting Medicare
+reimbursement (Balanced Budget Act). This type of executive behavior should not be tolerated in hospitals.
+<P>
+Further, after years of being non-helpful to this project, the same senior executive
+now tells other executives he "does not see the value of the data", that the informaticist was "way out there", and that the physicians are wasting money.
+This executive clearly has both feet firmly planted in the Stone Age.
+As was recently observed in a book about business practices, only those interested in the future build tools.
+Whatever they might say, those who build few tools are not interested in the future
+("Building Wealth", Lester C. Thurow, HarperCollins Publishers, 1999).
+<P>
+This senior executive's opinions flew in the face of an evaluation by invasive cardiology
+experts of national prominence. These experts rated the data project
+"<I>extremely important</I>" and "<I>an exceptional initiative</I>" during an independent
+evaluation of the facilities, requested by the cardiac administrator for performance improvement purposes.
+<P>
+Those truly interested in improving healthcare and <I>reducing medical errors</I> must critically evaluate the obsolete,
+defective organizational structures that allow <I>medically and technologically-unknowledgeable persons</I> to domineer
+qualified, competent professionals on such data initiatives.
+<P>
+This story illustrates one danger to clinicians and to patient care of permitting non-clinician business personnel to take charge
+of clinical matters. The business personnel, often more politically-savvy, may then engage in behaviors
+to call attention away from deficiencies and shift blame for problems onto the clinicians. Clinicians must
+stand up for progressive and constructive behaviors from management on clinical information technology in the service of patients.
+<P>
+It should be noted that invasive cardiologists and other such subspecialists are necessarily quite tough.
+As one of my mentors, Dr. Victor P. Satinsky (inventor of the Satinsky clamp used in cardiac surgery, among many other things)
+used to say about his tough training programs, <I>"If you don't like it, don't come."</I> MIS personnel and executives who are
+unqualified or uncomfortable with the rigor required in such demanding clinical environments should find positions elsewhere,
+in simpler settings, rather than engage in politics that obstructs technology used to improve patient care.
+<P>
+Finally, in an example of the Peter Principle running amok, the bright cardiac services
+manager decided to leave the organization after being passed up for
+promotion, while those who had impaired this project and numerous other projects through illogical thinking,
+clinging to the past, and various other mismanagement flavors (at great waste of money) received generous promotions.
+<P>
+Sadly, it is clear this organization <I>learned nothing</I> from medical informatics.
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="drg"><FONT COLOR="brown"><H3><B>Inadequate data modeling causes Medicare misallocation of billions</B></H3></FONT></A>
+As a striking illustration of the potential dangers of inadequate data modeling, insufficient granularity in
+Medicare's current system of diagnosis-related groups (DRG's) has caused
+revenue shifting over the past decade away from cash-starved urban medical centers to smaller facilities.
+Many billions of dollars are involved. This revenue shifting is due to the fact that the current 491 DRG categories
+<I>do not adequately capture the differences in severity
+of illnesses within a single DRG</I>, resulting in underpayment to some providers (i.e., those that have
+the capability to handle very sick patients, often transferred from small facilities) and overpayment to others
+(small facilities that keep the simpler cases).<BR>
+<BR>
+In fact, it is proposed that the number of DRG's be increased by almost one hundred percent,
+to a total of 900 groups. This reflects not an adjustment, not an iterative change, but a stunning complete overhaul of a defective DRG system.
+It is especially important to note that healthcare has not recently doubled in its complexity!
+(See "<A HREF="http://www.modernhealthcare.com/currentissue/topten02.html">Panel may support doubling of DRG’s</A>", <I>Modern Healthcare</I>, 31 Jan 2000.)<BR>
+<BR>
+Such problems are complex, and it may be unfair to say the DRG situation might have been prevented.
+However, it is clear that correct modeling the medical world is not a process of "luck." The highest
+levels of medical informatics expertise must be deployed appropriately (in leadership roles) in
+organizational or national data initiatives that determine resource allocation, best practice determination,
+drug development, compensation, and other major healthcare decisions.<BR>
+<BR>
+Yet, advertisements for healthcare and biomedical data project leadership often appear similar to the following:<BR>
+<BLOCKQUOTE><font size="-1" face="arial">
+"Data Architect: As a leader in data modeling and development for the company, this position entails
+supporting software development activities and internal database usage.
+Primary responsibilities logical and physical data modeling, data application development,
+supporting of R&D projects through the vending of data services (SQL development,
+data transformations, database design & development, etc.), and limited DBA functions.
+Candidates must have real experience in database design (1-3 yrs), advanced SQL (2+ yrs),
+implementing concurrent large distributed databases, dimensional data modeling, developing
+data-driven applications, and the ability to work on a team. Additionally,
+knowledge of Oracle 7+ (UNIX & NT), and Business Objects WebIntelligence Query tool,
+are highly desirable. Requires a BS in IS, or equivalent."
+</font></BLOCKQUOTE>
+Skills in medicine, healthcare, or any biomedical field are considered optional or unnecessary.
+As in the example above, often only a bachelor's degree in "Information Systems" is called for.
+Unfortunately, optimal healthcare data modeling requires a background in <I>both</I> biomedicine and
+information science. Specific software or hardware package experience is far less important,
+yet this is usually unrecognized in the job formulation and hiring process.
+(It should also be noted that experience in <A HREF="ccmc.htm">management information systems</A> is <I>not</I> the same
+thing as experience in information science and scientific computing).<BR>
+<BR>
+<I>The common blindness to the primacy of the medical modeling process</I>
+over specific software and hardware skills in hospitals, industry and government is astonishing to many medical informaticists.
+They understand that medicine is of unparalleled informational complexity, and that mis-categorization or mismodeling of the healthcare environment
+can have significant, unexpected consequences on an individual, organizational or societal scale.<BR>
+<BR>
+Such blindness usually stems from a common business and MIS belief that "medical data is
+like everybody else's data" and that "if it's data, we can do it." Instead of
+selecting individuals optimally, high-level cognitive abilities such as biomedical data modeling are sacrificed for
+fluency with the latest whiz-bang software platform. Interestingly, the business and MIS leaders who adhere to such beliefs
+and practices almost always have no clinical experience or training.<BR>
+<BR>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="morse"><FONT COLOR="brown"><H3><B>New technology under tinkerers: how one person can impair progress for entire organizations</B></H3></FONT></A>
+<P>
+<P><FONT COLOR="black">
+This story comes from a major U.S. academic institution. The informatics director, a <A HREF="taxonomy.txt">tinkerer</A>
+and <A HREF="bully.htm">bully</A> with major political connections, usually got his way at a major academic teaching hospital.
+The director believed himself an expert on all aspects of computing and communications.
+<P ALIGN="LEFT">
+The director was asked to perform a demonstration to V.I.P.'s of voice and visual communication for telemedicine applications
+over the campus computer network. This person knew there were experts on staff in telecommunications and in this area in particular,
+including an informaticist on his own staff with significant amateur radio expertise, including slow-scan and fast-scan television.
+<P ALIGN="LEFT">
+Rather then engage these individuals and share the spotlight, this director created a demonstration without such
+expert assistance. Small cameras were hooked to two computers, one in the campus library where the demo
+was to be performed, another in an office across campus. Simple communications software was installed. Minimal
+testing was done since "unless the network was down, nothing could go wrong."
+<P ALIGN="LEFT">
+At the demo, the software was started while a dozen or so senior leaders in the organization observed. The first
+few moments went well, with the director in the library talking to his wife in the office across the campus.
+However, the demo was performed in the early afternoon, during a time of peak network traffic. Network delays started
+to cause pauses in transmission and reception. When it appeared one party had finished speaking, the other
+party would begin, only to be interrupted by the completion of the first party's transmission.
+<P ALIGN="LEFT">
+These "packet collisions" continued for several minutes and made meaningful communication of even
+simple information difficult and frustrating. The assembled V.I.P.'s got a very bad first impression
+of this technology, and first impressions are very, very important (especially with non-technical
+people who are responsible for funding of new technologies).
+<P ALIGN="LEFT">
+At the wrap-up discussion of this demonstration, the embarrassed director-tinkerer concluded that the technology was
+immature and may not yet be ready for fruitful use until higher network speeds were available. This
+discouraged those in the audience who hoped this would be a good technology for medically-underserved areas in the poorer
+rural communities of this state.
+<P ALIGN="LEFT">
+The informaticist amateur radio expert in the audience begged to disagree and stated that a simple communications protocol could
+suffice to facilitate use of the technology, even under heavy traffic situations. He explained that
+a mutually-agreed upon protocol of saying "over" (or similar acknowledgment) to signal the end of a statement would be a foolproof
+mechanism to prevent collisions.
+<P ALIGN="LEFT">
+The director responded in a sarcastic manner that this was a 'ridiculous idea', that he would never say things like 'roger, over', and that others would feel the
+same way in the age of fast communications. The amateur radio enthusiast replied that this was not the case. He pointed out that
+radio operators had been using such protocols for almost a hundred years, especially with Morse Code or any form of half-duplex communication such
+as radioteletype or voice. A senior member in the audience, the medical school educational computing director, agreed with the radio expert about this,
+himself knowing a bit about telecommunications, but the audience still left the demonstration quite disappointed.
+<P ALIGN="LEFT">
+Unfortunately, the amateur radio expert was to learn the problems with challenging someone politically well-connected,
+and not surprisingly no longer works for that organization. <P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="mac"><FONT COLOR="brown"><H3><B>Disrespect for the needs of clinicians: platform bias taken to an extreme</B></H3></FONT></A>
+<P>
+An informaticist who was consulting with a large east coast hospital was called by the Chairman
+of the Department of Medicine about a very frustrating problem that had been ongoing for
+about two years.
+<P>
+The Chairman was not knowledgeable about computers but had purchased a
+home Apple Macintosh computer several years before to perform useful tasks
+such as word processing and medical information searches. It was a PowerPC-based unit,
+which he thought was handsome and fit well with his home decor.
+(Perhaps even more importantly, it had obtained spousal approval.)
+<P>
+The MIS department of his hospital had adopted a strict "PC only" rule, however.
+All connections into the organization, whether to the mainframe or other GUI-based
+clinical applications, were via PC-based terminal emulator software or winframe applications.
+<P>
+The Chairman of Medicine liked the Mac at home and did not want to install a second computer, a PC,
+into his home for hospital connectivity. The MIS department "did not do Macs" and therefore
+would make no attempt to look for Macintosh applications or emulators that could allow this
+physician to connect to the hospital network. MIS leaders told senior executives that making the
+Chairman's Mac connect to the hospital network was impossible. They would not even touch the Macintosh. Stalemate.
+<P>
+The Chairman had, on his own, obtained a PC-on-a-board for the Macintosh from a well-established third-party
+vendor, Orange Micro, but did not have the experience to install it. The MIS department was adamant
+that this could not work, that any PC emulator would have bugs, that it could not
+reliably run the PC software used for hospital connections. They refused to assist
+the Chairman of Medicine install his purchase. This was certainly not good for intercultural
+relations between MIS and the clinical staff. The Chairman turned to the informaticist
+for assistance.
+<P>
+The informaticist, not being a platform religionist, was proficient with both the PC and Mac platforms
+and the third-party add-on. He explained to the MIS department leaders that the add-on
+board was a complete PC, with its own Intel CPU, memory, serial ports, etc. running native
+Windows. The Macintosh would just share the keyboard, disk drives, and cabinet, and that
+this board would turn the Mac into a true PC when it was operational (a "MacCharlie", to
+those who remember the mid-1980's). The add-on was an industry standard itself and
+would convert the Chairman's Macintosh into a 'PC living in the Mac box', he said, with
+a great chance of success in running the needed telecommuniations software.
+<P>
+The informaticist stated he was going to attempt to install the third-party board and
+wanted MIS support. The MIS personnel remained adamant. They felt such a contraption
+could never work, that a Mac would not be compatible, that even if it were a "PC in Mac clothing" it
+was not the Standard Vendor Brand PC they utilized exclusively, that they don't support Macs.
+MIS still refused to touch it, as if it was a heresy. In fact, they never researched the third-party
+add-on board, showing one basic difference between clinical and MIS culture. Clinicians are used to
+researching new potential clinical tools and treatments.
+<P>
+MIS somewhat sarcastically wished the informaticist luck,
+and hoped it "all worked out." Behind the scenes, as the informaticist discovered,
+the CIO ridiculed the informaticist to other senior executives, wondering aloud where the
+informaticist "gets the time" for such adventures. The informaticist could not fathom
+how assisting the Chairman of Medicine in such a basic need could be trivialized in such a
+manner and obviously felt such behavior highly inappropriate.
+<P>
+This behavior is symptomatic of irrational thinking. The Chairman of Internal Medicine is
+an absolutely key leader in the difficult cultural transition of a hospital's physicians
+to electronic medical records, computerized order-entry, etc. The undivided support
+of such key medical leaders is <I>absolutely crucial</I>. This CIO represented himself as
+a religiously-devout person who nonetheless took pride in admitting his work-world philosophy
+came from the ancient Chinese book "The Art of War", perhaps indicating an ability to <I>rationalize</I>
+that tragically exceeded by a wide margin the ability to <I>think rationally</I>.
+<P>
+The informaticist installed the new board into the Macintosh, installed MS-Windows, and had the
+communications software installed and operational in a few hours. The MacCharlie was now able,
+with a single keystroke, to appear as either a Macintosh or a fully-functional PC. Compatibility
+with the communications software was not an issue and the Chairman now "had his cake, and could eat it, too." So ended several
+years of frustration for the Chairman.
+<P>
+The only gratitude received by the informaticist was from the Chairman of Medicine,
+although other executives in the organization (acclimated to an MIS culture representing
+computers as mystical) thought of this trivial, teenager-level accomplishment as something of a miracle.
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="eats"><FONT COLOR="brown"><H3><B>An International fiasco: University mistreats its young informaticists, destroying clinical IT</B></H3></FONT></A>
+<P>
+This story of wasted opportunity, attempted misappropriation of intellectual property, ethical and legal improprieties perpetrated
+by senior university officials, and academic suppression and dismissal comes from the Yale University Center for Medical Informatics. It is a good example
+of the losses to the healing arts that result from organizational dysfunction. It is also a story about
+a rare victory of a "little guy" over the powerful "Old Boy's Club."
+<P>
+<blockquote><font face="arial" size="-1">
+(The story is also a detailed, blow-by-blow illustration of
+academic "Bahramdipity," a term coined to describe
+autocratic academics (<A HREF="http://www.the-scientist.library.upenn.edu/yr1999/feb/opin_990201.html">'Bahramdipity'
+and Scientific Research</A>, <I>The Scientist</I>, T.J. Sommer, Volume 13, #3, Feb. 1, 1999).
+Bahramdipity is the suppression of a discovery by the
+often-egomaniacal acts of a more powerful individual who does cruelly punish, not merely disdain,
+a person of lesser power and little renown who demonstrates sagacity,
+perspicacity, and truthfulness. From a story about Bahram of Persia in the fairy tale <I>The Three Princes of Serendip</I>.)
+Also see a similar story of academic abuses at <A HREF="http://www.justice4t.org.uk/"">http://www.justice4t.org.uk/</A>.
+</font></blockquote>
+<P>
+An informaticist (the first of two in this story) volunteered to take a position as
+Director of Clinical Informatics for Yale-New Haven Hospital to help customize a new computer
+order-entry system. The hospital's leadership had decided to mandate the electronic order-entry
+system for all patient orders, completely replacing paper. It was announced that any physician
+who would not use this system "could leave the organization." A mainframe-based system
+was purchased and a huge team was assembled to operationalize it throughout the hospital
+at a cost of tens of millions of dollars.
+<P>
+As the system was implemented and tested, it was realized that as delivered, the system
+was not easily usable in this hospital's environment due to workflow fit, nomenclature,
+grouping of screens, and many other issues involving features and functionality.
+The informaticist was enlisted to customize the thousands of screens, screen relationships
+and screen flow (logical arrangement of screens), order sets, data, and so forth.
+The informaticist was to report to two bosses: hospital MIS and University informatics.
+The territorial issues of working in an MIS department, and the precarious position of
+reporting to two bosses, were bad enough, but did not prove to be the biggest challenge.
+<P>
+This informaticist spent over a year spearheading and overseeing the revisions to the order-entry
+system. Even after this extensive work, because the system was simply mandated by administration,
+the extra time, effort and work required to use the system was strongly resented by many staff
+and attending clinicians, and unfortunately this resentment was targeted to a great extent on the
+most available and vulnerable target, the informaticist. One senior physician actually
+refused to attend any meeting where the informaticist was present, another threw pencils
+at the informaticist after an argument, and the informaticist's name came up in a very negative
+manner among the house staff who spoke as if they wanted to burn him in effigy (if not literally).
+The medical leadership of the medical center were not very sympathetic nor supportive to the
+informaticist.
+<P>
+Despite a successful technical implementation of the order-entry system, the sociological
+ramifications and negativity experienced by the informaticist caused him to resign suddenly.
+After six months of purposeful unemployment for R&R, this informaticist took a position
+outside both academia and hospitals, with a healthcare IT vendor.
+<P>
+Meanwhile, another faculty informaticist at the University who had been working on electronic medical
+records was approached by the hospital's senior medical leader, Ed Cadman (a person who was both Chief of Staff and Senior VP for
+Medical Affairs, and had been the former Chairman of Internal Medicine) to take over the role of physician liaison and Director of Informatics
+at the Hospital. This informaticist had a background very similar to the first informaticist,
+including a Medical Informatics postdoctoral fellowship at the University, and was working on clinical IT for a complex
+research setting in Saudi Arabia.
+<P>
+The second informaticist began a series of formal interviews with Chief of Staff, clinical leaders and MIS.
+The interviewers were pleased with the results of the interviews. The Chief of Staff then wrote
+a letter to the informaticist stating that he would be "<I>delighted to create a position
+for you...the organization needs people with your skills and commitment</I>."
+<P>
+The Chief of Staff also promised the informaticist that the new
+position would be structured so as to avoid the problems experienced by the departed predecessor.
+A reasonable salary level was negotiated and agreed upon. The Chief of Staff informed the
+informaticist that the hospital had extensive funds for expert resources to ensure this project
+was a success. In addition, the position was to report to this Chief of Staff himself, not to
+MIS or to the academic Informatics department head. The informaticist was also told the Informatics
+department head, Perry Miller, was "overcontrolling" and had problems getting along with people,
+and such behaviors had been a strong factor in the resignation of the original hospital Director of Informatics.
+<P>
+The informaticist, a person of high standards who believed strongly in collaboration and fairness,
+attempted to defend Dr. Miller, saying that perhaps various
+territorial issues were causing him anxiety.
+<P>
+The informaticist defended his boss despite earlier signs of exactly the behaviors mentioned by the
+hospital Chief of Staff. Miller once coldly asked the informaticist how he could "get rid of"
+one postdoc he didn't like, who had difficulty writing research papers, as rapidly as possible. (The
+informaticist instead volunteered to help the postdoc, and the resulting paper was successfully published.
+That postdoc is now head of informatics at a major New York teaching hospital.)
+In addition, the informaticist had been prohibited from submitting a paper
+for publication because an algorithm he'd developed showed significantly better results
+than an earlier NIH-sponsored work by the Informatics department head. The Informatics department head wanted the results
+"adjusted to more closely correspond with my own", which the informaticist refused to do. The paper
+remained unpublished due to this academic suppression (and perhaps worse).
+<P>
+<blockquote><font face="arial" size="-1">
+(Miller was a stockholder and consultant for a medical
+software company registered in his wife's name, who was also an informatics faculty member. This
+private company was staffed by a scientist who also worked in the university Informatics department, and a postdoc
+in the department was enlisted to write code for the company as an "academic project" without pay or acknowledgement.)
+</font></blockquote>
+<P>
+In any case, it was apparent the Chief of Staff did not
+like Miller. The informaticist had seen such personality issues many times
+in academic settings and at this point did not think too much of it (as it turned out, unfortunately so).
+<P>
+The informaticist agreed that he would take the new informatics position after returning from a month-long
+research trip to Saudi Arabia to install the software application he'd authored.
+He was promised that the new position would begin shortly after his return.
+<P>
+As a due diligence, the informaticist registered
+his software with the university's technology transfer office before his departure, in accordance with University
+policy. He felt it contained innovative and marketable ideas. According to the technology transfer office and the University copyright
+policy on such works, they could help market the software, although copyright remained with its faculty author.
+<P>
+Signs of trouble appeared very early.
+<P>
+Shortly before the Middle East trip, Miller had seemed intimidated by the informaticist's incorporation of
+a complex controlled vocabulary into his program. It took him only a few days to implement this vocabulary. The informatics
+department head commented in a tone of disbelief that "it took another staff member over a year to do that a few years ago."
+The informaticist sensed something amiss and tried to disarm his boss by saying that he had "better programming tools
+to work with" compared to several years prior, which was at least partially true.
+<P>
+Miller repeatedly cut off the informaticist at a meeting with the medical school's director of
+administrative computing, not letting him get a word in edgewise. The administrative
+computing department was seeking new user interface ideas for an executive application being developed to cut
+costs. The informaticist wanted to point out that the novel user interface concepts he'd developed for the
+Middle Eastern computer program might be adaptable, but was interrupted repeatedly by Miller.
+<P>
+Miller's wife, Sandra Frawley, a member of the department, sent the informaticist an unexpected email "nastygram"
+regarding not having informed her about some very trivial matter on another project. This type of communication from
+Frawley had never before occurred. The informaticist had worked in tough environments before
+and tried to ignore these atypical events.
+<P>
+On the evening prior to his departure for the Middle East, the informaticist received a mysterious departmental email
+from Miller about a special meeting
+to occur on his first day of travel. The topic of the meeting was not mentioned.
+<P>
+Signs of trouble continued. The informaticist's distance was taken advantage
+of. Several days after he arrived in the Middle East, he received an international phone call from a consultant friend. A minor contract
+the informaticist had helped arrange between his
+university clinical department and the consultant (for customization of an administrative computer program)
+had been <I>usurped by Miller</I> without the informaticist's knowledge or
+involvement.
+<P>
+According to the consultant, the already-written contract had been turned over to another
+faculty person in the informatics section, and the work was to be performed for free. The informaticist
+thought this embarrassing breach of etiquette was particularly odd, considering the
+faculty person in question was extremely busy and had his hands full writing bioinformatics tools. It
+was a tremendous waste of this person's talents to write
+trivial administrative programs. (This opprobrious behavior by the Informatics department head
+turned out to be a warning sign for what was to come.)
+<P>
+In another odd sign of trouble ahead, the informaticist was able to use the Internet overseas and logged into the department Sparcstation.
+When he attemped to use the UNIX 'talk' feature to open real-time dialog with his colleagues, his overtures
+were mysteriously ignored or quickly dismissed. He'd though people would have been excited by typing to him real-time from halfway around the world.
+<P>
+The informaticist and the computer program were extremely-well received by the Middle Eastern hosts. So well
+did the trip go that his hosts offered the informaticist a full-time position in medical informatics
+in their hospital. This was despite the fact that he was of an ethnic background not even permitted entry
+into their country just a few years prior. Ironically, the positive feedback from the Middle Eastern hospital to the informatics department
+head probably sealed the informaticist's fate (it seems no good deed goes unpunished in a pathological environment).
+<P>
+<I>It was on his return from the Middle East that this second informaticist's real troubles began</I>.
+<P>
+Upon the informaticist's return, he found the environment had changed completely.
+His boss, Perry Miller, demanded copies of all his correspondences with the hospital
+and the Chief of Staff. (It should be noted that the hospital was organizationally not part of the University.)
+Even more dramatically, he left an intimidating handwritten note with those demands taped to the informaticist's workstation,
+instead of sending it by email as he had done with all messages over the prior several years.
+<P>
+Miller also informed the informaticist that after a meeting that occurred while
+he was overseas, it was decided that the salary level for the new hospital position would be one-half (50%) of the
+figure he had agreed upon with the hospital Chief of Staff. Due to the concerns of the
+MIS director, he said, the position would also report not to one, not to two, but to <I>three</I> individuals,
+Miller himself, the hospital Chief of Staff, and the MIS director, who
+would meet after six months and decide "if the informaticist was doing the job well enough
+to merit a full salary."
+<P>
+Miller also strongly discouraged the informaticist from seeking a job title of
+<I>Director</I> at the hospital. He thought a <I>manager</I> or <I>consultant</I> title more "appropriate."
+This opinion was given with a distinctly odd tone. It was an especially odd
+request, considering that the first informaticist in this story held exactly that title, and that the Director
+title (at minimum) was needed for credibility with powerful hospital executives and clinicians.
+(The reasons for this 'advice' from Miller would not become apparent until several years later, below.)
+<P>
+In reality, Miller should not have had authority to
+make such decisions for the hospital, which had its own independent HR department. How he may have had such influence
+was not to come out until several years later, as described below.
+<P>
+The informaticist was shocked by the changes, and concerned that the position as described now
+was unworkable and that the salary issue as above was absurd if not illegal (a "trial salary" as
+it were, and worse, at a level that came out to be 25% <I>lower</I> than the salary paid to the first informaticist).
+However, the Chief of Staff seemed afraid to talk to him and was unable to reverse these
+"changes." Within a few weeks, the informaticist was informed by a middle MIS manager that the
+budget did not contain enough money for another FTE (full-time employee) and that the position
+of Director of Clinical Informatics at the hospital was therefore no longer available.
+<P>
+Unfortunately, the leadership of this Middle Eastern country changed, and research funding to the University
+from this country was to be discontinued. (To this day, the informaticist still wonders if some of the events below contributed
+to the Saudi funding discontinuation.) Shortly after the letter from the middle MIS manager, the informaticist was informed
+by Miller and geneticist collaborator Dr. Ken Kidd that his University appointment would end as well due to
+"lack of funds". (The informaticist had received a letter from the clinical department overseeing
+informatics that talked of significantly increased revenue for the year.) The dismissal letter
+from Miller and Kidd also mentioned "if the Saudi project does
+continue, we will <I>try our best to insure</I> it includes continuing support for you." Ominous
+choice of words, though the informaticist...
+<P>
+<blockquote><font face="arial" size="-1">
+(The informaticist remembered a comment made a few months prior to his trip to the Middle East.
+The informaticist was laboring over a grant proposal with a pharmaceutical company collaborator, seeking funds for
+an advanced IT application. Miller boasted and laughed about how he
+could write the proposal "in just a few hours." This was a clear put-down of some kind,
+and he did not offer to help.)
+</font></blockquote>
+It also had not helped that Miller had refused to take on a self-supporting physician
+from Saudi Arabia as a postdoctoral fellow for
+informatics training. The informaticist had interviewed the candidate while overseas and found him
+very well-qualified, feeling he would be an asset to the field. Unfortunately, the Informatics department
+head had emailed the physician's sponsor (the head of IT at King Faisal Specialist Hospital) that he could not make any commitment, and that such an
+appointment needed to await word of the continuation of the country's funding of the university.
+This was rightly viewed by the foreign collaborators as an insult, especially since Miller
+had a number of foreign nationals from Asia and India working under his aegis. The informaticist
+encountered the Saudi head of IT at a conference the following year and heard his expression of
+incredulity about this decision by Miller.
+<P>
+Miller, who has his own private software company as an outside venture, also demanded that the informaticist surrender his current
+research work and computer programs prior to departure. He told the informaticist that the program was "university property"
+since the university "paid for it." He said the Associate Dean for Scientific Affairs, Dr. Carolyn Slayman, who had
+been a PI of the overall international project, agreed. However, Miller would not commit to a role for the informaticist in any future
+use of the work. The informaticist pointed out that the university copyright policy stated: "<I>the university disclaims ownership of
+works by faculty...except where the assignment explicitly states that the work will be owned by the university...the university
+advances no ownership claim to copyrights...the copyright policy is legally binding</I>."
+<P>
+The informaticist noted that no special agreement regarding university ownership of his work had ever existed in this project,
+implicitly or explicitly, nor had such an agreement ever been discussed.
+Miller did not care at all to hear about the copyright policy or the informaticist's
+already-established relationship with the University's Technology Transfer office regarding the work,
+which was of potential commercial value. Miller simply wanted the source code
+turned over without any agreements or understandings on its use. <I>It was as if Miller
+simply felt himself above any university policy or law that infringed on his unfettered use of others' work</I>.
+<P>
+The informaticist wrote a polite letter to Dr. Carolyn Slayman, Sterling Professor of Genetics and Associate Dean for Scientific Affairs, letting her know
+that he wished to continue a collaborative role in the further development and use of his own work. He sought her thoughts on the matter.
+The letter was <I>ignored</I>.
+<P>
+Simultaneously, geneticist Kidd, who was a close friend of Miller, also joined in the effort
+to "<I>find a way to take the software away</I>" from the informaticist. (Apparently these words
+were used by Kidd, as reported to the informaticist by a staff member in the Technology Transfer Office, Henry Lowendorf).
+Although Kidd had essentially ignored the software during its development, Kidd apparently found the software highly innovative and potentially
+useful and marketable upon the software's initial roll-out (debut). When he'd requested the software from the informaticist
+to send to a genetics colleague in France, the informaticist informed him that the university technology
+transfer office required any such transfers to be preceded by an NDA (nondisclosure agreement).
+This angered Kidd. He growled about "those damn lawyers getting in the way," but made no effort to have
+such papers signed so that the transfer could occur.
+<P>
+Instead, Kidd tried in a rather disingenuous manner to obtain the software from a scientist from
+Saudi Arabia, Marios Kambouris, who'd become a friend and colleague of the informaticist, while Kambouris was visiting Yale.
+Kidd requested the software and the instruction manuals from Kambouris repeatedly <I>while failing at all to mention
+that there was an intellectual property issue</I>. This proved unsuccessful
+as Kambouris had been forewarned about the dispute by the informaticist. This was
+deeply embarrassing to both Kambouris and the informaticist. Kambouris had frantically emailed the informaticist
+seeking advice when confronted by these requests from Kidd.
+<P>
+Actually, this should not have surprised the informaticist. Several months before the informaticist's departure to the Middle East, Kidd (who'd been
+to this country several times) called the country's culture "very odd" at a department meeting.
+Shortly after arriving in Saudi Arabia with the informaticist, Kidd
+complained that there was an insufficient supply of paper towels in an airport bathroom he used,
+and made snide remarks to the informaticist about this "being typical of a third-world country like this."
+<P>
+The informaticist was shocked at such a rude comment,
+especially considering the gracious hospitality shown by his hosts. The informaticist also recalled that
+Miller had called this country "weird" after an exploratory trip there
+a few years before. As a member of a minority group himself,
+the informaticist could only wonder what the blue blood Informatics department head and geneticist thought of <I>his</I> background.
+<P>
+The irony of this situation was that Kidd was a leading figure in an international genetics study of indigenous
+peoples, the Human Genome Diversity Project. The study was strongly opposed by a number of such indigenous populations around the world. Despite
+promises to the contrary, the indigenous populations feared misappropriation of their genetic material and of commercial
+discoveries made from their blood and tissues. Perhaps those fears were not inappropriate.
+<blockquote><font face="arial" size="-1">
+(This incident apparently cost Kidd some rare blood samples he wanted from Saudi Arabia. Kambouris, upon his return to Saudi Arabia,
+told his boss, a member of the Saudi Royal Family, that "the informaticist
+had really gotten screwed." This apparently did not go over very well, in terms of trusting American
+geneticists with Saudi citizens' genetic material and confidential medical records.)
+</font></blockquote>
+<P>
+The levels of hypocrisy shown
+by the turn of events over the software, and the rude and perhaps racist comments, disappointed the informaticist to a degree unparalleled in
+any of his prior career experiences, some of which involved working in a big-city transit authority dealing with
+labor unions, workman's compensation, drug testing and abuse, and the like. (It was this experience that
+perhaps gave the informaticist the strategies and tools to fight effectively. Most scientists
+would probably not have been able to respond well. The principals of this
+story forgot to ask themselves the question "<I>do we feel lucky?</I>" prior to committing their
+actions.)
+<P>
+In an attempt to defend his intellectual property, the informaticist once again pointed out to Miller
+and Kidd that by written University policy, copyrights belonged to faculty, not to the University.
+Miller did not care to hear anything about this and raised the issue of
+insubordination on not following his orders to turn over the intellectual property. This did not
+surprise the informaticist, as he had already observed Miller misappropriate the work
+of postdoctoral fellows into his personal company's products without attribution.
+<P>
+<blockquote><font size="-1" face="arial">(As an aside, with modern computer code being so complex, the informaticist was amazed at the
+apparently backwater "FORTRAN mentality" of these supposedly world-class people. They clearly coveted a single instantiation of a person's work -- a computer
+program whose misappropriation and modification would be quite difficult without the author's involvement --
+over what was really important, a modern computer professional's mind and creativity. This shows a near-complete misunderstanding
+of what's strategic in IT, namely good people and creativity, vs. transient and
+tactical, e.g., a specific instantiation of a leader/creative person's work.)
+</font></blockquote>
+The department yearbook was published, and not surprisingly it failed to make any mention of the informaticist's
+Mideast trip or work. When asked about this, Miller replied that "he'd <I>forgotten
+to put it in</I>." Miller was also not very supportive of the informaticist's
+desire to have the trip mentioned in the academic medical center's monthly news publication.
+<P>
+Miller neglected to tell the informaticist about a meeting with representatives
+of one of the largest pharmaceutical companies in the world, Pfizer, seeking collaborations. Such a collaboration
+could obviously have preserved the informaticist's university position, or given him an employment opportunity
+with the pharmaceutical company. The informaticist had not intended to be in the
+office that day, and only found out about it by accident the afternoon of the meeting. He attended, but when he tried to speak he
+was cut off by Miller.
+<P>
+Miller actually laughed and found funny a rambling, incoherent, disruptive letter shown to him by the informaticist.
+The letter had been sent to a number of the informaticist's associates by a close relative who'd recently suffered a severe psychological trauma.
+The informaticist had shown it to make sure its source was understood, and to seek possible sensitivity towards the family pressure the informaticist found
+himself under simultaneously with the career stress of the intellectual property issue. Instead, the informaticist
+found only the most callous insensitivity. Coming from a fellow physician, the laughter was all the more offensive.
+Far worse, he questioned the informaticist about the "possibility" the letter was written by the informaticist
+<I>himself</I> in the middle of the night and that he didn't remember doing so, perhaps due to effects of "sleeping pills" or drug abuse of some kind.
+Such a reprehensible insinuation, right out of the "clear blue sky", shocked the informaticist and his family immeasurably.
+<P>
+Due to an intolerable work environment, the informaticist cleaned out his office unannounced over the weekend and submitted a
+letter of resignation the following Monday, several months before the official end of his appointment.
+<P>
+Even after his departure he received emails from the informatics department (sent by a staff member who'd been
+requested to do so by Miller) and Kidd for
+the software, and even a request to show the staff programmer "how it all worked." The informaticist asked
+for a written request from Miller. This was refused in an email from Miller himself.
+The informaticist then sent an explicit notice of copyright to the university, as advised by an intellectual property
+attorney he retained.
+<P>
+In the end, as a result of this dispute, the informaticist found himself <I>blacklisted</I> by his former department and the University.
+His medical staff appointment at a new medical center was deliberately blocked. Miller refused to fill out repeated requests for references and verification of postdoctoral training.
+Several friends of the informaticist told him
+"weird things were said about him at a party at Miller's home."
+On two occasions, Miller told one caller in a reference-checking request that he "didn't have the time to give a reference," even when the caller said
+the need was urgent. In addition, there was an outright disavowal given to this caller of the informaticist's training
+at Yale University ("<I>sorry, never heard of him</I>") by Miller's second-in-command, the associate education
+director Rick Shiffman, with whom the informaticist had enjoyed cordial relations. Needless to say, this
+was a disgraceful and egregious violation of the University's written policies and the state's labor laws.
+<P>
+<blockquote><font face="arial" size="-1">
+(Fortunately for the informaticist, but very unfortunately for Miller and Shiffman, this particular caller was a <U>private detective</U> hired by the informaticist. The detective's report is quite
+chilling, showing an utter disrespect for the career and livelihood of the informaticist and his family.)
+</font></blockquote>
+The extramural programs division of the National Library of Medicine was kind enough to send the informaticist a letter
+verifying his postdoctoral training at the University when informed of this problem, but the letter was insufficient for the requirements of
+new medical staff appointment. It was also highly unusual for NLM to have to verify such training because the
+funded University refused, needless to say. The NLM otherwise said they could not intervene in this matter, not having
+authority to do so, even though they extensively funded Miller's informatics training program.
+<P>
+To save his career the informaticist had to file a blacklisting grievance with the state's Department of
+Labor. He initiated a lawsuit as well.
+<P>
+Worse, this terrible situation was accompanied by the refusal of a lawyer in the University's Office of General Counsel, Susan Sawyer, to enforce the University's policies
+on such reference requests until the intellectual property issues were settled, a rather unsubtle
+form of <I>extortion</I>. The informaticist also found himself locked out of any further interaction or communication with the Technology Transfer
+office on the use of his work. The Technology Transfer Office said it could not share with the informaticist any information about companies to whom
+the software had been shown, or whether any income had been generated. (An uncooperative cooperative research office, as it were.) This was in violation
+of provisions of the federal legislation that set policy on University technology transfer, the
+<A HREF="http://infoserv.rttonet.psu.edu/spa/bayh.htm">The Bayh-Dole Act of 1980</A>, and explicit provisions in the
+University's own copyright and patent policies guaranteeing income-sharing.
+<P>
+An uninvolved informatics department system administrator (and friend of the informaticist), Matt Healy, was
+apparently ordered by Miller to retrieve copies of the informaticist's code from encrypted
+departmental backup tapes. Despite written assertion of copyright by the informaticist, the system administrator
+retrieved the code from the tapes. This demand had put him in a clear situation of double jeopardy (at risk
+for becoming involved in possible copyright litigation, or being accused of insubordination if he refused).
+Placing him in such an uncomfortable situation was very bad HR practice and was probably unethical. It also damaged the friendship
+the informaticist had enjoyed with his former colleague.
+<P>
+Apparently under orders from Miller, department staff members disassembled
+and examined the source code retrieved by the system administrator, completely ignoring the informaticist's explicit copyright assertion.
+Then an Associate General Counsel at the university, Susan Sawyer, offered a series
+of absurd claims and supposed interpretations of case law on copyright issues to the informaticist's copyright attorney.
+These claims attempted "in every which way but sideways" to prove
+university ownership of the informaticist's work. (More on this person's qualifications and authorization to practice law appear later in this story.)
+<P>
+Sawyer's material included frivolous claims such as the geneticist Kidd having "contributed
+ideas" and therefore being an owner of the program (completely irrelevant to copyright which applies only to tangible works).
+An outrageous, absurd claim was even made that another university faculty member contributed a
+small programming language extension (a 'get file number' function distributed for general use that conveniently replaced about
+15 lines of code), giving the university ownership rights to the informaticist's program.
+<P>
+This is analogous to saying that using a function such
+as SQR(X) in Microsoft BASIC (instead of writing a square root algorithm in a few lines of code)
+makes Bill Gates, the author of Microsoft BASIC, an owner of any BASIC program itself!
+The informaticist both marveled at, and was saddened by, the idiotic arguments <I>coming from
+the legal authorities of a university with one of the finest law schools in the world</I>.
+<P>
+<blockquote><font face="arial" size="-1">
+(Ironically, Kidd had all but ignored the program during its development by the informaticist.
+His "ideas" included such critical issues such as drawing pedigree diagrams with conventional straight rather
+than angled lines, and coloring control buttons red, green, and yellow as a cue to their effects.)
+</font></blockquote>
+It's been said that when lawyers can't argue the law, they argue the facts. When
+they can't argue the facts, they argue the law. When they can't argue the law or the facts, they
+<I>attack the witness</I>. True to this saying, Sawyer, who made these absurd
+arguments to the informaticist's copyright attorney, only to be soundly rebuffed through the facts and the law,
+then circulated a letter accusing the informaticist
+of acts of computer hooliganism. According to this lawyer, these acts reflected the informaticist's "inability to
+appreciate or understand collaboration." These "acts" supposedly had occurred many months <I>before</I> his departure from the
+University and were now being circulated, along with this <I>ad hominem</I> character attack, many months <I>after</I> his departure.
+<P>
+These allegations (actually, a condemnation of guilt) were apparently initiated by Miller
+and were now being heard by the informaticist for the <I>very first time</I>. No
+opportunity whatsoever had been given to the informaticist to address these allegations prior to their
+circulation. This was in violation of University and federal policies on fair process, as well as the founding
+principles of this country's justice system, needless to say.
+<P>
+Sawyer also produced and circulated a written statement from another informatics staff
+member, Xia Liu, a young citizen of China hoping to establish American citizenship. Liu had drafted a very early conceptual working prototype of a novel user interface invented by the
+informaticist, done to the informaticist's specifications. Now, she made a new claim that she had invented the
+user interface and that it was <I>copied by the informaticist</I>,
+and that she had <I>written significant parts of the program itself</I>!
+<P>
+Unknown to Liu or her boss Miller, the informaticist had
+retained in his own personal records detailed, dated lab notes including his original sketches of the user interface
+created at a preliminary meeting where staff member Liu <I>was not present</I>. He also retained
+his drawings of it that had been passed out and minimally annotated (with editorial suggestions)
+by others, in their own hand, at a staff meeting some weeks afterward. It was at that meeting where Liu saw the invention
+for the <I>very first time</I>. The informaticist had also retained extensive printouts
+of his evolving code, printed almost daily as he worked. These were annotated in his own hand with planned changes,
+modifications and improvements, that were then implemented as his code evolved. (As a physician, he'd learned the
+value of documentation both in facilitating clear thinking and in legal situations.)
+Yale University never responded to these rather embarrassing disclosures and materials.
+<P>
+It is not known if Liu had been pressured into making these claims.
+She had been having severe personal difficulties, involving an
+estranged husband who had literally kidnapped their child back to their home country,
+forcing Liu into a difficult international child-custody situation.
+Liu left the university several months after making the above claim.
+<P>
+For self-protection, the informaticist filed a grievance with the State Bar Association against
+Associate General Counsel Sawyer for numerous legal practices he felt were inappropriate, in addition to
+the already-filed blacklisting grievance with the State Labor department.
+<P>
+As a result of the informaticist's blacklisting grievance to the State Labor Department, a state field agent began an investigation.
+Miller actually came within a few days of the Labor Department's issuing a <I>warrant for his arrest</I>
+for obstruction of the Labor Department investigation, as he repeatedly ignored calls and would not reply to the field investigator's inquiries and
+site visits.
+<P>
+Somewhat spectacularly, as a result of the grievance with the State Bar Association, it was discovered that Susan Sawyer,
+author of the "hooliganism" letter and the tying of the University's reference letters to the intellectual property issue,
+was found to have <U>never passed the State's Bar Exam</U>.
+Sawyer was therefore <b>unauthorized to practice law</b> in the state. In fact, by state
+law <I>it was not legal for such a person to even use the title "counsel."</I> The informaticist, at the suggestion of the
+State Bar Association, therefore filed an "unauthorized practice of law" grievance against
+this unauthorized practitioner, somehow employed as Associate General Counsel at this prominent university.
+<P>
+The University's Office of General Counsel was now forced to intercede, removing unauthorized Associate General Counsel Sawyer
+from the case (and merely agreeing with the Bar Association to change her title, since state law forbade the use of the title "counsel" by a
+person who had not passed the Bar exam.) This was a University oversight that to this day the University
+denies as negligence. In medicine, unlicensed physicians who injure patients are treated
+somewhat differently than a title change and a slap on the wrist.
+<P>
+In fact, the University disingenously
+refused to turn over documents about these matters to the informaticist's attorney during legal <I>discovery</I>,
+based on a claim of not knowing what the term "the alleged incident [of hooliganism]" meant in the requesting documents. Likewise,
+the State Bar Association would not turn over information to the informaticist or the Connecticut Freedom of Information
+Commission on how they made the decision not to sanction Sawyer. (Sawyer had hired a prominent Yale-trained
+attorney to represent herself in this matter, so this outcome is not surprising.)
+<P>
+The University Office of General Counsel also put in writing to the Labor Department that University
+human resources policies would be followed, and that behaviors by Miller and Shiffman such as refusal to verify
+the informaticist's training at the University and outright disavowal of the informaticists' ever having
+worked in the department would cease. The malicious accusations by unlicensed lawyer Sawyer against the informaticist
+were also retracted.
+<P>
+However, the informaticist had incurred legal fees of over ten thousand dollars
+that the University refused to reimburse. The university's official position was put in a letter to the
+informaticist. A university Deputy General Counsel, William Stempel (authorized to practice
+law in this case; the informaticist checked) wrote that he "does not at all agree
+with suggestions that 'basic fair play' was not followed."
+<P>
+The Technology Transfer Office and the Office of General Counsel still refused to share information about
+any possible commercial interest or income generated from the informaticist's software. Meanwhile,
+the Director of the Technology Transfer Office was reported in a national publication to sit on the Board of a company
+he helped found that does research in an area related to the domain of the computer program. It took <I>intervention by
+the office of Senator Joseph R. Biden</I>, from whom the informaticist requested assistance regarding the violation
+of the Bayh-Dole act, to finally cause the Office of Cooperative Research to divulge information about what was done with the computer program.
+(The University denied that any income had been generated. However, the Office of Cooperative Research refused to
+reveal what companies or organizations they might have shown the work to.)
+<P>
+Somewhat predictably, the Medical Informatics departmental Web pages were altered to "erase" mention of both
+the computer project by the informaticist and any mention of his work as a faculty member, despite numerous
+requests by the informaticist for restoration of the information. This persists to this day.
+<P>
+The Chief of Staff at the hospital, Dr. Ed Cadman, left the organization himself, to take a better
+position with higher-quality people, in a much nicer climate (figuratively and literally), as Dean
+of the University of Hawaii School of Medicine. He was kind enough to offer the informaticist a
+letter of recommendation that reflected the informaticist's accomplishments and reputation accurately.
+This letter helped saved the informaticist's career.
+<P>
+One very tragic aspect of this story was that the informaticist had been,
+and in the new position had planned to continue to be, a strong proponent and ally of Perry Miller.
+Instead, the informaticist was forced to oppose his former boss and mentor to save his own career.
+<P>
+<b>Multiple written and personal attempts to obtain assistance from numerous university officials</b>,
+including Roberta Hines, the department chair over the informatics section, associate dean for scientific affairs Slayman,
+the medical school dean, the deputy provost, the provost, the equal opportunities representative,
+human resources, the university president's office, and others were simply <I>ignored</I>.
+The informaticist could never satisfactorily explain this "blind eye" towards Miller's behavior until
+several years later.
+<P>
+The informaticist found out several years later in an <A HREF="http://www.yale.edu/opa/ybc/v25.n21.obit.01.html">Yale obituary</A>
+that the <I>Miller's father had been an influential Dean, an adviser to President Harry S. Truman, and Yale executive of
+national prominence</I> at the University decades prior.
+This fact had been kept very low key and nobody else in the informaticist's department seemed to know, either. This
+perhaps explained to the informaticist the favoritism shown this professor. His father had been alive
+at the time of these events.
+<blockquote><font face="arial" size="-1">
+(Miller's father had written a book several years prior about his career. It seemed to
+have been a career of integrity. In the forward, he thanked his son, Miller, and daughter
+for contributions of ideas and their critiques of the manuscript. Ironically, <I>the
+copyright of the book rested solely with the father</I>. It seemed apparent to the informaticist
+that the son was <I>not</I> the father.)
+</font></blockquote>
+<P>
+The informaticist also discovered that Miller had been a candidate for a <I>multi-million dollar
+Endowed Chair in Medical Informatics</I> at the University, but that hospital Chief of
+Staff Cadman (who had supported the informaticist for the hospital informatics position)
+opposed the candidacy of Miller for the Endowed Chair. Instead, an informatics
+leader from <I>another</I> prominent university, Dr. Clement McDonald of the Regenstrief Institute
+at the University of Indiana, was preferred. The informaticist later found out
+that Dr. McDonald had actually <I>toured the department</I> while the informaticist was overseas
+(but much later decided not to accept the Chair). The informaticist believed this helped explain a great deal of what had occurred.
+Perhaps it also explained the earlier resistance of Miller to a hospital title
+"Director" for the informaticist. Miller may have wanted that title for himself.
+<P>
+<blockquote><font size="-1" face="arial">
+(One other puzzling event that occurred months before, early in the promotion process, now made sense as well.
+Minutes prior to the initial, critical meeting between hospital Chief of Staff Cadman,
+informaticist, and Miller to discuss the Director of Informatics
+position, Miller had asked the informaticist a most unusual question. He asked the informaticist
+"<I>Do you have a toothbrush?</I>" The informaticist was perplexed by this question. He told Miller that he didn't
+keep a toothbrush in his office, and inquired about the purpose of such an odd question.
+Miller told the informaticist that "his breath was terrible and could
+be smelled from many feet away."<br>
+<br>
+The informaticist was shocked, as he had never before been told
+such a thing. The informaticist was then even more perplexed by Miller's annoyance
+at the informaticist's quick action in running to the nearby hospital gift shop for breath mints.
+It was now clear to the informaticist that this "bad breath" pretense had been an execrable attempt
+by Miller to disrupt the informaticist's performance at the critical meeting. In retrospect,
+realized the informaticist, this was not a surprise, coming from a person who once called his own wife
+an <I>idiot</I> in front of many others at an informatics departmental meeting.)
+</font></blockquote>
+The Ombud at the university, Merle Waxman, had been highly concerned about these events, but expressed a lack of real authority to intervene.
+The Ombud at Harvard who read this story had this pithy statement for the informaticist: "Your story is a <I>nightmare</I>."
+(Linda Wilcox, EdM, CAS, The Ombuds Office, Harvard Medical School).
+<P>
+True to the highly territorial nature of computers, information and networks, it was
+obvious the informaticist had gotten caught in the middle of a three-way battle between the hospital
+Chief of Staff, the Informatics department head (with his powerful political connection and rather
+tasteless tactics), and the MIS director for influence, territory, and money. The informaticist, to whom
+the Chief of Staff had written that "the organization needs people with your skills and commitment," nearly
+had his career destroyed.
+<P>
+Not one, but two bright young informaticists were literally mugged and eaten alive by this University, apparently due to
+political and territorial battles and extremes of back-stabbing. Ironically, the technology issues were quite
+simple compared to the sociological ones.
+<P>
+The principals in this story were approached by a number of the informaticist's colleagues and by the
+informaticist himself about apologizing for the events in this story, but they refused and continue to shun
+the informaticist, and rudely so in front of others, at national meetings. Their ego space issues apparently will not permit
+an admission of wrongdoing or any apologies. Breaking the "unwritten rules" of this academic medical center
+(i.e., that junior faculty members have no rights, even if those rights are in written policy) is apparently a far
+more serious matter than potentially criminal violation of state law, fair process, and holding back state-of-the-art healthcare IT progress for an entire
+community.
+<P>
+That point recently became explicitly apparent. A few years after the above story occurred, the informaticist received an ironic email from an IS staffer in the
+organization he left. The IS staffer had recently seen some of the informaticist's commentary about electronic medical records
+in an informatics listserv, but had not known of the issues in the story presented here. The IS staffer wrote:
+<blockquote>
+<I>We are implementing an interdisciplinary automated medical record at Yale-New Haven Hospital and are struggling to identify an
+evaluation tool to measure overall success of the project implementation. Open to suggestions or references. Thanks, [name withheld].
+</I></blockquote>
+Ironically, Yale-New Haven Hospital was only starting on an electronic medical record
+implementation, while another organization had received the benefits of the informaticist's expertise and
+had already succeeded in exactly the areas the first hospital was now struggling with, several years later.
+The electronic medical record system he'd implemented had facilitated documented, substantial improvements in
+appropriateness and thoroughness of care, significant improvements in immunization and preventive medicine rates, and
+good acceptance of cultural change by the organization's clinicians.
+<P>
+This university seems afflicted with what author Diane Vaughan
+calls "<I>the normalization of deviance in organizations</I>." Behaviors within
+the organization that deviate from societal norms of conduct outside
+the workplace become accepted, due to overgrowth of bureaucracy and 'politics' (a euphemism
+for intimidation or other unprofessional behavior shrouded in a veneer of propriety).
+This phenomenon often results in occurrence of significant errors, due to
+suboptimal use of expertise. See "The Challenger Launch Decision," University of Chicago Press, 1996.
+<P>
+<blockquote><font size="-1" face="arial">
+(In another strange twist, it turned out that the wealthy retiree funding the Endowed Chair in informatics, Lynn Williams, son of
+the former second-in-command at IBM in its heydey, had actually
+been the person who'd led the informaticist to this university for informatics training. They had struck up an electronic friendship years before
+on the CompuServe "MedSIG" (medical special interests message board). Williams had praised
+his alma mater and its informatics program to the (future) informaticist. Miller had not known
+of this connection. When Williams found out what had
+occurred to the informaticist, he probably was not very happy. It may not be merely coincidental that the Endowed Chair remains
+unfilled, several years later. Chief of Staff Cadman, who left to become Dean at the
+Univ. of Hawaii Medical School, told the informaticist that Miller would probably never get the chair.
+Perhaps there is some justice in this world.)
+</font></blockquote>
+The informaticist in this situation has created a detailed web site about this episode, including
+extensive document images of related letters and correspondences. He is willing to share this information with
+others for educational purposes. He may be contacted via an email to this web site's author, at <A HREF="mailto:scotsilv at aol.com">scotsilv at aol.com</A>.
+<P>
+<B>Addendum</B>:
+<P>
+The informaticist, now in the management ranks at one of the largest pharmaceutical companies in the world,
+recently saw an <A HREF="http://info.med.yale.edu/external/pubs/ym_fw0001/biotech/biotech1.html">article about New Haven's Biotech Boom</A> in the publication
+"Yale Medicine" that wrote of how well the Office of Cooperative Research (OCR) collaborates with faculty to develop their ideas into
+commercial products. "<I>The OCR worked closely with faculty whose discoveries had commercial value</I>", the article states.
+He emailed the URL of the story you are now reading to a number of faculty and senior university officials listed as involved
+in OCR, including:
+<P>
+<blockquote><font size="-1" face="arial">
+Henry Lowendorf, Sharon Oster,
+Ian Shapiro, Ian Ayres, Susan Carney, Benjamin Bunney, Richard Edelson, Richard Flavell,
+John Geanakoplos, Andrew Hamilton, Susan Hockfield, Pierre Hohenberg,
+Lawrence Manley, Robert Shulman, Jon Soderstrom, Stephanie Spangler,
+Richard Szary, and Michael Zeller.
+</font></blockquote>
+The informaticist told these Yale personnel in his email that the "Yale Medicine" statement about OCR
+apparently had not applied to him, and that only intervention by Senator Biden caused the OCR to reveal whether
+any money had been generated from his work.
+<P>
+In his web logs, the informaticist subsequently noted a number of viewings of this story about his experiences by some of these people
+whose IP's carry their names (e.g., spangler.hgs.yale.edu), by people using
+workstations in the Office of Cooperative Research (e.g., cr45.ocr.yale.edu), and by people using workstations in the Office of General Counsel (e.g.,
+ogc15.councel.yale.edu). To date, however, he has not had any replies from any of these people, nor does he
+expect any. He has heard from friends at Yale that he'd been labeled a "disgruntled former employee",
+a type of semantic chicanery sometimes used by the powerful to discredit and <I>blame their victims</I>.
+<P>
+Readers of this story may find the following story about abuse of a postdoc at
+another University quite interesting: <A HREF="http://www.justice4t.org.uk/">http://www.justice4t.org.uk/</A>.
+At this URL is a story
+of similar injustices and abuses of power at one of France's most prestigious scientific research
+schools. But it is also another story of a how a scientist can stand up to such overwhelming odds
+and fight back.
+<P>
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="emr"><FONT COLOR="brown"><H3><B>Chaos from MIS mismanagement of a clinical information system project</B></H3></FONT></A>
+<P>
+An informaticist took a full-time position as a Director of Informatics at the
+healthcare organization where he obtained his Medical Informatics education.
+He was to lead the clinical team working on a full-blown inpatient Computerized Patient Record.
+The project plan included nursing documentation, full online medical records, and physician
+order entry. The experience the project would provide and the prestige if the project were
+successful were very attractive to the informaticist.
+<P>
+For the first 6-9 months the project seemed to go well. The clinical data repository
+implementation was progressing and interface specs for lab results and data coming from ancillary
+systems were largely done with what seemed to be a few minor issues left to resolve.
+The hospital had just hired more clinical analysts to start the design and implementation
+of the physician order entry system, and that phase of the project was underway.
+<P>
+Then, due to muddled thinking and basic incompetence by the hospital’s MIS leaders,
+the <I>bottom fell out</I>.
+<P>
+The informaticist and his clinical team actually found themselves <I>excluded</I> from
+preliminary interface testing. Significant obstacles causing long delays in clinician
+participation in the project started to appear. Further, numerous essential aspects
+of the design had been delayed. As the clinical team finally began to see a test system,
+there were numerous clinically-important configuration settings that had not been addressed
+by MIS.
+<P>
+The delays in implementing the interfaces to other systems (e.g., lab) ran into
+months. Fortunately (or unfortunately, depending on one's point of view), there was
+a major network infrastructure problem that had to be fixed before new production systems
+could come on line. (Of course, that issue should been realized well beforehand by MIS,
+but we digress.)
+<P>
+The network issue, plus the Y2K issue, gave the organization a four-month ‘reprieve’ on the planned
+go-live date. Despite that, major interfacing problems continued to persist.
+What could only be described as outright incompetence
+by senior MIS personnel followed, both in understanding the technical issues and their
+clinical significance and in establishing consensus on how to resolve them.
+As a collateral injury, this caused even more delays in the informaticist and
+clinical team being informed of (and helping provide solutions to) these issues.
+<P>
+MIS wasted considerable resources and time with <I>band-aid solutions</I>, that,
+when the informaticist and clinical team found out about them, made them literally
+groan, as they usually were unacceptable and actually clinically nonsensical.
+MIS would then re-think the problem and possible solutions, often with
+still-unsatisfactory results!
+<P>
+Furthermore, the "go-live" date was by edict made a <I>drop-dead</I> date.
+Senior IS management and senior health-system management, lording it over
+the informaticist and clinical team, gave no heed to concerns that the clinical
+information system was not yet "ready for prime-time." Therefore, the project team was forced
+to either push ahead with ridiculous solutions to major interface problems, or simply
+postpone some interfaces crucial for full system effectiveness.
+<P>
+As it turned out, the clinical information system went "live" with only about 50% of the functionality
+and interfaces that had been planned.
+<P>
+The incompetence of the vendor's on-site personnel was another major factor
+contributing to delays. They quite literally could not understand the concerns
+of the clinical team or the clinical significance of the issues, and were instigators
+of several absolutely <I>idiotic</I> "solutions" to significant interface problems.
+Worse, many of the so-called "solutions" would actually <I>not work</I> with their data
+repository upon testing!
+<P>
+In other words, the vendor’s personnel came up with solutions not just clinically
+absurd, but also <I> technically unfeasible</I>! Also, they could tell the clinical
+team precious little about how the database and interface designs would influence
+the display and functionality of the GUI, which was another huge causative factor
+in delays and system rework. Between MIS and the vendor, it was like the blind leading the deaf.
+<P>
+As is typical in hospitals, MIS (not the project committee or clinicians) controlled
+the budget and the MIS resources that were responsible for executing the design and
+implementation of the data repository. Due to this, clinical concerns were often simply ignored.
+<P>
+The informaticist and clinical team compiled a list of about a dozen
+configuration changes that affected the GUI that were essential prior to
+bringing the system live ("go-live issues"). These
+dozen issues were simple preference settings that could be made with GUI tools
+provided by the vendor. They did not involve vendor enhancements or new code from the vendor.
+<P>
+At least half of these trivial configuration changes <I>were not made for months</I>, despite
+the fact that it would have only taken the informaticist or someone even minimally
+technically competent about <I>an hour</I> to do them. Of the remaining half,
+several were still not done at go-live. Senior MIS management simply never put
+them on the priority list, and they never got done, to the severe detriment
+of the success and ROI analysis of the system to date. It is amazing how MIS always seems
+to concentrate on "process" to the exclusion of needs and results.
+<P>
+The escapade that finally sparked this informaticist to resign his position
+is as follows: At a meeting of the senior MIS and clinical stakeholders
+of the project (the informaticist, the Medical Director of the project,
+the MIS project manager, and the MIS staffers), it was decided that since the
+current security functions did not meet the needs of the psychiatric hospital,
+the initial implementation would not include psychiatric data until the vendor
+redressed the security deficiencies. Several other options, all of which were "hacks,"
+and would have compromised the functionality of the system for other users,
+were discussed and rejected at this meeting.
+<P>
+In fact, no users would be able to access psychiatric data even if it were included.
+The team did not plan to roll out the system to users
+with clearance to access psychiatric data for at least a year.
+Thus, the lack of psychiatric data would be of absolutely no
+clinical significance for at least a year after go-live.
+<P>
+However, when it came time to meet with the psychiatric stakeholders, a
+mid-level MIS manager sent an email listing "options" that were to
+be discussed at the meeting with psychiatry. To the informaticist’s horror,
+they were the very same "hacks" that had been ruled out at the previous meeting!
+<P>
+The informaticist and clinical team quickly challenged this MIS person,
+and the MIS senior managers, on this rather egregious breach of a consensus decision.
+They requested that the MIS manager and the manager’s superiors
+NOT present these options at the meeting.
+<P>
+Despite this, the MIS manager went ahead and <I>presented the options anyway</I>.
+When the Medical Director of the project stated at the meeting that those options
+were not acceptable to him, the whole Clinical Information System project quickly lost
+all credibility with the psychiatrists, and irreparable damage to morale had been done.
+<P>
+The options had been presented at the direction of the senior MIS person on the project.
+This person had apparently made promises to the psychiatrists that the informaticist and
+clinical team had not been consulted on, promises that were impossible to keep. It was that
+day that the informaticist realized that MIS was completely unresponsive to clinical end-users,
+and that the Clinical Information System project was in serious jeopardy as a result of its
+inappropriate leadership.
+<P>
+The informaticist sent resumes out that day. In less than two months he had a new
+position at another organization.
+<P>
+The MIS CIO, the Medical Director, and the academic Medical
+Informatics director pleaded with the informaticist to stay and even
+offered a salary increase and the promise that MIS would have more accountability to
+clinical members of the project. However, one senior VP in MIS was extremely reluctant
+to allow any changes, and did not want to remove the senior MIS manager responsible
+for the psychiatry debacle. The senior VP apparently felt a sense of loyalty to this MIS manager.
+It would have taken a serious restructuring of this person’s position to effect real change.
+The position would have to <I>report directly to the Medical Director of the project</I>.
+It was clear this was just not going to happen.
+<P>
+The promise of change was therefore window dressing, not the substantial change needed
+to make the project successful, in the informaticist’s opinion. He accepted a very
+attractive job offer with a healthcare IT vendor. Hospitals thus lost one more
+informaticist and abundant intellectual capital due to inappropriate leadership
+and organizational structures, structures that inappropriately put MIS in the pilot’s seat
+of an initiative to create a clinical tool.
+<P>
+The informaticist had hoped his leaving would send a strong signal
+and that real change would result. However, he later reported that he’d
+heard from a close friend (another clinician) on the project that things
+had actually got worse starting just a few weeks after his departure.
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="lobotomy"><FONT COLOR="brown"><H3><B>Salesperson performs frontal lobotomy on industry healthcare group</B></H3></FONT></A>
+<P>
+The healthcare IT vendor industry is not immune from the mismanagement and unqualified decisionmaking afflicting
+the healthcare delivery sector, one informaticist reports.
+<P>
+An informaticist was contacted by a national recruitment firm for a
+"director of clinical IT" position in the healthcare group of a large,
+respected information technology vendor. The healthcare group had focused
+on leasing of expensive medical equipment.
+<P>
+Due to decreasing life cycles of IT-related equipment including medical
+machinery, making leasing less profitable, and a corporate mandate from
+the company’s CEO, the healthcare group was moving to a services delivery
+model. The role of the informaticist would be to provide strategic
+guidance to this transition, help in new product development, and
+assist the sales force in navigating the complex territorial waters of
+healthcare IT. The sales force was very unfamiliar with healthcare IT per se.
+They had predominantly interacted with medical officials and
+CFO’s, not CIO’s or M.I.S. in hospital settings.
+<P>
+The informaticist noted that the healthcare managerial staff all seemed
+very intelligent, with a senior VP approaching genius level.
+People were generally affable, creative, and entrepreneurial.
+His boss-to-be was relatively new to healthcare IT and was quite friendly.
+True partnering with this person seemed possible.
+<P>
+His interviews went well. Despite a salary offer lower than his background
+really merited, and the presence of a "<I>medical instamaticist</I>"
+as Director of Informatics (an MIS person with no clinical or informatics training or background,
+see "<A HREF="infordef.htm#isnot">What medical informatics <I>is not</I></A>"), he decided to
+accept the position. He was impressed by a corporate-wide telecast in which the
+company’s CEO announced a major push in healthcare IT. Also, the "instamaticist"
+was smart and affable, and the informaticist was to join a technology group of people
+with healthcare backgrounds (including some new hires). The informaticist
+hoped to be able to advance through the ranks of this company to make up for these
+issues, and thought his accepting the position was a good career move.
+<P>
+<B>BAD mistake</B>!
+<P>
+Due to political turmoil that began at about the same time as the
+informaticist started the new position, the position could only be described
+as <I>stillborn</I>. For several months, not much happened and the informaticist was
+rarely called upon to do much, other than help in an early product development
+initiative. This was primarily due to political turmoil regarding leadership of the healthcare group.
+The technology subgroup he was now part of found itself similarly marginalized.
+This was a shame, as this technology group consisted of hard-to-find, extremely
+competent people who collaborated as a team extremely well.
+<P>
+The informaticist noted other signs of impending doom. One senior networking
+person explained at lunch that he believed in practices such as "therapeutic touch."
+He was not amenable to the informaticist's explanation that a prominent medical journal
+had published a scientifically-valid survey debunking such
+practices ("<A HREF="http://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query?uid=9533499&form=6&db=m&Dopt=b">A Close Look at Therapeutic Touch</A>",
+Rosa et al, Journal of the American Medical Association, April 1, 1998). The networking
+person objected with the statement that "medicine doesn't know everything."
+<P>
+(The informaticist refrained from explaining that medicine indeed doesn't know everything but
+sure as hell has a superior path to knowledge and wisdom compared to pseudoscience and
+pop mysticism, namely, the scientific method. He
+also refrained from telling the networking person about "therapeutic computer touch," where
+people diagnose failed hardware, disk corruption, and computer viruses by wearing long robes
+and waving special digital divining sticks to sense sick computer spirits.)
+<P>
+There were more serious signs of brain damage in this company's comprehension of healthcare.
+One of the company’s technical divisions had a healthcare
+accrediting agency of national prominence as a client. The company's technical division did not
+pay much attention to this account as it was very small, dollar-wise.
+As a result, the computer technicians and MIS managers in the technical division did not
+aggressively adhere to their own standards of rigor, doubtlessly saving such rigor for "bigger,
+more important" accounts.
+<P>
+Predictably, they <I>failed miserably</I> in crucial matters related to the accrediting
+agency’s IT, in an area exactly corresponding to the new product
+being developed by the healthcare group and informaticist, and lost the
+account to a competitor. Worse, <I>they could not even understand the impact of this
+debacle</I>: namely, pissing off a national healthcare accrediting agency
+and the effects on the healthcare group’s hopes of securing national
+contracts with hospitals. Worst of all, nobody in the company thought
+to ask the informaticist about any of this.
+<P>
+Then, the politics fell apart. The division VP over healthcare was moved.
+The genius-level Senior VP over healthcare was also asked to move to another
+division of the company. He declined and chose retirement instead.
+The informaticist’s boss then resigned suddenly, and the informaticist
+and his technology group found themselves with an "acting boss" and even
+less opportunity to do any useful work.
+<P>
+A new Senior VP was appointed. In a staggering example of
+decision-making through the <I>Dilbert school of management</I>, a sales
+manager of a real estate background who’d been with the healthcare group for
+several years was appointed. This person had been a good salesman but lacked both technical skills
+and intellectual bandwidth, the informaticist thought. The division VP was
+also changed to someone far less visionary than the original. Once again,
+the domain experts, the informaticist and the technology group, were not
+even consulted for advice about such appointments.
+<P>
+What followed was what the informaticist could only describe as a "<I>theatre of the absurd</I>." At the healthcare
+group sales meeting where the new VP debuted in his new role, he told the assembled
+group in Darth Vader-like tones that "<I>sales figures would need to increase at
+least 300% the next year, that salespeople needed to work harder and that
+slackers would be out of a job</I>." Great news for a group of tired salespeople
+in a healthcare industry on the verge of collapse due to the cuts of the Balanced
+Budget Act and impact of managed care. The roar of silence was deafening.
+<P>
+To help accomplish these goals, he announced a "restructuring" soon after.
+In a brilliant move, nearly the entire technology group, including the medical informaticist,
+was <B>summarily dismissed</B>!
+<P>
+Not surprisingly, the "instamaticist" was about the only person retained.
+In his short announcement to the group, the new VP told the healthcare IT experts, including
+the medical informaticist, that "your backgrounds are <I>too specialized</I> for our needs."
+<P>
+This is truly a spectacular attitude to have in a field at the intersection of medicine and
+information technology, two of the most specialized of all human endeavors, where good people
+are exceptionally hard to find. The informaticist thought of the slogan "<I>frontal lobotomies
+are good for business!</I>" to describe this new debacle.
+<P>
+Apparently, word of this debacle spread rapidly to senior management.
+This real-estate-salesman-turned-clinical-IT-expert was apparently demoted back to a regional
+sales manager within weeks of the layoffs. An intelligent healthcare
+IT marketing person was promoted to become the healthcare group general manager.
+However, the damage was already done, and competitors began snapping up the
+laid-off technology team.
+<P>
+The motto of this story may well be "allowing the wrong people to make the wrong
+decisions at the wrong time is a generic route to failure, always."
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="justice"><FONT COLOR="brown"><H3><B>Insufficient IT management depth results in Justice Dept. investigation</B></H3></FONT></A>
+<P>
+A large University medical faculty practice plan, noted for doctors who are among the
+finest in the world with expertise in cutting-edge therapy, entrusted the hospital's
+MIS department to upgrade their administrative and financial information systems.
+The plan, consisting of almost 1,000 physicians of over one hundred specialties
+and subspecialties, was seeing over a quarter of a million patients yearly.
+<P>
+The management team, as management teams do, assembled a large Task Force to
+draft the system requirements, send out RFP's, and work deals with possible
+vendors. Several high-powered business and MIS executives were brought in to run this
+Task Force. The institution's informatics specialists were kept at a
+distance from these proceedings because they were academics and not
+business-minded. On the few meetings they attended, their input was
+treated as secondary to the executives.
+<P>
+After some time, a commitment was made by MIS to a vendor package in the usual MIS way,
+with all the "proper business process." A series of preview meetings
+were held for the package. Two informaticists who attended the preview
+sessions for the financial software package felt that the software package looked rather like a Rube Goldberg contraption, with a primitive
+and cryptic user interface, needless complexity, poor manageability, difficult navigability,
+poor customizability, obtuse documentation, and other highly concerning characteristics at odds
+with many basic precepts of informatics.
+<P>
+Even the informaticists were severely
+confused by the demonstrations, and wondered aloud to each other how
+this package and these people could ever make this application fly
+successfully in such a complex environment. On the basis of their
+familiarity with those environments and with IT, they were concerned about a project
+'flame out and crash.' Unfortunately since they were not empowered they were afraid to speak up,
+and what they did say was not taken very seriously.
+<P>
+About two years later, The U.S. Department of Justice and U.S. Attorney's
+Office announced an investigation of several million dollars worth of
+overbilling by the Faculty Practice Plan. In a press release, University
+officials downplayed overbilling as a common failure of medical centers
+across the country.
+<P>
+"The allegation is that we were not doing the refunding," the University
+said in a press release. "We don't yet know how much of the credit balance
+is overbilling. ... We've been vigilantly working with the federal authorities
+to determine the credit balance of the University." Of course, with the
+computer billing system as discombobulated as it was, determining that
+information, let alone anything more complex, proved to be quite a challenge.
+<P>
+Individuals and organizations with gripes against the University hyped
+the government probe. A former medical school worker, who was
+suing the University for over $3 million on charges of sexual harassment,
+suggested that the School of Medicine Dean had been fired as a
+result of the investigation. Several University officials said
+sources from the University unions told reporters that the dean
+was carried away in handcuffs by the police and that the sum
+under investigation was in the area of $20 million.
+<P>
+After a few years of investigations, the University faculty practice
+plan announced a settlement. Under the settlement, the plan would
+refund about $500,000 to the federal government with respect to
+Medicare and other federal health care programs, and make available
+approximately $2 million to designated health care carriers, and
+about $2.5 million to individuals and other entities. Furthermore,
+the University would make a settlement payment of $700,000 to the
+federal government in complete resolution of all claims.
+<P>
+The University announced that the credit balances included accounting
+entries for payments or portions of payments that the Faculty practice
+plan had been unable to match against outstanding charges for patient
+care, in many cases because information was erroneous or incomplete,
+as well as excess amounts resulting from duplicate payments from multiple
+payors. The inability to resolve these payments resulted from "faulty
+administrative and inadequate computer systems."
+<P>
+The University also announced it had voluntarily taken steps to upgrade
+its systems and their management, and would need to invest roughly $15 million
+more in "state of the art computer billing and information systems."
+(The old system, which cost several million in capital and heaven knows
+how much in operational costs, was scrapped.)
+<P>
+The medical director of the Faculty practice plan intoned that
+"the growing complexity of health insurance demands a billing and
+clinical administrative system as world-class as the quality of our
+patient care, and we have aggressively taken the necessary steps
+to put that system into place." The faculty practice plan resumed its
+practice of world-class patient care and perhaps learned that approaches
+to information technology can be as important as approaches to medicine.
+<P>
+In an uncharacteristic and somewhat stunning act of candor, the University attributed the
+shortcomings of the management team in a press release to "inadequate
+management depth." The informaticists were saddened but not surprised by how this
+Titanic billing system debacle led to a successful (for the Justice Department) diving expedition.
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="trust"><FONT COLOR="brown"><H3><B>Who serves whom: physicians felt completely unnecessary in clinical IT decisions</B></H3></FONT></A>
+<P>
+An informaticist is involved in an informatics program
+that is not expected to survive due as he says "to the very political scenes you so aptly describe in
+your web site." He describes the hospital as run by a "MIS"-mash of at least 5 different systems, 3 of
+which don't talk to each other, and one that can get some messages from the other three,
+but only if things are running well. Specifically, the lab and radiology systems (LIS & RIS)
+are completely stand-alone and require totally different terminals for users.
+There are increasing number of PCs breeding around the facility, but some are still
+Windows 3.1, most are Win95, and a few are Win98. Macs exist within individual departments,
+but the IS department officially declared the Mac a dead-end and, of course, does not support such
+an "obtuse and moribund" platform.<BR>
+<BR>
+The major machine for the enterprise is a piece of mainframe "big iron" (software platform
+unknown) running many user-hostile programs leftover from the Johnson administration.
+Using this machine is not for the faint of heart. First a person must find either a functioning
+terminal with its light pen still attached, or one of the aforementioned PCs with a terminal
+emulator. (The light pen equivalent is cleverly mapped to the right mouse button, but
+there's no documentation to that or any other effect.)<BR>
+<BR>
+Very few docs learn to use the beast, but those who do discover that they can actually
+get to read and/or print old H&Ps and discharge summaries. This is the only electronic
+text available on previously admitted patients. There is no information if the patient
+is new. The mainframe does have access to labs and radiology reports (text only, no images)
+but there is an 8 to 24 hour delay before that information is batched from the originating
+systems.<BR>
+<BR>
+The PCs were recently bred in captivity and populated into a new clinic building.
+All faculty and housestaff were issued an email account if they had not had one before.
+The username, password and POP server name were <I>emailed to the account itself</I> as a way
+of informing users of their new capabilities. Unfortunately, this did not work.
+The new PCs had cleverly been outfitted with the newest layer of Netware which required a
+different signon and password than the email account. This signon and password were <I>never
+distributed</I> to the housestaff, because the housestaff didn't come in for the 4 hours
+of training and setup for the accounts.<BR>
+<BR>
+(The informaticist points out there's a very, very appropriate Dilbert cartoon in which Dilbert's password
+becomes invalid, but he can't log in to send a Help Request because....)<BR>
+<BR>
+The reason that no house staff carved four hours out
+of their already busy day for training was because the computer programs that could
+obtain patient information (terminal emulators) were placed in the default Start Menu
+of all of the PC's, even if there was no one logged into that PC. It took over four
+months of complaining before a WWW browser was placed into this open availability status.
+When asked why a WWW browser couldn't be put there in the first place, IS reported that
+that would be a <I>breach of security</I>.<BR>
+<BR>
+The informaticist found this highly ironic. Software that leads to patient information is
+readily available, but software which is public domain, and can't reach patient information
+is protected by a non-documented sign-on identity. Browsers were added only when the point
+was made that the hospital formulary and clinical lab definition handbook were no longer
+available in print, and thus could only be accessed via browser, and the lack of a browser
+constituted a major inconvenience and perhaps breach in patient care. Risk Management
+concurred with this analysis. The WWW browser appeared in the StartMenu the next day.<BR>
+<BR>
+The PC's will still jam the attached printer if a user attempts to print a document
+from the "open" account. This is not documented. The user can't clear the jam, because
+both the open accounts and the named accounts don't have access to any control panels, the
+local explorer or any other software tools for the afflicted PCs.<BR>
+<BR>
+Lastly, even those who have been through the training and have named accounts on
+the PCs don't use them. This is due to the simple fact that it takes the machines
+a full 2 minutes (120 seconds) to logout/login from the open account to your own.
+As the informaticist relates, "try doing that in a clinic environment more than once. Hah!"<BR>
+<BR>
+For the future, this hospital is in the middle of trying to pick a super-system,
+turnkey 'this-will-solve-all-your-problems' vendor. <I>Notably absent from the
+specification stage were any physicians</I> (!) After some complaining,
+a few MDs were permitted to join the committee to discuss proposals
+which came in from the RFP. One of the physician informatics leaders objected to the way
+that MD needs were being relatively ignored. He was removed from his informatics position and now is in
+an office at the remote campus, and has no further responsibility or involvement with
+informatics at this hospital.<BR>
+<BR>
+Some months ago, the three vendor finalists were invited for a 1 week (each) demo of
+their product. By word-of-mouth, one system was very well received by the MDs and many
+of the RNs and adminstrators. Not one word on final selection has since been heard since by
+the informaticist. As he says, "it may only be a coincidence, but one
+of the other finalists was the same company that had perpetrated its
+mainframe mentality on us 20 years ago. It may also only be a
+coincidence that the CIO is quite fond of the current system, and has announced that
+he is <I>not</I> going to retire until after this selection issue is done.
+It should be noted that he has neither CS nor medical training."<BR>
+<BR>
+Postscript:<BR>
+<BR>
+The plan to purchase the new system was quietly withdrawn, without so much as a
+"sorry for getting your hopes up," according to a followup message from this informaticist.
+He relates there are rumors that the procurement project is on hold "for 2 years" but the
+rumors can't be confirmed or tracked to origin. Nonetheless,
+suggestions for improvements in the RIS, LIS and Mainframe systems continue to be
+rejected out of hand by Information Services because "these systems are going to be decommissioned after
+the new system gets here. We're not going to spend good money upgrading an
+obsolete system."<BR>
+<BR>
+The informaticist, also a practicing physician, points out that
+by this thinking process there would be no reason to treat someone's grandmother
+because she is obsolete and going to die anyway. This counter-argument doesn't seem
+to make much sense to the Information Services staff, who seem to forget physicians
+take care of patients, a process I.S. is there to support, not to control and <I>certainly</I>
+not to obstruct.<BR>
+<BR>
+"Please, have pity on us" asks this informaticist.<BR>
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="culture"><FONT COLOR="brown"><H3><B>Cultures of mismanagement: toxic to healthcare quality</B></H3></FONT></A>
+<P>
+In a large regional healthcare system, the CEO and the executive VP/COO seemed not at all to agree on the value of, and role for, an Ivy league-trained Medical Informatics
+professional. The CEO, himself a physician, had hired the informaticist in a previous role as Sr. VP for Medical Affairs. He had done
+so since the organization's clinical information technology was in disarray due to leadership problems.
+Expensive business consultants and even an industrial psychologist had been brought in, but were unable to facilitate improvements or change.
+The CEO seemed to understand the value of informatics expertise in invigorating clinical computing projects that were in difficulty,
+breaking up old ideas with visionary IT thinking tempered by a clinician's work ethics and insights, and so forth.
+Unfortunately, the VP/COO, who also oversaw MIS, apparently did not share these views.</P>
+<P>
+This manifested itself after the informaticist wrote an op-ed to a popular healthcare MIS journal about the importance
+and value of informaticists in hospital IT projects</A>. The informaticist and other clinicians working on clinical
+computing projects were heartened to see the op-ed actually published in a journal directed towards the healthcare MIS world.</P>
+<P>
+A short time later, the <A HREF="http://www.advisory.com">Healthcare Advisory Board</A>, a think-tank that scans the
+periodic literature for new ideas and topics of relevance to healthcare organizations, reviewed the article and found
+it interesting. The Advisory Board is a membership organization representing over two thousand member hospitals,
+health systems, physician practices, insurers, pharmaceutical companies and medical technology firms, and whose
+publications and white papers on trends in the industry are widely used in setting policy and making purchasing decisions.</P>
+<P>
+The Advisory Board wrote to this organization's VP/COO (who was their listed
+contact person) about the op-ed on informatics, seeking more information on a topic that they found of interest.
+Despite good progress at this hospital system on many fronts in which the informaticist had taken a leadership role
+(e.g., strategy, EPR, GMPI, procedural medicine databases, etc.), and acknowledgment by the organization's medical staff that the
+'new thinking' of formal medical informatics had changed the environment very positively, this VP/COO's reaction for
+whatever reason was to severely downplay to the Advisory Board the value and role of a professional informaticist.
+The informaticist was represented as a relatively unimportant 'internal consultant' to this VP/COO and to his MIS department,
+who were the 'real' movers and shakers.</P>
+<P>
+(One reason might have been that this VP/COO and the MIS director
+reporting to him oversaw some of the failed clinical IT projects that were later made successful by the informaticist.
+I leave it up to the reader to surmise what might motivate such a reaction.)</P>
+<P>
+To compound the unfortunate marginalization of informatics as a field that occurred here, the letter from the Advisory Board
+was never shown to the informaticist and was thrown away by the VP/COO. The informaticist found out about the Advisory Board's interest
+completely by accident several days later. The Advisory Board wasn't directed by the VP/COO to the informaticist
+author of the article that attracted their attention, which would have been a basic common courtesy. Finally, due
+to <I>ambivalence</I> about informatics, other senior executives did nothing upon being informed of the breach of etiquette
+(at best) represented by this revealing incident.</P>
+<P>
+At worst, on the other hand, thousands of Advisory Board-subscribing healthcare organizations were potentially denied
+hearing about informatics in a positive light due predominantly to the partiality of one
+executive and the ambivalence of others. Further, due to incidents like this occurring repeatedly,
+the informaticist resigned from this organization, depriving the clinicians of informatics expertise.</P>
+<P>
+This VP/COO also repeatedly obstructed the informaticist's presentation to an panel of senior
+industry CIO's who were advising the organization on IT at the board's request. These CIO's had
+very little knowledge of healthcare. Extremely verbose, complex and intimidating
+diagrams and charts on healthcare IT from a large, expensive management consultant firm were shown to them
+by the VP/COO and MIS director. These documents confused the CIO's, by their own acknowledgement.
+In fact, the informaticist thought the quality of these documents was appalling, which is
+a serious matter since they were the product of a multimillion-dollar consulting engagement.
+The informaticist's critiques, however, were glossed over by the organization. That is a story for
+another time.</P>
+<P>
+A concise, clean, clear presentation assembled by the informaticist on 'healthcare computing for business IT
+professionals' was suppressed by the VP/COO using a number of subtle and direct tactics, such as
+"forgetting to put it on the schedule" or allowing other discussions (once it was on schedule) to run overtime,
+then forgetting to put the presentation on schedule for the following meeting. In effect, the organization was
+deprived of the CIO advisory panel's full value. Although possible explanations for this behavior
+range from ineptitude and sophistry to high-level political intrigue and sabotage,
+God only knows the true reasons for such behavior. This executive often micromanaged,
+could be ingratiating when he needed to be, but was generally cold, <A HREF="bully.htm">authoritarian and a bully</A>. This combination of characteristics can be
+very destructive to innovation spearheaded by creative people. Bright people should beware such executives and the "intellectual
+hospice" atmosphere they sometimes create.</P>
+<P>
+Not surprisingly, other executives did little when informed about this matter, since this was just the "way of business." Even the
+CEO remarked that this was a good VP/COO, that such views about IT excellence were a form of "extremism" and that "other
+views had to be taken into account" (i.e., views of those with little or no knowledge, skills or experience in computing or
+medicine, the <I>chiropractors of clinical computing</I>).</P>
+<P>
+Even under the most favorable of circumstances, this executive did not let up on such territorial tactics. Despite this executive's starving the budget of an EPR project (electronic patient record) for a large
+primary-care clinic, causing key personnel to resign, the medical team successfully implemented the EPR
+on-time and under-budget anyway. They did this through advanced informatics thinking, ingenuity, medical will and true
+collaboration. The reaction of this executive at a meeting with other senior executives about minor fine-tuning and future directions
+for this project were that "the project was improperly managed in that the style was <I>too collaborative</I>." The
+delivery of such rhetoric had to be seen to be appreciated for its breathtaking combination
+of smooth self-confidence and patent absurdity.</P>
+<P>
+To make matters worse, the executive team then gave a key EPR staff member, a Senior Resident who'd done
+an excellent job writing and programming custom templates for the EPR system, a difficult
+time on promised payment for his services. They believed such a customization function was
+trivial and wasteful, and essentially <I>reneged</I> on their agreements with the Resident.
+When challenged by the informaticist and others that this person's services
+were essential, the views were met with indifference, if not disdain, for facts and logic.
+In fact, the executive team clung persistently to a mind-numbing leap of logic: they seemed to believe
+that just as home computers were "plug and play", so was clinical IT. Their attitudes seemed
+to reflect a belief that the EPR team and resident were basically deceiving them.
+<P>
+These attitudes and actions inflamed the Resident and the entire EPR team. The services of this resident were lost as a result, a problem in a clinical computing
+project requiring iterative development and frequent change. This is a concept that seems beyond the cognitive grasp
+of this type of executive. This is a typical example of the problems caused by progress-inhibiting
+bureaucrats who seem common in healthcare. (In a sense, current healthcare turmoil is beneficial in
+that it may cause bureaucrats who cannot handle rapid technologic change, or who are incompetent, to seek jobs elsewhere.)</P>
+<P>
+Unfortunately, healthcare IT is <I>never</I> plug-and-play, and in IT a person is either <I>part of the solution</I> or <I>part of the problem</I>.
+Such executives are the latter. One thing is certain: patient care ultimately becomes the unfortunate victim of such behaviors and beliefs.
+The presentation on healthcare IT to the panel of senior industry CIO's was actually never given because the informaticist left the organization due to its chronic
+casuistry and <I>culture of mismanagement</I>.</P>
+<P>
+It is interesting to note that many such executives in healthcare, such as
+in this example, have no background in either medicine or in information technology.</P>
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="basic"><FONT COLOR="brown"><H3><B>Intranet server or rocket science? A hospital MIS dept. fails on basic tasks</B></H3></FONT></A>
+
+<P>
+A three-hospital integrated delivery system invested approximately a quarter of a million dollars
+in online access to its financial databases, as part of an "executive information system."
+Gerald Nussbaum, a consultant with Hamilton HMC, New York, noted the project yielded little
+return due to a number of major errors in very basic areas.
+<P>
+First, the intranet as set up suffered from technical problems. It lacked sufficient server
+capacity and lacked adequate bandwidth. Worse, it suffered from flawed programming such that
+database queries timed out, causing report requests to fail.
+<P>
+But basic technical errors weren't the only problem. The reports that were produced were
+not formatted to print in a way that staff members desired or were accustomed to, causing
+frustration even when reports were produced by the system. [From Health Data Management,
+Nov. 1999, p. 62.]
+<P>
+Such basic technical and workflow errors are often secondary to basic mismanagement by project leaders,
+either due to micromanagement by their non-knowledgeable superiors, or by direct acts of commission or omission
+due to insufficient skills and insights in information science, healthcare, and IT itself.
+<P>
+It must be remembered that IT is only a raw tool. Only with proper insights in the domain area, in information science and
+in user interaction design (a research area that addresses how computer applications <I>behave,
+communicate and inform</I>) can IT be implemented to facilitate delivery of useful information.
+This is especially true in complex healthcare environments.
+<P>
+It often surprises me when adverse outcomes in healthcare IT are treated differently than adverse
+outcomes in other fields, such as in clinical medicine itself. If a contractor builds a building with
+an inadequate foundation and concrete and the building collapses, this is attributed to
+<I>incompetence</I> at best, and criminal behavior at worst. If a clinician fails to diagnose a cancer
+or has an adverse patient outcome due to suboptimal therapy, this is called <I>malpractice</I>.
+<P>
+Yet, in healthcare information technology it seems such words are forgotten when the causes of failure are
+dissected. Instead, one sees or hears only milder, indirect words. One never hears that a patient's
+adverse outcome resulted from "delayed clinical progress and cost overruns due to technical or sociological issues."
+The term <I>malpractice</I> is used. Yet, one rarely hears terms such as <I>mismanagement</I> to describe why clinical computing or other healthcare IT projects fail.
+It is ironic that healthcare IT seemingly gets treated preferentially or with "kid gloves" compared to
+the very field it is supposed to facilitate: clinical medicine. The dynamics of this phenomenon
+deserve further study.
+<P>
+</td></tr></table></center>
+
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="thousand"><FONT COLOR="brown"><H3><B>A thousand MIS personnel cannot merge two healthcare systems?</B></H3></FONT></A>
+
+<P>
+The leaders of a newly-merged multi-hospital integrated delivery system have given up on the two-year-old
+merger of their distinguished academic medical centers. "The results of the
+merger have been even more disastrous than had been anticipated," said one hospital staffer.
+<P>
+After posting an estimated $43 million in losses over its life, officials said it was decided the new system
+will be dismantled. The two university systems that made up the merged entity are to go their separate ways.
+<P>
+"With great anguish I have concluded that, in our efforts to find bold solutions to
+the problems of academic medical centers, we have taken on too much," one of the University's
+presidents said in an Oct. 28 letter to the other University's President. "We have failed
+to achieve a new common culture that would provide the wholehearted support needed."
+The letter outlined his desire to unwind the financially troubled merger. The 1997 merger
+had brought under one umbrella four hospitals with a total of 1,350 beds, with two
+hospitals coming from each University.
+<P>
+The decision came less than three months after the university presidents sent
+a joint letter to the system's board challenging the merger and asking for a review.
+The top two executives at the merged system subsequently resigned, and a state audit
+outlined the merger's financial shortcomings.
+<P>
+The merger's architects originally predicted a $65 million
+profit in fiscal 1998 and 1999. But in the most recent fiscal year ended Aug. 31, the
+system had actually realized an operating loss of $86 million and a net loss of $73 million on operating
+revenues of $1.5 billion.
+<P>
+Instead of reducing staff, the system had added <I>nearly 1,000 employees</I> during its first
+year and a half, primarily to <I>integrate financial and other information technology
+systems</I>. The attempted information system merge was running far behind schedule and had
+not been highly successful. The cost of merging the two systems' computer networks jumped
+fivefold, from the original estimated $25 million to a whopping <I>$126 million</I>.
+<P>
+A troubled-hospital management consultant "rescue" firm was called in. A leader of that
+firm stated that "A poorly executed merger causes trouble; there's no doubt about it. I think
+there were certainly execution difficulties in this one. I think it was a good concept that
+was not executed as effectively as everybody would have liked it to have been."
+<P>
+He also stated that the projected cost savings were real, but the merger's leaders didn't pursue
+them hard enough. Among specific failures were a lack of meaningful consolidation, an
+unwillingness to cut expenses and expensive corporate overhead, he said.
+<P>
+What has been missed is why 1,000 employees were unable to merge the information systems of the
+two institutions. One thousand I.S. employees should be able to merge <I>General Motors</I>. Considering
+such a number amounted to about one I.S. person for every 2-3 physicians in the system, this is an astonishing
+failure.
+<P>
+It is apparent that MIS in this situation was not operating very efficiently (in fact,
+<I>spectacularly poorly</I> may be a more fitting description), but
+unfortunately there rarely are any "morbidity and mortality" conferences to address such shortcomings.
+Healthcare IT seems to exist in an isolated, siloed environment, immune to the same critical scrutiny
+and discipline that healthcare itself is subject to. Metrics and standards for healthcare IT are necessary.
+A system of "managed computing" analogous to the system of "managed care" that's been placed upon healthcare
+itself (on the basis of measuring and improving efficiency) may be of great benefit to the
+healthcare industry.
+<P>
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="nova"><FONT COLOR="brown"><H3><B>The cost of lost opportunity: Medical Informatics can't gain a foothold (4 stories)</B></H3></FONT></A>
+<P>
+<B><I>A reader in the United States writes:</I></B>
+<P>
+Thank you for your messages to the CISWG listserv -- and for your web site. As a recent graduate
+of a medical informatics training program, I have devoured most of it and am now taking the
+time to digest and reflect. Currently I am struggling in a relatively new informaticist position
+for me and for my organization.</P>
+<P>
+Two years ago I accepted a position with a not-for-profit integrated healthcare delivery network.
+Though I was not a novice in the business world, my excitement upon graduating and joining the
+"real world" again may have contributed to the "blinders" I was apparently wearing during setting
+up the position. My far-too-many bosses (problem #1) understood that to have a medical
+informaticist on staff would be a good thing on paper -- but claimed they didn't really know
+what to do with a person with this expertise. I attempted to help provide structure to my position
+and responsibilities. Unfortunately, I soon ran into some well-established organizational and
+cultural obstacles which were not initially apparent that prevent me from applying my informatics
+expertise, to the detriment of the organization.</P>
+<P>
+In any case, the time has come to fish or cut bait, as it were. We have a new CIO who, although
+not informatics or medically-trained, seems to understand that IT isn't just about hardware and
+software. For example, he is proposing a Medical Management team led by clinicians that, in the
+course of the larger scope of their work, would help set IS priorities (whatever that means).
+Perhaps that has potential, if the team is not just a figurehead. Not surprisingly, I had proposed
+a similar idea a year ago. The executive clinicians had loved my proposal. IS ignored it and
+would not allow me to continue work on it, and everyone else got involved in planning for the new
+budget year, etc. etc., so it died. Perhaps this was just a classic case of political
+marginalization as your site indicates. It certainly didn’t help the organization in any way
+and may have harmed it in the long run, strategically and financially.</P>
+<P>
+The present challenge: finally, I have been able to schedule a meeting with my current supervisor,
+a Director of Clinical Information Systems (not an informaticist), our new CIO and an executive
+clinician on staff. The topic is "Who am I in this organization? Exactly what am I going to do?
+And where organizationally do I belong?" As if the answers weren’t obvious. That’s like asking
+where a surgeon belongs. In the operating room, perhaps?</P>
+<P>
+I am preparing to present some very concrete, realistic ideas that are in line with what I
+understand of the priorities of our new CIO and the corporation as a whole. My bottom line
+is whatever responsibilities we agree to must be supported by the appropriate organizational
+position, authority, and resources.</P>
+<P>
+Truly, I am not on some sort of a power trip here. I just want to spend more time doing meaningful
+work than wringing my hands in frustration. Above all, I don't want to give up and move on
+prematurely. Nevertheless, I am aware that my pride in not being a "quitter" may be getting
+in the way of making the decision to cut my losses and move on. My greatest concern is that
+I am not growing. Practicing Medical Informatics is not just a job for me; it is my chosen
+profession and an integral part of my personality and life.</P>
+<P>
+I am not a clinician, although none of the people in IS are either, nor do they have any formal
+medical informatics background. I have been and continue to be diligent in learning all the
+clinical material I can -- reading, attending seminars, rounding with physicians and nurses,
+asking lots of questions. I hold a Master’s in Organizational Behavior, did some time with a
+Big 5 consulting firm, conducted my research in data mining of real-world ER / specialty data
+pertaining to the treatment of acute, life-threatening medical presentations.</P>
+<P>
+It is a shame this organization cannot get its act together in leveraging the expertise of
+medical informatics in its healthcare IT projects.</P>
+<P>
+<B><I>A reader in a European country writes:</I></B>
+<P>
+I've recently taken up a position as Director of Medical Informatics at a
+not-for-profit hospital. I have been greatly heartened and
+encouraged by your comments to the CIS-WG (AMIA Clinical Information
+Systems working group listserve) and the pieces you have on your WWW
+site.</P>
+<P>
+We are implementing a major-vendor suite of applications (EMR, Order entry, ICU, ER,
+Surgical documentation, Theatre Management, etc). My five months here seemed to
+have mirrored a lot of your experience with Information Services departments.
+The CIO here has a background in health administration and business, with no
+formal training in computer science and no clinical background.</P>
+<P>
+As you've noted in your postings to the AMIA listserve, the "Director of Clinical
+Information Systems" position seems all to frequently to be "director of nothing."
+I too have very little control over decision making for our CIS project, in fact
+I have been actively excluded from the real decision making process.</P>
+<P>
+One of the problems is that administrations of hospitals make themselves dependent upon Heads of
+MIS/CIOs/etc to advise them about the set up of projects mostly well before our
+kind are involved, thus ensuring that power and resources are not shared.</P>
+<P>
+Cheers and keep up the excellent postings and WWW content on your web site.</P>
+<P>
+<B><I>Another reader in the United States writes:</I></B>
+<P>
+We definitely have the same problem here. Everything that is not
+the MIS "gold standard" is considered completely "unsupported" and they
+will do their best to "get rid of it" - people included!</P>
+<P>
+One of our former attending physicians was on our hospital's MIS-dominated
+pediatric electronic medical records (EMR) committee. He always told me that his biggest
+fight, when they were in the planning stage, was convincing the EMR committee that
+you can't have "people on separate sides of the fence". You need
+to have physicians that speak and understand computer talk and programmers that
+speak some "medicine". Otherwise, it will never work, he said. He also
+pointed out that MIS people ONLY need to be involved in the deployment
+of the database, not in the development. An informatics-familiar physician
+should lead that process. This type of thinking, of course, "ticked" MIS
+off.</P>
+<P>
+It was very difficult for MIS to accept any of this. Eventually they
+gave in, sort of, and the physicians on the committee picked one of our former
+neonatologists as pediatric EMR project leader. However, the neonatologist had
+to do so much "head butting" with MIS, and MIS made the project so politically
+unbearable for him, that he quit within two years.</P>
+<P>
+<B><I>An orthopedic surgeon in the United States writes:</I></B>
+<P>
+An excellent website! I discovered it in a discussion forum on
+Physicians Online.</P>
+<P>
+I am beginning my "hard knocks" education in medical informatics on the
+smallest scale: implementing electronic medical records in our office.
+Although "micro-informatics" differs in many ways from the
+"macro-informatics" you discuss in your site, there are obviously
+similar basic principles involved.</P>
+<P>
+Your grim tales of Dilbert-ish CIOs and befuddled healthcare execs
+would be amusing if they didn't impact so negatively on our ability to
+efficiently manage patients and patient information. One of our local hospitals
+"upgraded" their hospital information system with an expensive,
+user-hostile system which was obviously designed by someone who hasn't
+the faintest idea of what a clinician needs. Example: when I request
+my rounding list, I receive a gigantic compendium of every patient whom
+I've "encountered". This means that my inpatients are scrambled with
+discharged or even deceased patients, consults, patients for whom I'd
+given voice orders while on call, etc. There is no way to sort through
+this mess, and I have to resort to checking the census floor by floor to
+find my inpatients. Complaints to the "help desk" yield no useful
+information, only suggestions to attend additional "training sessions"
+(which are 50% propaganda) and the assurance that "this is the best
+patient management software available". Despite the superlative
+qualities of the software, we have been informed it will be "upgraded"
+again next year!</P>
+<P>
+Be careful not to attribute to malice that which can be explained by
+mere stupidity...</P>
+<P>
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<FONT COLOR="brown"><H3><B><A HREF="http://home.earthlink.net/~austintxmd/Pages/bad0498c.html#PruRefer">Abusive IT: technology making clinical work more difficult</A></B> (hyperlink)</H3></FONT>
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<FONT COLOR="brown"><H3><B><A HREF="http://members.aol.com/scotsilv/0322srmc.htm">A single informaticist could have prevented this South Carolina clinical IT debacle</A></B> (hyperlink)</H3></FONT>
+<P>
+
+</td></tr></table></center>
+
+<HR>
+<BR>
+<center><table width="65%" cellpadding="5" border="0" cellspacing="0">
+<tr valign="middle" align="left"><td>
+
+<A NAME="biggest"><FONT COLOR="brown"><H3><B>Perhaps the most significant shortcoming in healthcare IT</B></H3></FONT></A>
+<P>
+<P><FONT COLOR="black">
+The preceding stories represent suboptimal use of resources, intellectual capital, high cost of lost
+opportunity, and risk to patients and to the well-being of healthcare organizations.
+The people in these stories all note a "metaproblem": the difficulty bringing the obvious
+problems to the attention of senior healthcare leadership, and be heard and have significant action taken. Politics
+is commonly one of the problems, although just as frequently the reported problems are not well-comprehended.
+<P>
+That it is very difficult to have such problems dealt with decisively speaks to a weakness in
+current healthcare leadership structures. That these stories are apparently commonplace should
+be troubling to all who think critically. The individuals currently charged with planning and
+implementation of healthcare information technology, in particular healthcare executives and
+CIO's, must accept an authoritative role for clinicians and informaticists in healthcare IT decisions.
+In addition, when executives are made aware of problems with clinical IT by clinicians
+and informaticists, they need to see, look, listen, and pay very careful attention to the messages.
+Once given information on the problems, they should turn to the clinical informatics specialists
+and allow them to address the problems in a collaborative manner.
+<P>
+In summary, clinicians and informaticists need much stronger authority in clinical computing.
+A system where critical decisionmaking about clinical IT is made by executives who may be
+unqualified must evolve and become more appropriate to patient care needs.
+<P>
+This site calls for such changes in healthcare, consistent with the compassionate patient
+advocacy traditions of the medical profession. <A HREF="mailto:ScotSilv at aol.com">Comments</A>?
+<P>
+
+</td></tr></table></center>
+
+<!-- <HR>
+<P>
+<B><A HREF="http://members.aol.com/medinformaticsmd/index.htm">Definitions</A> of Medical Informatics -->
+<P>
+<HR>
+<CENTER><B><A HREF="mailto:scotsilv at aol.com">Please send me
+Comments and related material</A></B>
+<BR>
+</CENTER>
+</BODY>
+
+</HTML>
Added: trunk/packages/med-doc/trunk/index.html
===================================================================
--- trunk/packages/med-doc/trunk/index.html (rev 0)
+++ trunk/packages/med-doc/trunk/index.html 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,51 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<title>Debian-Med Documentation</title>
+<link rel=\"stylesheet\" type=\"text/css\" href=\"med-doc.css\">
+</head>
+<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#800080" alink="#FF0000">
+<h1>Debian-Med Documentation</h1>
+
+<p>
+Debian-Med is an Debian internal project to support tasks of people in
+medical care. The goal of Debian-Med is a complete system for all
+tasks in medical care which is build completely on free software.
+</p>
+<p>
+The Debian-Med documentation meta package provides valuable information
+for developers of medical software. Currently it depends from:
+</p>
+<ul>
+ <li><a href="file:///usr/share/doc/doc-linux-html/HOWTO/index.html">doc-linux-html</a> which provides
+ the <a href="file:///usr/share/doc/doc-linux-html/HOWTO/Medicine-HOWTO/index.html">Medicine HOWTO</a>.<br />
+ The <a href="http://www.linuxdoc.org/HOWTO/Medicine-HOWTO/">latest upstream version</a>
+ is available at the <a href="http://www.linuxdoc.org/">Linux Documentation Project</a>.
+ </li>
+ <li>The <a href="file:///usr/share/doc/resmed-doc/html/index.html">Analysis document</a> of Resmedicinae.<br />
+ The
+ <a href="http://resmedicinae.sourceforge.net/model/analysis/">latest upstream</a>
+ can be found at the <a href="http://resmedicinae.sourceforge.net/">Resmedicinae homepage</a>
+ </li>
+ <li>The <a href="file:///usr/share/doc/med-doc/html/failure.htm">Typical examples of healthcare IT
+ mismanagement</a>.<br />
+ This document was included into Debian-Med because it seems possible that it will
+ vanish from the web otherwise.
+ </li>
+ <li>A document about
+ <a href="file:///usr/share/doc/med-doc/html/medicalfreesource.html">Open-Source
+ Medical Information Management</a>.<br />
+ This document was included into Debian-Med because it seems possible that it will
+ vanish from the web otherwise. This is the <a href=" http://lorenzo.uwstout.edu/QQMIM/medicalfreesource.html">original
+ location</a>.
+ </li>
+ <li><a href="file:///usr/share/doc/med-doc/talks/index.html">Talks</a> about
+ Debian-Med.
+ </li>
+</ul>
+
+<p>
+Moreover there is a <a href="debian-med-faq.html">Debian-Med FAQ</a>.
+</p>
+</body>
+</html>
Added: trunk/packages/med-doc/trunk/med-doc.css
===================================================================
--- trunk/packages/med-doc/trunk/med-doc.css (rev 0)
+++ trunk/packages/med-doc/trunk/med-doc.css 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,110 @@
+
+h1 {
+ font-family: Verdana, Helvetica, sans-serif;
+ font-size: 24pt;
+ font-weight: bold;
+}
+
+h2 {
+ font-family: Verdana, Helvetica, sans-serif;
+ font-size: 14pt;
+ font-weight: bold;
+}
+
+h3 {
+ font-family: Verdana, Helvetica, sans-serif;
+ font-size: 12pt;
+ font-weight: bold;
+}
+
+a:hover {
+ font-family: Verdana, Helvetica, sans-serif;
+ text-decoration: underline;
+ color: #333333;
+}
+
+a:link {
+ font-family: Verdana, Helvetica, sans-serif;
+ text-decoration: none;
+ color: #000099;
+}
+
+a {
+ font-family: Verdana, Helvetica, sans-serif;
+ text-decoration: none;
+ color: #000099;
+}
+
+a.strong-link {
+ font-family: Verdana, Helvetica, sans-serif;
+ text-decoration: underline;
+ color: #000099;
+}
+
+p {
+ font-family: Verdana, Helvetica, sans-serif;
+ font-size: 10pt;
+}
+
+ul {
+ font-family: Verdana, Helvetica, sans-serif;
+ font-size: 11pt;
+ color: #111111;
+}
+
+ul.sub {
+ font-family: Verdana, Helvetica, sans-serif;
+ font-size: 10pt;
+ color: #222222;
+}
+
+.conclusion {
+ text-align: center;
+ font-family: Verdana, Helvetica, sans-serif;
+ font-weight: bold;
+ font-size: 12pt;
+}
+
+.hint {
+ text-align: center;
+ font-family: Verdana, Helvetica, sans-serif;
+ font-weight: italic;
+ font-size: 11pt;
+}
+
+.mark {
+ text-indent: 25px;
+ font-family: Verdana, Helvetica, sans-serif;
+ font-weight: bold;
+ font-size: 11pt;
+ color: #111111;
+}
+
+.typewriter {
+ font-family: Fixed, Courier_New, serif;
+ font-weight: bold;
+ font-size: 11pt;
+ color: #111111;
+}
+
+.pageno {
+ text-align: right;
+ font-family: Verdana, Helvetica, sans-serif;
+ font-weight: italic;
+ font-size: 9pt;
+ color: #444444;
+}
+
+.title {
+ text-align: center;
+ font-family: Verdana, Helvetica, sans-serif;
+ font-size: 18pt;
+ font-weight: bold;
+}
+
+.subtitle {
+ text-align: center;
+ font-family: Verdana, Helvetica, sans-serif;
+ font-size: 14pt;
+ font-weight: bold;
+}
Added: trunk/packages/med-doc/trunk/medicalfreesource.html
===================================================================
--- trunk/packages/med-doc/trunk/medicalfreesource.html (rev 0)
+++ trunk/packages/med-doc/trunk/medicalfreesource.html 2008-06-05 15:57:58 UTC (rev 1975)
@@ -0,0 +1,2041 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.07 [en] (X11; I; Linux 2.0.36 i586) [Netscape]">
+ <TITLE>Title</TITLE>
+<!--Created by Applixware HTML Author, Release 4.4 on Sat Nov 6 00:00:46 1999-->
+<!--Ax:WP:DocVar:HTMLOriginalPath@:"/tmp/ex03380d.aw"-->
+</HEAD>
+<BODY>
+
+<CENTER><B><FONT FACE="helvetica, helv, geneva"><FONT SIZE=+2>Open-Source
+Medical Information Management</FONT></FONT></B>
+<P>Copyright 1999, Daniel L. Johnson</CENTER>
+
+<BR>
+<P><BR>
+<P><B>Disclaimers</B>
+<P>I have no commercial interest in any of the software discussed in this
+essay; in fact, I've spent a lot of my own money on this project just for
+the pure pleasure of it. My only conflict in this arena is that I have
+lately come to own a little Red Hat stock through accident of birth.
+<P>I am not a <I>GNU/Linux</I> or <I>free software / open source</I> zealot;
+I simply recognize its genuine strengths and enormous potential. I am not
+opposed to commercial software; in fact, I am an investor and board member
+of a company, Technology Concepts, Inc., that is a provider of real estate
+database software and which does not use any free or open source technology,
+and is wedded to Microsoft technolgy.
+<P>My employer, the Red Cedar medical Center, and our owner, the Mayo Regional
+Health System,
+<BR>have not supported this work, nor have they been asked to endorse it.
+It is purely my own
+<BR>work.
+<P>I have done enough coding to know that my time is better spent supporting
+skilled hackers rather than trying to become one. I have watched the computer
+industry carefully for twenty years, but I do not know nearly enough about
+it; in this essay I have done my best to tell the truth: all errors are
+inadvertent, and I'll be grateful to be educated where you see a need for
+it.
+<P>Whenever something I say in this document seems not to make sense, please
+consider it a failed attempt at humor.
+<P><B>Author's background</B>
+<P>I am Daniel L. Johnson, an internist from Menomonie, Wisconsin. I've
+had an interest in office ergonomics for about 30 years, since being an
+office supervisor before medical school; and an interest in finding ways
+to use computers to aid clinical efficiency since about 1983, when I found
+a replacement for the accounts-receivable software that my clinic was using.
+In 1985, after a change in practices, I became interested in the intellectual
+and manual processes of mining information from a clinical record for medical
+decision-making. This led me in 1986 to write a specification for software
+to make the intellectual tasks of the office physician more efficient,
+but the databases and tools did not yet exist to make this feasible. This
+specification, updated for current technology is available at
+<P>http://lorenzo.uwstout.edu/QQMIM/qq4.html.
+<P>The tools now exist to create such a system, but it remains to be determined
+whether interest, motivation, and human capital can be assembled to bring
+this about. This specification I whimsically call "QuickQuack."
+<P>The html version of this essay will be located at
+<P>http://lorenzo.uwstout.edu/QQMIM/medicalfreesource.html
+<P>You may contact me at
+<BR> johnson.danl at mayo.edu
+<BR> or
+<BR> johnsondanl at m1.uwstout.edu
+<P><B><FONT SIZE=+1>Open-source medical software.</FONT></B>
+<P>The focus of this essay is medical-record software aimed at the outpatient-care
+setting. Hospital care requires record-keeping with an entirely different
+philosophy than outpatient clinical care, such that it is not possible
+to do justice to both in one presentation.
+<P>Hospital documentation is oriented around single, completely encapsulated
+events of care, lasting hours to weeks. Outpatient-clinic documentation
+is oriented around longitudinal care for at least an episode of illness,
+but in primary medicine, the "episode of care" is the patient's entire
+life. In the most general sense, any chronic illness or primary care requires
+rapt attention to the longitudinal aspects of the patient's condition;
+a transient condition is an "interlude"<SUP>1</SUP> of care.
+<P>Thus a hospital-based electronic medical record could be subsumed within
+an outpatient-clinic record, as a "lobe" off the main record; but it is
+not possible to take a record designed for the hospital and generalize
+it to the outpatient-clinic setting.
+<P>A strategy of any project must be to begin simply; to identify accurately
+the essentials of the electronic record and focus on these while planning
+for the inevitable addition of complexity and evolutionary needs. One of
+my goals here is to begin to identify the "kernel" of the record and recognize
+the directions it must take.
+<P><B>Extant Computerized Medical Information Management Projects</B>
+<BR>
+<TABLE BORDER CELLPADDING=0 WIDTH="524" >
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Project</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">Internet address for more information,
+if any
+<P>(principal author or project leader, project location)</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Perceptions</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.enjellic.com
+<P>(Greg Wettstein, Fargo, North Dakota)</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>VistA</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.hardhats.org/apps/APPSmain.html
+<P>or http://www.va.gov/vama.htm</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Arachne</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.arachne.org/arachne_overview.html
+<P>(Stephan R.A. Deibel, John Ehresman, Massachusetts)</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Littlefish</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.paninfo.com.au/intro/littlefishproject_homepage.htm
+<P>(Chris Fraser, Australia)</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Tk_familypractice</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.psnw.com/~alcald/Tk_familypractice.README.html
+<P>(Alexander Caldwell, California)</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>FreeMed</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://freemed.org/
+<P>(Jeff Buchbinder, Connecticut)</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>FreePM</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.freepm.org/
+<P>(Tim Cook)</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Circare</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.minoru-development.com/circare/
+<P>(Brian Bray, Joseph Dal Molin, Hamilton, Ontario)</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>QQ-MIM</B></TD>
+
+<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://lorenzo.uwstout.edu/QQMIM/medicalfreesource.html
+<P>and /QQMIM/qq4.html</TD>
+</TR>
+</TABLE>
+
+<P>A listing of most projects is at
+<P><FONT FACE="helvetica, helv, geneva">http://www.minoru-development.com/en/healthlinks.html#projects</FONT>
+<P><B><FONT SIZE=+1>A brief history of free software:</FONT></B>
+<P>(See http://www.fsf.org/gnu and http://www.tuxedo.org/~esr/writings/hacker-history/)
+<P>In the 1970's, the success of proprietary operating systems, particularly
+UNIX, created frustration in the academic community, who could not use
+these systems for study or teaching. This was a tremendous hindrance to
+their effectiveness. This situation motivated Richard Stallman to begin
+the GNU project in the mid 1980's. At first this project produced utilities
+and applications, but its fundamental goal was a free OS. Meanwhile, the
+proliferation of different flavors of UNIX resulted in development of the
+POSIX standards. In 1991, the world still was without a functional OS that
+was available for teaching.
+<P>The FSF had already begun an OS project, but this had bogged down due
+to hardware limitations and its own complexity. Into this vacuum, Linus
+Torvalds in 1991 posted his preliminary work on making a UNIX-compatible
+OS for Intel processors. This project was sufficiently simple and its goals
+quite clear; and the felt need was very great, so that it attracted the
+interest of many skilled programmers around the world.
+<P>It is important to realize that Linux was initially a success: it immediately
+was a useful teaching tool and its development quickly liberated academicians
+from the vendor lock that had paralyzed them for a quarter-century. These
+developments are more important to the rapid progress of software and connectivity
+than is its subsequent commercial success, as free access by programmers
+to code and basic tools makes them significantly more efficient and more
+effective.
+<P>A by-product of this success has been a controversy over the meaning
+of "free" and the development of an interesting variety of points of view
+on what restrictions are or are not important for the continued development
+of such software. The controversy ends up, of course, with some disagreement
+over whether there is some code that must be or should be confidential
+and proprietary in order to ensure the viability and reliability of businesses
+that develop it and are expected to maintain it.
+<P>To review the open-source material, visit
+<P>http://www.opensource.org
+<P><B><FONT SIZE=+1>The Moral Basis of Free Software/Open Source.</FONT></B>
+<P>Now that I have your full attention, let me explain why I use the word
+"moral" here. Although I have seen programmers deride the enthusiasms of
+f-s/o-s enthusiasts as "religious," this accusation is inaccurate, and
+the movement is not in any way a religion. The word "moral" is an important
+secular term to describe the fact that when we form groups and associations,
+we encourage and follow rules that define the group and that help the group
+produce benefit for all its members. Such rules are, in the most general
+sense, "moral" obligations, which are relative to the goals of the group.
+The social nature of mankind is such that group loyalties are strong, and
+the norms of any tightly-knit group may sometimes be enforced with "religious"
+zeal. The f-s/o-s movement was begun by people with strong convictions,
+and continues to attract some people with strong convictions about what
+it can and should be.
+<P>Hence, to understand the strength of the "free software"/"open-source"
+community and the vigor of the debates over proper handling of free software,
+we must notice that these phenomena involve groups of people, not individuals.
+These groups did not form on the basis of economic need, but of educational
+and functional need. Economic use followed.
+<P>Let's step aside briefly to understand the free-software/open-source
+revolution better:
+<P>Capitalism has traditionally been a bastion of individualism, and personal
+freedom is thought to be part of its foundation. On the other hand, academia
+and commercial enterprise have often been in conflict, partly because free
+exchange of ideas is the most important principle of an academic community,
+while privileged knowledge has always been a source of riches for the businessman.
+<P>In the centuries since Adam Smith's work, economists have paid ever-closer
+theoretical attention to the idealized construct of "perfect competition."
+Two of the requirements of perfect competition are freedom to participate
+in the economy ("to trade") and equal access to information. Businessmen
+who profess loyalty to "competition" and to the ideals of capitalism are
+assertive in advocating their rights to freely participate in trade and
+to compete, but don't share information, favoring imperfection as long
+as it favors them. Academicians have paid scant attention to trade and
+have devoted much attention to freedom of ideas, often with trumpeting
+and breast-beating.
+<P>In 1986, David Gauthier famously wrote in <I>Morals by Agreement</I>
+that a perfectly competitive market, "Were it realized, would constitute
+a morally-free zone, a zone within which the constraints of morality would
+have no place. ...this is not a fault, but the essential virtue of the
+market." This libertarian ideal has had significant influence on the behavior
+of judges and businessmen. But it is not correct. The reason it is not
+correct, and the fact it is not correct, are important to understanding
+the vitality of the open-source, free-software community.
+<P>In his forthcoming book, <I>The Moral Conditions of Economic Efficiency,
+</I>Walter
+Schultz analyzes the Fundamental Theorem of Economics and clarifies its
+presuppositions, and proves rigorously that an idealized economy cannot
+be efficient if the agents acting within it have neither moral constraints
+nor an internal incentive to act morally.
+<P>One key to understanding is that "morality," at its kernel, is neither
+religious nor absolute. It is relative to the values of a particular community.
+Schultz, a philosopher, presents a minimal definition of "morality" that
+is valid across Western and modern Eastern cultures:
+<P><I>Morality</I> is
+<BR> - a normative social practice,
+<BR>
+the purpose of which pertains to collective and individual well being,
+<BR> - guided by beliefs held in common,
+<BR>
+concerning
+<BR>
+- criteria by which to evaluate behavior,
+<BR>
+- criteria for mutual responsibility, and
+<BR>
+- procedures for mutual accountability.
+<P>That is, "morality" is the word we use to describe the behavioral standards
+or limits a group evolves to define itself, for the benefit of the group
+and the individuals in it. The well being of the individual does not necessarily
+conflict with group well-being, but when they do conflict, the balance
+is tipped somewhat in favor of the well being of the group as long as the
+individual is not harmed.<SUP>2</SUP>
+<P>We humans are social animals; we--that is, our self-concept and our
+public identity--are significantly defined by the groups we belong to and
+which will have us. Some of our deepest convictions and strongest emotions
+involve group dynamics. Much of what we regard as "right" or "wrong," "just"
+or "unjust," stem not from religious moral absolutes but from informal
+group or community dynamics.
+<P>So Robert Young of Red Hat is taking a consciously moral stance when
+he states that Red Hat releases all its code because "it is the right thing
+to do," and when he refers to partnerships with developers and users as
+"setting up an ecosystem" that creates a "virtuous circle." (See PC Week,
+Sept. 27, 1999, p.100)
+<P>As Linux has drawn millions into the fringes of the free-software movement,
+we have seen vigorous debates over the standards and "normative constraints"
+which are proper for this evolving community. These debates are an essential
+part of community formation and evolution; their outcomes define the community
+and the nature of the "well being" it confers on its members. The enduring
+conflict of values and priorities between the commercial and the academic
+communities, both of which can benefit from free software, has fueled the
+fires of debate. The existence of "community" <I>does not</I> imply <B>consensus</B>!
+Anyone who's lived in a small town knows this.
+<P>In fact, the objectivity and the personal restraint of most participants
+in this debate is more remarkable than the occasional bursts of intolerance
+or foolish egocentrism. (As opposed to prudent egocentrism...)
+<P>Robert Young notes the lack of consensus in the same PC Week interview:
+"This term "Linux Community" and the implication to outsiders that the
+community is cohesive--it has never been cohesive. It is, far and away,
+the most argumentative, acerbic group I have ever had the misfortune to
+be a part of . But don't get me wrong. That has been good for the technology.
+It's a community that values truth and values engineering excellence over
+marketing and compromise."
+<P><B>Academic Freedom and Capitalist Opportunity.</B>
+<P>The history of the medical community is a paradigm for what has been
+developing in the free software/open source community, as the same debates
+have occurred across recent centuries.
+<P>Two and three hundred years ago, doctors, particularly surgeons, were
+entrepreneurial craftsmen. Those who had discovered secrets of anatomy,
+surgery, or medication used this special knowledge to make themselves famous
+and rich. They used this knowledge to attract clients and apprentices,
+and an apprenticeship to a famous surgeon was not purchased cheaply. Their
+discoveries were published after decades, or posthumously, if at all.
+<P>In fact, publication itself is a late development. Gutenberg's invention
+of the printing press was not done in order to make mass publication possible.
+The motive and the first use was simply to reduce the production cost of
+illuminated manuscripts, to sell these for the (very high) going rate,
+and make a large profit. Mass communication became possible only with inexpensive
+methods of typesetting, paper production, and printing -- and with the
+discovery that a mass market might indeed exist, a nineteenth-century phenomenon.
+<P>Today doctors, particularly surgeons, still put enormous energy and
+politically-sophisticated efforts into justifying and protecting our high
+fees and comfortable incomes. But this is no longer done through entrepreneurial
+promotion of medical secrets; it is done by maintaining special expertise
+in areas of highly complex <I>public</I> knowledge and providing <I>service
+</I>of
+extremely high quality.
+<P>In fact, if a health practitioner claims to have special, secret knowledge,
+this is always assumed to be quackery -- until it is published and subjected
+to the rigors of scientific validation. The "doctor" who practices strictly
+entrepreneurial medicine using "peculiar" knowledge is viewed contemptuously
+by physicians, and is in fact acting immorally based on the standards (social
+norms) of the medical community using the cross-cultural definition of
+"morality" above.
+<P>This is exactly the transformation that free software, particularly
+GNU/Linux, is fostering. Software is becoming a community asset, and community
+ownership is becoming a moral standard.
+<P>Why is this happening?
+<P>Because there is unequivocal <I>community benefit.</I>
+<P>The justification for academic freedom is ultimately that common knowledge
+benefits society -- "community" in the broadest sense.
+<P>The reason that medical knowledge has become public property is that
+there have been successive revolutions in knowledge of anatomy, surgical
+technique, anesthesia, bacteriology, antibiotics, physiology, pharmacology,
+and now immunology and molecular genetics which have transformed medical
+care from shamanism to reliability. To share this knowledge benefits mankind
+-- "community" in the broadest sense.
+<P>And the reason that proprietary operating systems and basic tools are
+coming under the rubric of academic freedom -- the underlying significance
+of "free software" -- is that computers are becoming a ubiquitous and essential
+tool of society.
+<P>Our definition of "moral" limns (highlights) the observation that social
+benefit, in practice, outweighs individual benefit. That is, if a group
+is to exist at all, benefit to the group must outweigh benefit to an individual
+when they are in conflict. To put it another way, the group exists to benefit
+its members: this is an individual benefit. But when taking an action that
+benefits an individual will "harm" the group in some way, then the individual
+is "morally" constrained in some way to avoid the harm; ideally without
+also harming the individual.
+<P>The "harm" that proprietary, secret code brings to a community of users
+(end-users and the programmers that serve them) is (for examples) delayed
+development and failure to resolve bugs, frustration from achieving goals
+of known feasibility, inefficiency, and financial exploitation. The "benefit"
+of open code is (for examples) to accelerate development, enhance efficient
+use of code, freely exchange and debate ideas, which leads to improved
+algorithms and techniques, to expedite agreement on communication and exchange
+protocols, and to hinder financial exploitation and gouging by introducing
+competition for service.
+<P><B>How does this apply to the development of medical software?</B>
+<P>It means that those features of software which will be of general use
+to the entire medical community in promoting communication, appropriate
+data exchange, and those features which tend to improve health care in
+society should be subject to the principles of academic freedom: the code
+should be open.
+<P>It means that software designed to perform tasks that tend to be unique
+to organizations or matters of individual preference, or knowledge that
+is special to a particular enterprise need <I>not</I> be open; in fact,
+opening such code does jeopardize the security of the vendor.<SUP>3</SUP>
+<P>Nevertheless, users of software tools are learning that open code helps
+protect them from vendor lock and exploitation, and sophisticated users
+are beginning to require, as part of vendor agreements, that the code as
+well as the executables be released to the user, typically with a non-disclosure
+agreement executed by the user on behalf of the vendor.
+<P><B>Rights of the Programmer</B>
+<P>Dr. Schultz, after proving rigorously that economic inefficiency is
+the outcome of a morality-free community, then asks what are the normative
+conditions that will provide efficiency in an idealized competitive economy.
+He rigorously proves that at least four exist in respect to economic exchange
+situations, which happen to moral rights in the cross-cultural sense already
+given. I list them without his proof:
+<BR><FONT FACE="symbol">·</FONT><B> A right to truth.</B> This is
+a right to truth regarding goods and services and acceptable prices; it
+entails an obligation not to lie.
+<BR><FONT FACE="symbol">·</FONT><B> A right to property.</B> This
+permits a set of defined property rights; it entails an obligation against
+theft.
+<BR><FONT FACE="symbol">·</FONT><B> A right to autonomy.</B> This
+is a liberty right, to act freely within group constraints; it prohibits
+exploitation and slavery.
+<BR><FONT FACE="symbol">·</FONT><B> A right to welfare.</B> The
+Fundamental theorem presumes an "initial consumption bundle;" this right
+obligates the community to restore a minimally adequate consumption bundle
+to the person whom disaster strikes; everyone else contributes to its restoration;
+it entails an obligation to give. (This is what commercial insurance and
+government disaster relief provide.)
+<P>It is useful, in seeking to understand the nature of the free-software/open-source
+movement, to extend these rights to production situations, specifically
+the economics of software production and service. In this sense, what do
+these rights entail? I attempt here to connect them with the known mores
+of the community, to the extent that there appears to be any consensus.
+<P><FONT FACE="symbol">·</FONT> <B>A right to truth.</B>
+<P>The hacker has a right to verifiable code.
+<P>There is an obligation not to distribute (deliberately) obfuscated code,
+rogue patches or binaries, Trojan horses, and not to give false instruction.
+<P><FONT FACE="symbol">·</FONT> <B>A right to property.</B>
+<P>There can be a set of ownership rights by which a hacker may own and
+distribute code, and there is (separately) an absolute right to have possession
+of code.
+<P>This right also implies a right to hack; there is an obligation not
+to hinder hacking, an obligation not to plagiarize code; and an obligation
+not to destroy code or its repositories (an obligation not to disseminate
+destructive viruses).
+<P>This property right gives a hacker the right to earn a living from the
+community's code and his/her own modifications.<SUP>4</SUP>
+<P><FONT FACE="symbol">·</FONT> <B>A right to autonomy.</B>
+<P>There is a right to liberty within the community; to hack in whatever
+way the individual wishes; the right not to be exploited, interfered with,
+or enslaved. It entails an obligation not to intrude on the autonomy of
+others (e.g., with false announcements).
+<P><FONT FACE="symbol">·</FONT> <B>A right to welfare.</B>
+<P>There is a right to receive a "grubstake" from the community, either
+as a newbie or after a destructive disaster. This entails a right to learn
+to hack new code (apprenticeship) and an obligation to teach others in
+the community. (Property welfare is in our society covered by commercial
+insurance.)
+<P>Programmers in the free-software/open-source community are not, of course,
+in any sense consciously working under these principles; what I have done
+is to attempt to take a well-defined set of theoretical rights that apply
+to an idealized exchange economy and ask informally whether there is commonality
+with what I've observed in the f-s/o-s community. These parallels are interesting.
+<P><B><FONT SIZE=+1>Motivations of Open-Source Participants</FONT></B>
+<P>What causes programmers to participate in the f-s/o-s community? Several
+people have commented on this with interest, and after reading some of
+this commentary and after analyzing my own observations, the only possible
+conclusion is that people participate in this activity for the full range
+of reasons that they participate in any other activity, and it is not realistic
+to attribute any particular motive to the entire community, even though
+one part of the community might be easily characterized for one reason
+or another.
+<P>Regardless, there are some important factors to consider, that are important
+in understanding the free software / open software communities.
+<P><B>Non-economic incentives.</B>
+<P>In the beginning of free software, there was "officially" only Richard
+Stallman, and he has made his motives clear in his own writings. Some of
+those who latched on perhaps shared his motives, but it's also clear that
+not all did. Nevertheless, for several years, free and open software was
+not commercially useful, so while economic dreams might exist, participants
+had to satisfy their economic needs elsewhere. Thus free software was the
+hobby of the "rich," and those who devoted time to it were doing so for
+reasons other than simple avarice.
+<P>By "rich," I do not mean that the participants have been or are financially
+wealthy; only that their survival needs are somehow satisfied in a way
+that left considerable time for experimentation with free software. Some
+may have been wealthy; most simply had "day jobs" or were students with
+the usual sources of student support.
+<P>My own impression, from the sidelines, was that to some extent the free
+software community was a "sandbox culture." That is, like play in a child's
+sandbox, some of the work was done for the sheer pleasure of being able
+to build something by yourself, which one did not have the opportunity
+to do otherwise, for any variety of natural reasons. Linus Torvalds was
+quoted in an interview in the November, 1999, <I>Linux Journal</I>, as
+saying, "Linux didn't start out as a message to the masses. Unlike Richard
+Stallman, I really don't have a message. He has one and can go on about
+it forever. I'm just an engineer. Let's see. Do things well! Do them with
+heart!..." The desire to build seems to be built into the human psyche,
+and to build well is a natural goal.
+<P>It is also clear that some participation is morally based, as Stallman's
+seems to be; often this is a response or adverse reaction to negative commercial
+values such as greed or debilitating secrecy. In any case, as a community
+develops, it intrinsically develops a morality that defines its borders
+and its purposes. This results in strong and even militant advocacy of
+these characteristics. To the extent that non-economic incentives are seen
+as an essential characteristic of the community, there will be emotional
+and persuasive argument against permitting economic incentives to guide
+the community. We have seen such debates.
+<P><B>Economic Incentives.</B>
+<P>The quality and usefulness of the mature GNU/Linux system has been great
+enough to make these tools useful in many ways to people who must make
+their living with software. This has led to non-commercial successes such
+as <I>Apache</I> and <I>Debian</I> and to commercial successes such as
+<I>Red Hat
+</I>and <I>Caldera.</I> As a result, we now have a larger community,
+which presently includes all the usual economic motives for participating.
+This has resulted in the "free" versus "open" software debate, and the
+recognition by most people that it is economically appropriate for some
+software not to be free. (Overall, the commercial-software community does
+not understand the strength of freedom for power and quality, does not
+understand its benefits to the end user, and does not understand when software
+is most suitably "open" and when it is suitable to keep it "closed.") The
+agreement that some software is best "free" and other software may be suitably
+proprietary has, of course, resulted in vigorous and sometimes intense
+debate about where to draw the grey zone.
+<P><B>"Open" vs. "closed" medical software.</B>
+<P>The medical community brings a special complication to this debate,
+because the information that is kept by this community is <B><I>confidential</I>
+</B>.
+The requirement for confidentiality will inevitably confuse the debate
+about what aspects of medical software may be open-source. Some of this
+confusion will likely be deliberate. While the code may be free, the information
+it contains and manipulates must never be free. It is perhaps less obvious
+that commercial exploitation of this confidential information, whether
+or not behind the veil of closed code, is unethical.
+<P>Briefly, our need in the medical community is for open-source connectivity
+tools, common databases, and open-source security and authentication tools.
+That is, we medical professionals need to be able, on behalf of good care
+for our patients, to transfer clinical information electronically to other
+professionals involved in a patient's medical care, either concomitant
+with a referral or by the direction of the patient. At the same time, we
+must protect this data from mining by insurance companies, government agencies,
+and interested individuals who have no right to the information, and who
+might use it in ways adverse to the patient's benefit.
+<P>It is clear that user interfaces, productivity tools, and display techniques
+can be as proprietary as desired. Business offices, medical ancillary staff,
+and physicians do need to have top-level tools that help them work efficiently,
+and this is best done by being able to customize theses tools to local
+and individual needs.
+<P><B><FONT SIZE=+1>Open-source Medical Software Projects</FONT></B>
+<P>With this philosophical rubric in mind, let's review current open-source
+projects and consider how they meet the need for free code in medical information
+management.
+<P><B><FONT SIZE=+1>Classification of software:</FONT></B>
+<BR>
+<TABLE BORDER CELLPADDING=0 WIDTH="525" >
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER><B><I><FONT FACE="helvetica, helv, geneva">Project</FONT></I></B></CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER><B><I><FONT FACE="helvetica, helv, geneva">Classification</FONT></I></B></CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Perceptions</CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Creviceware</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>DHCP / VistA </CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Whaleware</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Arachne</CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Creviceware</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Littlefish</CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Wholeware</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Tickle-FP</CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Taskware</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>FreeMed</CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Cloneware</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>FreePM</CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Designware</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Circare</CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Foundationware</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>QuickQuack</CENTER>
+</TD>
+
+<TD VALIGN=TOP WIDTH="50%">
+<CENTER>Demoware</CENTER>
+</TD>
+</TR>
+</TABLE>
+
+<P>The classifications are whimsical, and should not need elaborate definition;
+there is no "hidden meaning."<B><FONT SIZE=+1>Perceptions</FONT></B>
+<P>At the beginning of this decade, the Roger Maris Cancer Center was formed
+in Fargo, ND. The staff was faced with the challenge of managing four legacy
+systems which could not communicate with each other. Important goals were
+to develop an information support system (for the clinicians brought together
+by the center) and to increase business efficiency. The usual barriers
+were encountered while trying to link the four legacy systems through cooperative
+efforts with the vendors, and during this process Linux emerged into the
+world.
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Dr. Wettstein has
+offered some reflections on my comments, which I quote in this typeface
+(Helvetica).</FONT></FONT>
+<P>Dr. Greg Wettstein developed this information system, deployed with
+Linux 0.96c and continuously upgrading kernels as Linux matured, which
+successfully achieved all the functional goals of the group, and which
+survived from 1993 until 1997, when it was replaced by a less efficient
+commercial system. The design and functionalities of <I>Perceptions</I>
+are important to this project.
+<P>I call <I>Perceptions</I> "creviceware" because an important prerequisite
+for clinical usefulness is to fill the (very large) interstices left by
+commercial software, which is characteristically single-task software,
+and which is never designed primarily with the information needs or efficiency
+needs of clinicians in mind.
+<P>Using shell scripts, Dr. Greg created a set of "interrogatory robots"
+to mine the legacy databases. When a patient came to the center and registered,
+these interrogatory robots were dispatched from the workstation to collect
+data for a packaging utility. This data packaging utility followed the
+patient through the center and additional data was added. Update utilities
+were used to maintain parallel database concurrency. A modular mid-level
+tool set, written in Perl 5, was used to manage this process. The user
+interface was written with tcl/Tk.
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1><I>Perceptions</I>
+was basically built as a series of software packages that sat on top of
+the information distribution system. This design strategy basically flowed
+from the fact that Perceptions started out as simple patient tracking software.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>This paradigm actually
+proved to be quite powerful. One of the most interesting features of the
+system from a pharmacy perspective was that the pharmacy component of the
+tracking system actually 'looked' for patients that were scheduled for
+treatment. This work was actually motivated by my study of Just In Time
+Inventory (JITI) control methods that were being deployed in the late 1980's
+and early 1990's in American industry.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>A big component of
+ambulatory treatment of cancer patients involves administration of multi-day
+treatment regimes, eg. VP16/CDDP, CF/5-FU. The pharmacists would designate
+that treatment orders were multi-day in nature and Perceptions would immediately
+schedule subsequent treatment dates. On subsequent days the pharmacy software
+would watch the tracking logs to see when a patient registered at the front
+desk. When they did the orders would automatically be executed in the pharmacy
+and labels created to initiate creation of the chemotherapy product.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>This system allowed
+logical enhancements to be made to the system. One of the problems with
+JITI was that as dose-intensity increased, situations began to arise when
+the patient's clinical state warranted discontinuation or modification
+of therapy. The pharmacy tracking system component was modified to implement
+a state-engine which required that multiple criteria be recognized from
+the tracking log analysis before an error could be generated. For example
+the patient had to check in to the front desk and be placed in a treatment
+room before the order would be executed. Extensive work was being initiated
+on this component of the software when the roof fell in.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>The Linux workstations
+that composed the system basically replaced terminals at many locations
+that were used to contact legacy systems. Typically these terminals had
+serial connections to the legacy systems which Linux talked to. When a
+patient arrived at the front desk an initial tracking message was broadcast
+to all the workstations. These workstations than contributed additional
+information that they were able to find on these patients and broadcast
+this information as well.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>The software was
+designed on the following hierarchy:</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Shell script wrapper
+-> Perl functionality -> tcl/TK interface</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>All the utilities
+and programs were encapsulated with a shell script wrapper which did things
+like parse options etc. Major functionality was implemented with Perl programs
+which could stand by themselves if necessary. In the case where a GUI was
+needed the Perl scripts were designed to open a wish shell and would talk
+back and forth over a bidirectional pipe to implement the user interface.</FONT></FONT>
+<P>This system provided a means to perform the fundamental clinical information
+task of the center -- collection, organization, and presentation of clinical
+data -- and also increased staff efficiency sufficiently that a 75% increase
+in patient load required only a 20% increase in staff.
+<P>Subsequent development of mid-level languages and standards would make
+this task easier today, but functionally the needed design is the same:
+both horizontal and vertical modularity of software, particularly to separate
+the process of data acquisition from the task of presentation.
+<P>Two crucially important features of this system, not present in any
+commercial software I've seen, are that it was specifically designed :
+<P><FONT FACE="symbol">·</FONT> to aid clinical decision-making
+by collecting, organizing, and displaying information for physicians, and
+<P><FONT FACE="symbol">·</FONT> to make the work of business staff
+and ancillary medical staff more efficient.
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Another major feature
+of the system is that it was actually implementing functional data interchange
+long before XML was in vogue.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>The data abstraction
+was carried out interestingly enough by using TeX. When a pharmacist entered
+an order into the pharmacy component of the system the function of the
+data entry was to basically encapsulate all the patient information into
+a TeX script. Running the TeX script through a document header file specific
+to the needs of the pharmacy resulted in generation of IV labels etc. The
+same TeX script run through a document header specific to the nursing unit
+caused it to generate a charting label which met the requirements laid
+out by the Oncology Nursing Society (ONS) for chart notes.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>This worked to support
+one of the most important design criteria of the system. This criterion
+was that information obtained and/or entered by one discipline or group
+within the center should work to increase or aid the functioning of other
+groups. More simplistically we were trying to address the age-old issue
+of having to double enter data.</FONT></FONT>
+<P><I>Perceptions</I> is no longer in use due to the merger of the Cancer
+Center with a large hospital and the administrative insistence on a commercial
+"solution." Perceptions is not maintained, nor is the code available to
+the community. Dr. Wettstein and his colleague, oncologist Paul Etzell,
+MD, presented an excellent summary of their work at the first MIT conference
+on Free Software in 1996. Dr. Wettstein has promised to convert this paper
+to .html and .ps or .pdf and place it on his web site "shortly" at
+<BR> http://www.enjellic.com/
+<BR>and he is considering making the entire code available to the free
+software community.
+<P><I>Perceptions</I> deserves a place of honor in f-s/o-s annals not only
+as the first open-source medical information manager but also because it
+was thoughtfully conceived, ergonomically designed, and well engineered.
+<P>We hope that future medical information management software will be
+not only creviceware, but the central software tool of the enterprise.
+Still, the special strength of the GNU/Linux system is in communications
+and data acquisition, so that this is the best choice for linking disparate
+systems no matter what other tasks are assigned to it.
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>I would have to say
+quite unequivocally that the most important component of the success of
+Perceptions was that it was based on an open source philosophy and toolset.
+I was never really afraid of failure since we were in control of all aspects
+of the project. If something didn't work we simply invented something different
+that did work. That sense of flexibility and solution mobility simply does
+not exist when working with commercial solutions.</FONT></FONT>
+<P><B><FONT SIZE=+1>DHCP / VISTA</FONT></B>
+<P>This is the medical software project of the (USA) Veterans Administration
+system. We'll call this <I>Whaleware</I> because it is the largest public-domain
+medical information mammal on earth. Originally called the DHCP (Decentralized
+Hospital Computer Program), it was begun in 1982. It is now called <B>VistA</B>,
+Veterans Health Information Systems & Technology Architecture. Information
+about this sophisticated and complete medical information system is available
+at the VA's web site at
+<BR> http://www.va.gov/vama.htm
+<BR>and at a programmers' web site
+<BR> http://www.hardhats.org
+<BR>where it is maintained by volunteers who are current and former employees
+of the Department of Veterans Affairs (DVA). The VistA system is available
+on CD-ROM through a Freedom of Information Request, which can be initiated
+at the hardhats web site. Some software components have been published
+to the hardhats web site. A full descriptive monograph is published at
+http://www.va.gov/monogrph.htm
+<P>VistA is clearly well developed and in use. It comprises more than 80
+integrated DHCP applications which include both administrative and clinical
+functions, including medical imaging, laboratory management, and pharmacy
+management.
+<P>The M computer language is the foundation of DHCP / VistA. This non-proprietary
+4GL began life at Massachusetts General Hospital as MUMPS, and has become
+an ANSI-standard programming language, database management system with
+related bindings and protocols (for a non-technical explanation of M, see
+http://www.mcenter.com/mtrc/whatism.html).
+<P>I do not know whether this work, designed around the needs of the VA
+system, could be "ported" to the private-sector medical community with
+an acceptable expenditure of time and effort. There are two barriers to
+use: the M language, which "makes sendmail scripts seem organized and Perl
+seem well structured;" and that it was designed around the needs of the
+VA system, which is like no other medical organization on earth.
+<P><B><FONT SIZE=+1>Littlefish</FONT></B>
+<P>The <I>Littlefish</I> project is an ambitious enterprise led by an Australian,
+Chris Fraser, to bring the power and efficiency of database tools, particularly
+epidemiologic analysis, to third-world and remote practices. The project
+will follow the GEHR or Good Electronic Health Record standards (see http://www.gehr.org/
+The GEHR standards are at http://www.gehr.org/gehr_architecture.html in
+.pdf format).
+<P>I lightheartedly call such software "wholeware" because their goal is
+to be a complete solution to the perceived needs. This project is in design.
+I have not investigated it in detail yet.
+<P><B><FONT SIZE=+1>Tk-FP</FONT></B>
+<P>This is a personal project of Dr. Alexander Caldwell, a family physician
+in California. He uses tcl/Tk to produce an information-gathering and documentation
+system. Features include menu-driven progress note generation, prescription
+management, preventive health management, and importation of lab values
+from his lab information system.
+<P>This software is available for Linux, Windows 95/98/NT, and Macintosh
+OS's. It is oriented toward specific tasks important to the physician,
+so I'll call this "taskware."
+<P>Dr. Caldwell is constructing a system that serves the primary care physician's
+ergonomic needs, as can be seen by his list of working modules. Inspection
+shows that some of these tasks are essential to efficiency, others are
+decorative enhancements made possible by powerful software tools. I quote
+from his own description.
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Insert drawings into
+progress notes - mods to Impress, a Tcl/Tk program. Store templates for
+various anatomical or other drawings, draw on them, then save directly
+into a progress note.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Lab Results - automated
+download from an IBM AS/400 directly into Tk_familypractice with some user
+intervention on Linux only. Requires a TCP/IP connection to the AS/400.
+Script edited by hand to suit each user's log in and host configuration.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Clinical Decision
+MAPs - integrated with progress note writing module. Tcl/Tk widgets used
+in clinical decision making algorithms create chart notes as you interact
+with the program.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Prescription Module
+- Fax based, stores and sends drug refill information to drugstores. The
+stored data can be used to compile a medication list for inclusion in clinical
+notes. Prints hardcopy Rx and patient education monograph for the patient.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Demographic Data
+Module - addresses, phone numbers etc.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Problem List Module
+- stores problem list, allergies, past medical history. Data can be inserted
+into clinical notes.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Progress Note Generator
+- History and Physical Synthesizer - GUI based program that presents menus
+for numerous common office problems or presenting complaints. Your commonly
+used phrases can be inserted at the click of a mouse. Phrases are easily
+added or removed from the menus. Automatic saving to patient's file and
+a daily file that can be printed out at the end of the day for hard copies.
+Integrated with the other modules so data from problem list, allergies,
+medications can be inserted into the notes with the push of one button.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Progress Note Display
+Module - data stored as HTML so you can insert pictures, tables, etc. and
+enables data to be accessed via a web server. Can work with IBM's Via Voice
+for speech recognition under Windows 95/98, or run the Linux version on
+one machine and use X-win 32 (an Xwindow server that runs on a Windows
+machine) for the display to dictate into the Tk text widgets using Via
+Voice with the data stored on the Linux machine.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Allergy Checking
+- checks prescription refills against patient's allergies</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Drug Interactions
+- checks prescription refills against the patient's drug profile for drug
+interactions.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Drug Doses - checks
+prescription refills for appropriate doses, with Pop-up menus.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Drug Information
+- patient package insert information can be viewed or printed out for the
+patient.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>HMO authorization
+request generation - generates an HMO authorization request form that can
+be faxed or send via e-mail to an HMO office. Includes copies of progress
+notes you specify.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Recall Letter Generator
+- when writing a progress note, you can set a future date for a recall
+letter .</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Referral Letter Generator
+- fax or e-mail a referral letter to the consultant, including a copy of
+your patient's progress note if desired. You just highlight the part of
+the note you want to send and pick from a menu of consultants you use.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Statistics - view
+or print various stats on no. of prescriptions, list of patients on a certain
+drug, most commonly prescribed drugs etc.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Graphic data plotting
+- scan your data and plot weights, blood pressures and lab data, etc.,
+over time.</FONT></FONT>
+<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>The modules are linked
+so that if you are working on a patient's drug refills, all his or her
+data in the other modules are pulled up at the same time so you have access
+to all information on that patient if you need it.</FONT></FONT>
+<P><B><FONT SIZE=+1>Arachne</FONT></B>
+<P>The Arachne project was a "Toolset for the Development of Clinical Workstation
+Applications from Distributed Components." It currently is a more general
+tool designed to provide an extensive, CORBA-2 compliant, object-oriented
+tool set for integration of disparate systems. The first iteration was
+done in order to permit the development of clinically useful tools. The
+Arachne group, whose principals were IT specialists in Massachusetts, was
+part of an "Internet Collaboratory" project, InterMed, that included medical
+informatics specialists at Columbia, Stanford, Massachusetts General Hospital,
+and others. This part of the project has been abandoned. The open source
+license does not include any healthcare-specific parts of the code. So
+at this point the project has been pared down to purely an open source
+CORBA implementation.
+<P>The motivation for its development was the frustration inherent in the
+current state of commercial medical software, based primarily on large,
+single-vendor systems not designed for integration or customization. This
+is characterized by a lack of common software infrastructure, services,
+or paradigms. The Arachne project has as its goal the ability to construct
+richly interoperating software components via a suite of cross-platform
+software tools, collectively referred to as Arachne. A description of this
+ambitious project is at
+<P>http://www.arachne.org/arachne_overview.html
+<P>Work on Arachne began in 1992. Its first release was in August, 1997;
+its current version is 0.8.4.2, is dated Dec 16, 1998. The developers of
+course discovered that cost and limited function prohibited the use of
+commercial products as a basis for portable component development and integration.
+The development of Arachne required laborious tracking of relevant and
+conflicting industry standards, and consists of several largely independent
+subsystems, which are capable of platform independence and permit the construction
+and integration of arbitrary software components. Arachne is currently
+available for Windows 95/NT, Linux, HP/UX, SunOS, and Macintosh .
+<P>Arachne fits into the category of "creviceware" because its most important
+purpose was to permit connectivity and data exchange for the purpose of
+presenting integrated medical data to clinicians to support decision making.
+<P><B><FONT SIZE=+1>Freemed</FONT></B>
+<P>This is a project of a Connecticut IT professional, Jeff B, and a podiatrist.
+It is designed to be an functional clone of a commercial medical management
+system, The Medical Manager
+<P>(http://www.mdmgr.com/).
+<P>It uses MySQL, a proprietary SQL server. It is functional. I have not
+been able to access its site for a couple of weeks, so I don't know the
+current public status of the project.
+<P>Its chief limitation as an open-source/free software "solution" is that
+it was designed to duplicate the functionality of a particular commercial
+product, and thus has the inherent limitations that this design approach
+entails.
+<P><B><FONT SIZE=+1>FreePM</FONT></B>
+<P>FreePM is a new project, aiming to produce a completely open-source
+practice management system. Design was begun in June, 1999.
+<BR> See http://www.freepm.org/
+<P>The design of this project appears to be carefully done, and the database
+is currently in design.
+<P>PostgreSQL is being used for the database; ZOPE for middleware. They
+plan to use CORBA based OMG's (object management groups).
+<BR> see http://www.omg.org/omg/background.html
+<BR>
+http://www.zope.org/
+<BR>
+http://www.corba.org/
+<BR>
+http://www.postgreSQL.org/
+<P>FreePM's efforts are being coordinated with Circare.
+<P><B><FONT SIZE=+1>Circare</FONT></B>
+<P>Circare is a new project to build an open source patient centered network
+index system. It is a commercial project of Minoru Development, Inc., a
+Toronto firm. Primary funding has been by the non-profit Hamilton, Ontario,
+Information Network, HappIN. The project's goal is to provide key infrastructure
+for Regional Health Networks, by developing new modules which include
+<BR><FONT FACE="symbol">·</FONT> a clinical management system,
+<BR><FONT FACE="symbol">·</FONT> a Web-based physician-pharmacist
+consultation system (this involves an effort by pharmacists to electronically
+notify physicians of the full list of medications--including herbal remedies--taken
+by an individual and potential interactions; and
+<BR><FONT FACE="symbol">·</FONT> a geriatric patient index: this
+includes a minimum clinical data set.
+<P>Circare is a client and provider index that ties together the information
+about a single patient and makes it available securely to care providers
+in a distributed network. Thus it aims to be a solution to the "portability"
+problem that hinders the exchange of clinical information necessary to
+care for patients as they are referred from one provider to another in
+an extended health care system, or as they necessarily change primary providers
+for all the usual reasons.
+<P>Overall, this appears to be a sophisticated and well-managed project
+by experienced IT professionals.
+<P>Circare is open source software, distributed under the GNU public license:
+<BR> http://www.fsf.org/copyleft/gpl.htm
+<P>Minoru Development maintains a web page that collects all the open-source
+efforts related to health care
+<BR> http://www.minoru-development.com/en/healthcare.html
+<P>Minoru sponsored an Open Source Practice Management Summit, held in
+Toronto, Canada, on September 23, 1999. I was not able to attend this conference,
+and have not seen a summary of it yet. At this conference, Minoru staff
+offered to coordinate open-source coding projects by sponsoring a discussion
+group and offering space.
+<P><B><FONT SIZE=+1>QQ-MIM</FONT></B>
+<P>QQ-MIM is my project. It began in 1985, when I changed practices, and
+been able to learn about database, medical software, and microcomputers,
+so that the clinician's need to gather information came into focus while
+I adjusted to a new charting system at the same time that I became fully
+aware of the potential of computers as a tool to information storage and
+retrieval. I wrote a long specification that I whimsically called "QuickQuack"
+that described the ergonomics a physician needed in such a system, but
+was unable to persuade any of the leaders I knew in software firms to invest
+their capital in solving all the world's problems.
+<P>It also turned out that the leadership of my clinic and most of the
+other physicians were extremely comfortable with the world as it was, and
+had neither sufficient discomfort with the limitations of the paper chart
+to motivate interest, nor sufficient knowledge of computing to understand
+what I was trying to say. In retrospect, they have not been interested
+in learning, either; but I naively believed that if they saw a system that
+put a few concepts into practice, that the light would dawn. It has not.
+<P>Meanwhile, my First Offspring, Michael K. Johnson, who had been immersed
+in the free software world since Linus Torvald's first post, has worked
+diligently to educate me on its potential.
+<P>After I was done paying college tuition, I decided to fund a demonstration
+project with some simple programming. Stage One was the development of
+a simple progress-notes reader: In this project we took a collection of
+ASCII progress notes, created a simple PostgreSQL database, and used Perl
+to create a reader that displayed each patient's notes in a standard browser,
+in reverse chronological order.
+<BR> http://www.postgreSQL.org/
+<BR> http://www.perl.com/
+<P>Stage Two was the development of a prescription-tracking system. This
+was done in two steps: First, the drugs in the FDA Orange Book (available
+in several segments on the web) was reduced to a PostgreSQL database.
+<BR> http://www.fda.gov/cder/ob/
+<P>Later, ZOPE was used to create a medication-tracking system and prescription
+writer that is still in development.
+<BR> http://www.zope.org/
+<P>One criterion of this project has been to use only free software, and
+to donate the finished work to the free software community when it is sufficiently
+mature to do so.
+<P>During this project, I came out of my hole into the sunlight and looked
+around, blinked, and discovered that several other projects were under
+way, most begun in 1999, to perform many of the same functions. This has
+redirected my interests toward the overall effort to create a free-software
+medical information manager; the most important question to answer, in
+aiming to contribute, is to ask how free software can be most useful to
+the medical community.
+<P>The functional priorities seem clear to many people: connectivity, data
+exchange, and usability (ergonomics) are worth attention, energy, and time.
+A crucial secondary priority, because we deal with confidential information,
+is authentication and security. (It is secondary not in importance but
+is functionally subordinate to the task of achieving connectivity and exchange
+while creating tolerable ergonomics.)
+<P>I assume that you understand the need for connectivity and easier data
+exchange. It is not clear whether the need for efficient ergonomics is
+well understood by anyone. Administrators seem to assume that the inherent
+efficiencies of computers are obtained automatically; programmers insulate
+themselves from users to increase their work output and do not do "time
+and motion" studies to see if users are actually made efficient. Users
+are hindered both administratively and technologically from making their
+tasks more efficient. Physician-users sometimes have the power and sophistication
+necessary, but tend to be afflicted with egocentrism, which tends to produce
+idiosyncratic solutions rather than general solutions.
+<P><B><FONT SIZE=+1>Important tasks for medical software projects:</FONT></B>
+<P>I believe that the most effective evolution of free and open source
+medical information management software will be roughly like this: First,
+the greatest strength of the GNU/Linux system is connectivity. This is
+why the first clinically effective use of free software, the <I>Perceptions</I>
+project, was "creviceware," a collection of tools and programs that made
+connectivity and efficiency possible among independent commercial products
+that were never designed to work together.
+<P>Second, free and open software tends to begin as hobby projects. These
+begin with individuals designing tools that meet their own needs. Superficial
+examination of such projects may leave the impression that they are purely
+idiosyncratic; the truth is that beneath the idiosyncracy there are usually
+useful, generalizable paradigms. More importantly, they serve as demonstration
+projects that teach users, observers, and programmers how to make the next
+iteration of software design more efficient and functional. In this stage
+specific tools are designed -- "taskware."
+<P>If specific tools are designed <I>within</I> a culture that understands
+their design principles ("has a clue") and recognizes the importance of
+connectivity, then the project can begin to actually reshape the medical
+community, producing "wholeware" -- software systems that actually begin
+to meet the needs of an enterprise.
+<P>At first, these enterprise systems will need to "embrace" proprietary
+legacy software; but as the power and flexibility of using open code becomes
+generally understood, strictly proprietary solutions will atrophy.
+<P>How can we best proceed to build shareable open code? I believe that
+the following conceptual foundations are necessary:
+<BR><FONT FACE="symbol">·</FONT> Protocols and data structures for
+area-wide exchange of individuals' basic health information: a <B>"medical
+demographic."</B> This is the significance of the <I>Circare</I> project
+in Hamilton, Ontario.
+<BR><FONT FACE="symbol">·</FONT> Agreement on <B>database design
+</B>.
+I believe that it is important for the medical f-s/o-s community to maintain
+a common database design, independent of code. This is the significance
+of the <I>FreePM</I> project of Tim Cook.
+<BR><FONT FACE="symbol">·</FONT> Free availability of <B>coding
+systems
+</B>for clinical information. The fact that the CPT system is proprietary
+to the AMA is a great hindrance, and the AMA should be pressured to make
+this coding system freely available to the community, under appropriate
+commercial restrictions that permit the AMA to recover the high costs of
+maintaining this complex system.
+<P>Let's look at these principles in more detail.
+<P><B><FONT SIZE=+1>Foundational needs of open-source medical software</FONT></B>
+<P>Contemplating the various f-s/o-s efforts that are being attempted,
+and the work that has been done, such as the Health Level 7 project (http://www.hl7.org/
+), to create data standards for medical software it is difficult to envision
+how to effectively corral the enormous efforts that are going on and harness
+them to a single wagon.
+<P>Each "player" is performing in a different arena; has unique needs;
+has individual priorities. There is such a large variety of tools and mid-level
+languages that it is difficult to envision how it may be possible to provide
+a substrate suitable for every need.
+<P>I conclude that it is impossible to create a software project that can
+encompass the needs of everyone in the medical community, and therefore
+we should not attempt to do so. Instead, we must focus first on identifying
+the commonalities: what <I>everyone</I> needs (whether they realize it
+or not).
+<P>Let's approach this logically. The reason this community exists is to
+provide health care for individuals. Hence the first consideration is,
+what are the fundamental "data needs" of the individual?
+<P><B>Demographics must include health information</B>
+<P>The first mistake made by commercial software developers is to assume
+that the standard "demographic information" is an adequate description
+of a patient. It is not. For billing we try to collect enough information
+about each person to uniquely identify them. Name and date of birth are
+the starting points; in a large population this is not sufficient. Social
+security number is used in the USA, but organizations do not have a legal
+right to require this, and many people either refuse or provide a false
+one. So we collect a large amount of ancillary, usually temporary, information
+that serves to locate rather than identify persons.
+<P>But in all this effort, we have not included in our demographics the
+<I>medical</I> identity of the patient: their <I>conditions</I>. Every
+physician knows that this is the medical identity of a person; this is
+why we refer to "the gallbladder in room 320A." Such talk can be demeaning,
+but in a professional context it is a whimsical way of focusing discussion
+on a disease process rather than on a personality.
+<P>So a minimum medical demographic must include some version of what is
+called a person's "problem list." The fact that this is not "public knowledge"
+and must be protected from inappropriate access and use has been an absolute
+hindrance to adding it to the demographics. But medically to do so is an
+absolute necessity. There is a corresponding obligation to include in the
+specification of the complete medical demographic <B>a confidentiality
+rule and procedure</B>.
+<P>This rule and procedure is at its heart simple: the public and non-public
+data in the medical demographic record must be differentiated within the
+record; release of non-public data is permissible from one provider to
+another in order to provide health care to the individual and other release
+is permissible only with the express, documented, permission of the individual.
+Any software project must therefore include security procedures that permit
+protection of this confidentiality.
+<P>But without this "problem list" the patient remains "unidentified" medically;
+no software will be clinically useful that excludes this data.
+<P>As an aside, it is worth mentioning that all the information in the
+demographic record, <I>including the patient's name,</I> may be considered
+confidential and non-public by the patient. Famous or notorious people
+may not want anyone to know they are part of your organization's client
+list; telephone numbers may be unlisted, addresses private. The medical
+information is <I>especially sensitive</I> to breaches of confidentiality,
+but it is proper and prudent to give equal importance to preserving the
+confidentiality and privacy of every datum held on a person.
+<P>This has smaller implications for area-wide data repositories than might
+be thought. First, the patient must be informed that this area-wide repository
+exists, its purposes, the conditions under which consent to share data
+is implied, the conditions under which explicit release is necessary, and
+the recourse the patient has for violations. If all the organization's
+data is held in an off-site repository, the organization has the responsibility
+to ensure its security and confidentiality. There is no reason for an individual
+to object to an area-wide data-sharing arrangement if the privacy protection
+is as good as it should be.
+<P>In fact, practices are already beginning to use data services located
+as far as across the continent from the practice location, and there will
+of course the suspicion that vendors will mine this data for commercial
+purposes. I have no doubt that this will occur unless contractual and procedural
+protection is added to the legal protections that already exist.
+<P><B>Dynamic inaccuracy.</B>
+<P>The most important feature of the medical demographic is its <I>dynamic
+inaccuracy
+</I>. What do I mean by this?
+<P>Persons are real, and exist until death (after which they are at least
+no longer dynamic). Any demographic information is a representation of
+a person, to permit indexing of records and to aid locating persons in
+order to communicate with them. Historically, the only interest in communicating
+with the patient was to send a bill. Recent changes in practice paradigms
+have led to communications about health maintenance, which a cynic would
+see as a means to ensure the sending of more bills.
+<P>Anyone who has ever interacted with demographic records knows that they
+are inherently inaccurate for several reasons:
+<BR><FONT FACE="symbol">·</FONT> The person is constant, but characteristics,
+even names, change.
+<BR><FONT FACE="symbol">·</FONT> Typographical errors and incomplete
+or partially duplicate entries are made by operators.
+<BR><FONT FACE="symbol">·</FONT> Locations change.
+<BR><FONT FACE="symbol">·</FONT> Medical conditions change.
+<P>This means that any demographic record is only temporarily accurate,
+and that the degree of inaccuracy will increase with the passage of time.
+I call this <I>dynamic inaccuracy</I>, and it is, in my judgment, the most
+important characteristic of a demographic record.
+<P>Thus the most important task for the keeper of the record is maintenance.
+Who is willing to take responsibility for "keeping" the record? There are
+four people who have clear and primary interest in its accuracy:
+<BR><FONT FACE="symbol">·</FONT> the person about whom the record
+is a summary
+<BR><FONT FACE="symbol">·</FONT> the medical professional using
+the record to make healthcare decisions
+<BR><FONT FACE="symbol">·</FONT> the fiscal intermediary who is
+responsible for making proper compensation for correct claims
+<BR><FONT FACE="symbol">·</FONT> the programmer who creates the
+repository and the tools to access it.
+<P>Note that this list <I>does not</I> include the well-meaning receptionist
+who records the information in the data repository, the manager of the
+clinic or hospital providing care, or anyone's attorney. These folks have
+a <I>secondary</I> interest in its accuracy.
+<P>Successful continual validation of the dynamically erroneous record
+requires that there be an <B>audit trail</B> of changes. It should include
+(or point to) the prior field contents and the new contents, and include
+<I>when</I> the change was made, <I>who</I> made the change (i.e., who
+was the source or informant and which entry tech recorded the change),
+<I>why
+</I>the change was made, if a reason is relevant (such as "marriage"
+"adoption" or "divorce" for a name change; "moved" "postal office directive"
+or "temporary address" for an address change). This audit trail need not
+be kept forever; once changes are validated independently and confirmed,
+the audit trail becomes irrelevant, and the record is ready to acquire
+fresh inaccuracy.
+<P>The remarkable thing about our current record-keeping practices is that
+we never allow the person whose data is stored to see, enter, or verify
+its accuracy directly. With rare exceptions, even the medical information
+stored there is not reviewed or verified by the healthcare professional
+who created it. (In most current systems this is the collection of diagnosis
+codes in the accounts-receivable system.)
+<P>A goal therefore, of any clinical information system must be to allow
+the patient and the physician each to have access to this summary record
+and to propose corrections to it.
+<P>What should this "medical demographic" contain?
+<BR><FONT FACE="symbol">·</FONT> Identifying information
+<BR><FONT FACE="symbol">·</FONT> Location
+<BR><FONT FACE="symbol">·</FONT> Payors
+<BR><FONT FACE="symbol">·</FONT> Medical data set.
+<P>The minimum contents of this medical data set are well known to practitioners:
+<BR><FONT FACE="symbol">·</FONT> Medication allergies and intolerances
+<BR><FONT FACE="symbol">·</FONT> Active medical problems
+<BR><FONT FACE="symbol">·</FONT> Past health events that will affect
+future health decisions
+<BR><FONT FACE="symbol">·</FONT> Heritable health influences
+<BR><FONT FACE="symbol">·</FONT> Continuing medication use.
+<P><B>Ergonomics</B>
+<P>Two seductive characteristics of computers lure the unsuspecting: the
+potential for automated data handling, and the possibility of enhanced
+efficiency. But computers do not save time, money, or effort -- unless
+they and their use are managed intelligently and with discipline. To use
+computers to manage large databases efficiently and effectively does require
+technical expertise. <I>Ergonomic design for efficiency requires detailed
+knowledge of how specific work is or should be done</I>.
+<P>Studies have shown that the chief barriers to acceptance and deployment
+of computerized medical record systems are <B>cost</B> and <B>usability</B>.
+It is not my purpose to address cost, except to note as an aside that medical
+enterprises are throwing away money on commercial systems that turn out
+to be extremely expensive to maintain due to needless inefficiency and
+to the economic captivity of <I>vendor lock</I>.
+<P>It is important to acknowledge the major barriers to usability, well
+identified in the literature:
+<BR><FONT FACE="symbol">·</FONT> workflow integration
+<BR><FONT FACE="symbol">·</FONT> geographic access to devices
+<BR><FONT FACE="symbol">·</FONT> the importance of actually improving
+productivity
+<BR><FONT FACE="symbol">·</FONT> the effect of the "learning curve"
+on the use of systems
+<BR><FONT FACE="symbol">·</FONT> the effect of failing to use web-based,
+modular, "lightly structured" approaches.
+<P>Executives seldom have knowledge of either information technology or
+physician work patterns; in any organization they tend to isolate themselves
+from detail and often become captives to a whirlwind of communication with
+each other and communiques to their underlings. IT professionals and physicians
+are both often thought to be too "narrow" to be effective leaders; American
+management culture is mistrustful of experts, who are presumptively viewed
+as egocentric and biased, as if ignorance granted objectivity or wisdom.
+<P>Commercial medical software has been and remains "pieceware," applications
+designed to serve a particular part of the enterprise. More importantly,
+data exchange with other applications has been completely and deliberately
+ignored, in the best circumstance to ensure that when a company expands
+its efforts to another area within the medical enterprise, it will not
+have "given away" anything to a potential competitor.
+<P>The first software in clinics and hospitals was <I>accounts-receivable
+</I>systems,
+and these products continue to dominate the market. They have been completely
+unsuccessful in producing useful computerized medical record applications
+because they have designed their efforts around the needs and requirements
+of medical records technicians, which has characteristically produced software
+that is ergonomically stressful for physicians.
+<P>Comprehensive <I>laboratory</I> data-management systems have emerged
+in this decade; they are chiefly oriented to the needs of laboratory technicians
+and their regulatory responsibilities; providing data to clinicians is
+superficially considered, and interfacing to clinical systems is not planned
+for.
+<P>Pharmacy software has emerged to aid in pharmacy management and dispensing;
+this has not been designed with the idea of providing integration with
+physician prescription-writing, or receiving prescriptions from physicians
+with electronic validation.
+<P><I>Transcription </I>software has been designed around the needs of
+typists, and has not been planned to create any kind of a structured record
+that might be useful in creating even a modestly useful database.
+<P>Some <I>hospitals</I> have tried to create ordering software and integrated
+charting; but these are characteristically oriented toward complete documentation,
+not for ergonomic efficiency; in any case, the hospitals that have felt
+able to invest in such systems are large and complex; the temptation is
+to try to do everything imaginable at once, which spawns bloatware, and
+hinders the discipline that could progress from a simple system that does
+essential, easily-automated tasks well into a collection of simple systems
+that interact smoothly, later adding features and complexity in a logical
+and ergonomically-driven sequence.
+<P>A few <I>physicians</I> have tried to create electronic medical records;
+not surprisingly, the only clinically respected EMR/CPR systems are those
+that have been designed by physicians for clinical usefulness. These developers
+have discovered that integration with legacy systems, especially those
+doing accounts receivable and laboratory data management, has been an interesting
+and laborious challenge.
+<P><B><FONT SIZE=+1>Security, Confidentiality, and Authentication</FONT></B>
+<P>It is not my goal to reproduce here the important discussions that have
+taken place regarding the challenge that the Internet presents for security
+and authentication for system access and data exchange. Instead, I wish
+to point out that there are several important issues, of which the technological
+challenge of S & A is only the foundation.
+<P>It is worth pointing out, as an aside to this discussion, that the most
+important threat to confidentiality of medical information is <I>not</I>
+unauthorized access to either paper or electronic records. The greatest
+threat is <I>authorized</I> access. Insurance companies, in particular,
+have for decades habitually required applicants to sign a blanket release
+for all medical records. Their signature authorizes exactly this, and clinics
+comply. What electronic records do is merely to make release easier and
+less expensive, and permit extremely sophisticated searches and statistical
+analysis. They also present an opportunity to use the information for commercial
+purposes without release, which itself presents some ethical concerns.
+<P><B>Confidentiality</B>
+<P>Ethically, all information regarding a patient, whether provided voluntarily
+or at the insistence of the nice receptionist, or produced by the clinicians
+and consultants, belongs jointly to the patient and the organization; despite
+having a share in ownership, the organization has only a limited "property
+right" over this information, as the patient has a greater interest in
+its control and more to lose by mishandling than does the organization.
+<P>There are no ethical levels of confidentiality; there are regulatory
+levels, related to the adverse consequences to the organization or to individuals
+in it that may follow inappropriate release. The organization does not
+have the right to release even the "public" information about a patient,
+for to do so reveals that the patient is in fact a client of the organization.
+<P>Based on the likelihood of "injury" to the patient and the consequences
+to the miscreant of inappropriate release, there are at least three levels
+of confidentiality:
+<BR><FONT FACE="symbol">·</FONT> Public information: address, telephone
+number, names of related persons, etc.
+<BR><FONT FACE="symbol">·</FONT> Routine medical information: ordinary
+diagnoses, lab results of no "general" interest and so on.
+<BR><FONT FACE="symbol">·</FONT> Sensitive medical and counseling
+information: psychology and psychiatry notes, pregnancy test results, lab
+results and clinical notes regarding sexually transmitted disease and the
+like.
+<P>Because of this construct, clinics customarily create "superconfidentiality"
+for psychology notes and HIV test results, which in most states is protected
+by law.
+<P>Thus any medical information management system should be designed to
+provide multiple levels of confidentiality.
+<P>Medical enterprises depend primarily on a <I>culture of confidentiality
+</I>rather
+than strict policing to preserve the privacy of medical records. The rules
+have been simple and clear for ages; the incentive to comply with these
+rules is part of "professionalism," and we store the records in mildly
+inaccessible places, not in bank vaults. Within our buildings, we leave
+charts laying all over, in stacks that are part of the records-handling
+process, and only a few employees are permitted (by rule) to have access
+to them. Security <I>within an intranet</I> can use professionalism similarly
+to keep security procedures simple enough that they do not hinder efficient
+work.
+<P>But the Internet poses special problems for security and authentication,
+both to make sure our firewalls effectively prevent unauthorized access,
+but also with the growing use of off-site data storage pioneered by Oracle
+and others, to devise effective protections against both confidentiality
+breaches and against commercial exploitation of their contents.
+<P><B><FONT SIZE=+1>Clinical data</FONT></B> (database design)
+<P>The key to creating a community medical informatics system is common
+agreement on the database configuration. It is not necessary to agree on
+every detail, as any user is free to modify the structure and any code
+as desired. But the felt need for such modifications will be minimized
+by careful attention to defining the essentials. The <B>FreePM</B> project,
+led by Tim Cook, is paying careful attention to database design in this
+manner. He realizes that it is more important to design well than to begin
+coding promptly. He expects to spend several months with database design.
+<P>There are four arenas which require this fundamental attention:
+<P><B>Professional fees</B>. To create a billing system for the salaried
+health care provider is a non-task. All other professionals have some fee
+structure that has these components:
+<BR>- the service(s) provided
+<BR>- the condition(s) treated
+<BR>- the identity of the provider (with location)
+<BR>- the identity of the patient (with location)
+<BR>- the date or duration of the encounter
+<P><B>Clinical documentation.</B> This is most importantly "progress notes,"
+but also related records such as prescription or medication tracking, problem
+lists, immunization history, growth charts, pregnancy flow sheets, and
+other documents created by the provider that serve as an institutional
+memory.
+<P>We must remember, in designing the database, that individual practitioners
+have strong personal preferences for various types of organization and
+presentation of clinical documents, so the database design must not presume
+any particular display organization for the elements that contribute to
+this material.
+<P>For example, some providers produce a single, unfragmented, narrative
+clinical document for each encounter. At the other end of the spectrum
+are technologically sophisticated providers such as Dr. Alex Caldwell,
+author of Tk-FP, who has written finely granular menuing software that
+permits creation of a progress note via mouse clicks from boilerplate text
+and can past text from the problem list, medication list, etc.
+<P>The solution for the database designer is to create a finely granular
+structure, as this can accommodate the highly subdivided note structure,
+and can be easily adapted to the needs of the user who creates a less structured
+note.
+<P>But to create a clinical record, even an organized one, is not the real
+task. The real challenge is to create a clinical record from which either
+oneself or <I>another provider</I> can easily cull newly-important information.
+The difficulty of this task is apparent when one thinks about the fact
+that the record created today, for a well patient with a sprained ankle,
+may be reviewed next month when the same person presents with abdominal
+pain. The fragments of history and observation that are <I>generally pertinent
+</I>across
+time need to be recorded or displayed differently that those fragments
+that are not of enduring interest medically, and are preserved only because
+the profession of law has a representative down the block who also may
+serve the patient in the indefinite near future.
+<P>What does a clinician actually look for in reviewing past notes. I claim,
+based on twenty years of experience in internal medicine, that a clinicial
+is never interested in the continuous narrative of an old note. We chiefly
+look for the following types of information:
+<BR><FONT FACE="symbol">·</FONT> The (approximate) date of onset
+of a chronic condition; e.g., when hypertension was noted, or diabetes
+began.
+<BR><FONT FACE="symbol">·</FONT> The(approximate) date and nature
+of any life-changing isolated events; e.g., when the left ankle fracture
+occurred, how severe it was, and what treatment was used; or when the laparotomy
+was done, why, and what was found; or significant but temporarily medical
+illnesses like tuberculosis.
+<BR><FONT FACE="symbol">·</FONT> A history of (dates of and results
+of) "health maintenance" actions: e.g., mammograms, endoscopies. immunizations,
+pap smears, and the like.
+<BR><FONT FACE="symbol">·</FONT> A medication history: allergies
+and intolerances, hopefully with a contemporaneous description; what medications
+were prescribed (especially for chronic conditions), what was the clnical
+response, and when and why they were discontinued.
+<BR><FONT FACE="symbol">·</FONT> Treatment history of chronic disease:
+especially radiation or chemotherapy for malignancies, immunologic treatment
+of non-malignant disease (e.g. Crohn's or RA), or significant changes in
+insulin regimens for diabetics
+<BR><FONT FACE="symbol">·</FONT> "Descriptive" historical data:
+baseline and recent chest xrays, EKG's, laboratory values, weight, blood
+pressure, visual acuity, etc.
+<P>We tend to depend on <I>summaries</I> for this information, and so look
+for hospital admission and discharge summaries, surgical reports, radiology
+reports, problem lists, and laboratory flow sheets.
+<P>Ergonomically, the clinician's task in reviewing past clinical notes
+is to sort out what has become "chaff" from what has been made "wheat"
+by the current complaint. It is possible to design our database, the display,
+and the user interface either to hinder or to expedite this task.
+<P>New enforcement pressures have been put on providers from the US government,
+which threatens criminal fraud action if the "level of documentation" does
+not match or exceed the "level of care" charged for. This has resulted
+in sometimes massive increases in verbiage to guarantee that the clinical
+note is as fat as the professional fee, and the result for the clinician,
+winnowing old notes in the chart for kernels of crucial information, has
+been a blizzard of chaff that often successfully obscures essential factoids
+and at least make the information-gathering task laborious.
+<P><B>Dual-track Clinical Notes Record Needed.</B>
+<P>The best solution to this challenge is to judiciously fragment clinical
+notes, using boilerplate as needed for documentation of charges, but to
+store separately the <I>boilerplate</I> and any <I>customization</I>. The
+electronic record, then, would consist of a collection of pointers to boilerplate
+text and a collection of unique observations about the individual.
+<P>When the entire note is to be printed or displayed, the boilerplate
+and customizations are merged to produce a complete document; but the clinician
+when viewing the record can choose to view only the unique observations.
+<P>Problem lists, flow sheets, medication lists and prescription writing
+are all features of a clinical notes system that each requires its own
+specification. It is not now my purpose to create such specifications.
+<P><B>Clinical supporting data: intelligent system needed</B>.
+<P>This supporting data is pre-eminently laboratory results. The clinician's
+need for presentation of this data is usually different than the standard
+laboratory output provides. Hence the extensive use of <I>flow sheets
+</I>in
+clinical practice, for patients with conditions that persist for some time.
+Not nearly enough is done with data analysis. We need an <B>intelligent
+system</B> to mine and present this physiologic data in ways that are pertinent
+to the patient's current and continuing medical conditions.
+<P>This intelligent system would, based on the diagnoses in the patient's
+"problem list" (summarized as ICD-9 codes, for example) and the presenting
+complaint(s) (gathered by ancillary staff and summarized as V-codes, for
+example), "mine" the electronic record for pertinent laboratory data, radiology
+reports, health maintenance actions, and relevant clinical notes. It would,
+between the time the patient checks in and the time the physician joins
+the patient, prepare customized flow sheets of lab data and an index to
+relevant narrative notes, and have these available for display on screen.
+<P>Here's how this could work for laboratory results:
+<P>The flow sheet format that will work best is one which does not display
+empty columns, and that "collapses" into a single column those values obtained
+on approximately equivalent dates. The older the lab value, the less important
+for clinical decisions is its exact date. Use actual dates for the past
+month, monthly dates for four months, quarterly for a year, and then annual
+data telescoped in single columns. The "collapsed" or "telescoped" columns
+might contain several values, in which the rang) and number of observations
+could be reported, e.g.,
+<BR><TT><FONT FACE="courier, courier new"><FONT SIZE=-1>
+|alk ptase | 32-75 (4)
+</FONT></FONT></TT>| .
+<BR>If exact numbers are wanted, the user should be able to reference the
+cell or column with the cursor or keystrokes and "expand" perhaps by clicking
+on it. e.g.,
+<BR><TT><FONT FACE="courier, courier new"><FONT SIZE=-1>
+YR - QTR - MON - DAY .</FONT></FONT></TT>
+<P>The rightmost column could simply be labelled "older," and either contain
+simply a tag noting that values exist (this would be easier to implement
+and faster to calculate and display), or the range of all older values.
+It would be useful to summarize lengthy reports such as a urinalysis or
+complete blood count by simply noting than they have been done--with a
+minus if no abnormal values are reported or a plus if there are abnormal
+values (the plus could be over-ridden by a doctor if the abnormalities
+were judged to be trivial, so the display would not be misleading in the
+future.) An"expand" feature would open to the complete report, or to a
+flow sheet devoted to a set of complete reports for the period of time
+encompassed in the column. For example,
+<BR>
+<P><BR>
+<CENTER>
+<P>Joe Markiewicz
+<BR>Wednesday 3-20-99
+<BR>Clinic # 377-95-2287
+<BR> DOB 12-17-64
+<BR>Dr. Gruenhagen</CENTER>
+
+<BR>
+<TABLE BORDER WIDTH="525" >
+<TR ALIGN=CENTER>
+<TD WIDTH="14%">
+<CENTER>Dates:</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>3-20-99</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>3-14-99</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>Jan 99</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>4 Q 98 </CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>1997 </CENTER>
+</TD>
+
+<TD WIDTH="16%">
+<CENTER> Older</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD WIDTH="14%">
+<CENTER>Test</CENTER>
+</TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="16%"></TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD WIDTH="14%">
+<CENTER>potas.</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER> 4.2</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>3.8</CENTER>
+</TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%">
+<CENTER>3.3-4.0 (2)</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>3.5-4.3 (3)</CENTER>
+</TD>
+
+<TD WIDTH="16%">
+<CENTER> 3.2-5.0 (12)</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD WIDTH="14%">
+<CENTER>Creat. </CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>2.7</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>2.4 </CENTER>
+</TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%">
+<CENTER>1.8 </CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER>1.6 (2)</CENTER>
+</TD>
+
+<TD WIDTH="16%">
+<CENTER>1.2</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD WIDTH="14%">
+<CENTER>HgbA1c</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER> 8.3 </CENTER>
+</TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%">
+<CENTER> 7.8 </CENTER>
+</TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="16%">
+<CENTER>10.2 (3)</CENTER>
+</TD>
+</TR>
+
+<TR ALIGN=CENTER>
+<TD WIDTH="14%">
+<CENTER>Fast. gluc</CENTER>
+</TD>
+
+<TD WIDTH="14%">
+<CENTER> 186</CENTER>
+</TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%">
+<CENTER> 204 </CENTER>
+</TD>
+
+<TD WIDTH="14%"></TD>
+
+<TD WIDTH="14%">
+<CENTER>193 (2) </CENTER>
+</TD>
+
+<TD WIDTH="16%">
+<CENTER>92-420 (15)</CENTER>
+</TD>
+</TR>
+
+<TR>
+<TD ALIGN=CENTER WIDTH="14%">
+<CENTER>UA</CENTER>
+</TD>
+
+<TD ALIGN=CENTER WIDTH="14%"></TD>
+
+<TD ALIGN=CENTER WIDTH="14%">
+<CENTER> +</CENTER>
+</TD>
+
+<TD ALIGN=CENTER WIDTH="14%">
+<CENTER> - </CENTER>
+</TD>
+
+<TD ALIGN=CENTER WIDTH="14%"></TD>
+
+<TD ALIGN=CENTER WIDTH="14%"></TD>
+
+<TD ALIGN=CENTER WIDTH="16%">
+<CENTER>- (7) + (2)</CENTER>
+</TD>
+</TR>
+
+<TR>
+<TD ALIGN=CENTER WIDTH="14%">
+<CENTER>hemogram</CENTER>
+</TD>
+
+<TD ALIGN=CENTER WIDTH="14%"></TD>
+
+<TD ALIGN=CENTER WIDTH="14%">
+<CENTER> - </CENTER>
+</TD>
+
+<TD ALIGN=CENTER WIDTH="14%"></TD>
+
+<TD ALIGN=CENTER WIDTH="14%">
+<CENTER>+ </CENTER>
+</TD>
+
+<TD ALIGN=CENTER WIDTH="14%"></TD>
+
+<TD ALIGN=CENTER WIDTH="16%"></TD>
+</TR>
+</TABLE>
+
+<P>Besides clinical notes, there are many other types of narrative supporting
+data:
+<P>- medical imaging - typically consisting of a report by a physician
+of a graphic
+<BR> xray and fluoroscopy
+<BR> nuclear medicine
+<BR> ultrasound
+<BR> MRI
+<BR> PET
+<BR> procedure videos
+<BR> clinical photographs
+<BR>- pulmonary function
+<BR>- EKG
+<BR>- EEG
+<BR>- nerve conduction (EMG)
+<P><B>Chart index. </B> It is not be necessary, for example, to always
+show the actual xray report (or other narrative report). Just having the
+xray procedure and its date would permit the creation of a table of contents
+to this part of the chart as well as a flow chart of the procedures that
+had been performed. At most, one could add a summary diagnosis to the list:
+<BR>
+<TABLE BORDER WIDTH="525" >
+<TR>
+<TD WIDTH="33%">Date</TD>
+
+<TD WIDTH="33%">Exam</TD>
+
+<TD WIDTH="34%">Result</TD>
+</TR>
+
+<TR>
+<TD WIDTH="33%">6-85 </TD>
+
+<TD WIDTH="33%">Barium Enema</TD>
+
+<TD WIDTH="34%">diverticulosis</TD>
+</TR>
+
+<TR>
+<TD WIDTH="33%">8-99</TD>
+
+<TD WIDTH="33%"> CXR</TD>
+
+<TD WIDTH="34%">nl</TD>
+</TR>
+
+<TR>
+<TD WIDTH="33%">11-94</TD>
+
+<TD WIDTH="33%"> UGI</TD>
+
+<TD WIDTH="34%">DU</TD>
+</TR>
+
+<TR>
+<TD WIDTH="33%">8-98 </TD>
+
+<TD WIDTH="33%">BE</TD>
+
+<TD WIDTH="34%"> tics, polyp</TD>
+</TR>
+
+<TR>
+<TD WIDTH="33%">9-00 </TD>
+
+<TD WIDTH="33%">MRI lumbar spine </TD>
+
+<TD WIDTH="34%">HNP Rt L5</TD>
+</TR>
+</TABLE>
+
+<P><B>Professional communication.</B> Many types of communication need
+to be kept in a patient's record. Many of these need not be reduced to
+electronic form. At most, the electronic record should be an <I>index</I>
+to the paper documents that have been archived in a paper file. Examples
+of historical records that do not require electronic access are:
+<BR>- reports from consultants
+<BR>- hospital admission and discharge summaries, operative and procedure
+notes
+<BR>- letters to or from patients
+<BR>- correspondence with employers and attorneys
+<BR>- forms from or for employers, DME providers, home health nurses, insurance
+companies, etc.
+<BR>- old records sent from past caregivers
+<BR>- nursing home documentation
+<BR>- reprints from the medical literature
+<BR>- archival clinical records
+<P>Communication between providers is more and more likely to be in electronic
+form, usually as email. If intranet connectivity is achieved between providers'
+clinical databases, it will be possible to directly add data and notes
+generated by other providers in a clinician's own electronic record. If
+this is done, then the <I>source</I> of the data must be indicated within
+the clinician's database.
+<P><B>Prescriptions and a drugs database</B>
+<P>This I consider to be a part of the "clinical notes" function, because
+it is the clinician who uses it, and the results of the prescribing process
+belong with the clinical note. I will briefly list here the essential features
+of a prescription system.
+<P><FONT FACE="symbol">· </FONT><B>Drugs database</B>. It is not
+a difficult task to import the FDA <I>Orange Book</I>, available at their
+web site (http://www.fda.gov/cder/ob/), into a database, and the FDA publishes
+monthly updates which could be used to automatically the drugs database.
+<P><FONT FACE="symbol">· </FONT><B>Prescription-writing tool</B>.
+A prescription should be easy to create, and the software should be capable
+of printing a prescription on paper for signature, faxing a signed prescription
+directly to the pharmacist, or electronically submitting the prescription
+if the pharmacy is capable of accepting this.
+<P><FONT FACE="symbol">· </FONT><B>Medication list</B>. It is important
+to be able to produce not only a complete list of current and recent medications
+for the chart, but to prepare a list of the patient's current medications
+for the patient, for the pharmacist, and for home health nurses.
+<P><FONT FACE="symbol">· </FONT><B>Allergy/intolerance list</B>.
+It is not essential for this list to be part of the database if the clinician
+is working from a paper chart, as it is the clinician's responsibility
+to be sure that all medication intolerance is considered prior to writing
+a prescription, and such lists are notoriously incomplete. But it is helpful
+to have this feature, and the clinician should work diligently to maintain
+an accurate list in the database.
+<P><B><FONT FACE="symbol">·</FONT> Medication interactions.</B>
+The <I>Medical Letter</I> has a web site,
+<BR> http://www.medletter.com/
+<BR>and during this last year has made their drug interactions software
+available to subscribers via the Internet. As set up on the Internet, the
+user can check interactions on up to six drugs at a time. This is a limit
+of the web page, not of the software. The program does not check for interactions
+with food or "natural" products, but does provide reprints of literature
+for many interactions. I have found it more than sufficient for my own
+needs, and the response has been very fast.
+<P>It is important to the clinician providing longitudinal care to have
+an audit trail of past prescriptions, listing when each was begun and stopped,
+and when a change was made in medication, form, dosage, or schedule, to
+indicate succinctly a reason. Such an audit trail can eliminate the repetition
+of past futility.
+<P><B><FONT SIZE=+1>Coding Systems</FONT></B>
+<P>It is not my purpose in this document to review coding systems for symptoms,
+diagnoses, supplies, and professional services. A concern is that the AMA
+does not make the CPT coding system freely available; nevertheless the
+cost of this database is within the means of any practice.
+<P><B><FONT SIZE=+1>Information Resources</FONT></B>
+<P>Two software technological advances have greatly reduced the work needed
+to bring a usable integrated medical information system into the exam room:
+These are the multi-windowed desktop and the web browser.
+<P>The <B>Multi-window desktop</B>, with proper tools, permits the clinician
+to simultaneously have access to disparate systems that live on the same
+network. It is not necessary to switch from one application to another.
+I can have simultaneously open a word processor for patient instructions
+and educational material that can be customized for the patient's individual
+needs in seconds, a terminal session to access their lab data, an Internet
+session to check drug interactions, an intranet session for access to an
+electronic medical library, and a window on real-time radar so she can
+see if the rain will quit before she has to go back out to her car.
+<P>The <B>web browser</B> solves an access and display problem, and its
+ubiquity has made information and tools readily available without the intervention
+(i.e., work) of the local programmer. We will do well if all displays use
+this technology to present information. However, HTML is presently has
+very limited ability to use screen real estate efficiently, and has inadequate
+flexibility in managing keyboard input, so that the ergonomics of browser-based
+data display and entry are awkward. A current example of this is the FAA's
+new DIWS software for Aviation Medical Examiners. Most of you will never
+see this, and it is not possible for me to demonstrate it here; so let
+me say simply that its ergonomics is awkward, error checking of input is
+scant, response times are highly variable from seconds to tens of minutes,
+and security and authentication were a daunting challenge. After talking
+personally to the programmer, I am confident that this system pushes pure
+HTML as far as it can.
+<P>Despite its severe ergonomic limitations, HTML and browsers prove that
+a shared display technology is an important part of the foundation for
+the necessary clinical connectivity of the future. In my own institution,
+the use of XML is being specified for all future clinical applications,
+and many commentators have agreed that this will likely be the future common
+specification for presentation and display.
+<P><B><FONT SIZE=+1>The Organizational Politics of Systems Design</FONT></B>
+<P>This discussion about the genuine and perceived strengths and shortcomings
+of commercial versus open software is in fact a political one, as within
+institutions decisions are usually made politically, even though experts
+would prefer that technical merit be the basis for planning and decisions.
+<P>Commercial software solutions <I>do</I> have some strengths. These are,
+by and large, well understood. But vendors, no surprise, obfuscate or deny
+their deficiencies.
+<P>Free and open source software <I>does</I> have some limitations and
+deficiencies, upon which vendors focus; but also some strengths, which
+are not widely recognized in part because vendors deny their existence
+and partly because they are simply new and word has not gotten out.
+<P><B>Strengths of commercial software</B>
+<P>Commercial applications <I>exist</I>, they are supported, many have
+a very long history, the companies understand their customers' needs, and
+many commercial systems provide extensive training as well as installation,
+customization, and usually maintenance. Only a commercial solution can
+provide a "turnkey installation." A customer with no technical expertise
+whatever can own and use a well designed software application.
+<P>A strength of commercial software that is not well understood is the
+cutting off of political unrest by taking huge portions of a company's
+IT efforts outside company walls. Is there controversy in the company over
+technical or ergonomic issues? The canny administrator can obviate all
+this infighting simply by going to a turnkey commercial solution. A side
+benefit is that the internal combatants then become allies against the
+alien invader that management has so "stupidly" obtained.
+<P>A corollary to this principle is that if a company is not able to bring
+organizational discipline and focus to its IT efforts, a commercial solution
+may be less costly. Organizational "focus" is particularly difficult in
+academic institutions and highly democratized firms which have powerful,
+independent department heads, particularly when IT professionals are kept
+in a "service" role and not permitted to participate at leadership levels.
+<P><B>Myths about commercial software</B>
+<P>The assumption that in buying commercial software the customer is typically
+getting a reliable, cost-effective, well supported system is wrong. Some
+very good commercial solutions exist, but good experiences are hardly universal.
+<P>In particular, the <I>cost effectiveness</I> of commercial software
+is often assumed, without actually examining costs carefully before purchase,
+and almost no one actually does a continuing cost analysis of such software
+after installation. My former clinic, the Rhinelander Medical Center, which
+did this in the mid 1980's and responded to favorable numbers by opening
+a service bureau as a profit-making subsidiary after reviewing excellent
+performance, is exceptional.
+<P><B>Weaknesses inherent in commercial software</B>
+<P>The two greatest hindrances to the use of commercial software are the
+proprietary (and therefore unique) files, databases, protocols, display
+technology, etc.; and inflexibility toward any single user. Getting two
+separate vendors to cooperate with exchanging data is difficult and slow.
+At the two clinics with which I am affiliated, approximately eight disparate
+systems in two locations were more or less wedded by creating a single
+common demographic database which all applications must access and use
+(to some extent), a task that was not easy or brief.
+<P>Administrators often say that one reason they use commercial software
+is that if something goes wrong, there is someone to sue. This is one of
+those rhetorical bites that is catchy but wrong. An economically strong
+vendor will be able to resolve genuine difficulties; an economically weak
+one might be unable to garner the resources to solve a difficult issue,
+may have "thin" technical support staff, and the failing company will have
+nothing for the user to recover in a suit -- never mind the years it takes
+to get a settlement.
+<P>In fact, the chance that a vendor might disappear while their application
+is still needed is one of the biggest potential weaknesses of a commercial
+product.
+<P>The most difficult situation that plagues the users of commercial software
+is <B>vendor lock.</B> This is a real phenomenon; fundamentally it involves
+the vendor milking the cow once it is in the barn. For example, our hospital's
+accounts-receivable software vendor told us that A) they planned not to
+upgrade or support the product we had been using; B) it was not Y2K compatible;
+C) they had replacement software, a completely different system, available
+for $1 million and we should plan to purchase and install it well before
+December 31. A conflict followed, wasting time and money for both parties,
+following which the old software became Y2K compliant.
+<P><B>Strengths of free and open source software</B>
+<P><I>There is no vendor lock</I>. If one manages projects poorly, there
+can develop "programmer lock," if code is not well designed or properly
+documented. But the organization possesses its own code, and is free to
+hire any programmer, as a contractor or employee, to improve, modify, or
+adapt to the organization's specific needs.
+<P><I>Interconnectivity</I>. The majority of the Internet is run by GNU/Linux
+systems and tools. The genesis of the free and open source community was
+within the Internet, and so this system has the best toolset and best expertise;
+and it is designed to use old, out of date, inexpensive equipment efficiently.
+<P><I>Large numbers of skilled programmers</I>. The GNU/Linux community
+has thousands of developers, most able to work remotely, by contract. The
+challenge to an organization is not finding them, but managing its projects
+and personnel. Organizations which cannot manage technical professionals
+well should purchase commercial solutions and be happy with vendor lock.
+<P><I>Robust, redundant toolset</I>. The GNU/Linux system, bolstered by
+more or less open software, has the broadest, most complete collection
+of software tools, including the most interesting middleware. (Medical
+information will continue to be dominated by commercial vendors of proprietary,
+closed software for at least a decade, and there is no solution for the
+clinician who hopes to create a comprehensive system for data access and
+display except to use middleware to mine data from disparate proprietary
+systems.
+<P><I>Reasonable and controllable costs.</I> There are no royalties to
+be paid in this arena; the organization that is able to manage software
+projects and is able to focus strategically to use free and open software
+for its strengths will be rewarded with the ability to control its costs
+and manage the pace of its development, as well as focusing software on
+its own priorities.
+<P><B>Weaknesses of open source software</B>
+<P><I>No medical applications.</I> In the past, GNU/Linux was disparaged
+because it had no applications; this is because this is a new OS and free/open
+software is a new paradigm for development and management. This will change,
+but it is true that now there are no applications ready for deployment.
+In fact, non-commercial code will likely be slow to enter this arena.
+<P><I>No turnkey installations.</I> Obviously.
+<P><I>No training</I>. This is a corollary of "no apps."
+<P><B>Myths about open-source software</B>
+<P><I>No support.</I> Actually, one of the fascinating characteristics
+of the free-software community is its broad and skilled support via Internet
+discussion groups. But commercial support has become available as companies
+have emerged to serve this arena. As commercial offerings continue to develop,
+the growing number of organizations offering 24 x 7 support will continue
+to increase.
+<P><I>Unreliable.</I> This is simply false. My Linux systems have been
+up without crashing since installation, and have been down only for kernel
+upgrades. Device drivers can be installed without re-booting. My Windows98
+system must be taken down every third day, or memory leaks lock it up.
+WinNT/2000 must be re-booted for installation of any device driver.
+<P><B>Summary</B>: Free/open software solutions are suitable for medical
+organizations who have managers with technical understanding who need maximal
+cost effectiveness; and are best used as "creviceware" for connectivity
+and data gathering, and "taskware" that is designed for display and manipulation
+of stored data.
+<P>The most important limitation of open source solutions now is that an
+enterprise needs truly to manage its IS <I>and</I> its "internal customers"
+well in order to benefit efficiently from their use. For many businesses
+to purchase turnkey software, with all its obvious severe limitations and
+inherent frustrations, is a way to avoid managing IS personnel or to obviate
+internal debates over ergonomics, priorities, and function. As turnkey
+open-source solutions emerge, this concern will abate.
+<P>Commercial solutions are most appropriate for organizations that are
+unable to understand or manage technical resources, who have more money
+than knowledge, which are not able to agree on IT priorities, and for those
+who need proven software or turnkey solutions.
+<P>It is my judgment that it will not be possible to provide a complete
+free/open source medical information management system for three to five
+years; that the chief mistake managers are making with regards to open
+software is to ban it or ignore its genuine strengths, as it is extremely
+cost effective.
+<P>I am not sure whether vendors and users can agree on a basis for interchange
+of common data; but that we do so is important for our patients, who need
+their health information to be portable as they are referred among specialists
+and move about the country and the world.
+<P>Responses may be directed to me at:
+<P>johnson.danl at mayo.edu
+</BODY>
+</HTML>
+
More information about the debian-med-commit
mailing list