The way we understand these, they’re statistical calculations for specific values such as height or weight, based on a population average, similar to percentiles. We’re not sure how to model this in archetypes, and were wondering if anyone else have solved this already? We’ve got an archetype that’s related to child growth charts that will solve the problem for now, but we’re looking for a more generic solution.
One of our hypotheses is that Z scores and percentiles should be handled using some sort of RM “Statistical value” element. Could someone from the specs program comment on this?
Kind regards, Silje Ljosland Bakke
Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
I’ve just uploaded the Child Growth archetype to CKM a couple of hours ago - http://www.openehr.org/ckm/#showArchetype_1013.1.2741 - as it covers some of the data required for the archetype proposal – see RP 43 in the openEHR CKM.
However there is a question whether a Z-score should be an attribute for every quantity data type. Keen to get more expert feedback than my limited statistical knowledge.
Then there are also concepts like the estimation of pregnancy which is often recorded as ‘x weeks +/- y days’. Currently this is hard wired as two separate data elements.
I’d humbly advice against making Z-Score an attribute for every quantity data.
The first reason is that Z-Score is a meaningful metric for the assumption of normality, that is the possible values of the numeric quantity demonstrate a particular characteristic (the bell curve)
In a non-normally distributed case, the Z score is meaningless and even though many stakeholders end up assuming a normal distribution, there is a lot of data out there that is not distributed normally.
So if Z-Score becomes an attribute of every quantity type it will be an attribute that implies a particular statistical/probabilistic context when it is set and won’t be set that many times given all the instances of quantity types in openEHR.
So I believe from a software design/implementation perspective, Z-Score is a higher level concept than the quantity primitives we have in the reference model and should be modelled at the archetype level.
The slightly more subtle reason for not making z-score an attribute of quantity types is the wider definition of a probabilistic event. A particular diagnosis in a population could be interpreted as a probabilistic event, for which there is a population distribution, the prevalence, if we bend the language towards the clinical lingo.
Now when that diagnosis is expressed with a DV_CODED_TEXT and mappings to a snomed_ct code, there is also a valid requirement to associate a z-score to it, say to assess the likelihood of a particular diagnosis in the context of the patient’s data.
So now it may make sense to add Z-Value to dv_coded_text as well
So even though it looks like a simple metric, the Z-Value is associating statistics and all things based on it (machine learning, risk estimation etc) to clinical data and that association should be very clearly described IMHO, which would not be possible if we do it at the RM level.
If all of the above makes no sense and I completely misunderstood the suggestion, then accept my apologies along with a nice pint that I’ll buy when I see you next time
I don’t know if it should be in the reference model, but the ability to constraint this at archetype level could be useful for data validation purposes
As is the case, there are several different ways in which data form the data base is represented on a screen or inputted via the key board.
Next to text, codes, images there are numerical values.
Many times the present data types are sufficient.
But there are more complex numerical results such as:
value and normal ranges for a specific population
value as the result of a statistical method. The Z-vlaue is just one of them.
For each kind of statistical result we need a specific archetype pattern.
These could be additional (extended) data types, but equally could be standardised archetype patterns.
The latter I prefer because data types I associate with the interface with program languages. And there statistical result do not play a role.
