Introduction

Technical (archive)
1

Hi to the list,

My name is Philippe AMELINE, and I am the leader of the french project Odyssee and manager of a small company named Nautilus.

Inside Nautilus, we have been working for several years on the way ontologies can allow large scale sharing of medical datas in order to adress continuity of care.
The open source Odyssee project has been built in order to have these techniques become a genuine system.

We are currently working on several knowledge management domains : ontologies, Archetypes, smart agents, multiple view angles... as you will soon discover from my contributions :wink:

Best regards,

Philippe

2

Hi Philippe

Good to see you there - Tom is in Europe at the moment - perhaps you will
catch up.

I am interested in your multiple view angles - in English 'perspectives' is
a good word.

We are working on HealthConnect - the planned Australian EHR system - and it
is already clear that different users will have different perspectives. The
problem as I see it is how to keep the information 'safe' such that a
perspective enables suitable healthcare. I believe that this will be more
done through policy than overly smart systems in the short term - e.g. A
nurse must notify a doctor explicitly - not via the EHR - if there is some
medical need of the patient that warrants the attention of a doctor.
Likewise for the doctor.

We are using Folders as our informational structure to deal with this -
obviously views will add another means of displaying information required by
a particular user. The important thing about folders is that they can
contain symbolic links - that is to say, the same data might appear in more
than one folder. Symbolic links are shown below with *

The logical folder structure as far as I see it at the moment would be:

\Alopathic medicine
  \Persistent data (Mandatory)
  \Event data (Mandatory)
    \Episode data (optional)
    \Administrative data*
\Patient data
  \Administrative data
  \Patient entered data

\Naturopathic healthcare

The important thing here is to allow patients control of parts of their
record - other parts will need clinicians to accept the data as accurate.

We clearly have the option of collecting enough context information so as to
allow views to be helpful. BUT, a podiatrist might like a problem list that
is quite different from a family physician. I have not considered how we
might allow this to work. We could do it with context and have a shared
problem list and then a problem list specific to the user - or we could
allow different problems to be organised within our transactions in ways
that allow the shared and specific problems to be discerned by the computer.

Do you have any references on this interesting area - any ideas that might
be relevant in the openEHR context?

Cheers, Sam

3

Hi Sam,

We have two reasons to work on 'perspectives' :
- First our 'Life line' concept is based on a server dedicated to continuity of care and - as so - is made to link EHR nodes. If we don't want this to become a 'garbage collector', we have to properly organize it.
- Our first 'clients' in France are care networks since they are properly funded, but cannot find a genuine information system ; the systems they currently buy are tying them in a mono-pathology point of view, and our challenge is to present them with a system that can allow to see the whole patient, but can also be as efficient for them as the previous dedicated systems.

two reasons :
- It makes you cut the patient in pieces (through its EHR of course ;o) ), and I believe that a good system is precisely a system that allows a vision of the patient as a whole
- You will eventually encouter a lot of medical descriptions that are slightly different from a specialist to another, but - being in a different folder - will have to be done again.

We are just starting the 'perspectives' project, with the help of a knowledge management research team, funded by a french ministry of research grant ; however, I think that Archetypes are one of the key point : we will think on the way we can put the proper informations in them, in such a way that we can 'show' the same instancied tree in different ways (sub-tree for example), depending on the doctor 'perspective'.

As you may know, the main difference between openEHR and Odyssee is that we use an ontology as the core component ; it means that we will probably explore some solutions that may not be relevant in the openEHR context.

Tom and I will meet in Berlin, I think we will talk about that.

Cheers,

Philippe

4

Hi Sam,

I think I forgot telling you that we mixed Fil guides and Archetypes inside Odyssee : Fils guides can be used to find the proper Archetype to use in a given situation (if there is any). We also use Fils guides to extend the description further than the leaves of an Archetype (switching to another Archetype, for example).

We also needed another component (we named it Referential) : as you may know, we have incorporated inside Nautilus a blackboard (we studied, then modified BBK from Stanford). It allows us, for example, to automatically evaluate risk factors through data grabbing inside the patient file. Once you have calculated a risk, you have to present the user with the proper EBM behaviour (we call it health goals) and have him choose among these proposals. As you can guess, we needed a component to store the pre-elaborated trees describing each health goal, with a link to the Archetype that allows to modify it afterward.
Did you encounter the need for such a component inside openEHR ?

Cheers,

Philippe

5

Philippe

Thank you for your communication - I have always been interested in your
Fils guides but have not seen the place for them in our system - I think I
do now - they are a representation of our ontology that is ordering and
describing our archetypes.

This is very basic at present, and represented in protege. It allows us to
say what are the allowable archetyped components to add at any point.

We had seen this being available at design time and, in part, at run time to
speed the dataentry process.

To answer your question -

I think I forgot telling you that we mixed Fil guides and
Archetypes inside
Odyssee : Fils guides can be used to find the proper Archetype to
use in a
given situation (if there is any). We also use Fils guides to extend the
description further than the leaves of an Archetype (switching to another
Archetype, for example).

This is what I have described above - although at times the archetype might
express this itself.

We also needed another component (we named it Referential) : as you may
know, we have incorporated inside Nautilus a blackboard (we studied, then
modified BBK from Stanford). It allows us, for example, to automatically
evaluate risk factors through data grabbing inside the patient file.

Does this mean references - queries pointing to one or more entries that are
required. A fundamental proposition that we have at the moment is that the
meaning of data in an entry can be computed regardless of where it appears
in the EHR - regardless of organisation or other context. That means all
meaning altering context must appear in the entry.

We realise that this is not essential in the long run but is very helpful to
getting fast and efficient implementations.

It sounds as though your queries have a calculation engine as well?

Once

you have calculated a risk, you have to present the user with the proper
EBM behaviour (we call it health goals) and have him choose among these
proposals.

Does this mean the clinician or the client or both?

As you can guess, we needed a component to store the
pre-elaborated trees describing each health goal, with a link to the
Archetype that allows to modify it afterward.

We have at present the idea of a target - a quantified value to aim for, a
goal - a qualitative (requires description) and an instruction, a detailed
process to follow. All are in care plans. The former are archetyped
'evaluative entries', the later - the instruction is in the information
model as an entry type (instruction, evaluation and observation).

Did you encounter the need for such a component inside openEHR ?

How does this match up?

Cheers, Sam