Reply below.
-------
On Sun, 03 Sep 2000 03:20:05 John S. Gage wrote:
>Thank you for this extensive reply. In the absence of outcome research,
>cost-benefit analyses become cost analyses. This is unacceptable and
>leads to gross inefficiencies in the delivery of health care arising
>from various lobbying efforts rather than science. I'm looking forward
>to exploring OIO.
>
I am looking forward to your comments.
>A question. My initial quarrel with Javascript several years ago was
>that it did not "do graphics". Does OIO do graphics?
The current release of the OIO (0.9.1) does not
have special provisions for handling images or
other graphics. Since it is a middle-ware development tools and a hosting environment
that puts a web-interface on a backend database, it is trivial to add image handling
capabilities (since all the enterprise-level
databases including Postgresql can handle images/graphics).
If you have a special interest in
images/graphics, perhaps you can help
identify a real-world project that needs
graphics and we can work together to implement
a solution for the project. In my experience,
that is the best way to not waste time
designing and building capabilities that are
useless. That is also why OIO has already
achieved production stability (but certainly
not feature complete!).
> Another
>question. Initially, I was very gung-ho about web-based medical
>applications. I have recoiled somewhat from that initial enthusiasm for
>the following reasons. First, security should not be made an issue if
>it can be helped.
Security should always be an issue. But one
needs to differentiate between security risks
that are specific to web-browser based systems
vs. risks shared by all public-network connected
systems vs. risks shared by all information
systems - paper or electronic.
>Second, performance of a web-based application is
>poor.
Well, that depends on a lot of factors. It is
just not too helpful to make a blanket statement
like that. I have seen web-based applications with adequate performance. Haven't you?
The current version of OIO performs adequately
over dial-up modem connections in part because
we did not waste bandwidth on graphical buttons,
cool backgrounds, menu bars, etc. We also
chose to not use technology such as client-side
Java and XML that has a long latency due to
need to first download applets and DTD's,
for example.
There is never such thing as a free lunch.
DTD/XML will always eat up more bandwidth than
HTML. That's why we decided not to implement
XML as a communication protocol but rather
only as a "file" format for data and
meta-data interchange.
>Third, clients are incredibly powerful, and web-based
>applications tend to take no advantage of this (forget thin clients,
>they're strictly for Larry Ellison's ego).
>
Unfortunately, in the era of networked
computing, computationally "powerful" is not
sufficient. The other critical variable is
network performance. If it takes 5 minutes to
download a page, then whether the page can be
rendered in 1 second or 5 seconds by the client
device is largely irrelevant. The only way to
have adequate performance is to optimize the
application's use of the network bandwidth,
the host, and the client-side processing.
The adequacy of the chain is determined by the
sum of the weaknesses of each component of the
chain.
>Can OIO take a array of numbers from the server and use the processing
>power of the client to do complex graphics with that array?
Sure. It will be easy to use the OIO to
deliver graphics data. Since Javascript
is rather weak in the department, what you
need to use is a browser plug-in. There are various browser plug-ins that do exactly
that (Macromedia's Flash is one example). You
can find a long list of graphics plug-ins at http://www.davecentral.com/1249.html.
(This particular one, Protoplay 1.0, is especially
sophisticated and exemplifies what you are describing).
What is your area of interest/research? What
type of graphics does it require?
Andrew
-----------
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org
Assistant Clinical Professor
Department of Psychiatry
Harbor-UCLA Medical Center
University of California, Los Angeles
>
>John
>
>Andrew po-jung Ho wrote:
>>
>> John and Chris,
>>
>> Can't agree with you more about the need for
>> RAD-type tools in this arena. However, I think
>> Javascript is a bit too technically challenging
>> for most "medically"-trained developers.
>>
>> We have been working on a project that we are
>> calling "Open Infrastructure for Outcomes" that
>> allows the creating/editing of web-based forms
>> with automated backend data handling routines.
>> All without "programming" - just clicking.
>>
>> We have been reluctant to call it a RAD-tool
>> since that sounds too much like something for
>> the "computer-literate". But it essentially is
>> a RAD-tool in disguise.
>>
>> The Open Infrastructure for Outcomes (OIO) is
>> coded with Zope/DTML (like JavaScript) and SQL. But users of the OIO need not even
>touch a line
>> of code.
>>
>> The OIO has been in production at Harbor-UCLA
>> Medical Center in clinical/research projects for about 6 months. It was released
>to the public just a few days ago. Brian Bray was
>> just telling me how his DocScope and OIO
>> have very similar aims. We may be able to work
>> together to advance these common aims.
>>
>> You can read more about the OIO at www.TxOutcome.Org. There is also a project
>> page hosted by Sourceforge.net, http://sourceforge.net/projects/open-outcomes/
>>
>> You can also see some screenshots at
>> http://open-outcomes.sourceforge.net/
>>
>> There are much more that can be done to
>> add functionality to the OIO. However, after
>> you have a chance to try it, I am sure you
>> will realize how right you are about the power
>> of RAD/development tools.
>>
>> If you look at all successful software
>> platforms, the initial steps must always be
>> producing the usable / useful development tools.
>> Linux is based on Gnu C compiler, Microsoft similarly succeeded because of their
>development
>> tools and developer network.
>>
>> How can we be any different in attempting to
>> build open source health information systems?
>>
>> I agree with you 100% - and hopefully working
>> together we can get closer to having the RAD
>> tools that you envision. And, perhaps
>> our recent release of OIO-0.9.1 is a useful
>> step in that direction. We cannot get there
>> working alone, and that is why the OIO is
>> released under the GPL.
>>
>> I hope you will join our effort.
>>
>> Andrew
>> -----------
>> Andrew P. Ho, M.D.
>> OIO: Open Infrastructure for Outcomes
>> www.TxOutcome.Org
>> Assistant Clinical Professor
>> Department of Psychiatry
>> Harbor-UCLA Medical Center
>> University of California, Los Angeles
>>
>>
>> --
>> Sat, 02 Sep 2000 09:10:50 -0400 "John S. Gage" wrote:
>>
>> There is a much, much more important issue lurking here, which I believe
>> has been touched on time and again in this forum but never really
>> discussed directly (I think). Open source at the present time solves
>> only one of the two major problems facing software developers: ease of
>> access to powerful code. This is a terrific thing that, correctly, has
>> turned the world on its ear. But the other problem remains: ease of
>> development. By which I mean rapid application development tools that
>> really work and are sustainable. When one scratches the surface of
>> software development, one finds an *enormous* amount of commercial
>> software written with rather primitive RAD tools. If I'm not mistaken,
>> Lotus Notes is written in Visual Basic.
>>
>> The open source community must focus directly on a consensus surrounding easy to
>use, efficient, and robust RAD tools.
>>
>> John
>>
>> >
>> >I don't know about the practical appropriateness of javascript (from a user
>interface standpoint, it's easy to abuse, and it appears to
>> >currently have security issues that one would have to be careful to work around,
>see
>> >http://slashdot.org/askslashdot/99/08/10/049200.shtml), but it's license is listed
>as being among the the GPL compatible licenses on the
>> >GNU foundation's web site: see http://www.gnu.org/philosophy/license-list.html.
>> >
>> >
>> >Chris
>> >
>> >
>>
>> Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
>http://www.eudoramail.com
>
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
