Tim, >A couple of things to say here. 'Redefinition' as in openEHR and most model-based systems I know of doesn't mean you change something that has been deployed. It means being able to specialise an existing model in the design environment, in a similar way as in object-oriented programming. So the point is to be able to re-use and adapt existing definitions, not just 'use' things.
>Not being able to do this means either: - you are stuck using someone else's definition, and you just live with not having the bits you wanted - you have to make a copy, and rewrite to suit yourself. Now you have a different model, technically unrelated to the original, and tools have no idea that they might be able to query for some of the same data points. If you look at the sort of thing Tim models in his CCDs, the concepts tend to be very granular and low-level and tend to embody pre-existing classification systems, such as ICD10. As long as he keeps to that sort of thing, these individual tiny units of thought, in and of themselves, would probably not need to be specialized or extended. That's why he can argue that specialization and extension are bad. The need to specialize would seem to increase when the archetype or concept embodies a higher level of thought, involving more interrelated and moving parts. For example, concept A will probably not change or be extended, nor will concept B. But when your concept includes some combination of A and B, combined with C, then someone will probably need to extend or specialize it. As I understand it, Tim's system could model A, B and C into some CCD known as E. But not the slightest thing about E could be extended or added to without calling A something else, B something else, C something else and the whole thing (E) something else. Then, as you say, the power to query across the change is lost despite continuity of most of the content. 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. 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. Randy On Wed, Apr 10, 2013 at 9:47 AM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 10/04/2013 13:33, Tim Cook wrote: > > [reposted for Tim; hist original bounced] > > On Wed, Apr 10, 2013 at 5:14 AM, Thomas Beale<thomas.beale at > oceaninformatics.com> <thomas.beale at oceaninformatics.com> wrote: > > > it's similar, but misses the crucial distinction between archetypes and > templates. Without that there is no library of re-usable concepts to use in > your data-set definitions. As far as I can tell, this distinction just > doesn't exist in MLHIM. So it means that every 'model' has to make up its > own definition of standard items like vital signs, lab analytes and so on. > > > MLHIM allows reuse but does not allow redefinition. Redefinition of a > component after it has been used to generate instance data is a BAD > THING. You are simply looking for trouble when models can morph into > something they were previously not. Then we can discuss the > complexity managing that process. It just isn't necessary in MLHIM. > > > A couple of things to say here. 'Redefinition' as in openEHR and most > model-based systems I know of doesn't mean you change something that has > been deployed. It means being able to specialise an existing model in the > design environment, in a similar way as in object-oriented programming. So > the point is to be able to re-use and adapt existing definitions, not just > 'use' things. > > Not being able to do this means either: > > - you are stuck using someone else's definition, and you just live > with not having the bits you wanted > - you have to make a copy, and rewrite to suit yourself. Now you have > a different model, technically unrelated to the original, and tools have no > idea that they might be able to query for some of the same data points. > > There is actually no such thing as 'redefining a deployed model'. Models > can be evolved over time, and they get new version numbers. Breaking > changes get new major versions, which are treated as distinct models in > archetype land. > > But new versions with non-breaking changes can be treated by querying, > modelling tools, reporting etc as being compatible with earlier versions. > Being able to query safely over longitudinal data whose models change over > time is essential in health. > > It's clear that these needs (specialisation of models, longitudinal > querying over data) are seen as essential by large orgs, e.g. the CIMI > members Mayo clinic, InterMountain Health, Veterans Health, Nehta and so > on. The OHT Model-driven Health Tools (MDHT) project is founded upon > concepts like model specialisation and re-use. > > I don't think there is any way these needs can be ignored in a scalable, > adaptable health information modelling ecosystem. > > - thomas > > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130410/a338f465/attachment.html>
