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).
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
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.
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.
not surprisingly CLUSTERs, ELEMENTS, ITEM_TREE and a few other classes figure prominently
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.
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).
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
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.
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.
not surprisingly CLUSTERs, ELEMENTS, ITEM_TREE and a few other classes figure prominently
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.
I should point out that the .bmm file format has changed, so if you have a custom model to add, it probably won’t work if it is in the previous format. Changing it is easy, and you can see the new format here. I will replace the old format files on the trunk in a few days once I have done a bit more testing.
Generally there is no constraint on dates so partial dates are allowed. When
dates occur as data points they will usually want to allow partial dates.
The concise dates are almost always part of OBSERVATIONs or ACTIONs where
they are reference model attributes and generally not constrained. Some
administrative dates are examples where partials may not be acceptable.
Interesting question but although I would suspect the number of
archetyped partial dates is extremely low, partial dates are very
common in real world clinical data, e.g. year of diagnosis or
month/year of procedure.
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org
