Hi Ralph, I am very impressed by the innovativeness and originality of this plan. It looks, at first sight, like the best two-level-modeling kernel architecture I have seen for years.
I trust you that it will work like you say it does, but I haven't looked deep enough into that to judge in that way. Also very good you share this with the world. You write: "Of course there is room for improvement and maybe it is not enough to implement all possibilities of OpenEHR " I don't know how to understand this. Do you mean that, for the moment, it is not possible to implement all OpenEHR requirements? Best regards Bert Verhees Ralph van Etten schreef op 5-2-2014 20:34: > 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? > > >> Additionally, storing the >> archetypes in a relational fashion is not be our first choice. > Why not? > > >> 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. > > 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. > 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. > > 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. > > > Regards, > > Ralph van Etten > MEDvision360 > >
