I have refined the generated statistics in AWB, and the result is shown
below for CKM archetypes (snapshot June 2011). Notes:
* the stats are over the 197 archetypes validated by the ADL 1.5
compiler (note that this is more strict than any of the ADL 1.4
tools). Another 80 archetypes did not pass, most for trivial reasons
of 1.5 validity like repeated occurrences and cardinality constraints.
* the stats are obviously skewed toward the actual archetypes that
have been done and are currently valid, which is more heavily
OBSERVATION and EVALUATION related types.
* the first group of stats is aggregated ontology codes, e.g. 3794
at-code definitions over those 197 archetypes (I will add in average
computation, but it is easy enough to see that its about 19 at-code
average per archetype).
o this is a guide to costs and scale of translation and binding work
* in the RM metrics stats group, these are aggregated counts of
archetyped nodes of any kind, i.e. there are 4327 nodes of any kind
of C_OBJECT. This is an average of around 21.5 nodes per archetype
o this is potentially a guide to complexity and maintainability
* in the RM breakdown stats group, each row indicates how many times
that RM class was mentioned (i.e. constrained) in the 197 valid
archetypes. E.g. the ADDRESS class was constrained 7 times.
o for each class, the number of occurrences of constraints on each
attribute is available on the next level breakout (see further down)
+ what this tells us (usually) is that a relatively small
subset of the total number of attributes defined for a given
type (e.g. DV_QUANTITY) are archetyped
+ within the DATA_VALUE types, it also tells us what DV_XXX
types are actually needed, according to clinical modellers,
e.g. DV_DATE, DV_DURATION and DV_DATE_TME are all used.
o not surprisingly CLUSTERs, ELEMENTS, ITEM_TREE and a few other
classes figure prominently
o re: the recent debates about ITEM_STRUCTURE simplification, note
that ITEM_SINGLE and ITEM_LIST types turn up in the stats (maybe
these classes are candidates for turning into ITEM_TREEs, or
maybe they are evidence that we need to retain ITEM_LIST?)
There is more work to go here obviously, and I won't try to draw any
hard conclusions right from what we see here. In terms of tooling the
next steps are:
* add a few further stats like average, max, min
* some cleanup in visual presentation
* generate an XML report form of this data with a .css for use with
normal browsers
* publish a new beta release of the Workbench, including all this
functionality
Any suggestions, feedback is of course welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111024/2516d7e5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iidhecfe.png
Type: image/png
Size: 25395 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111024/2516d7e5/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jgafeceb.png
Type: image/png
Size: 12176 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111024/2516d7e5/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gbccjicj.png
Type: image/png
Size: 5658 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111024/2516d7e5/attachment-0002.png>
