On 19/03/2012 02:15, Grahame Grieve wrote: > for me, conversion between different units that are comparable. You > should ask Tom what else he thinks it yields up. I'd be interested. > > Grahame > > > * > *
well any mathematical operation working on quantities - e.g. averages, max, min, variance, standard deviation etc etc. These kind of operations are ubiquitous in research queries, and will become increasingly so in personal health records. Just consider what is needed to determine the actual amount of tobacco consumed by each of 10,000 patients in a cohort - each of whom report their usage in terms of 'tailor-made cigarettes', 'hand-rolled cigarettes', 'cigars', 'chewing tobacco' (okay not popular, but still in use in some places!), 'grams a week (of pipe tobacco)', etc etc. Some patients have a mixture of these. Same argument for amounts of drugs taken by patients in a cancer study, amounts of sugar, salt, cholesterol computed from food recorded in patient diet and so on. How about a query that finds all patients with blood sugar over 7? What if they input the data (at home) in different unit systems due to different equipment? We simply can't do any useful /computing /if we can't trust the data. We don't do that much computing now with it because of the unreliability of the available data, but the only interesting future really is being able to do intelligent computing with the data. To get there we have to be able to compute reliably with quantities. I have no problem with data that records only 'puffs', 'patches', 'pessaries', 'pills', 'pellets' or 'powder'.... but we don't want to compromise data that record normal scientific quantities. Therefore I think we should be treating these kind of amounts as a separate type. This is distinct from the problem of Quantities that do have scientific units, but there is a conflict with the displayable form. I think we should accommodate that in the current data type - a small modification would take care of that. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/d866d2e2/attachment.html>
