Greg, In this case at0004 does represent a unique concept but if you take another archetype that uses archetype internal references such as OBSERVATION.blood_pressure.v1 at0004 is not a unique concept as a systolic BP within an "Any Event" event is different to a systolic BP within a "5 Minute reading" event. Therefore you should consider the full paths as your unique concept identifiers, not the node IDs.
BTW, the node ID predicates on singular attributes such as data, protocol, state etc are superfluous and if you want to shorten paths, this would be a valid way to do so without changing the semantics of the path (although it is not a significant shortening). For example, the following path is equivalent to the path previously provided in the query. o/data/events[at0002]/data/items[at0004]/value Regards Heath > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Greg Caulton > Sent: Tuesday, 6 November 2007 12:24 AM > To: For openEHR technical discussions > Subject: Re: Searching/Accessing your data was: OpenEHR queries > > One reason for the question was that it wasn't clear whether the > atxxxx uniquely identifies a concept within the ADL. I think it still > does, but it can have different context depending on where it occurs. > > Implementing a hierarchy of information (information model) using > entity relationships (data model) is common place. > > The argument of Object databases versus Relational databases is an old > one that I expect most people have already chosen their camp based > upon their personal career experiences. > > I will agree with you that MySQL is not well suited to terabyte > databases with 1000's of concurrent users, with many people attempting > to update the same patient record :-) My own hospitals largest table > is growing at a rate of 500,000 rows per day, MySQL would choke with > the number of queries and updates hitting it regardless of hardware > IMHO. > > Greg > http://www.patientos.org > > On 11/5/07, Tim Cook <timothywayne.cook at gmail.com> wrote: > > 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 > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
