CQuantityItem.units not empty
On Tue, February 10, 2009 2:22 pm, Karsten Hilbert wrote: > On Tue, Feb 10, 2009 at 02:01:59PM -0500, Greg Harris wrote: > >> Not that it's dispositive of any larger issue, but doesn't VAS >> actually record a physical quantity (specifically, the centimeter >> position on the horizontal line where the patient indicates the >> level >> of pain)? > > 7 centimeters of pain ? No, that's just a device, a > metaphor, basically. It does add a bit of comparability, > though. > > Karsten > -- The VAS is not a direct measurement of "pain." It is a direct measurement of where, on a 10 cm. line, the patient records her impression of her pain severity. So a reported VAS of 6.5 is a record that the mark the patient drew was located at 6.5 cm from the left endpoint of the pre-printed form. There are other assessments of pain that attempt a more direct numerical measure of the pain itself. See, e.g., http://www.ispub.com/ostia/index.php?xmlFilePath=journals/ija/vol8n1/vrs.xml. But this is only a trivial point that doesn't really affect the discussion. Sorry for the distraction.
CQuantityItem.units not empty
Not that it's dispositive of any larger issue, but doesn't VAS actually record a physical quantity (specifically, the centimeter position on the horizontal line where the patient indicates the level of pain)? On Tue, February 10, 2009 12:19 pm, Thomas Beale wrote: > > > >http-equiv="Content-Type"> > > > href="mailto:Williamtfgoossen at cs.com">Williamtfgoossen at cs.com > wrote: > face="arial,helvetica"> face="Arial" lang="0" size="2"> > > Thomas, > > Thank you for your reply, however it does not satisfy the request. > > > I think that the pain score is indeed not a physical measurable > instrument. > But it is not an Ordinal, in statistical terms it is an Interval if > the > numeric score is used (0, 1, 2, 3 etc up to 10) and a ratio when the > VAS scale is used. > Hence reliability studies have determined that it is useful in > practice. > > > I certainly didn't mean to imply that things like the pain score were > not useful! > > face="arial,helvetica"> face="Arial" lang="0" size="2"> > However, I would like to have the following > > DV_PhysicalQuantity meeting the PQ requirements from ISO 21090 > and the > DV_CodedOrdinal, or DV_Ordinal meeting the requirements for the CO > (Coded Ordinal) from ISO 21090. > The CO does allow the order as we need, and allows the mathematical > operations such as summations, calculations like BMI style, among > others. > > > > 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? > > 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. > > Would you agree with my understanding of the problem as stated > here? > > - thomas > > > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
On Fri, 27 Jun 2008 13:46:27 -0300 Tim Cook wrote: > > On Fri, 2008-06-27 at 14:42 +0200, Thilo Schuler wrote: > > Very interesting - maybe we could have seperate namespaces for the > > core tags and extensions. Could be a good compromise! While I see > > the advantages of keeping GUI stuff out of the template, I also see > > that this more and more complicated as we add additional abstraction > > layers. > > Ahhh, true. It is complicated. It is the reason why health > informatics is where it is today. The beauty of the openEHR specs is > that each portion does one thing well and yet all the parts fit > together. > > If we get carried away and start mixing the layers then the specs get > more complex, the tools more difficult to use, applications less > likely to inter-operate and there won't be very many implementations. > > > If you aren't careful you could end up with something HL7v3. > > > As "my buddy" Albert E. said; Make everything as simple as possible > but no simpler. ;-) > > > --Tim > As counsel for a trade group many years ago, I watched a committee work long, earnestly, and hard to develop a proposal for a standardized set of paper forms for claim notices. When that committee subsequently was asked to review the adequacy of a set of draft EDIFACT messages to communicate the same information content, they had a very difficult time separating the information from its presentation. They were neither stupid nor uncommitted to the effort; their input was both indispensable to success and immediately useful for the developers. But for them, IT was something of a single cloud. It took a while for them to distinguish between the separate problems of (a) signing off on inter-company data sufficiency and (b) implementing and presenting that data on their respective internal systems. And while these people were volunteers in a sense, getting this done was part of their jobs and had the full backing of their employers. But if their input governed the back-end design and development, there would have been no progress. It was successful (or not) project management to get their involvement in the right amounts at the right times. Without any qualifications whatsoever to offer a judgment on this, I see a development interplay among three groups: the clinicians, the developers of the underlying structure, and the designers of implementing systems. (My guess is that's an obvious and seriously non-profound observation.) Aside from a long anecdote, it strikes me that UI decisions should be kept as separate as possible from any of the underlying structure; that presumption could be rebutted where an identified UI need can't otherwise be satisfied. Of course, at some level that's a nullity because the UI needs really define the structure design. As simple as possible can be quite complex. It's amazing what's been accomplished. Greg Harris
