Tim Benson wrote:
>Tom, >I do not think that structure can be justified if that structure is unlikely >to add either value or safety down the line. > a priori, I agree 100% with this; our unwritten motto is: only make it structured if it is safely computable... >So in the situation where we >are not able to rely on a time as being either a strict point in time or an >interval is likely to create semantic problems. Unless you can rely on >strict chronological listing it is unhelpful to try to give spurious >precision. So my suggestion is that such fuzzy dates should be put into >free text only and all dates associated with any entry should only be the >ones we can rely on, such as date and time of entry. > well, I think it depends on how fuzzy. If someone jsut can't remember which date in the first week of July 2001 she first experienced organ rejection symptoms after a kidney transplant, that's not a completely unusable date; and one can easily imagine researchers wanting this kind of date to be in computable form in a study which is trying to characterise the efficacy of immunosuppresant drugs on transplant patients. It seems to me that this is a good case for creating a PARTIAL_DATE object with the day unknown (or maybe an INTERVAL<DATE> - it doesn't matter). We also added the follwong routines to PARTIAL_DATE: probable_date: DATE possible_dates:INTERVAL<DATE> These provide statistically reasonable approximations to the true date, for the purposes of querying and research. So the question in my mind is: when is a date or a time _too_ fuzzy to record as a structured object? (I should point out that we agree completely that very unreliable dates/times should indeed be text; but where is the cut-off point?) >What is more precise: "the first of the month, but do not remember which >month", "the night it rained" or "the morning that the kids were late for >school"? To me there is no point in using anything other than free text for >any of these. Julian dates can be very useful, but not all date information >fits the simple model and errors are made when we try to force it in. > again, on the face of it I agree. But it may be in some circumstances that during a 1 minute discussion with the receptionist at the surgery, the patient agrees that "the night it rained" was indeed either tuesday of wednesday of last week, then we do in fact have a reasonable partial date... apart from these (probably few) cases, I agree, we do not want to suggest that all statements about time no matter how fuzzy should be encoded as structured instances. >We should always have a time stamp for computer entry, which should be >flagged if this is the only Julian-type date information that is available >(and must be used with great caution along side free text data). > agree. Ultimately it is up to the clinician to read the entry and act properly upon it of course. I think we need to make some additions to the openEHR RM text to do with "when is a date too fuzzy to record in a structured way". thanks for your comments - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
