> 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
