On Mon, 2007-11-05 at 06:18 -0500, Greg Caulton wrote: > Of course that would break if a new data element was added in a > position (fabricated) > data[at0001]/events[at0099]/data[at00100]/items[at0004]/value but the > simplicity is tempting.
This is of course why you should (IMHO) change your focus (it takes an "Ah Ha moment") from "data model" to "information models". Using an object database (ZODB, POET, Gemstone, Versant, Objectivity/DB, etc.) in your chosen implementation language is usually transparent at that point. If your heart can't handle that (OODB) approach for some reason and you insist on PostgreSQL or Oracle (please do NOT use MySQL for healthcare information) you should still look at using the custom data type capabilities of them and follow the information model as defined in the specifications. Again, you end up with an information model approach and you do not adhere to (necessarily) to a relational model but you still maintain data integrity and the relationships defined in the information model UML. DISCLAIMER: I understand that Ocean Informatics uses MS-SQL but I do not know what their "data model"/"information model" looks like at the persistence level. The really cool thing about truly supporting the openEHR Information Models is that it doesn't matter as long as you can support and EHR Extract in context of the information requested. My 1 cent (the USD is in trouble). Cheers, Tim -- Timothy Cook, MSc Health Informatics Research & Development Services http://timothywayne.cook.googlepages.com/home LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
