requirements of health care apps

[Bud P. Bruegger]

Dear Erlangers:

I'm highly interested in using Mnesia/Erlang for an open source laboratory
information system.  We (Sistema and the joint FAO/IAEA division) plan to
get together a consortium to develop such a system.  In this context, we
have discussed the suitability of Mnesia/Erlang on the openhealth mailing
list.  

This discussion has identified some limitations of Mnesia/Erlang in respect
to health care applications that I hope can be overcome.  I would be very
grateful if you could give me information on the possibility and necessary
effort/time to overcome these limitations.  

Also, there are two killer apps that I imagine could work well with
Mnesia/Erlang.  I briefly describe them below and hope that someone could
give me some feedback on how well Mnesia/Erlang are suited for the purpose.

Limiations:
===========

1. Limit of Mnesia databases to a size of 4GB
(http://www.erlang.org/faq/x1084.html#AEN1103).  Competing dbms usually
handle terrabyte of data.  Is there an easy fix?  Does this limitation
apply to a single node in a distributed setting or to the whole database?

2. inefficient handling of text 
(http://www.erlang.org/faq/x299.html#AEN309).  Many health care
applications make heavy use of free-text style data (such as medical
records) that are if possible losely structures (with XML).  How difficult
would it be to extend Mnesia/Erlang to efficiently store and manage
(regular expressions, free text search etc.) textual data?  The FAQ
mentions work underway.  Will this only apply to Erlang or also Mnesia?
Does anyone know when to expect the results to be available?


Killer Apps:
============

1. Persistent Object Store
--------------------------

Many health care applications seem to use some object-oriented
implementation language (often Java) and use an object-relational mapping
that makes objects persistent in a relational DBMS.  The persistance layer
brings a lot of overhead since object access is handled by the persistance
layer, JDBC, SQL interpreter, to finally reach the native representation.
A more detailed description of object-relational mapping can be found in
http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm and
http://www.ambysoft.com/persistenceLayer.html.  

My impression is that this approach is way to slow for managing large
numbers of fine grained objects.  (Note that this is generally accepted for
Enterprise Java Bean Container Managed Persistance--a variation of the
above topic).  I looked into object-oriented DBMS as alternatives, but
didn't find anything convincing.  The serious OODBMS are not open sourced,
the open sourced ones are usually simplistic (no redundancy, fail-over,
etc) and yet slow (since written in Java).  

I imagine that Mnesia, being object-relational and very fast, would be a
great backend DBMS for a persistent object store.  The overhead introduced
by a Java persistance layer on top of Mnesia intuitively seems to be less
than that of the "normal" object-relational mapping.  And the distribution
and fault-tolerance features of Mnesia are unique and highly attractive.  

I would be very interested in you opinion on feasibility, performance,
degree of paradigm mismatch, etc.  A practical project could for example
add a Mnesia backend to Castor (http://castor.exolab.org/).  


2. Distributed, fault-tolerant XML Repository
----------------------------------------------

Another killer app (that is admittedly related to the above) would be a
distributed, fault-tolerant xml repository based on Mnesia.  XML is
difficult to map to relational tables (see
http://www.poet.com/products/cms/white_papers/xml/repository.html) and some
approaches use a (IMHO slow) object-relational mapping
(http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xmldbms/xmldbms.ht
m) to overcome this problem.  
I would be very interested in your opinion on how well Mnesia would be
suited as a backend for an XML repository.  For example, how easily the
structure of XML would map to Mnesia.  

Looking forward to your feedback

many thanks

--bud
/------------------------------------------------------------------------\
| Bud P. Bruegger, Ph.D.  |  mailto:bud@REDACTED                       |
| Sistema                 |  http://www.sistema.it                       |
| Information Systems     |  voice general: +39-0564-418667              |
| Via U. Bassi, 54        |  voice direct:  +39-0564-418667 (internal 41)|
| 58100 Grosseto          |  fax:           +39-0564-426104              |
| Italy                   |  P.Iva:         01116600535                  |
\------------------------------------------------------------------------/