Thomas I am not sure that we need to do such a major rework. These samples are time ordered but have no sensible time. So they could appear in the history list without an offset, labelled in what ever way was helpful, recognising they are part of the same measurement. On thinking about this (if you wanted to keep all the measurements) a simple office based measurement like peak flow is a candidate - you might do three measurements in a row.
At the moment the history demands an offset - the set of measurements would still be timed - but only the sequence of each would be known, not the time of each individual. This seems more appropriate. The query could return them all at the same time or, as I have suggested, with a nominal offset 1,2,3 etc This would allow for the fuzziness of a series to be captured. Another alternative is just to allow the application to put in what ever time it likes as the offset, and label them Sample 1, Sample 2. This would require no changes, and would not upset the query model. I probably favour this approach as there is no doubt there is a time element to sampling, otherwise it is not a sequence. Cheers, Sam > -----Original Message----- > From: Thomas Beale [mailto:thomas at deepthought.com.au] > Sent: Friday, 24 October 2003 5:58 PM > To: Sam Heard; Openehr-Technical > Subject: Re: Pathology requirements TIMED MEASUREMENTS > > > > > 1. We recognise this is a sampling issue and there should be a > label on each > > sample which is transfered to the report - we have sample 1, 2 > and 3 with > > three separate microscopies and cultures in a single > composition. This would > > get around the confusion of trying to deal with this as a > timing issue - it > > would work for any sampling including location. We do not want > to compare > > these CSF samples in queries as equals but we would have some > sort of label > > associated. So, the sample label and order might be part of > this - in the > > request and then in the result. I guess this goes on at the moment. > > > > 2. We have a sequence idea in the event model, by using the offset but > > having 'sequence' as the unit rather than time. This would mean > that people > > did not have to enter spurious times in the data and name the event as > > Sample 1, which could be misleading. > > I guess there are a few possibiities. > > a) we change HISTORY to SEQUENCE and make it general enough to > cope with other > sequences, not just time > > b) we add a type SEQUENCE and make the current HISTORY a subtype > of it. The > only reason to do this, rather than to have two disjoint types would be to > enable software re-use (less code; better code) and to allow runtime > substitutability. I am not sure what query could sensibly request all > sequences, including histories, so I am not sure if this is an argument > > c) we add a type SEQUENCE as another subtype of STRUCTURE. > > Without having done the analysis, I would favour b), since there > appears to be > a fair overlap of semantics and therefore argument for reuse. > > What we need is a nice statement of a new model for history, > which includes > means, maxima, minima etc as Sam has been modelling, and a > similar model for > sequence. Then we can see what to do about changing the Data Structures > Information Model > > - thomas > > > - thomas > > > > c) > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
