On Mon, 16 Apr 2001 15:46:29 Tim Benson wrote:
>Andrew,
>We are talking about two different types of thing.
Hi Tim,
I beg to differ. I believe the OIO data model supports clinical decision making and
inference, although it is also used to "collect data". I think it is the idea of this
"dual-role" that is both powerful and unconventional.
>You describe a simple
>data model used for data collection,
Yes. Thanks for agreeing that it is a simple data model :-). I like to know why you
think it cannot also support simple and complex processing as you nicely outlined
below?
>while the big debate is about how to
>provide unambiguous identifiers for attribute values such as diagnoses,
>surgical operations and medication,
Since the OIO system supports _unambiguous identifiers_ at three separate levels (as I
described), how is it less capable than other naming systems?
> in such a way that information about
>these can be processed in both simple ways (e.g. to count open heart
>operations) and in complex ways (e.g in clinical decision-making protocols
>for managing patients with heart problems).
We have already done quite a bit of the "simple processing" using the OIO system. The
complex processing still requires too many "manual steps" which I plan to automate
through workflow modeling. However, complex processing is clearly possible using OIO's
rather simple data model. Perhaps if you can give me an sample problem, I will talk
you through the steps that the OIO system will go through.
>To answer the question that I posed to Thomas, I think that for real
>systems, terminology deals with the identification of concepts as attribute
>values, not with the identification of objects (instances of classes), which
>is a different but related problem.
I suppose THAT is the conventional wisdom that I am challenging. :-).
It boils down to this: Why can't we directly use "concepts" to generate data
collection objects (e.g forms)?
Each plug-and-play web-form in the OIO system is both 1) a "concept" as pragmatically
defined by its clinical/research use and 2) a visible, renderable, interchangeable
data collection form. So far in my communications, I have emphasized #2 since it seems
to be a more practical concept from the point-of-view of the end-users.
>To use a tree analogy. Terminology deals with the leaves, (a leaf is
>something at the end of the hierarchy that has no children), not with the
>root, trunk, boughs and branches (but the catch is that every tree, root,
>bough and branch can also be thought of as a leaf, and this is where the
>analogy breaks down).
Right. In the OIO system, the approach is to "stitch" relevant forms together to build
the tree as-needed for data merging/interchange/inference. I have already implemented
this for the basic case where no item value or item name translation is necessary.
Basically, a mechanism to merge data collected through different forms for data
processing/analysis.
This is the mechanism that I referred to before as the "linkers metadata"
(http://www.mail-archive.com/[email protected]/msg03072.html) and
the form-to-form translator. I think this should work well even with name and value
re-coding (especially since Thomas said GEHR will also use archetype-to-archetype
translator in addition to the multi-level archetype tree). This part has not been
fully implemented yet in the OIO system so it is still (mostly) vaporware. :-)
Best regards,
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
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
