Hi Thomas, hi Sam (and high the list - if it makes sound)
I wish I could quickly translate my web site - or at last build some english
pages. Unfortunately, I am awfully busy, and to be honnest, discussions on
the list help me a lot finding the accurate words.
First, I would like to say that the Fils guides technique is a part of
Odyssee project, and can hardly be used - and even understood - as a single
component.
The Odyssee project is based on the assumption that most medical description
can be structured as a tree representation and that most knowledge can be
expressed in the same way.
Then we shall build powerfull decision support systems through semantical
tree matching (matching knowledge base and patient data is possible when
both are expressed in the same langage).
You can understand that we had to make powerfull tools in order to have
doctors report their examination as trees.
The Fils guides technique is in the range of interface tools, to ease and
guide trees construction.
It is very important to understand that once a tree is build, nothing
remains from the Fils guides involved during elaboration process.
From: Thomas Beale
> 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...
Lets make it easy ; you have 2 kind of interfaces standardised and open (of
course real life is always somewhere between, but we make simple in the
beginning.
1) Standardised interface is good for report generators, since it must be
fast, and the structure of the model is always the same : you never put your
colonoscop in patient ears... (I don't use a colonoscop at all, but I know
lots of people who do - by the way, I never told you Nautilus is used in
more than 50 hospitals for endoscopic report generation, and a lot of
private sites).
For standardised interface you will use dialog boxes (that necesseraly leads
to static model), and Fils guides is just a convenient way to hold
repetitive items.
Lets write some genuine example Fils guides (translation on the fly) in the
form (path)->proposal1/proposal2/... :
(colonoscopy)->admin data/context/technical
chapter/description/conclusion/coding
...
(colonoscopy/context)->clinical context/to do
(colonoscopy/context/clinical context)->bleeding/pain/....
It looks like static tree, but don't forget Fils Guides engine works with
semantical links, then if you create a new kind of examination, say 'virtual
colonoscopy' and establish that virtual colonoscopy "is a" colonoscopy, then
you automatically *inherit* all those Fils guides.
In our colonoscopy module, we decided that the treatment dialog box was the
same for every kind of lesions, then we made Fils guides of the kind :
(colonoscopy/description/?/treatment)->ablation/destruction/heamostasis
(colonoscopy/description/?/treatment/ablation)->tool/efficiency/side effects
(colonoscopy/description/?/treatment/ablation/tool)->list of tools (can't
translate)
and let's suppose polyps needs specific tools, we could just add a new Fil
guide
(colonoscopy/description/polyp/treatment/ablation/tool)->list of tools for
polyp ablation
2) Free interface is the only way to handle examination (either GP or
specialist), because
- nobody does it in the same way
- you have to be able to describe any disease or symptoms, for every organ,
with many modalities
- each patient is a special case
Then even if examination is stored as a tree, it can't be a part of a
pre-defined model tree.
What you can do is guiding the description in when the user *enter* a
domain.
For that, 3 kinds of Fils guides :
- Root
(examination)->Subjective/Objective/Assesment/Planning
... and, for a cardiologist
(examination/subjective)->thoracic pain/dyspnea/palpitations
- Specific
(examination/*/pain)->location/irradiation/intensity
(*/palpitations)->when/kind of/duration
(*/palpitations/when)->effort/quiet
- General
(*/intensity)->(low/moderate/mean/high)
You must remember two things :
1) Fils guides proposals are only proposals, the user can pick in the
Lexique instead (and maybe a Fil guide will be fired, maybe not)
2) Each time, the system looks for the Fil guide which path is the closest
from your actual path - then General ones are only fired if there is no more
specific choice
> 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...
Yes, of course, but remember they all are trees, express with the same
Lexique, and sharing the same semantic network.
A colonoscopic report, and a GP examination can't have a common structure,
and a GP using SOAP paradigm won't have the same structure as another one,
but these are the Root fils guides, and they perfectly could share the same
General and Specific ones (that's why fils guides can be put in and out in
groups - say blue Lego bricks, red Lego bricks and so on).
The overall Odyssee paradigm is intended to be use through health networks,
it is the reason why we fix the langage (Lexique and trees) and the meaning
(semantic network), but we thought it was a very important point to guide
people with expert knowledge in a *soft* way.
> I keep thinking of our kernel path processing, which handles paths with
> wildcards in them...
Does it handle semantic relationship either ?
With fils guides, we handle 2D generality (*horizontaly* through wildcards,
and *verticaly* through semantic "kind of")
There is one thing that often disturb people : a given a set of fils guides
can't be represented as a tree (and neither as a collection of trees) ; it
is really a non deterministic approach, and that makes me happy since real
life is of that kind.
Regards,
Philippe
Odyssee project
www.nautilus-info.com
