Dear all
My french isn't good enough to understand the information at the Odyssee
site - and from the discussion below it is hard to comprehend the actual
technology - can you point me to any illustrated literature on this subject?
Cheers, Sam
----- Original Message -----
From: "Thomas Beale" <[EMAIL PROTECTED]>
To: "OSHA list" <[EMAIL PROTECTED]>
Sent: Friday, 30 March 2001 11:30
Subject: Re: Odyssee
>
>
> trying hard to understanding this concept...I have a feeling there is
something
> deep here....
>
> Philippe AMELINE wrote:
>
> > Usually, you can choose that tree or that other tree, but you can't jump
> > from one to another (its a good thing, since you would have two roots -
> > monkey business).
> > You can imagine a giant tree, but it is hard to maintain and good only
for a
> > single speciality (and imagine a single tree including gastroscopy and
> > colonoscopy - hard to swallow !)
>
> this seems to be the same reason we have separate archetypes rather than
one
> giant archetype (which would be more like a structural SNOMED or
something...)
>
> > Now, when you want to build Fils guides, you take the tree, and break
each
> > and every branch (eg you break the static links between father and sons)
> > and, for EACH branch, you replace that static link with a *typical path*
in
> > which that branch can fit.
> > There is no stats involved, just asking the expert : Well when you make
a
> > proposal of description like size/aspect/location is it good for every
> > polyp, or only polyps seen during a colonoscopy, or even for every
polypoid
> > lesion
>
> but don't you want to try and standardise these models? Else, for
> interoperability, and especially automatic processing what do you do with
> information created according to one fil guide (do you think of them in
the
> singular?) which is _nearly_ the same as another one, and the purpose of
both is
> exactly the same , eg. to record results of colonscopy exam...
>
> > Then you will attach a *path label* to the branch with "*/polyp" or
> > "colonoscopy/*/polyp" or "colonoscopy/description/polyp" or "*/polypoid
> > lesion"...
> >
> > Remember the lego brick analogy :
> > In the classical approach, the expert builds a model with glue.
> > With Fils guides every brick remain autonomous, and the expert task is
to
> > put a label on it, indicating in which situation it can be used.
>
> Hm. I think fils guides are like segments from an underlying information
model,
> e.g. GEHR/HL7 RIM/CEN etc; the trick seems to be to find the right kind of
> segment or information shape to use for a particular clinical concept,
e.g.
> colonoscopy results. So it is like creating archetypes on the fly. But
this must
> mean that there is some a priori information shape understood for the
clinical
> information, since you need this to decide what fil guide to match it
to....
> it's like ad hoc archetypes on the fly (sorry to use my own terminology,
but you
> understand that all humans must necessarily revert back to their own
conceptual
> structures in order to interpret the utterances of others;-)
>
> > 2 very great advantages :
> >
> > 1) You can mix all Fils guides in the same bag, and each of it can be
chosen
> > any time. To be precise, each brick belongs to a *group* (for example
> > *proctology by
> > Dr X*, *pneumo by Dr Y*), and you can put a new group in your bag or
remove
> > a group from it. A group is imported/exported in a single .nsg file.
>
> It still seems as if the result structures created by each clincian's
system
> could be different, just because they all manufactured their own fils
> guides...or tags for fils guides...
>
> > Andrew think it is computationaly intensive to find the most appropriate
Fil
> > guide for a given user path.
> > It was a genuine problem at first, but we now have a Fils guides engine
that
> > is very fast.
>
> I keep thinking of our kernel path processing, which handles paths with
> wildcards in them...
>
> I hope to understand this approach better as this dicussion continues!
>
> - thomas
>
>
