Andrew po-jung Ho wrote:
> On Mon, 13 Nov 2000 00:08:53 Thomas Beale wrote:
> ...
> >In a nutshell, for the OIO system to work as a GEHR server, it will need to have
>semantically equivalent ideas of TRANSACTION, ORGANISER, various kinds of CONTENT,
>and various DATA_VALUE types, and all the structural relationships between these.
>This is the object model GEHR servers agree to, and it is expressed both in
>Eiffel/UML, and also in an XML-schema document, which is how systems written in other
>technologies can understand it.
>
> What about in terms of input / output equivalence? What if OIO can store,
>manipulate, process, and output data according to GEHR archetypes?
The technical point to understand is this: the GEHR archetypes are currently written
in XML-schema. The way they are written is this: the GEHR object model - an oo class
model - is expressed in XML-schema. That means that every class in the GOM appears in
the XML-schema, TRANSACTION, ORGANISER, PROCESS_CONTENT, the lot. Each archetype is
then written as an extension/restriction of the schema; each archetype document is
effectively written in terms of the aforenamed concepts, in XML-schema syntax.
We are about to change the way we do this, and create a different schema based on the
GEHR "A" classes (the actual archetype constraint classes) and write archetypes as
proper instances of this schema. But the effect is about the same: the archetypes are
written in terms of a set of underlying concepts which all systems have to agree to to
work together.
Now, we don't believe that this underlying model is that onerous - have a look at the
GOM, you will find less than 40 classes, and that includes about a dozen DATA_VALUE
classes. We also expect that we will evolve it further (as we have already done in the
case of HL7) to incorporate things we have missed or badly modelled.
> >> The OIO now provides the "business logic" layer (forms) and a kernel that 1)
>renders the forms as web-forms, 2) builds database tables / fields according to the
>"forms", 3) import/export the forms as XML, and 4) archive the forms in online forms
>library server for upload/download. The web-forms can contain Java applets and can
>do client-side validation. There is an integrated "forms" editor, a "forms" manager
>(with version control), a patient/user ID manager, and a rudimentary data mining
>module. All these are built with Zope and are 100% browser-based.
> >
> >Hm. Then I think your "forms" are like class instance templates. Is there
>variability in the forms?
>
> Yes, they are class definitions (or class instance template if you will). When a
>form is filled out, an "instance" of the "form" is created. This maps directly to
>the clinician's daily experience of pulling out a blank form and filling it out. The
>blank form is an instance of the form. The "design" of the form is the class
>definition. Forms are reproduced through photocopiers to make more blank
>forms=instances. The reason to have "forms" is to allow *variability* in class
>definitions. That is also why "forms" are metadata.
>
> You are correct that I use the term "forms" not in a standard way. OIO forms do not
>contain layout data, instead they are purely class definitions (=metadata). However,
>they can be used by the OIO kernel to render "web-forms" that can be used to collect
>data according to the definitions.
Ok, I am beginning the understand the structure of OIO now. I suspect the main point
of departure with GEHR is that it doesn't have a strong underlying concrete model like
the GOM (i.e. is not expressed in terms of the strong types of a class model), but on
the other hand, it is the only other health system I know of that is seriously
meta-data oriented - a crucial factor for success, I believe.
I think that integration could take place in the following ways:
GEHR archetypes <-> OIO form definitions
GEHR system instance data <-> XML-schema instances <-> OIO form instances
It may be that OIO could act as a standalone GEHR server, or that incorporating a GEHR
server to add a bit of "hard processing" to data going in and out of the GUI might be
better. But there is a good match in the general structure of things.
> Well - in the meantime, thanks for allowing me to study GEHR. I am not convinced
>yet that the model is all that complicated. From my reading of the docs on GEHR, it
>seems very straight forward, elegant - and very similar to OIO. :-) Perhaps it is
>because the two systems are so similar that I find the GEHR model very elegant and
>powerful!
Ah, well, if it's not bad, it's because a lot of good minds worked on it over the
years. Out latest achievements have been on the shoulders of those before us, as
always.
> I told Sam during the AMIA GEHR session that we may already have field-tested GEHR's
>object model in an actual production system implemented through the OIO. I will be
>very glad to give you additional details to help you understand how the OIO works.
>
> If indeed it is true that OIO is a GEHR kernel (or nearly so), then this may
>accelerate GEHR's development and perhaps save a few million dollars. Would that be
>a good thing?
Always! We will pursue the matter here in Australia to determine the best path to
convergence/cooperation. One of the points that most fascinates me is that you have
come up with a system which is so heavily meta-data oriented, independently of us. I
said before that I knew of no other serious contenders in this area (actually not
quite true: Dr Dipak Kalra and David Lloyd's (and European partners') work on Synex at
UCL went down the same path, also independently, from a GEHR/CEN model, and last time
I looked, used the same approach).
One thing I would like to do is get some common terminology and models accepted. I
think the word "archetype" is a good one, since it doesn't get used for too many other
things, and I think it would be worthwhile if it could be accepted to mean "constraint
definition", which is what it is (and more than a "template", which is a more
simple-minded idea of "archetype").
We have already published the GOM, and will publish the GOM A_ classes as a constraint
model. We think this would be a good framework to incorporate other concepts; it is
better (we think) than the CEN ENV 13606 model, but very compatible; it has close
compatibility with CORBAmed's COAS model; and it is fairly congruent with the RIM USAM.
We still have to incorporate the UCL ideas, a couple of CEN ideas, and probably a few
more things from HL7v3 (which is still evolving). This model needs to be the object of
some agreement, because it is what is encoded in the XML-schema definition from which
archetype documents come, and to which GEHR-compliant systems must minimally comply
(if they don't, they can't even process XML instances let alone use the COM or CORBA
interfaces).
One further idea to float: it would not bother me to rename such a model something
other than "GEHR" (although "Good Electronic Health Record" is fairly neutral). It
would be nice if everyone felt that their intellectual efforts were not simply merged
into one group's framework. One possibility would be to use the name "openEHR", which
comes from the international non-profit being set up to promote and evolve open (and
open source) EHR models, systems and standards. Just an idea. Maybe we have too many
models already...
- thomas beale
