Ok guys, sorry, I?m a little confused as to what is the result here.Thomas,
could you kindly clear it out for me?
The spec says:
invariant
units_valid: units /= Void and not units.is_empty
But you also said
However ... the current specification allows DV_QUANTITYs to have an
empty unit string
I just want my archetype validator to follow the specs, so I?m guessing, it
should really consider [units=] as IN-valid, right?
Cheers
Tony
On Thu, Feb 12, 2009 at 5:01 AM, Sam Heard
sam.heard at oceaninformatics.comwrote:
Hi All
It is possible to use the proportion with the numerator of 1 to express
continuous reals from 0...n
It is how we say that someone has had 5.1 lots of something, or fractions.
Cheers, Sam
*From:* openehr-technical-bounces at openehr.org [mailto:
openehr-technical-bounces at openehr.org] *On Behalf Of *
Williamtfgoossen at cs.com
*Sent:* Wednesday, 11 February 2009 7:27 AM
*To:* openehr-technical at openehr.org
*Subject:* Re: CQuantityItem.units not empty
Thomas wrote:
In a message dated 10-2-2009 18:21:06 W. Europe Standard Time,
thomas.beale at oceaninformatics.com writes:
As far as I can see, the current openEHR data types satisfy your needs
(with one exception - see below):
DvQuantity - handles all PQ, including with no units
DvOrdinal - handles all ordinals, with any kind of symbols, including from
coding systems I don't understand the need for summations etc for ordinals,
because the general nature of ordinal values is that that symbolically
identify arbitrary ranges in a value space (e.g. amount of pain, amount of
protein in urine etc). Mathematically they don't satisfy the requirements to
be summable. Can you explain further the intended semantics here?
William: That is perfect and will help deal with the VAS and numeric and
base ordinal.
The exception is that neither of the above types handles a non-integral
'ordinal' idea. Hence my proposal of DV_SCORE. There are probably better
solutions, I have not thought much about it. I do think however, that any
solution needs to be mathematically sound, because downstream data computing
relies on that.
The mathematical requirement of summation is a clinical necessary feature
for about a 1000 to 10.000 assessment scales used in a variety of clinical
domains.
The generic feature is that an ordinal scale is used as a value for a
variable, so per node the value can be e.g. 0 = no problem, 1 = some problem
and 2 = severe problem
the semantics is clear and indeed an ordinal scaling.
However, ususally assessment instruments / scales / indexes of scores
consist of more than one variable. E.g. Apgar score has 5 variables, with a
minimum score (worst case) = 0 and a maximum score (best case) = 10.
Similar scales include Barthel, Glasgow coma scale, Braden etc.
So the summation as mathematical approach is as follows (using the
following explanation to the scores: 0 = no problem, 1 = some problem and 2
= severe problem).
variable 1, score = 1
variable 2, score = 0
variable 3, score = 2
variable 4 score = 1
variable 5 score = 0
variable 6, score is 0
Total score on the instrument is score variable 1 + score variable 2 +
score variable 3 + score variable 4 + score variable 5 + score variable 6 =
1 + 0 + 2 + 1 + 0 + 0 = 4.
This is usually viewed agains scientifically derived reference ranges, e.g.
4 out of 12 (maximum for 6 variables is
So for appropriate scales / indexes etc the mathematics need to be possible
on the ordinal values.
See for a discussion on these features e.g.
*White
TMhttp://www.ncbi.nlm.nih.gov/sites/entrez?Db=pubmedCmd=SearchTerm=%22White%20TM%22%5BAuthor%5Ditool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_DiscoveryPanel.Pubmed_RVAbstractPlus
*, *Hauan
MJhttp://www.ncbi.nlm.nih.gov/sites/entrez?Db=pubmedCmd=SearchTerm=%22Hauan%20MJ%22%5BAuthor%5Ditool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_DiscoveryPanel.Pubmed_RVAbstractPlus
*. *Extending the LOINC conceptual schema to support standardized
assessment instruments. *J Am Med Inform Assoc. 2002 Nov-Dec;9(6):586-99.
*
*
Would you agree with my understanding of the problem as stated here?
- thomas
Sincerely yours,
dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
email: Results4Care at cs.com
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090220/9b9e2381/attachment.html
