Re: [Fwd: Re: [Gnumed-devel] how to configure gnumed to use not just "localhost"]

[Thilo Schuler]

Carlos Moro wrote:

> Hi all,
>
> Congratulations Thilo for your work and experience with openEHR... It's 
> also always great to hear  of more medicine students with IT and open 
> source interests (i finished past year medicine studies, though at the 
> moment haven't went on with clinical profession, in favor of health 
> informatics... time will say ;) )

I think I will want to work as a clinician but none-the-less I find 
health IT issues fascinating and I want to help that their are better 
systems in the future when I start practising.

> Thilo Schuler wrote:
>
> > Karsten Hilbert wrote:
> >
> > > > Yes the project is going to be open source thoroughly as openEHR, 
> In past Eurorec conference, Dipak 
> (http://www.prorec.be/events/eurorec2004/eurorec/04-DipakKalra.pps) 
> spoke about a full opensource  reference implementation (in java) 
> scheduled for 2005. Also, a python implemetation is commented in openEHR 
> FAQ pages... Do you know something about its development status or 
> perspectives?

This is one of those going-to-bes. I know what is on 
http://www.openehr.org/projects/t_demonstrators.htm and that Thomas 
Beale (one of the main characters behind the two model approach) has 
gone to London to work with the CHIME/UCL guys on the java EHR server 
with openEHR technologie.

But overall the information policy is not to good. I will try to contact 
Thomas to find out more.

I don't know specifically about a Python implementation. Their a quite a 
few projects with openEHR specifications involved to some extend all 
over the world.

Recently their was a request on the openEHR mailinglist to send in 
project descriptions. The idea is to create a forum of early 
implementors. This could cater for more information about each other and 
better communication. I am very much in favour of this forum stuff and I 
send in a short description about my project.

> > At least the Presentation layer (and XUL doesn't want to be more than 
> > that) that itself is connected to other components (written in other 
> > languages)
>
>
> I don't  know about mozilla XUL (it seems heavily based on XML and 
> Javascript, please, correct me if i'm wrong... two big beasts  not easy 
> to deal with ;) ) but, wouldn't be useful for these first steps of 
> openEHR and related projects develop in  more widely adopted and known 
> technologies (python/wxPython/pyorb, java/Eclipse RCP/J2EE-corba 
> interoperable , other...). Maybe making easier for other developers to 
> understand and contribute will help in final adoption spread... An 
> example could be the experience of  original openEHR Eiffel's reference 
> implementation...

Yes XUL relies on XML and Javascript but it has many ways to link to 
other components (XPCOM).
I have chosen this framework because it seems to be a relatively simple, 
yet powerful way to express interfaces. What is also nice that it 
provides means for customization (skinning). And with mozilla their is 
already an engine to run the XUL interfaces even without connection to 
the underlying middleware and the backend.
Since the UI expression is all text (XML) my idea was that it can act as 
a kind of universal interface format that can then in successive steps 
be converted (tools) to other technologies like you mentioned. Actually 
their are already other XUL engins around that produce e.g. java code 
(see http://xul.sourceforge.net/)

What do you think about that? I am happy to discuss this and still can 
switch to more suitable technology. One thing that irritates me is the 
relatively small degree of XUL propagation.

This generator is not supposed to produce a whole EHR system but give 
archetype/template editors and idea what the these archetypes are good 
for (preview of mock interfaces) and producing a rough pattern of 
archetype-compliant UI that the EHR system implementors can then use 
eiter just as visual input or as starting point for their code.

I can still see that for small web based front ends a XUL solution 
powerd by web services could work.

As a proof of concept I envision builing such a small system. Maybe 
archetypes and templates could be produced that are compatible with 
parts of the Gnumed backend. The generated interfaces could then be 
linked to the backend by writing a web service wrapper for some 
middleware routines.



> Best regards and best luck,
> carlos

thanks

-thilo
>