# Open Sorce Database

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2007-08-01 18:20 UTC
**Views:** 2
**Replies:** 7
**URL:** https://discourse.openehr.org/t/open-sorce-database/14666

---

## Post #1 by @adrian_gomez

Dear group

I’ve a question about ? what is the experience implementing openEHR in opensource database like mysql or progreSQL in a hospital of 500 beds?

Thank

Adrian Gomez

Hospital Italiano - ARGENTINA

---

## Post #2 by @system

> Dear group
>
> I've a question about ? what is the experience implementing openEHR in
> opensource database like mysql or progreSQL in a hospital of 500 beds?

I don't think there will be much difference as long as it comes to an
SQL\-based implementation\. The benchmarks for ANSI\-SQL\-handling MYSQL of
SQL\-server or Oracle are more or less comparable\.
It is very easy to test, you can also take a look at TPC\-benchmarks,
because you can regard the OpenEhr database\-use as a rather complex use
with 50 to 100 tables \(depending on the architecture\-specifics\)

But when you look to other ways, f\.e\. object\-oriented databases, like
Matisse or Cache, or XML\-features of databases, then you bind yourself to
vendor specific features, then it is another story, and not easy to
determine what is a good choice\.

There is not much discussion on this subject, good that you bring it up\. I
hope others will say something about this subject\.

Thanks
Bert Verhees

---

## Post #3 by @Tim_Churches

Bert Verhees wrote:
>> Dear group
>>
>> I've a question about ? what is the experience implementing openEHR in
>> opensource database like mysql or progreSQL in a hospital of 500 beds?
>
> I don't think there will be much difference as long as it comes to an
> SQL\-based implementation\. The benchmarks for ANSI\-SQL\-handling MYSQL of
> SQL\-server or Oracle are more or less comparable\.
> It is very easy to test, you can also take a look at TPC\-benchmarks,
> because you can regard the OpenEhr database\-use as a rather complex use
> with 50 to 100 tables \(depending on the architecture\-specifics\)
>
> But when you look to other ways, f\.e\. object\-oriented databases, like
> Matisse or Cache, or XML\-features of databases, then you bind yourself to
> vendor specific features, then it is another story, and not easy to
> determine what is a good choice\.
>
> There is not much discussion on this subject, good that you bring it up\. I
> hope others will say something about this subject\.

The key issue is no so much what database back\-end to use, but rather
what to use or write as the openEHR layer \(kernel and query system\)\. I'm
told that there are various closed\-source, proprietary implementations
of openEHR \(e\.g\. by Ocean Informatics\) which can use an SQL back\-end,
but only one open\-source implementation, by ACode in Sweden, which is on
the openEHR\.org web site\. But what is the current status of this
implementation \- it is rather hard to determine exactly what bit work,
what bits have been fully tested and what is left to be done, short of
installing it, looking through its source code and writing one's own tests\.

The latest release notes for it at
http://svn.openehr.org/ref_impl_java/TRUNK/readme.txt say:

---

## Post #4 by @system

I have some opinions on this, I like to express:

---

## Post #5 by @system

forgot to end my previous email properly, and the phrase in the end was
generated by Fortune, a small Linux\-program which does that in my emails, and
I leave them sometimes, when they are funny or in another way good\.

Kind regards
Bert Verhees

---

## Post #6 by @sebastian.garde

Instead of waiting an indeterminate length of time for the 'Acode implementation' \(which has been donated to openEHR as far as I know\) to finish, anybody interested in getting the job done faster could of course also consider to contribute to it instead of writing an entirely new kernel?
Take a lot and give a little bit back where you can\.
The java reference parser for example is very usable in the state it is in now, we use it all the time\.
I agree with Bert that the emphasis of openEHR is on the specifications, and that the reference implementations are a means of evaluating the specifications\. It is thus essential for the specifications to be open source and the source code of the ref implementation is great to have \- but you cannot expect 'download, install, and completed is my EHR project' ;\-\)

Sebastian

---

## Post #7 by @Tim_Churches

Bert Verhees wrote:
>> <snip>
>> <snip>
>> <snip>
>
>> I'm not sure whether that means it supports queries or not \- I suspect not\.
>>
>> So for an open\-source implementation of openEHR, it looks like, as at
>> August 2007, one has to either wait an indeterminate length of time for
>> the ACode implementation to be completed or one has to write an entire
>> openEHR kernel \(and test and validate it, which is the more
>> time\-consuming part\) oneself\.
>
> I have some opinions on this, I like to express:
> \-\-\-\-\-\-\-\-\-\-\-\-\-\-
> This is true, I wrote my own version of the kernel, following the specs very
> carefully, and heavily inspired by the work of ACode\.
>
> A bit of history and the current situation:
>
> Discussions around last Christmas, ended up in a way that I decided to go on
> on my own way, and write my own data\-access layer\. First I worked a lot with
> Hibernate3, but I came to hate the way you lose control when using Hibernate\.
>
> But a part of the idea of hibernate is good, the fact that it uses derived
> classes to make them persistent is good\. I followed that idea and I wrote my
> own data\-access layer for OpenEhr\.
>
> I am about to finish this work\. The test\-results are very promising\. I can
> tell you more in only a few weeks\.
>
> It was a big job, but I had to do it, because there was no open source work
> done, as you say\.
>
> Sad enough, I cannot publish my work as open source, all by all \(not only the
> data\-access\-layer\), it took me about a year to do it, and that money I have
> to make, to use for that very expensive thing called "living"\.
>
> Because my data\-access layer is fully based on SQL, and only clear simple ANSI
> SQL, it can be used on a wide range of database\-engines, open source, or
> closed source, it is just a matter of changing a configuration file\.
> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
> What and why
>
> I think, people spend a lot of time/money in OpenEhr, for me as a person,
> about a year of living, really a lot of money \(for a person, I am not a
> student, I have two suns, lovely, but expensive twins\)
> And for Ocean and ACode, also a lot of human time\-spent and so a lot of money\.
> This makes it impossible to give it away\. I see no other solution then to
> keep it closed source\. \(do you? I am interested in ideas about this\.\)

I don't know the exact cost, but I suspect that writing and validating a
production\-quality open\-source openEHR kernel \(including the query
language\) to work with popular open\-source database back\-ends, and with
bindings for popular open\-source programming languages would cost, say,
between $2m and $10m\. This is not much money in the big scheme of
things, but at the upper end of a the funding range for single research
projects\. It is conceivable that the philanthropic organisation of a
technology company could be persuaded to fund it\. It would be easy for a
government to fund\. It only needs to be funded once, then it would
quickly become self\-sustaining as other companies move to help support
it as part of their health informatics businesses \(if it works well,
that is\)\.

My take is that until there is such an open\-source, production\-quality
implementation, openEHR will remain a mainly academic endeavour and
perhaps may gain a niche or small foothold in the health informatics
scene, but it won't take over the world\.

> I regard the \*good work\* \(emphasize this\) done by Rong and Thomas and many
> others as reference work\. That is how they call it\. It is a reference\-kernel\.
> You can use it, inspire you're work on it, it is not meant to be working
> software\.

Yes, no criticism of ACode or Ocean Informatics\.

> OpenEhr, IMHO is \*not\* an open source project, but an open
> specification\-project, which is very very good\!\!\! I see no other way to do
> it\.

I agree that openEHR is definitely not an open\-source software project,
and that it is rather a set of open specifications\. I disagree that
there is no other way to do it, because I think that open source is the
future and that the current closed\-source software ecosystem will slowly
wither away over the next two decades\. But that is some time off, and
people will continue to try to make money out of selling closed source
software\.

> So these were opinions which I wanted to express, I am very anxious to hear
> others about this subject\.

My opinion is that there is no compulsion for anyone to produce a
completed, open\-source implementation of openEHR, but that without such
an implementation, openEHR will remain a niche player, a bit of a curiosity\.

Tim C

---

## Post #8 by @system

> Bert Verhees wrote:
> >> Dear group
> >>
> >> I've a question about ? what is the experience implementing openEHR in
> >> opensource database like mysql or progreSQL in a hospital of 500 beds?
> >
> > I don't think there will be much difference as long as it comes to an
> > SQL-based implementation. The benchmarks for ANSI-SQL-handling MYSQL of
> > SQL-server or Oracle are more or less comparable.
> > It is very easy to test, you can also take a look at TPC-benchmarks,
> > because you can regard the OpenEhr database-use as a rather complex use
> > with 50 to 100 tables (depending on the architecture-specifics)
> >
> > But when you look to other ways, f.e. object-oriented databases, like
> > Matisse or Cache, or XML-features of databases, then you bind yourself to
> > vendor specific features, then it is another story, and not easy to
> > determine what is a good choice.
> >
> > There is not much discussion on this subject, good that you bring it up. I
> > hope others will say something about this subject.
>
> The key issue is no so much what database back-end to use, but rather
> what to use or write as the openEHR layer (kernel and query system). I'm
> told that there are various closed-source, proprietary implementations
> of openEHR (e.g. by Ocean Informatics) which can use an SQL back-end,
> but only one open-source implementation, by ACode in Sweden, which is on
> the openEHR.org web site. But what is the current status of this
> implementation - it is rather hard to determine exactly what bit work,
> what bits have been fully tested and what is left to be done, short of
> installing it, looking through its source code and writing one's own tests.
>
> The latest release notes for it at
> [http://svn.openehr.org/ref_impl_java/TRUNK/readme.txt](http://svn.openehr.org/ref_impl_java/TRUNK/readme.txt) say:
>
> ##########
> Java openEHR Implementation project
> -----------------------------------
> VERSION Release-1.0.1 RC
>
> STATUS Based on openEHR release 1.0.1 RC and implemented Reference Model
> - EHR, EHR Extract, Demographics, Common, Data Structures, Data Types
> and Support, and Archetype Object Model, openEHR Archetype Profile.
> Besides, support for archetypes based object creation has been added
> into Archetype Object Model classes.
> The work is still in progress. The intention is to have complete
> implementation of openEHR Reference Model and Archetype Object Model,
> with support for archetype based object creation and validation.
> ###########
>
> I'm not sure whether that means it supports queries or not - I suspect not.

Tim,

Adding support for EHR Query is definitely on the road-map of the Java Reference Implementation project. A draft of the road-map can be accessed from [http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm](http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm). But one has to wait until the Query specification is released.

> So for an open-source implementation of openEHR, it looks like, as at
> August 2007, one has to either wait an indeterminate length of time for
> the ACode implementation to be completed or one has to write an entire
> openEHR kernel (and test and validate it, which is the more
> time-consuming part) oneself.

When we at ACODE donated the Java source code to openEHR, we hoped the implementation was good enough to serve as a good starting point for others to contribute to so they don't have to start from scratch. It was certainly not completed and would require lots of man-hours to keep it healthy and grow. The last three years journey proves to be very fruitful (considering how scarce the resources have been allocated to the project) - the Java implementation has experienced several major updates and now up-to-date according to the latest specification release (one proof is now nearly all clinical archetypes from the openEHR knowledge repository can be handled by the Java parser). Several tools and pilot applications have been developed based on the Java components from the project, e.g. LiU archetype editor. Both academic and commercial R&D projects have been conducted on the Java implementation. All these early implementations have been valuable for validation and improvement of the openEHR design specifications. This experience has been summarized as a research paper and accepted to Medinfo 2007.

I am more optimistic than I was three years ago since 1) the design specifications have been finally finalized so the main focus of the Java project will shift to adding new functionalities from updating existing software; 2) the interest on openEHR and archetypes based EHR systems have been increased a lot in the past 12 months - so it's not unlikely that the Java project gets external funding to speed up the implementation work; 3) my current employer, Cambio Healthcare Systems, a leading Sweidsh healthcare only Software supplier will sponsor the Java project development through my work, which means I don't have to use only my spare time on the Java project. In fact, they also donated an Linux server with high internet bandwidth to the Java project. A continuous integration server based on Apache Continuum has been configured there and will be announced through the Java project shortly.

And finally the project page will be updated and a new release will be announced soon before Medinfo.

Cheers,
Rong

---


**Canonical:** https://discourse.openehr.org/t/open-sorce-database/14666
**Original content:** https://discourse.openehr.org/t/open-sorce-database/14666