Regarding consistency checks, we have been able to generate schematron rules from the archetypes to check constraints stated on the archetype on the XML files. I think it is also what HL7 people uses for validating instances.
2014-02-06 Birger Haarbrandt <birger.haarbrandt at plri.de>: > 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 > > _______________________________________________ > 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/20140206/ea63bc78/attachment-0001.html>
