Karsten Hilbert wrote: >>Consider a maximum temperature measured over a 12 hour period - or an >>average. At the moment the date/time will be the beginning of the 12 hr >>period. >> >>My suggestion is that clinicians will record this at the end of the 12 >>hours and the date/time should reflect this. >> >>That is to say: >> >>a 12hr maximum temperature of 36 C over the period 0600-1800 on 2004 Jan >> 01 should be: >> >>2004 Jan 01 1800 12hr max Temperature = 36 C >> >>and not >> >>2004 Jan 01 0600 12hr max Temperature = 36 C >> >> >I think one should think of it this way: The temperature value >(be that average or maximum) gets recorded as soon as it is >known (hopefully). Hence the second version (@0600) seems >wrong. The first version seems OK but it seems to hide >something implicitely. There are actually two things being >recorded: a) the maximum temperature - recorded at a given >time. b) the time range this maximum applies to - eg an >interval that needs to be recorded, too ! > > In openEHR it is. See http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/reference_model/data_structures/im/data_structures_im.pdf - section 6, figure 7. Every EVENT has a width (by inheritance) and an offset. Sam is arguing that the offset should represent the end of the interval rather than the start, since this makes sense for any recording where the value has been averaged, or is a maximum etc.
>It just so happens that many recorded values will have their >time of recording and their time of occurrence *coincide*. In > > in openEHR, this means that the width is 0 and it is a point sample. There is a function defined on the ITEM_EVENT class called "is_instantaneous" which tells you this (although I notice it is not shown on the UML diagram). >many cases that will suffice, too, and in many cases - say GP >level free text for an encounter - it does not matter too much >whether I record the progress now when I hear it or two hours >later. Nonetheless are there two times: recording and >occurrence. Which should - in cases where it matters - be >explicitely modelled. > > well, that's always taken care of in openEHR - recording times appear in the VERSION class audit trail; when data is committed in openEHR, it is always as a COMPOSITION which inherits from VERSION. Also, COMPOSITION.context contains data/time info of patient contact etc, if there was one. >Paper charts make us forget about this distinction because we >routinely lie about the time of recording, eg. we put down the >time of occurrence while we actually mean that of recording. > > interesting point - makes you wonder just how many scanned/keyed in paper records are actually misleading, and what kind of skew this might have caused in statistical studies! - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
