This is getting to be a very informative discussion for me.
I think OIO is actually more similar to GEHR than you think. I'll
try to explain below.
----
On Sun, 12 Nov 2000 18:50:45 Thomas Beale wrote:
>Let's consider the architecture of a web-capable information system. THe following
>elements are required:
>
>- database/persistence
>- business logic
>- GUI front end
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.
>The back-end does mainly high volume but fairly mindless data transformations
>according to a fairly low level ER model, or else an object model (in the case of
>object databases). The front end does data transformation to get data onto the
>screen, and some more intelligent validation to take data in. Both front and
>back-ends may of course have some very sophisticated processing in them to
>achieve their ends, but neither are implemented at the level of the business model -
>they work with technical concepts like "rows" and "input fields" rather than business
>or domain concepts.
Exactly.
>THere are many systems which only have a backend, a front end and nothing in between.
>The problem with these systems is that the underlying business rules and object model
>are implied in the GUI code and (typically) relational schema of the database; there
>is no explicit place you can go to see the design model of the system.
Right. That is why separating the business logic "metadata" from the rest of the
system is critical.
>Consequently, the whole process of maintenance and enhancement
>must be done purely at the implementation level (maybe with a bit of help from ER
>modelling tools) - there is very little possibility for any intellectual
>understanding and modification of the system at a design level. As a result, such
>systems soon stop being able to deal with changing requirements.
Right. Like when a new lab test or disease or treatment is discovered.
>Now, in an information-rich domain like clinical medicine, where the numbers of
>concepts are measured in the 100,000s, much of it highly structured, the need to be
>able to reason about how such information is processed is paramount to a successful
>system. It's a hard problem, there's no doubt about that. But in the long run, decent
>business logic is what is needed (sorry about using the
>word "business", but it's a standard in the oo literature; some people talk about
>"domain" models, but they're not quite the same thing; anyway, it's nothing to do
>with finance).
I agree 100% so far. The reason why OIO uses the term "forms" to attempt to describe
this concept is that "business logic" is kind of hard to grasp for most scientists and
clinicians.
...
[Database implementation section skipped. I agree that interpreted languages are not
the best to use to implement DBMS.]
>Now.... the question of suitability of Python for the GEHR kernel hinges on questions
>like:
>
>- performance
>- solid type system
>- decent OO modelling semantics (e.g. design by contract, genericity, MI, feature
>redefinition, etc).
>
>Python is not likely to come up to the mark required by certain classes of systems,
>including GEHR. There is nothing wrong with Python (I am considering using it
>actually), but it won't do the job in some cases.
I am sure you can even implement GEHR in assembly. Of course, Eiffel gives you lots
of conveniences and object suppport. If a compatible
system can be built in Zope that can "render" GEHR's business logic, then it would be
a GEHR kernel.
...
>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. 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?
>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?
>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. :-)
We need to think about how we can integrate the two projects!
>By the way, despite some of my comments, I have the greatest respect for people who,
>with whatever experience, actually get down and do something active.
Thanks! Since it cannot be bought, it has to be built.
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.
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.
>I think we can achieve something together; there is just a learning process required,
>and with that, patience on both sides.
Yes. Since our two projects use different terminology to describe similar concepts,
please let me know if I am not making myself clear.
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
