Hi Birger, In our EHRServer we took the opposite approach: we get XML compositions committed, we store those in the filesystem and we extract and create records on a relational database for parts of those XMLs. The difference from EHRGen is that EHRGen has the composition model implemented as classes and we have an ORM tool that maps objects to relational databases (generates DB schema, does CRUD, validate constraints, etc., we deal only with the object structure, not directly with the database). I'm really interested of comparing pros and cons of our different approaches, mostly on the querying and retrieval side. Here is a small demo of EHRServer: http://www.youtube.com/watch?v=D-hs-Ofb8SY Also the projects is public under my GitHub account: https://github.com/ppazos
-- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 4 Feb 2014 17:33:46 +0100 From: birger.haarbra...@plri.de To: openehr-technical at lists.openehr.org Subject: Persistence of Compositions Hey there, we make good progress in understanding and applying openEHR to our Data Warehouse project. First data mappings have been done and a poc ETL process utilizing mapforce generated c# code has been created for vital parameters (originating from the ICU). Currently, I'm working on the data model of the persistence layer. I know that there has been some discussion about this topic in the past and recently. I checked implementation examples like Pablo's ehrGEN project and Erik Sundvalls' Liu EEE. Additionally I read a paper that gave a helpful overview about persistence strategies and enjoyed the discussion Bert started on LinkedIn. To get to the point: We intend to use a mixed approach involving a MS SQL Server. More or less static data is supposed to be in the relational part while most clinical data (with the exception of lab values for example) should be represented as rows of XML datatype. Erik's approach was to develop a proprietary XML Schema to wrap compositions and contained entries. Obviously, this might work in a native XML database like eXist but does not serve our needs. Additionally, storing the archetypes in a relational fashion is not be our first choice. Therefore, I'm interested to learn if any of you has already spent some thoughts about best practices to split compositions into individual XML documents while keeping the relationship throughout different tables and/or rows. Cheers, -- Birger Haarbrandt, M.Sc. Peter L. Reichertz Institut f?r Medizinische Informatik Technische Universit?t Braunschweig und Medizinische Hochschule Hannover M?hlenpfordtstra?e 23 D-38106 Braunschweig T +49 (0)531 391-2129 F +49 (0)531 391-9502 birger.haarbrandt at plri.de http://www.plri.de _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140204/fdf8933e/attachment.html>
