Andrew po-jung Ho wrote:
> With the OIO, the database/persistence is currently Postgres. The
> business logic is OIO forms (metadata). The GUI and the metadata rendering kernel
>are in Zope.
>
> >The business logic does all the computing work according to the semantic model it
>was based on, typically an OOPL implementation of an OO model in UML or similar. Such
>a model is the result of an ongoing requirements, analysis and design effort, and is
>the repository for thinking about the semantics of the domain and the system.
>
> Right. Like what items should appear on a given form and what answer choices should
>be allowed for each item.
Well, not quite - "business logic" refers to the underlying semantic model of the
system. It has nothing to do with forms (but I see from the below that your use of the
word "forms" is not what most software people would expect). So in GEHR it is the GOM
(GEHR Object Model); in CEN EN13606, it is a model expressed in UML and some formal
documentation; in HL7 it is the RIM; in CORBAmed it is the UML models or the IDLs of
the interfaces (which should be semantically equivalent). None of these models is
about forms, per se, although there is clearly an
implication about how to design forms based on underlying concepts. But form design is
also heavily dependent on the typical temporal usage patterns of the system by users;
by domain norms; by usability requirements and so on. So the link can be quite tenuous
in some systems.
> >Point 1: I am not sure you are doing anything wrong. I am certainly not criticising
>your work. I have an idea that it can be integrated with a GEHR server, and OIO would
>keep most of its current form (but I am currently working on pure supposition so
>far!).
>
> I am still wondering whether a GEHR kernel can be more easily built with Zope.
Not sure what you mean here. The GEHR kernel is already built in Eiffel. We don't see
any need to rewrite it. I also see no a priori reason it cannot be integrated in a
Zope system.
> If the OIO can import GEHR archetypes and operate according to the business logic
>contained in the archetypes, would that make the OIO a GEHR kernel? If not, what
>other requirements are there?
Well, that's an interesting question. If the answer is "yes", then the answer is
"probably". We are working on complaince criteria right now actually, and hope to
publish a position paper on XML strategy in the next little while, which will clarify
things.
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.
> >You would probably find that some of the more difficult logic could simply be
>passed off to the server, making OIO a bit simpler.
>
> Right. That's what infrastructures are supposed to do. Objects in Zope are capable
>of calling external routines. I am sure we can find a way for the OIO to call GEHR.
>Does GEHR run on Linux?
It will. We have just never compiled it on Linux, but since all the tools required to
compile it (SmallEiffel or ISE Eiffel) exist on Linux, there is no reason it won't
work.
> >Overall, the addition of GEHR to OIO is really adding business logic server (or
>middleware component, if you prefer) to OIO. THis might be more of an intellectual
>leap than a technical one to deal with.
>
> Very interesting. I thought the OIO was supposed to provide the "business logic"
>and other common services to medical/research record systems that use it. :-)
It probably currently does. If it does what GEHR does, I'll be surprised (mainly
because it's taken quite a few people quite a few years to get this far), but there is
most likely to be an overlap.
> 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?
> I talked to your colleague, Sam Heard, after the GEHR session last week at AMIA
>about our plans to manage "Reports" metadata in the same way that we manage our
>"forms" metadata. I am not sure if he understood what I was proposing.
We need to study OIO. I have already listed it as a work item for a group to work on
in our next funding round.
- thomas beale
