On 21 Jun 2012, at 18:08, Thomas Beale wrote:
> > Let me try and clarify the time aspect of the ontology... the question is not > that time doesn't relate to all Entry types. The question is how. In the > Clinical Investigator Ontology Sam and I constructed, there are 3 temporal > upper level categories > history - i.e. information relating to reality the way it was in the past > opinion - thoughts formulated at the current point in time based on what has > gone before, and/or what is known so far > instructions - concrete statements about what should happen in the future It is clear: - things happened in the past before the time of recording - things happening at the time of recording - things that will happen after the time of recording. So far the things can be: - an Observation - an Evaluation - an Instruction - an Action And depending on the context the time can be a point in time or a period. > Obviously these categories were not primarily named based on the temporal > aspect, but nevertheless they are based on temporal considerations. They > correspond relatively well to the epistemic categories described in Sowa's > upper level ontology as follows: > history = Sowa's 'history' category, i.e. a proposition about an occurrent, > including anything that can be observed about the state of the subject at a > point in time > opinion = Sowa's 'description' category, i.e. propositions about a > continuant, normally the subject of care. A diagnosis of 'Diabetes' for > example is saying that the patient John Smith (a continuant) organism > includes the diabetes process as part of it > instructions = Sowa's 'script' category, which is itself an occurrent > representing time-based sequences of events, including conditional decision > points Yes they correspond. History= An Observation about an occurrent (state) Opinion= Evaluation propositions (inference) about a continuant (process) Instruction= Scripts to execute protocols (as occurrants) describing sequences of events including conditionality's > The first and last of these categories are considered by Sowa to be > occurrents, i.e. time-related while the second is not. This seems pretty > clear. > Helas. I disagree. The first and the last are occurrents and have timing related with them. But Evaluations have them as well. Processes (continuants) start and can end in time. They are recorded at a point in time but the beginnings and ends of these processes extend over time in the past, the present and the future. The evaluation Diagnosis=Diabetes can have a semantic annotation that this process (condition, continuant) it started at age 65 and is ongoing. To me this is clearly time related. > Now consider the diagnosis archetype (an instance of the 'opinion' aka > 'description' type)... it contains the main 'proposition' - i.e. the > identified index condition, diabetes or whatever - and a bunch of times / > dates / durations / other descriptive details. So how is this not time-based? > Well we need to consider that what this information is really doing is > drawing a picture of temporal disease course, in terms of these dates and > times and durations. These are a way of qualifying the main statement of > Diabetes - it is recent, severe, intermittant (symptoms) etc? > I fear that the inference Diabetes as process in the patient system as you describe IS time based since all continuants are processes with begin and possibly end-times. What this information is doing exactly what is intended. Other additional semantic annotations about the severity, frequency, behavior over time are other things than the notion that there was an inference of diabetes in the patient system. > So why does temporal aspect this matter, practically speaking? For the very > simple reason that 'history', i.e. past time, is linear, i.e. representable > as a series of events / states; instructions are future time, and therefore > unavoidably have a branching, conditional nature e.g. > > ICU insulin management protocol containing items like: if blood sugar drops > below 130 mg/dl, drop dosage. So the data structures for historical data - > Observations and Actions are unavoidably different from those for > Instructions, which are more like a set of statements, conditions, etc (the > structure can be quite complex). > Yes. Each of the 4 specialisations of Entry hav e attached to it specific patterns. And time is just one of the possible semantic annotations of each Entry. > And Evaluations (we could have named this one better) has neither historical > nor future-instructional nature, but instead the structure of a description > or set of statements (thoughts, ideas) about something else - in other words, > it could be any structure, so we just use a tree. If we subdivided (as indeed > we did in the paper), we could posit a number of more specialised data > structures. > > Really? I can record as inference (Evaluation) something in the past (as history) As something inferred now or inferred to happen in the future. All Evaluations with a history, present and future as do the Observation, Instruction and Action. > > See here for Smith/Ceusters/Scheuermann on an ontology for disease course and > diagnosis, in which they identify the same categories of information more or > less - clinical picture / diagnosis / plan. > > They use (to me) a funny definition of 'symptom'. But as realist ontologists they know that diseases whether diagnosed or not, inferred or not are occurrents (processes) with times attached to it. > So to summarise, it came down to finding categories on which health > information data structures - i.e. information models - could be based that > would work reliably for most if not all of medicine. Now, having used these > categories for some years, it turns out that they are remarkably stable. I > know that the grey-zone debate on Observation/Evaluation will continue for > ever, but if one steps back for a second, what you see is that for most types > of clinical data, it is obvious which category to use. Most of the archetypes > for these types are not really in question. Further, noone has identified (to > my knowledge) a strong contender for any new kind of category (excepting for > sub-categories of AdminEntry, which will probably appear one day). > On the contrary, in spite of your claimed years of experience, I have my claim to experience both in the openEHR world and that of the EN13606 association and this experience shows that they way users use the definitions in openEHR give rise to problems for the users. I agree that nobody will annotate a Blood Sugar Measurement result as an Evaluation or Instruction or Action. In literature I have seen many wrong annotations because of problematic and unclear definitions in the real of openEHR. Why are we having this discussion if there were no problems what so ever? > I think the main thing we got wrong was naming 'Evaluation' too narrowly, > when what we needed was a name that means 'what the clinician thought' (if we > had used Sowa's 'description' category I am sure we would now be having > arguments about why someone was using a 'description' to record a > 'diagnosis'!). We would know we had gotten things radically wrong if now, 5 > years later, it were clear that say another 5 or 10 data structure types were > needed. > I disagree. When a clinician is listening to heart murmurs as part of the physical examination I can assure you he is listening and thinking a lot, because it is very subtile what he is listening to. Idem dito for palpation, smelling, etc. And there are more examples. It is not whether he is thinking as a mental process but what matters is what is the relationship with the patient system. Is he thinking about an observable? Or is he thinking, inferring, about (disease) processes on the basis of observables. For an Evaluation it is clear that it is about a process (continuant) in the patient system and that by definition it is an inference. > If indeed we managed to get this sort of right (for now), it's only because > we had 3 previous attempts (GEHR 1992-95; Australian GeHR (1997-2000), first > draft of openEHR (pre-2005)) where we got it wrong. > The word Evaluation is OK. But we need the correct not confusing definitions with good discriminators to make judgements easy. > This is a hard problem to solve. In HL7v3, it was attempted with the 'mood' > code, which is certainly a reasonable starting point philosophically, but > doesn't in the end help you get the right data structures. This is well known > in HL7v3 as a difficulty (and I am not criticising for that, as I say our own > little effort was 10 years in the making). > The really amazing thing is that traditional epistemological categories are > of such little help. Divisions of a priori / a posteriori / how-to are only > vaguely useful (we used them and gave up on Aus GeHR), and yet to a > clinician, the differences between the observation of blood glucose over > 9mmol/l, Dx of diabetes mellitus and insulin care plan for glucose management > are crystal clear. > I don't doubt that something better is possible in the future, but I think > for now some finer adjustments on the current ontology and data structures > will be of most practical he > I can only point at our efforts dealing with semantical annotations in the EN13606 community. > - thomas beale > > > On 21/06/2012 13:37, Gerard Freriks wrote: >> >> Sam, >> >> According to me: >> - Observations have in reality points in time or ranges attached to it >> - As do Evaluations about processes in the patient system they have in >> reality times attached to them. Inferences are made at a point in time, but >> relate to inferred processes that come and go, or are believed to be >> present, or not, during a period of time. >> - As do Instructions >> - As do Actions >> >> Time is never is a discriminating factor that sets Observations apart from >> the other Entry types. >> > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120621/c9316c05/attachment-0001.html>
