Persistence of Compositions
record 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 >> > > > > ___ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://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/4983f585/attachment.html>
Persistence of Compositions
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 >> <mailto: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 >> <mailto: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 <mailto: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 > <mailto: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/a8e0fa00/attachment-0001.html>
Persistence of Compositions
Hi Birger, On 02/06/14 08:26, Birger Haarbrandt wrote: >> 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...) Ah, yes, about the same reasons as ours. Thanks for sharing! > Are both versions available as open source? Yesterday I took a look > at it (just the code) and was impressed by your work! Yes, they will be available as open source. > 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? Yes it is possible. Although it is not implemented yet. So far I have only implemented serialization to openEHR XML. Deserialization will be possible, but only for the archetypes known to MEDrecord. In fact, the original idea was to just create an API which (de)serialized everything to/from XML and just stores the XML. Regards, Ralph van Etten MEDvision360 -- This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.
Persistence of Compositions
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>
Persistence of Compositions
On 02/05/14 20:36, Bert Verhees wrote: Hi Bert, Thanks for your kind words. > 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? At the moment only the functionality required for our use cases is implemented. For instance, OpenEHR allows archetype slots with wildcards. This is something we do not need for our usecases and therefore we have not implemented it yet. There are many things like this. Eventually I think we will support all OpenEHR requirements but we are only planning to implement them when there is a need for them. Regards, Ralph van Etten MEDvision360 -- This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.
Persistence of Compositions
> > > > 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 > <mailto: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 > <mailto: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/655ba3dd/attachment.html>
Persistence of Compositions
Ralph van Etten schreef op 6-2-2014 9:45: > At the moment only the functionality required for our use cases is > implemented. For instance, OpenEHR allows archetype slots with > wildcards. This is something we do not need for our usecases and > therefore we have not implemented it yet. There are many things like this. This brings in a little code-complexity. I solved it by validating every part against its owns archetype, and check the archetype-id's against the wildcard, and if everything fits, then the parts can be glued together legally to one dataset, which was, in my case, an XML-dataset. I think there is no other way, because you only know at runtime which archetype is going to be used in a slot. I am afraid you cannot escape this use-case for long time. If I was you, I would prioritize this one. good luck, I am sure you will succeed Bert > > Eventually I think we will support all OpenEHR requirements but we are > only planning to implement them when there is a need for them. > > > Regards, > > Ralph van Etten > MEDvision360 > >
Persistence of Compositions
Hi Ralph, > Am 05.02.2014 um 20:34 schrieb Ralph van Etten : > > 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 lis
