Re: Re: [Gnumed-devel] Qt licensing issues for GNUmed

[Tim Churches]

On Sat, 2003-08-16 at 08:09, Karsten Hilbert wrote:
> > There is technology which
> > can be shared in both directions, I think.
> I have read you refer to FEBRL (spleling?) on openhealth
> before. IMO it would behoove us to consider this code being
> one way to select patients.

Febrl was originally designed for use as batch-oriented record linkage
system - actually as a test-bed for new techniques for batch-oriented
record linkage. However, some parts of it have potential utility for
patient look-up in health applications. We will be trialling this in the
next version of our public health application, so I suggest that you
hold off until we have worked out the details of doing this. We also
need to get the copyright holders to adjust the Febrl license - it is
based on the Mozilla Public license and needs to be relicensed under 
the triple license now adopted by the Mozilla project - see
http://www.mozilla.org/MPL/relicensing-faq.html

We plan to adapt Febrl for use as the engine for a regional PIDS
(Patient Identification Service), styled after the CORBAmed PIDS
specification, but not slavishly compliant with it. The actual code
interface will be WSDL-compliant, I think (others are doing this work,
not me).

> 
> > For example, we have
> > developed a Python object-relational wrapper which improves on all the
> > existing ones (there are about 6 or 7 extant ones which we found)
> I should like to see that code and read the design
> considerations if possible. URLs ?

Still working out the licensing issues - will let you know when it is
available.

> 
> > and is more general in some respects that the GNUmed business objects.
> Certainly so. GnuMed business objects are *meant* to be
> specific. They are not intended to be an ORM although right
> now they do include a rudimentary one due to lack of selecting
> and using a good generic one. I behold that it should be
> worthwhile to consider using your ORM inside the business
> objects.

Sure. Ours is very far from perfect, and is likely to be substantially
re-written a few (more) times yet. Probably best to borrow ideas from
our ORM, rather than using it as a whole, since it was written with
specific requirements in mind. Anyway, at this stage the code is not
released, so it is hypothetical.

> 
> > We also have some experimental
> > (i.e. unusual) but very functional aggregate and statistical analysis
> > classes written in Python and R which could plug into GNUmed at some
> > stage (these classes were designed for analysing massive data sets of
> I'd think that Christof (Meigen) might be interested in that
> aspect for the normcurves/measurements work - R is a powerful statistical
> package. It's being used in OIO, too...

Which part of OIO?

> 
> > well as possibly leveraging GNUmed as a vehicle for public health
> > sentinel surveillance (in which GP's information systems transmit
> > aggregated, completely anonymous data on the numbers, age groups, sex
> > and broad reasons for patient presentations to a centralised public
> > health surveillance database on a daily or more frequent basis, to
> > permit early detection of very subtle trends in things like flu-like
> > illlness, asthma etc.
> Tim, I have been trying to tout *exactly* that to our public health
> authorities (Robert Koch Institut, Ständige Impfkommission) !
> That's certainly one way of getting GnuMed installed on GPs'
> desktops ...

It may provide a mechanism by which public health authorities can fund
GPs to use GnuMed. But a working GnuMed system is required
first...onwards! In the meantime, we are talking to commercial system
vendors about this.

-- 

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B  EB37 7891 46A9 EAF9 93D0

signature.asc
Description: This is a digitally signed message part