Hi Tim, > The research for this thesis directly addresses the issues described > above. I will be happy to share the thesis and subsequent papers as > soon as the thesis has been marked (2-3 months?). > > In short, I would suggest that you not let marketing efforts by major > companies color your perception of how to persist data.
Point taken? > If you ask the > question; "Why do I want to persist data?". Begin with that answer to > engineer a solution you will (I believe) find an optimal solution. > I am very,very intruiged. Any 'sneak peek' of any of your work or ideas would be very welcome (privately of course if you prefer). If I could demonstrate to a skeptical audience that we have a solution such as OpenEHR to model complex clinical concepts and a way of persisting it (or not needing to????!!!), I would be a happy chap and my meeting tomorrow would go a whole lot easier! To answer your question 'why do we need to persist data?', I increasingly feel that we should adopt a document based model of persistence as the main requirement is speed of access and accessibility to the clinician in document style. However both clinician and 'secondary data users' have legitimate though lesser need to analyse and view data in the manner of bulk SQL queries, for audit, recall purposes etc. My own preference would be to persist the document 'serially' with embedded hyperlinks to 'traditional' row-based items. I have not yet got to grips with how this might be expressed using OpenEHR. Rong's comments are interesting. I think he is on the right track by splitting persistence splitting between normalised tables and serialised data but correctly identifies that it can be difficult to query such data effectively. I know that one of the aims of Archetypes is to incorporate querying capability but I am a little hazy as to how this might work, or is it simply an XPath/XQuery like mechanism? Regards, Ian
