On Fri, 11 May 2001 10:17:46 Woodhouse, Gregory J. wrote:
>(I hope you don't mind if I cross-post this to hardhats.)
>
>I'd be interested in pursuing this idea further. If it's old news and I've
>simply missed the discussion, I apologize.
Hi Gregory,
I hope you don't mind me jumping into the middle of your conversation but this is a
topic area that I am also very interested in. In fact, a key goal of our Open
Infrastructure for Outcomes (OIO) project is to provide a high-level "rapid
application development" layer/tools for clinical and research information systems. :-)
...
>At any rate, what do you mean by "programming"?
>From my point of view, "programming" means creating a customized information
>application that is useful.
>In your best of all possible
>worlds, what would you like a physician to be able to do?
Use a web-browser by pointing, clicking, and completing short and simple web-forms.
>Are you thinking
>about defining the schema of the medical using visual tools?
Yes. Visual interface is helpful.
With the OIO system, users can already rapidly design web-forms through the
web-browser interface.
>Building
>reports?
Yes. The OIO system already supports this. Again, through the web-browser and
requiring only a few minutes of "customizing".
>Logic to handle updates?
Yes. The OIO system uses a "forms"-based analogy. One can either add a "blank"-form to
the patient's folder or modify an existing "completed"-forms.
>Decision trees?
We don't have this yet. This will be part of the workflow modeling module that
supports conditional branching within and between forms, auto-completion, etc.
>What kind of view of the
>data are you interested in?
This is partly determined at report generation. Data are organized into "forms" which
contain "items". During report generation, data can be aggregated across forms.
>At the lowest level, it can be overwhelming, and
>many details of the database schema are basically "infrastructure" designed
>to suport what might be called the information or knowledge level view (as
>opposed to pure data).
It is not overwhelming if you keep your users' "use-cases" in mind. If you care give
me some "challenging" / "overwhelming" examples, I will take you through how the OIO
system approaches the problem.
>Elements may exist for no reason but to support
>logical relationships and not represent any "real world" object or
>attribute.
This is not true. Logical relationships do represent real world "attributes".
Remember, the fundamental concept in information systems is to "model" the real world
within the information system. Therefore, every piece of datum models some aspect of
the "real world".
>A lot can be done with "wizards" or "experts", tools that ask a
>series of questions and generate code based on the responses given.
Yes. This is one "analogy". The OIO system does not preclude the use of these
"wizards". It currently relies on the paper forms analogy. One can envision having
"wizards" that guide the users through the steps leading to the creation of an OIO
form.
>Object-oriented systems allow for "high level" operations, effectively
>concealing many of the "low level" details of programming in more
>traditional languages. However, it turns out that developing in
>object-oriented environments turns out to be more challenging than
>traditional procedural programming, and is quite a different skill.
This is because you have not seen object oriented tools that are at a sufficiently
high level. I would characterize the OIO system as a high level object oriented tool
that is less challenging to use than other "programming" environments.
For example, whenever users click to add a question "item" to a "form", the user is
interacting with "objects" and creating a new application "program".
>I think
>a lot can be done in the are of writing code to analyze existing code or
>designs, but we're still a long way for "automatic programming" for systems
>of any complexity.
We have to start somewhere and I think the OIO system should be examined for what it
attempts to provide and accomplish through "automatic programming".
Complexity will have to be achieved incrementally. We have already shown the
usefulness of the OIO system through our clinical trial project (N>1500 patients, 5
clinicians + 1 secretarial user with non-programming background).
>This is actually an area that interest me greatly, and
>look forward to hearing your ideas on the matter.
Likewise, I look forward to your views/review of these concepts and the software
system that implements them. We are actively developing, using, and disseminating the
OIO system and invite criticisms from colleagues with similar interests.
Best regards,
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
TxOutcome.Org (hosting OIO Library #1)
Assistant Clinical Professor
Department of Psychiatry, Harbor-UCLA Medical Center
University of California, Los Angeles
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
