# Introduction **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2002-12-06 14:41 UTC **Views:** 2 **Replies:** 4 **URL:** https://discourse.openehr.org/t/introduction/12025 --- ## Post #1 by @Philippe_AMELINE1 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 ;\-\) Best regards, Philippe --- ## Post #2 by @Sam 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 --- ## Post #3 by @Philippe_AMELINE1 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 --- ## Post #4 by @Philippe_AMELINE1 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 --- ## Post #5 by @Sam 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 --- **Canonical:** https://discourse.openehr.org/t/introduction/12025 **Original content:** https://discourse.openehr.org/t/introduction/12025