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
