On Sun, 12 Nov 2000 19:11:58 Thomas Beale wrote:
>Real question is what is the object model being used? I.e., CORBA and the rest expose
>an object-oriented interface of a server to the network. This interface is defined by
>an oo model; so a choice has to be made here. For example, CORBAmed's PIDS interface
>specification is effectively a model for demographic
>information.
I am sure the object model is sufficiently flexible. For example, if we don't have
the social security number, I am sure it will still work.
>> > Especially, if each does it a little differently?
>>
>> Now, you know very well there is no magic bullet for this (except CORBA?). The
>solution must include some type of metadata standard. This has nothing to do with
>whether the implementation is done with Eiffel, Zope, C++, etc.
>
>Well.... not quite. Back to the GEHR kernel: the interesting thing about it is not
>really that it's done in Eiffel, it's that it processes archetypes, (i.e. knowledge
>definitions, or if you like, meta-data definitions) written XML-schema. It is
>completely data driven by these definitions, and the development and operational
>context for
>archetypes is what turns it into a different class of system. (I did not invent this
>kind of concept of course - there is a great deal of literature on data-driven and
>meta-modelled systems).
Sounds exactly like the OIO-forms!
>So archetypes provide a kind of meta-data standard to drive systems with. They are
>designed to be edited standalone, managed and QA'd by clinicians, and used to drive
>installed systems. Most of all, they are designed so that standardisation processes
>can be built around them, without reference to any software technologies whatsoever.
Right! Systems that can "render" OIO-forms will be mutually compatible at the
"metadata"="business logic" level and therefore be able to interchange both metadata
and data.
>GEHR archetypes as they stand today are not the last word on this approach, on the
>contrary, they are just a beginning. But all the same, the approach is already
>bearing fruit. For some time now, we have been able to perform the process mentioned
>above (write an XML-schema archetype, parse it via Java & Eiffel, load it into a GEHR
>database, retrieve it, and finally, build EHR content compliant with the archetype,
>and save that as an EHR transaction).
We have also been using it in OIO. We can export an OIO-form as XML from one server,
load it into another OIO-server, and fillout the form in the second server. We even
have an online OIO Forms Library running at www.TxOutcome.Org that allows
upload/download/browsing/preview of forms.
>Whether or not you like Eiffel is irrelevant; you could write a homologous system in
>Java if you wanted.
Exactly! It may be good to make OIO-forms and GEHR-archetypes interchangeable. That
way, OIO immediately becomes a GEHR kernel and GEHR becomes an OIO kernel.
...
>Well, as per my other post, the core problem in designing systems is doing the
>business logic, or middleware model and software. Database and front-end are really
>predicated on this. And Zope is not suited for developing such a model or software at
>all; however, it seems that it could provide a nice back and front-end "sandwich"
>environment to do the core development in/with.
>From my experience, Zope is adequate for the link between the front and backends.
>Hence, it is usable as the *static* component of the middleware. The "business
>logic"="forms" is the part that I would consider the *dynamic* component of the
>middleware.
I look forward to your critique of the actual OIO implementation.
... section on "kernel-like" functions skipped.
>> >If I have a Java application, how do I use Zope as an application server for that
>application?
>>
>> Zope does not have a built-in JVM and thus does not run Java. Thus, server-side
>Java is not supported. However, it can serve Java Applets just fine.
>
>Which is what you would write your GUI in.
Not necessarily. The GUI can also be written in HTML/Javascript.
>But the question about the server side relates to business logic.
One can use DTML and any other language (Python, C, SQL, etc) through "external
methods" - perhaps even Java if a JVM is installed on the system. I wrote the OIO
kernel entirely in DTML. (I know, I know, *real programmers* don't develop with DTML.)
The real story is that I planned to use Python if necessary - but it has just not been
necessary. Why use 2 languages when one is sufficient?
...
>> Currently, OIO exports
>> metadata in XML format. This means compatible systems are defined by
>> their ability to use that metadata.
...
>They need more than the same format - they need to agree to a common meta-data model.
Precisely! That's what OIO provides. (and perhaps GEHR also does.)
>I think we're getting somewhere with this!
I encourage you to go to the OIO Forms Library and preview the forms and browse their
items / itemtype attributes. Download a form from there and look at the XML file.
You will get a sense of how easy/hard it will be to transform the OIO into a GEHR
kernel.
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
