Hi Tim, Because of your wide exposure to numerous systems and experts, I have two questions for you, both of which you can answer as briefly as you choose:
1. Did I capture an underlying difference between experts in this discussion we've had about Tim's system? Specifically, does one camp prefer high-level reusable units of meaning with enduring names (with some resilience to changes without changing the name), while others prefer to restrict re-usability to lower-level, more primitive (atomic) units of meaning, units consisting of fewer subparts and which allow for no changes without a name change? Are there basic variances of opinion around this axis and would Tim's MLHIM be a case in point? I can see how the question could be argued both ways, but maybe I'm assuming a lack of consensus where there actually might be little dispute. And I could be mischaracterizing MLHIM's position along this axis. I should have taken more time with it. 2. A second question concerns InterMountain Health and the VA's MDHT and other systems with which you are familiar. How do these systems persist their data? Do they put everything in standard RDBMS tables or do they put their records in some other container, such as XML or binary blobs, as do some openEHR implementations? A system based on MLHIM, for its part, would use XML (I'm assuming) to store all instance data. Is that practice quite common? Is it the norm? We've been arguing about whether XML is a good modelling tool. But how widely is it used for actual instance-level storage? Thanks, Randy On Wed, Apr 10, 2013 at 3:57 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 10/04/2013 16:42, Randolph Neall wrote: > > > > The real question thus comes down to what level of thought the nameable > components of a model should express. If the entire model could be > understood as a tree, how complex should the named branches of that model > be, and how enduring should the names of those branches be and what sort of > change triggers a change of name? Should named branches be allowed at all? > Or should the model consist only of re-usable leaves on unnamed branches? > Branches, even very complex branches, would certainly exist in the models > based on his CCDs, yes, but they would probably not be given names, and if > they are, those names would not endure across even tiny changes or > extensions. > > > this is actually a very deep question. I don't know that we even know the > answer for 20 year old programming languages, let alone archetypes. But it > is a core part of the thinking. > > Several realisations that have been made about this topic with respect to > archetypes: > > - archetypes are designed as 'maximal definitions' around a focal > topic. > - this doesn't mean they are data sets (they are not, except in > some edge cases like some lab results, where the archetype acts like a > template as well), but that it is entirely reasonable to aggregate data > point and data group definitions about the same topic together, even > though > only different subsets of the total set would even be deployed. Example: > the BP archetype contains systolic, diastolic, MAP and Pulse Pressure. > These are 3 mutually exclusive ways of measuring BP (i.e. sys+dia OR > MAP OR > PP), and yet they are in the same archetype... > - archetypes are units of governance > - a repository of archetypes is a library of re-usable domain data > definitions > > these principles give clinical modellers at least some handle on what is > appropriate in terms of branches, numbers and naming of data points and so > on. I am sure that at some theoretical level, mistakes are being made. But > in the end, the models are usable and re-usable, and that counts for a lot. > > > I wonder whether at even the most granular level, immutability is > realistic. There is a fair bit of content that Tim models for just one > ICD10 code component. Each ICD10-based CCD is itself a little tree, with > one branch with some leaves on it. What if the WHO "extends" the low-level > content in some small way, adding a leaf, without changing the code? That > would push Tim into a new CCD (named with a new GUID) for the very same > code with a completely different set of GUIDs for ALL the leaves. Models > using the old CCD would need to adopt the new one, and querying across the > transition would be aborted. And that would be consequential for something > as basic as an ICD10 code. This concern probably reflects some ignorance on > my part over what sort of change the WHO permits to the content of a given > ICD10 code, and how Tim would adapt to that. > > > I adapt with codeine. Due to the pain of thinking about it ;-) > > - thomas > > > _______________________________________________ > 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/20130411/bd4fd6d1/attachment.html>
