[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: [resmedicinae-developers]Plugin = Component?

From: Thomas Beale
Subject: [Gnumed-devel] Re: [resmedicinae-developers]Plugin = Component?
Date: Thu, 21 Mar 2002 08:51:58 +1000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:0.9.2) Gecko/20010726 Netscape6/6.1

Hi Christian & others,

Since you have mentioned it, the first cut of the openEHR models will be available for perusal in aout three weeks on Don't be put off by the amateurish feel of the site at the moment - it is changing quickly. These models are the result of wider input than our GEHR models were, and are also a formal input to the CEN EHR taskforce, which is charged with managing the next version of the CEN standard. Archetypes and some of the other ideas from openEHR are already assumed to be in; some things will take a bit more convincing. However, openEHR is about implementations, not standards as such, so if our ideas don't work when we try them, they will be fixed/replaced/thrown out.

In the coming months, people here might be interested to become part of openEHR, which simply means joining mailing lists (of course!) or watching the website; in some cases, some of you will want to do some implementation work, and it will be great to get some teams going around openEHR kernels, and/or inntegrating openEHR components into the projects you are already working on.

There will be 1 - 2 months before things get started properly, so you don't need to do anything tomorrow.

- thomas beale

p.s. I notice from the code below that everyone is writing in this unreadable "hungarian" notation (or "camelback" as some call it). Why don't people here use underscores, making words lexically parsable to the human brain? I.e. an_attribute_returning_boolean, AN_EHR_CLASS etc. I'm sorry to say that we will be using this format in openEHR, but I guess the name conversion rules are easy to define....(then again, I know that the german brain is specially wired to read really long words with no breaks or capitals to help parse it, so maybe that's why?!)

Christian Heller wrote:

Hallo Horst,

[English Readers: See below!]

um die mitlesenden Anwender nicht mit technischen Details zu nerven,
sollten wir diese Diskussion vielleicht in die folgende Liste verlagern:
Von mir aus auch gnumed-devel. Oder beide.

sehen. Das Problem ist dass wir immer noch durch einen evolutionaeren
Prozess gehen, bei dem es wenig Sinnn macht Code auf die CVS Server zu
laden der dann kurze Zeit spaeter wieder verworfen wird.

ist bei ResMed noch genauso :-)

Das hat wenig mit Mangel an Planung zu tun als mit dem Ausloten
"unbefahrener Gewaesser": wir versuchen, eine flexible plugin-faehige
Architektur zu finden, die es uns erlaubt die "eierlegende Wollmilchsau"
der Medizininformatik zu produzieren.

0 General Remarks

In the center, I see the Domain (Entities=DomainObjects=EHR-Model=~DB).
Around, there are several Applications (Modules), doing their very own
things such as EHR-Editor, LabData, FormPrinting/ReportGeneration etc.
Most of these Applications will have to access data of the Domain.

That's why I suggest a top-level distinction of Application and Domain and
that's why I created two independent directories for them in ResMedicinae.
KDE or GNOME for example are basically collections of Applications. They
don't have a special Domain directory because the data these Applications
are processing, are stored in files (or very small, Application-specific DB).
For our health domain, on the other hand, we need to create a big, common
Domain (Model) - similar to the GNUmed DB tables or to OpenEHR/GEHR. I guess
this kind of Domain would rather be comparable to SAP/BAAN/Peoplesoft's
Domain/DB Models.

1 Domain

For now, GNUmed/ResMedicinae should use their own DB models.
On the long run, however, these models should be replaced by the OpenEHR
ReferenceModel/Archetypes. That is also what the eventual
European/LatinAmerican/Australian (?) project will try to work on.

2 Applications

This is where we need to talk about things like ApplicationFramework/
Components/Plugins and Data/MessageExchange between Applications.
In ResMedicinae, I offer a common class (currently called AbstractApplication)
which can be used (by inheritance) as the parent class of any Application
(Module) to be created. Doing so, a developer gets offered a big amound of
default functionality for the new Application.
He/She doesn't need to use that default functionality, though. The
functionality (=Concern=Aspect) that _is_ used, however, should be indicated
by Interface classes. Example:

AbstractApplication (Module)    --- LabDataApplication
Configurable                    -|
Initializable                   -|
Displayable                     -|

The Module LabDataApplication inherits from class AbstractApplication
and also from the interfaces Configurable, Initializable and Displayable.
The interface Initializable forces the LabData Module to implement the two
methods "initialize" and "finalize". The interface Displayable forces the
implementation of the two methods "show" and "hide" or sth. similar.
When another (Main) Application starts the LabDataApplication, it needs to:

2.1 Call the constructor:

LabDataApplication a = new LabDataApplicationImpl();

2.2 Configure the LabDataApplication and hand over a Configuration object c,
to be determined somewhere in the code before:


2.3 Initialize the LabDataApplication


2.4 Display the LabDataApplication and possibly hand over a display
manager mgr (still need to figure out myself, am working on it):;

2.5 The other way around, the LabDataApplication would have to be destroyed
(hide, finalize, de/unconfigure).

That whole procedure is called lifecycle of a Component (=Module=Application)
and is described in detail at:

Now, concerning data exchange. To exchange messages between Applications,
there is something in Java called JMX. Don't know details yet.
To exchange data between Applications in terms of Client/Server, there
is CORBA/SOAP/RMI=RPC etc. It doesn't matter really if an Application is
a Client or a Server, since it can be even both at the same time. It can
offer data to other Applications through interfaces while using data of
other Applications as well. That is what people call "Distributed Objects".

That's why I don't know why OpenEMed distinguishes so hard (extra directories)
between Clients and Servers. But I think the reason is to offer clearly
separated Demo Applications for special purposes/CORBA IDL Interfaces.

I haven't done much with Plugins, but know roughly what it aims at (as user).
Could you write more on that?

3 Library/Framework

Like in KDE or GNOME, our Projects/Systems ResMedicinae and GNUmed etc.
should have a common library/Framework. This is the third top-level directory
in ResMedicinae, called "ResMedLib".

Keen on further discussion,

resmedicinae-developers mailing list

Deep Thought Informatics Pty Ltd
openEHR proposals -
Archetype Methodology -        
Community Informatics -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]