Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Twitter


In this Discussion

El fin de este foro es dar soporte gratuito y comercial a los distintos productos y servicios de El soporte gratuito se brinda en los foros de acceso público y no tiene garantía de tiempo mínimo de respuesta. El soporte comercial se brinda en foros privados donde se garantiza una respuesta dentro de las 24 horas.

generality and scalability of EHRServer

edited October 2013 in EHRServer
Hi all,

We want to use CaboLabs EHRServer's to store some openEHR compositions we have on our project.
If I understood well, some classes of the reference model (Version.groovy, Contribution.groovy, etc.) are implemented to model the datasource (a H2 database).

My initial questions are:
1) Are the classes implemented comprehensive, that's it, can one store any composition on the server?
2) By using a in-memory/file Java database, what is the expectation about scalability? We plan to store 100K compositions initially but we are wondering whether H2 can scale to that.
3) Since we have the compositions in XML, what is the best way to load them in the EHRServer?



  • Hi Douglas, thanks for your interest in EHRServer!

    Just a couple of context concepts:

    a. There's no need to implement openEHR IM classes one by one on the database to be openEHR compliant. It depends on the parts of openEHR the system implements. In EHRServer the main functionalities are COMPOSITION commit and query, so Version is needed to implement COMPOSITION versioning (in the near future) and Contribution is needed to implement commit log and it can help to implement rollback of commits if needed.

    b. This implementation uses ORM, so we don't really care about the database schema, we design and develop in OO, and the ORM (provided by Grails Framework) generates the schema and handles DB operations e.g. we don't code SQL queries.

    c. Since we user Grails, the DBMS doesn't matter, you can use H2, MySQL, Postgres, Oracle, ... just change the datasource config and copy the right Java DB connector JAR to the app.

    Said that:

    1) There are some classes that are defined in openEHR IM and some that not. The clinical information is saved into a generic structure designed to simplify querying, that is not part of the IM but can store any data point from a COMPOSITION. COMPOSITIONS are saved in the filesyste as received, i.e. the XML. Right now we support 3 datatypes (just for testing) DV_CODED_TEXT, DV_QUANTITY and DV_DATE_TIME. I'll implement more datatypes soon, this means that only implemented types can be queried.

    2) See c.

    3) Use the commit service. See REST API here: and expore the current test app here:
    You can find a demo that uses the test app here:

    Kind regards,
Sign In or Register to comment.