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.com>wrote: > 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 > TM<http://www.ncbi.nlm.nih.gov/sites/entrez?Db=pubmed&Cmd=Search&Term=%22White%20TM%22%5BAuthor%5D&itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_DiscoveryPanel.Pubmed_RVAbstractPlus> > *, *Hauan > MJ<http://www.ncbi.nlm.nih.gov/sites/entrez?Db=pubmed&Cmd=Search&Term=%22Hauan%20MJ%22%5BAuthor%5D&itool=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>
