Diego Bosc? schreef op 6-2-2014 9:52: > 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.
Hi Diego, I am to using Schematron for validation-purpose, but I use it together with RelaxNG, because RelaxNG is better in testing structures and Schematron is better in validating simple constraints. But creating a RelaxNG from an archetype is difficult, that is complex and hard to maintain code. But now I see your message, I think it could be possible to create Schematron only and check every possible constraint, which mostly (not on leaf-nodes) are occurrences and cardinality. Do you have every possible constraint in an archetype covered by Schematron? Bert > > > 2014-02-06 Birger Haarbrandt <birger.haarbrandt at plri.de > <mailto:birger.haarbrandt at plri.de>>: > > Hi Ralph, > > > Am 05.02.2014 um 20:34 schrieb Ralph van Etten > <ralph at medvision360.com <mailto: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 > <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>
