I believe that for non leaf nodes I'm sure you can easily check for check form occurrences and types, I don't remember if cardinality was taken into account, I have to check that. For leaf nodes, I don't remember having any trouble specifying that kind of constraints.
2014-02-06 Bert Verhees <bert.verhees at rosa.nl>: > 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>: > >> 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 >> > > > > _______________________________________________ > 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>
