On Fri, 7 Feb 2003, Robert Stark wrote:
> Andrew
>
> I don't want to cause a big argument here but after reviewing OIO, I
> feel that even though you have the actual software out for this
> project, you are lacking in some big areas, the main one being good
> documentation.
Robert,
Thanks for reviewing the OIO project! I agree that more and better
documentation will be helpful. However, you raised several relevant points
after gleaming what you can from the current set of documents. I am
confident that through our discussion, we will elucidate more deficits
both in documentation and substance that we need to address.
> Maybe I'm missing something here but I found it difficult to compare
> to openEHR in that you had no design principles, or modelling guides.
My understanding of the OIO system's "design principles" is that the
data model of the application is built with "forms". This is functionally
similar to openEHR's archetypes. The "modeling guides" is quite open and
un-restricted. There is no restriction on what kind of forms, how many
forms, and what goes on the forms. Of course, there are implementation
limitations on what forms can do at each moment in the history of the OIO
project. However, there are no theoretical or design-based limitations.
I am not sure whether the absence of a set of restrictive design rules is
mis-perceived as lack of design rules. If so, we need to explicitly
and prominently address this issue in our documentation.
What do you think?
...
> The only way I see open source projects in medicine/dentistry ever
> being accepted as mainstream is by working with standards bodies. As
> much of a pain that can be, it is the only way to gain acceptance.
I don't disagree that working with standards bodies may achieve some
goals. :-) However, it is not sufficient.
> It seams like the hardest battle is the political one. It is one I am
> fighting now in the ADA.
My view is that it is premature to work on standards. However, if indeed a
worthy standard has been achieved, the OIO can very easily be modified to
comply with it. This means migrating data collected through existing OIO
installations into the new standard.
> Where is OIO on this?
OIO project has not taken a stand on supporting any existing data or
application modeling standard. However, the OIO design is intentionally
simple and minimalistic so that it can more easily map to multiple
"standards".
One example of "mapping" to multiple existing standards is the
multilingual module ("Local Text"). You can think of human languages as
"standards" which co-exist and cannot be so easily harmonized :-). You can
judge for yourself how well OIO's "Local Text" module works by visiting
the OIO Library (we have a full German translation done by Karsten
Hilbert).
I am not saying that we have the entire solution for supporting multiple
data and application modeling standards worked out. However, I believe it
is feasible and some of my ideas have been described on this mailing list
and elsewhere:
>From Plug-and-Play Web-Forms to Solving Data Interchange Problems
UCLA BioStat seminar, April 2001
Abstract: http://www.ph.ucla.edu/biostat/course/seminars/ho_ab.htm
Slides: http://www.txoutcome.org/scripts/zope/readings/OIO_talk/data_interchange
> I think that is why it has taken OpenEHR more time in delivering
> executable code. There is tremendous work that has to be done early on
> here before a product can be delivered.
Maybe. If the "standard" is complex and intends to be the one and only
"standard" for the entire universe, then it will take a lot of political
maneuvering to achieve. Even then, it may very well be obsolete before it
is approved by all the committees :-).
It may be a wiser investment to put tremendous work _after_ a light-weight
infrastructure has been implemented, tested, and found to be useful.
Thereafter, if we discover that more complexity is required in the
infrastructure layer, then we shall discuss, come to a consensus, and
build it through the network of real stakeholders : those who actually use
the system - NOT the politicians!
This is the design approach that we try to use for the OIO project. Does
that make sense?
> I think the only way that I can discover OIO is just to install it and
> try to figure out how it is similar to openEHR's methodology.
Actually, we have 18 presentations in HTML online (full sets of slides),
indexed and searchable through Google et al. You can find them here:
http://www.txoutcome.org/scripts/zope/readings/OIO_talk
In addition, we have 40 documents (some translated into Spanish) hosted by
sourceforge linked through the "Documentation" hyperlink from
http://www.TxOutcome.Org. You can find them here:
http://sourceforge.net/docman/?group_id=9295
In particular, the subsection on "OIO features" contains documentation on
OIO architecture and metadata descriptions.
Of course, many of the new developments have not been documented yet - we
use the open-outcomes mailing list to discuss new items of interest and
deficiencies (bugs and lack of documentations :-). You can browse the
searchable list archives at : http://sourceforge.net/mail/?group_id=9295
There are 1408 archived messages there as of today.
For example, I am copying this message to the open-outcomes mailing list;
so that it will inform current collaborators, and archive useful
information for future reference.
> Also, it seems that openEHR is trying to make this open to many
> platforms and many programming languages. OIO may allow you to run on
> multiple platforms, but can it be implemented in other languages since
> it is is restricted to Zope?
No, the OIO system is not restricted to Zope. Zope was chosen because it
is a convenient and appropriate tool. We have discussed a JAVA
implementation awhile back for Palm-based devices. Since the OIO kernel
functions are intentionally minimal, it should be quite easy to implement
on any other platform.
See here for a diagram of the OIO kernel functions:
http://www.txoutcome.org/scripts/zope/readings/OIO_talk/slides/oshca2002workshop/kernel_functions
> > We had some pretty extensive discussions comparing OIO forms to GEHR
> > archetypes over the past few years on this list. To my knowledge,
> > openEHR
> > archetypes are essentially GEHR archetypes.
>
> Also, Andrew, if OIO is so similar to openEHR (templates vs
> archetypes), why don't you join their efforts. You can help shape
> openEHR in areas that you see fit.
But I have! :-)
Since I heard about GEHR during the AMIA meeting in 2000, I have joined
their efforts : By comparing OIO forms to GEHR archetypes through
extensive review and pointing out that the OIO system may already be an
implementation of GEHR kernel. In many ways, the OIO project has
established the feasibility of GEHR/openEHR design and brought technology
that openEHR is advocating quite far into the clinical and clinical
research domains.
> From what I have studied here, forms maybe a whole lot simplier than
> archetypes, but archtypes are more powerful than forms which is
> another reason why this takes time. I would like you to compare the
> two in terms of how forms describe data structures such as lists,
> table series, tree structures, datatypes, etc.
Let me address this important topic in a separate message. Some have
complained on occasion that my responses are too long and too convoluted.
I shall at least try not to be too long :-).
Best regards,
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org (Hosting OIO Library #1 and OSHCA Mirror #1)
