Hi Ralph, > Am 05.02.2014 um 20:34 schrieb Ralph van Etten <ralph at medvision360.com>: > > On 02/04/14 17:33, Birger Haarbrandt wrote: > > Hi Birger, > >> 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. > > Could you tell more about why a XML database does not serve your needs? >
That is because we got both complex and simple data structures. For example, we got millions of equally structured demographic data and lab values that can perfectly be represented in a static data schema. Furthermore, there is lots of catalogue data that fits best into relational tables. (Another important reason is, that our abailable ETL an BI tools are optimized to work with SQL Server...) > >> Additionally, storing the >> archetypes in a relational fashion is not be our first choice. > > Why not? > We have to do the trade off between performance and understandability of the data model. Medical data can become very complex. As we need to build data marts from our database it's more important to understand the data as it's not a real-time system. In my opinion that's a lot easier when you have data structured in a hierarchical way as a document (what XML is perfect for). > >> 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. > > I just released information about our "archetyped" MEDrecord. Our goal > was to create a more friendly API for MEDrecord based on archetypes. > While developing this API it proved to be a small step to also generate > SQL schemas from the archetype so that is what we tried. > Now we have a version of MEDrecord which stores data in a XML database > and a version which stores data in an SQL database whose schema is > generated using archetypes. > Are both versions available as open source? Yesterday I took a look at it (just the code) and was impressed by your work! > More information about the generated API and schemas can be found here: > > http://www.medrecord.nl/medrecord-json-api/ > > We are planning to implement some use cases and then see which approach > (XML database or SQL database) works best. > > But like I said, the main goal of the "archetyped" MEDrecord was to > provide a clean, type safe API to clients and not something which can > store anything without generating some code first. I'm wondering about it's capabilities to do validation of clinical data against archetypes. Is it possible to deserialize openEHR XML and check it for consistency or is it a one way ticket so far? > In time the "archetyped" MEDrecord might grow into such a solution, but > currently, for our use cases this is not important. > The important aspect is that we can create a clean API quickly which is > based on archetypes. > > What works best, relational database, native XML database or a > combination (like PostgreSQL with its XML datatype) is something we > still have to figure out. Although I see the benefits of using a native > XML database, I do not believe it will have decent performance any time > soon on cheap hard- and software for the type of queries we need for > building user interfaces without adding many more complexities. > I'm happy to exchange gained experience. I already got two ideas but I will need to do the implementation first. If it works I will create an article in the wiki. > Also, we basically treat archetypes as the schema for the information so > putting a schemaless database beneath it seems to be a bit of a > mismatch. Instead we attempt to convert the schema provided by > archetypes into a schema suitable for relational databases and I must > say I am quite pleased with the lack of complexity on the server side. > The server code turned out to be quite straight forward and simple. > Even the complexity of the generator which converts the schemas is > manageable. > Of course there is room for improvement and maybe it is not enough to > implement all possibilities of OpenEHR but for now it is enough to > implement the use cases we have in the foreseeable future. > We plan to develop it as new use cases present themselves instead of > trying to build something which can do anything first and then see if we > can fit the use cases in there. > I think your project might be a great starting point to implement a reference CRUD system people can learn from to build their own applications. Thank you very much for sharing :D > > Regards, > > Ralph van Etten > MEDvision360 > > Best, Birger > -- > This e-mail message is intended exclusively for the addressee(s). Please > inform us immediately if you are not the addressee. > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
