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.
o 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130410/5f1e3211/attachment.html>
