Re: SV: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 05/04/2018 à 15:43, Thomas Beale a écrit :

> we really should build a combined descriptive architecture to show how
> all this fits together to solve:
>
>   * the continuum of deterministic - non-deterministic utterances
> possible in healthcare
>   * the linguistic interface v structured info behind question
>

It would be great.
I can provide the wine for those who are interested ;-)

> the second is not the same as the first - there are many docs who
> prefer a language /document / writing / speaking interface than a
> structured form, even if the information really is or could be
> structured in a standard way.
>

Yes, you are plainly right and IMHO they are entitled to do whatever
they want as long as they "feed the ongoing processes with needed
information".
The pity being that there is no such notion in medicine so far... reason
why my current effort is oriented toward providing citizen with a
"personal health project manager" in order to have them demand that
their practitioners behave as contributors in a multidisciplinary team.

> Well, I knew that more than 10y ago when we first talked about this
> ... So much to do :)
>

Probably 15 years ago ;) But at that time, your task was to go get the
legacy systems where they were and offer openEHR as an evolutionary process.
Maybe times are changing... this kind of articles becomes mainstream and
I my bet is that the solution is not inside the box and that a
Copernican revolution from care places to patients as reference frames
is needed.
https://hbr.org/2018/03/to-combat-physician-burnout-and-improve-care-fix-the-electronic-health-record

Philippe
 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 05/04/2018 à 12:16, Thomas Beale a écrit :

> On 02/04/2018 18:38, Philippe Ameline wrote:
>>
>> Actually, I don't think that I use grammar in an unusual way. If I do
>> it technically, lets assume for the sake of the discussion that I am
>> really talking about a grammar, ie a set of rules that allows you to
>> interpret an arrangement of concepts as a discourse. Typically, a
>> dependency grammar is not just a tree representation, but a tree
>> representation where you take as a rule that the sons of an element
>> qualify this element. Since every natural language sentence can be
>> represented as a dependency grammar tree and vice versa, it is
>> possible to assert that a dependency grammar is a sufficient grammar.
>
> Right - but the normal sense of 'grammar' is something that controls /
> validates sentences made up of words so at least they have acceptable
> structural forms, even if they say semantically nonsensical things.
> The fils guides 'grammar' is supplying both levels - correct form (by
> implication, due to /ordering/ of tree elements as you pass through
> them) and valid semantics (due to the /content /of the tree elements,
> thus preventing 'colon of stenosis' but allowing the reverse).

Let's imagine that there is no fils guide.

A "patient record" is a graph of trees (means trees which nodes can be
interconnected by typed traits, either to connect the description tree
that implements a given document description tree, or to follow a given
issue over time, etc).

If you assume that this trees are organized as a dependency grammar and
their nodes are filled using an ontology, you don't need anything else
to read it, feed smart agents, etc. It is a story told using a
structured language (ie a grammar and an ontology).

Of course, as you mentioned, it is possible that it contains "wrong
entries" like "colon located at stenosis".

In the wild, it can be achieved by providing practitioners with just an
interface where they can freely express themselves by building trees
(this is the usual interface for encounter notes since it is fully non
deterministic).
Now, for many good reasons, we could want to guide the way (some/most)
trees are elaborated (to ease and speed up the process, to make certain
that the information we want to process will be "well put", etc).
In deterministic areas, we can use archetypes. In semi-deterministic
areas, we can use fils guides (a flexible way to guess and propose the
next "sons" depending on current path).

In my mind, fils guides and archetype are of different kind: an
archetype is a flexible information schema and nodes that were "build
using this mold" keep a link to it ; on the contrary, a fil guide is
nothing more than a UI helper that makes a one step deep proposal
(since, when validating a proposed son, you now are on a different path
(previous one + validated node) and the system will try to find a fil
guide for this path). Since the process is fully dynamic and local to
the user (depending on the set of fil guides he uses) the nodes don't
have to remember what fil guide they originate from.

To sum it up, you can have a journey walking in well known areas
(archetypes) and finding your way in the wild (tree filling interface).
When in the wild, you can sometimes be presented with a "step wide
carpet" (Fil guide) that helps you walk more comfortably (this process
being iterative, you can "follow the carpet as it unfolds", but can also
head on in another direction).

> well maybe 'structural terminology' is a bad term; what I am really
> talking about is /models of possible content/ (possible utterances).

I was mainly talking about the extra structural elements such as
"Entry", etc.

Besides, if "models of possible content" are very important inside the
deterministic area, it would be pretty limited to have the only
alternative "model of free text". If only because, if you provide users
with a structured language, you will also be able to detect that they
enter an area where you can present them with a model. When I wrote that
a fil guide only makes a "one step ahead" proposal, I forgot to mention
that it can also trigger an archetype (hey, since you are mentioning
blood pressure, why not simply fill this form?).

>
> yes, there is no  doubt that the way you engineered /fils guides/
> achieves this very well, and we have things to learn in terms of
> bridging the gap between linguistic expression and structural
> expression - for now, openEHR has no 'system' to do the former, it is
> just done /ad hoc/ by those who want it.

Fils guides are fit in a semi-deterministic environment and only when
there is a reference ontology available (because it compares user's
current path with semantically similar expert designed pa

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 02/04/2018 à 19:45, GF a écrit :

> 1- What stands AP)SA(A'P’) for?

I guess that you know the SOAP as the 4 main "chapters" of a clinical
encounter (https://en.wikipedia.org/wiki/SOAP_note).
From  Lawrence Weed's concepts, a patient encounter should be recorded
as a "grid" with problems as columns and SOAP elements as line.

This concept is theoretically sound for acute care since it starts with
patient's verbatim of the reasons for encounter (S standing for
Subjective - which is truly dated!).

In the current "state of the medical art", always more chronic care
oriented, a patient often comes with an ongoing list of problems and
treatments, hence (AP)SO... and leaves with the same or a different list
of A and P, hence (AP)SO(A'P').

14 years ago, I worked with a knowledge management research team on
establishing both the theoretical aspect and the user interface of such
concept, by the name "virtual staff".
To make it short, imagine the Ligne de vie, with the vertical "now"
separator... then spread this separator as a curtain in order to open
the patient encounter as a cognitive map located between the past (AP)
and the future (A'P').

>
> Here below some missing topics we need to have agreement about
>
> 2- Thinking about the health and care provission documentation process
> there are:
> - Observation process
> - Evaluation process (including, and restricted to, diagnosis, diff
> diagnosis, problem kist, episode list, etc
> - Planning process
> - Ordering process
> - Execution process of acts

I am currently writing a paper (in French) telling a story of "boxes"
and "bubbles". Boxes are care places (say organizations at large) with
roles within a domain. Bubbles are the patients (say persons at large)
with a "polar reference frame vision" about "who is around and among
them, who is close or not so close".

In the usual system, only boxes operate an information system... and
they are pretty bad when it comes to "continuity of X" (replace X with
care, education, employment, etc).

Now, let's suppose that the reference information system is in the
bubble. And that service providers are just considered as contributors
that can join the current team that surround the person.

In the ongoing paper, I am trying to describe what happens when "a
bubble steps through a box"... and it is an amazing model to make many
things clear!

>
> 3- We need to recognise that some data is de novo, other data is
> repeated after a querry
>
> 4- Systems need to be aware that some data is directly health care
> care related, other is administrativem process oriented
>
> 5- When that what is documented is used in shared working processes we
> need a common vocabulary: i.e. System of Concepts for Continuity of Care

Thanks to François Mennerat, a glorious CISP Club founder, we have been
aware of Consys for many years... but "so many years" is also the problem!

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 02/04/2018 à 12:54, A Verhees a écrit :

> > The "good all" SOAP is dead ; nowadays, the encounter stream is switching to
> (AP)SO(A'P'): 
> > people now come with an existing set of Assessments and Procedures, 
> > not "just" with "Subjective" issues.
>
> Wasn't that always the case?

We are currently switching from "mainly acute" to "mainly chronic" care.
Reason why I claim that the "encounter information stream" must switch
from SOAP to (AP)SA(A'P')

In my understanding, the concept of episodes of care came long after
Weed coined the SOAP approach; but I may be wrong.

However, the main concept here is to consider an encounter as part of a
global process and no longer as an isolated event. This is,
unfortunately, still a disruptive concept ;-)

Philippe
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 01/04/2018 à 14:13, Thomas Beale a écrit :

> On 31/03/2018 10:38, Philippe Ameline wrote:
>> ...
>>
>> When I try to explain all this to lesser tech-savvy people (means,
>> who don't belong to this list ;-) ), I usually explain that:
>> - usual systems (with an information schema tied to a database
>> schema) are like a printed form. The day after you received the 5000
>> printed sheet you ordered, you will realize that there are several
>> design flaws that you will have to endure while the stock is not empty,
>> - openEHR is a flexible schema, similar to a set of stamps that lets
>> you build forms dynamically from blank paper. If your design has to
>> evolve, you just have to adapt one of the stamps.
>> - in my system, based on an ontology and a dependency grammar, you
>> can use stamps (archetypes like) and/or "write" freely.
>>
>
> just by means of clarification for some readers, since I happen to
> know how both openEHR and Philippe's system works, here's the way to
> understand how openEHR would perform the same function as Ligne-de-vie
> (which it can):
>
>   * build a lot of CLUSTER archetypes, and probably more OBSERVATION
> ones; each CLUSTER archetype would be one of the 'trees' Philippe
> talks about
>   * each of those CLUSTER archetypes has slot nodes that indicate
> where subordinate CLUSTER archetypes join, and which ones are
> allowed, in the usual openEHR fashion;
>   o remember, a slot can allow multiple possible substitutions
>   * at run time, a form containing a top level Entry, usually an
> OBSERVATION will be deployed on the screen, and by a process of
> user choice / UI movements etc, the data will get filled in, and
> subordinate CLUSTER archetypes will be chosen on the way, and
> filled in along the way.
>
> This mode of operation is known by us in openEHR-land as 'dynamic
> slot-filling' or 'runtime templating', as opposed to the more typical
> design-time templating used in a lot of systems, where most of the
> choices are made prior to runtime. But openEHR systems do use runtime
> slot-filling as well, e.g. for writing discharge summaries and
> referrals, where the data items are only knowable in the encounter or
> report-writing session.
>

This trend allows me to discover that openEHR already became a rich
ecosystem. Isn't this technique close from Gerard's vision of archetypes
as "context for concepts" in a kind of ontology?

However, I probably wrongly expressed what I wanted to say, and is more
theoretical than comparing implementations, such as openEHR and Ligne de
vie.

When we talk to one another using a natural language, we just need a
vocabulary and a grammar. The grammar is simply a set of rules, but not
a physical pattern. We say "John sees the green house" and not "John as
the subject sees as the verb the green as an adjective house as a noon
in a position of direct object complement".

In the same way, it is possible to express a structured discourse just
using an ontology and a grammatical structure (say trees) without the
need of any structure description.

So, to make my point more accurate, I see the evolution as:
- all possible discourse structures "hard coded" into a database schema:
legacy systems
- all possible discourse structures locally expressed as a set of
archetypes that are flexibly expandable: ENV-13606, openEHR
- discourse simply limited in complexity by what can be expressed using
the current state of ontology and the grammar

> I mostly agree here, with one major exception: entering a diagnosis.
> In that case, you do want subsets that are meaningful to your work
> context. If it is paediatric oncology, you may have a form with a
> field that can only be some kind of cancer or related Dx that that
> department deals with - then you want reference terminology terms in a
> subset that cuts out everything else. You also want your subset to be
> structured, i.e. with the IS-A links intact, so that you can navigate
> it to choose.

Agreed ; subset can be useful for user interface purposes. But it
remains a design purpose ; since, for example, the oncologist diagnose
becomes a health problem that all other patient's team members have to
cope with afterward.

The "good all" SOAP is dead ; nowadays, the encounter stream is
switching to (AP)SO(A'P'): people now come with an existing set of
Assessments and Procedures, not "just" with "Subjective" issues.

Philippe
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: [Troll] Terminology bindings ... again

[Philippe Ameline]

Thomas,

If I had to sum up the debate, I would write something like:

- pre-coordination is necessary for legacy systems that stick to coding
systems and didn't make the move to more elaborated representation of
information,
- pre-coordination's drawback is that expressing sentences as concepts
will mechanically lead to an explosion of the list of concept unless the
scope/audience remains small enough so that it ends up reaching an
asymptote that can be dealt with,
- considering SNOMED's ambitions (worldwide, large scope), we can
reasonably doubt that such asymptote exists.

Philippe


Le 01/04/2018 à 14:33, Thomas Beale a écrit :
>
>
> One thing I have noticed in recent systems in Brazil I looked at is
> that the codes are locally defined (e.g. SIGTAP, a Brazilian
> vocabulary for procedures) and almost all pre-coordinations of the
> most unscientific kind (with terms of the form 'cholecystectomy
> performed at private or military clinic'). Initially, it looks like a
> lost cause, but in fact SIGTAP only has (from memory) < 5000 terms,
> and there are ways of dealing with it. The Read codes in the UK were
> more scientific, but still contained many weird pre-coordinations (the
> famous example being 'hit by falling space junk while riding a
> bicycle'), but was also only O(10k) in size.
>
> So the 'size of the problem' is often inversely proportional to its
> awfulness, when talking about legacy terminology use, and this is what
> makes it possible to do something about it.
>
> The fact is, many old systems just couldn't express that many things.
>
> - thomas
>
> On 31/03/2018 22:24, Diego Boscá wrote:
>> What I say is that legacy applications or current systems usually
>> offer limited options with the knowledge available when they were
>> created. These options were decided back in the day and usually fit
>> with precoordinated terms. And defining this subsets helps on going
>> forward 
>>
>> El sáb., 31 mar. 2018 22:14, Philippe Ameline
>> <philippe.amel...@free.fr <mailto:philippe.amel...@free.fr>> escribió:
>>
>> Some people (count me in) strictly ban what you call
>> precoordination (that I call "aglutinating language") because
>> they believe that there is a nearly infinite set of them and such
>> a system is born to "explode" as the frog that wanted to mimic
>> the ox.
>>
>> To put it differently: you cannot express all possible discourses
>> as predetermined concepts.
>>
>> Do I interpret your answer correctly if I say that you have an
>> optimist vision in the form "there is a limited number of
>> clinically sound precoordinations so that SNOMED expansion will
>> reach an asymptote that keep being manageable"?
>>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: [Troll] Terminology bindings ... again

[Philippe Ameline]

Diego,

IMHO your contribution is orthogonal to what Thomas very accurately
explained. Building subset is a symptom of the issue, not a solution.

As I tried to explain in my initial post, we are currently facing two
generation of technologies in medicine:
- systems that record information as trees of atomic concepts, in the
same way we are all exchanging in "globish" by inserting English
concepts in a grammatical structure,
- systems that still rely on a fixed database schema and usually have a
"discourse system" limited to field/value pairs.

When I try to explain all this to lesser tech-savvy people (means, who
don't belong to this list ;-) ), I usually explain that:
- usual systems (with an information schema tied to a database schema)
are like a printed form. The day after you received the 5000 printed
sheet you ordered, you will realize that there are several design flaws
that you will have to endure while the stock is not empty,
- openEHR is a flexible schema, similar to a set of stamps that lets you
build forms dynamically from blank paper. If your design has to evolve,
you just have to adapt one of the stamps.
- in my system, based on an ontology and a dependency grammar, you can
use stamps (archetypes like) and/or "write" freely.

I have always understood openEHR as a link, a step, between the "good
old way" (discourse range hard coded into a database schema) and a
modern approach where you can really "tell a patient story" using a
genuine (structured, processable) language. 15 years ago, Thomas and I
spent hours discussing the opportunity for openEHR to include a
reference ontology in its kernel ; this decision was not made for very
good reasons, but I guess that it still remains a necessary evolution.

Thomas very accurately explained why SNOMED is a deceptive candidate for
such a reference ontology. And, unfortunately, it is deep rooted in its
origins as a coding system. I can hear all the arguments about "legacy
system" and even "legacy medicine" (the one still fully organized for
siloed acute care at a time our society already entered the information
age and suffers from chronic diseases). The question remains to guess if
SNOMED is a component that lets you stuck in the past or helps you
disrupt the legacy craps.

Now, let's imagine a modern system that would allow you to "tell a
patient medical story" from the various viewpoints of a
multidisciplinary patient centered team. What would be the point about
having "local vocabulary subsets"? Do you think that a GP shouldn't use
the word "mitral leak" or any other "specialized" word in the medical
vocabulary?

My feeling is that selected subset is a solution when using SNOMED as a
coding system. The subset being the global list of values that are legal
for the fields in the existing schema, in the same way you will select
subsets in a billing system. But when it comes to "telling a story"
using a language, in my opinion subsets are a non-sense. We don't use
"vocabulary subsets" when we talk, and each contributor in a patient's
team would mechanically get exposed to a super-set; subset is actually
only fit for silos... and at a time when medicine is already becoming a
narrow silo in health, I really don't see it as a sound strategy.

Best,

Philippe


Le 23/03/2018 à 10:49, Diego Boscá a écrit :
> IMO having both representations (pre and postcordinated) is not bad
> per se (in fact, knowing that they are equivalent is pretty good). The
> main problem is that technical people (including myself) shouldn't
> just dump the entire snomed ct into a data field and call it a day. To
> design better and useful systems you need a first "curation" phase
> where you define your relevant subsets that fit your system. The
> boundary problem is less of a problem if even if different terms were
> used when the record was created we can assess that they are in fact
> the same thing.
> I think people are a little unaware of this step and causes problems
> as the ones you and Thomas mentioned
>
> 2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland
>  >:
>
> I read Thomas’ reply with great interest, and I generally agree
> that with a well thought out information model, the very detailed
> precoordinated expressions are redundant. At the same time I
> understand Mikael’s point of view too. BUT, what I’m often met
> with is that because these precoordinated expressions exist (like
> for example “lying blood pressure” and “sitting blood pressure”),
> we should use them INSTEAD OF using our clever information models
> (that we do have) for recording new data.
>
>  
>
> In my opinion this is wrong because it doesn’t take into account
> that healthcare is unpredictable, and this makes recording more
> difficult for the clinician. How many different variations would
> you have to select from? Take the made up example “sitting
> systolic 

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 30/03/2018 à 17:38, Thomas Beale a écrit :

>
> Paths is also how openEHR querying works, and in pretty much the same
> way, except for the technical fact of using archetype codes rather
> than literal strings.
>
> - thomas
>

I wrote literal strings for clarity ; actually it is a path of codes
from the ontology.

To be accurate, if the ontology contains:
GECHN1  Echocardiography  (means label 1 for concept GECHN ; it could
exist a "true synonym" GECHN2 = Cardiac echography)
0FIND1    Findings
AMITV1   Mitral valve

Then the query for "Echocardiography/Findings/Mitral valve" would be
expressed as the path of concepts GECHN/0FIND/AMITV

In openEHR, each Archetype is a "local semantic reference frame" while I
work with a global one.

Philippe




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 30/03/2018 à 16:49, GF a écrit :

> Philippe,
>
> I understand Archetypes are discourse models and form a sentences
> A collection of sentences (Entry Archetypes) form one
> story/session/Composition and define the content of a system-interface
> connected to a database, or screen, or other service like a messaging
> system.
> In my terms: A Template consists of Entry Archetypes and is the
> content of a system-interface.
> The Composition, Template, the system-interface are equivalent, but
> need the story, system-interface, Template must contain the data and
> its full context/ epistemology.
> The Archetypes in my thinking are standardised patterns with which to
> construct an Entry archetype.
>
> My hierargy becomes:
>
> Ontology- Encyclopedia
> Terminology- Dictionary
> Cluster Archetype- Standardised phrases/patterns
> Entry Archetype- Clinical sentence including epistemology/context
> (collection of patterns)
> Composition- Clinical story a Template with a collection of
> sentences/Entry archetypes
>
> Queries can be for leave nodes to find in a Patient Record the datum.
> In order to interpret the datum fully and safely one must inspect the
> whole associated Entry and/or Composition, (depending on specifics)

Gerard,

I think that I get your point, though not being proficient enough in
openEHR details.

In my own universe, the basic information unit (as stored on disk) is a
tree. Each node of this tree being an element from the ontology, the
tree is fully autonomous and doesn't need external interpretation material.

For example:

Echocardiography
    Indication
        
    Findings
        Mitral valve
            Doppler
                Mitral leak
        

Hence, the "basic query unit" is not for leave nodes, but rather for a
path ; for example a query for "Echocardiography/Findings/Mitral valve"
would return a sub-tree.

But maybe you were saying this already.

Best,

Philippe

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 28/03/2018 à 23:42, GF a écrit :

> I see the analogies:
> - Ontology= Encyclopedia
> - Terminology = Dictionary
> - Archetype = Phrase

Hi Gerard,

I would rather see Archetypes as "discourse models" that form a mold for
sentences or groups of sentences. The Phrase, in you enumeration, would
rather be the instantiated information (stored in database).

If you are curious about the way a tree of concept can be homogeneous to
a sentence, Google "dependency grammar".

This has been my main topic for 30 years in the report generation
domain, and I can say that "simply ordering information on a form" and
"trying to tell something using a structured vocabulary" are much
different tasks. Typically, the first approach concentrates on the
leaves while the other makes certain that branches give the proper
meaning to the leaves.

Best,

Philippe

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Gerard, I like your rule (build a grammar that coordinates a vocabulary
of "atomic concepts" instead of agglutinating meta-concepts in the
vocabulary), but not your "left eye" example ;-)

In my own "universe", the "left eye" is a true physical object (when
"eye" is a concept).
I would say the same thing about the "left common carotid artery" which
is something you can actually "touch". Representing this concept as an
artery which belongs to the carotid network on the left part of the body
is not pre-coordination but rather what could be expressed by a semantic
network.

I agree with your "blue eye" example since it is simply "an eye which
color is blue".

To answer Mikael Nyström in the same message, I would be OK with his
conclusion about "the simple solution is to not use what you don't need"
if :
- this task had not been unsuccessfully tested by Belgian GPs, who
literally spent years trying to select a subset with no avail,
- this "language" was not advertised as a communication system... which
actually keeps you exposed to the full set unless everyone agrees to a
common subset (using Tom's proposals and Gerard's rule, for example).

Mikael is right when he says that it would be unfair to say that Snomed
"is bad because it isn’t optimized for [one's] narrow use case"...
unless there are lots of narrows use cases needed and unless one of
these narrow use cases is key to the next mainstream use case. If
innovators (typically the ones with weird use cases) consider Snomed as
a millstone around their necks, it is actually an issue worth considering.
As pointed before in this thread, this conversation is closely related
to HL7 V3 and its RIM before it was "fhired".

Best,

Philippe

Le 22/03/2018 à 14:26, GF a écrit :
> One simple rule solves the boundary problem.
>
> In my words.
> In principle models we use in the Semantic Stack are autonomous and
> orthogonal to each other. Meaning that at _precisely_ defines points
> the intersect,
> SNOMED is an ontology defining terms for concepts.
> Concept can be primitive or compound.
> Primitive concept examples are: Left and Right and Eye, White, Red and
> Blue. All terms one expects in a dictionary.
> Compound concepts are pre-co-ordinated concepts: Left Eye, Right Eye.
> Eye White coloured Red, ‘Blue eye’. All terms one expects in a
> pattern/standard phrase using words from a dictionary in a syntax.
>
> The rule is:
> Pre-coordination is done via Archetype/Patterns using Primitive concepts.
> Pre-coordination is not done via an ontology/terminology.
>
> Off course clinicians on their screens or doing statistics need
> Compound concepts and therefor need pre-coorodinated terms.
> These pre-coordinated terms must never be used to store, retrieve,
> interpret raw health data inside Health IT-systems.
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl 
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
>> On 22 Mar 2018, at 00:46, Heather Leslie
>> > > wrote:
>>
>> Hi Mikael,
>>  
>> What efforts are being made to resolve the boundary problem?
>>  
>> I applied to get involved with the  SNOMED information modelling
>> group but wasn’t successful, to try to engage on exactly that  point.
>>  
>> I’m not aware of any work going on. I’d be very pleased to get
>> involved if I could. It’s a fiendish problem and we need cooperation
>> and collaboration from both sides of the fence.
>>  
>> Regards
>>  
>> Heather
>>  
>> *From:* openEHR-technical
>> > > *On Behalf
>> Of *Mikael Nyström
>> *Sent:* Thursday, 22 March 2018 1:00 AM
>> *To:* For openEHR technical discussions
>> > >
>> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>>  
>> Hi Tom,
>>  
>> I believe that you proposal to ”move / remove the pre-coordinated
>> codes out of SNOMED” is very appealing in theory. However it is very
>> difficult in reality to agree on where the line between a suitable
>> pre-coordinated concept and a concept that is better to
>> post-coordinate or handle in another way are. The line between the
>> two alternatives also seem to be use case dependent, which makes it
>> even more difficult, and of cause also related to the boundary
>> problem. However, until there is a strong agreement on where the line
>> should be I continue to believe that it is better so include the
>> concepts in the same pile and let each use case decide how to select
>> the concepts they need and transform between the different
>> representations.
>>  
>> I like discussions about SNOMED CT and I don’t have any problems at
>> all with critical comments as long as they are fair. Those kinds of
>> criticism quite often makes me writing change requests. I am also
>> happy to answer questions about SNOMED CT. 

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 16/03/2018 à 13:11, Thomas Beale a écrit :

> Ad hoc negation, in German ;)
>
> But that's not really the fault of ICD10; it's a misuse of it. One
> might argue that it occurs because ICD10 doesn't provide a proper way
> of representing exclusions, only positive identifications. And that's
> an old, long debate...
>

Not certain to get your point here.

"Geometrically", a classification is a pavement of a domain (for ICD10,
the diseases), each sector being delimited by inclusion and exclusion
rules (in the same way frontiers are defined for countries). "Rag bags"
(of the kind "other X") are used to fill existing interstices.

Hence, every code is by construction exclusive from any other code...
and using a classification to "describe" can only come from confusing a
point of the domain (say "type 2 diabetes") with the delimited sector
that comes with the same name (say, depending on inclusion and exclusion
criteria, all hyperglycemia that cannot be qualified as type 1 diabetes).

Of course, is it possible to forget all this and use a classification as
a lexicon... but that would be plainly evil ;-)

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 15/03/2018 à 20:30, Ricardo Gonçalves a écrit :

>
> I too want to look at the the future and picture a state of art
> component and hopefully a [health] technological utopia, but a lot of
> work led us to what is currently available. Are we taking that to
> try/improve things and get somewhere? Are we holding back until
> something more mature, more usable, more future-alike comes up? Which
> path is more likely to bring us closer to the goal?

Hi Ricardo,

The question of settling in a local optimum or to go find a better place
has probably been the most ancient question that sapiens has been facing ;-)
Should we keep working hard in this place where harvesting is so hard,
or should we try to climb this mountain and see if it is not easier on
the other side?

My opinion is that there is a good reason not to get stuck (trying hard
forever) with Snomed.

As you said, thinks started with classifications, then some people came
up with coding systems and later on with ontology. The ability to tell
things improved step by step and led to an evolution of information
structures.
Meanwhile, the whole society was transformed by ambient information
systems to the point that we entered the post-industrial era, and, as
you know it well, the chronic turn demands for a deep reinvention of the
medical domain.

My opinion is that you cannot cope with such challenges using a
"language" that, due to its roots as a coding system, includes "words"
like "Pathological fracture of ankle due to secondary osteoporosis"
(concept 704293000).

Time will tell if the settlers were more wise than the explorers... and
we all have to keep in mind, as you nailed it, that we may have
different goals.

Best,

Philippe
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 14/03/2018 à 12:41, Thomas Beale a écrit :

> so the long term solution is healthcare data and major services
> (workflow / process) must eventually be part of a back-end system that
> isn't owned by any product vendor or care delivery location, but
> instead managed on behalf of the patient by a trusted third party.

Why do you believe that a third party is necessary/useful?

In my opinion, your (health) information is yours and you can manage it
yourself in a personal cloud or with a Ligne de vie.

>
> I would say: the term 'patient' just gets demoted to meaning a
> client/supplier relationship that sporadically occurs between a person
> in a health system, and the health system's healthcare provider
> organisations.

OK. And the pivotal term here is "sporadically".

When switching from the (health) organization reference frame (still
cameras fixed on the walls) to the person's reference frame (head
mounted real time camera), you switch from a set of specialized sporadic
encounters to a life long holistic management (that includes sporadic
health related encounters). This is the reason why the term "patient" is
not consistent here.

I always wonder what people have in mind when they write "patient
centered system". Maybe a head mounted camera that just capture still
images and operates inside care places only ;-)

Maybe just words, but when properly analyzed, they tell a lot about
cognitive dissonances.

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 14/03/2018 à 12:41, Thomas Beale a écrit :

> Translated in technological concepts, my own take is that is means
> switching:
>>
>> - from a record oriented vision to a project management vision (a
>> record is the place where you optimize your own decision support
>> ability through keeping the signal/noise ratio as high as possible ;
>> a project manager is the place where people build/feed/contribute to
>> a set of shared processes).
>>
>
> I don't quite agree here: because the 'record' (properly conceived) is
> the only thing that exists to chart the long-term situation of the
> patient, as doctors retire, nurses go on holidays, patients themselves
> move to new cities or countries. What can you trust to tell the story
> from your childhood asthma to your 2 pregnancies and births, to your
> hypertension and type 2 diabetes? Or even just your 10 year battle
> with one of the lesser cancers (very common) or lifelong management of
> a single disease. There is only the longitudinal health record.
>
> I agree though with the project management notion of course. Our
> recent work on Task Planning
> is
> trying to get up to this next level and join 'model' care pathways
> with real patient care plans and team-based care processes. It's going
> to take some years to get it really sorted out, but I think we are on
> the right path. I have seen the latest increment of the Activity-Based
> Design work at Intermountain Healthcare last week - we are converging.
>
> So when I say the 'EHR' I also include informational artefacts from
> long-running Planning and work processes, not just what we have today,
> which is observations, decisions, orders, and a record of actions done.

Tom, this question is pivotal and deserves a dedicated conference ;-)

When you ask "What can you trust to tell the story from your childhood
asthma to your 2 pregnancies and births, to your hypertension and type 2
diabetes?" what can of "record" are you thinking about?

Namely, in the practitioner reference frame, a record is the place where
you mention the smallest quantity of information that are "food for
thoughts". What I summed up as "optimizing the signal/noise ratio".
Hence a GP record doesn't look like a cardiologist record and is much
different from a nurse record.

In many countries (France included), governments made the assumption
that a "record of records" can be a "continuity of care record". I have
always claimed that it is a terrible idea since a record of records is a
place where the signal/noise ratio plummets. In France, the DMP
(initially Personal Health Record, now Shared Health Record since the
"P" switched from Personnel to Partagé) already failed several times
since its announcement in 2004. A new attempt will start in October.
From 10 years of interaction with practitioner about this "record of
records", I noticed that what they expect from it (for those who expect
something!) is always in the form "other will provide their information
sorted as I expect it"... no need to say that it is not what the word
"sharing" means ;-)
Pretty everywhere, the answer relies on magical thinking, à la
"automatic specialized views"... but the core issue is not addressed
(and even not really understood).

So far, we ends up with
- many siloed specialized records that only consist in instant
"viewpoint oriented" pictures (in the words of Koray "As a result the
patient information is all over the place in various formats"),
- the conclusion that pilling them up in the same "meta-record" will
deliver a mess of heterogeneous pictures and not the movie that could
tells your story.

The real issue is twofold:
- how to select information that "historically matter"? (you may
remember the words of Ed Hammond in Berlin (Eurorec 2002) saying that
"hospitals produce lots of information, a small part of it being of
historical matter, while family doctors produce little information that
are nearly 100% of historical matter"),
- how to have them "tell your (health) story"?

As an engineer, the proper attitude when a problem cannot be (smartly)
solved in a given reference frame is to try to find a different
reference frame where "things become simple(r)".

My take is that what is very hardly achievable in the organizations'
reference frame (typically Cartesian, with access rights as matrix, for
example - what I call "the boxes") becomes much more "natural" when
addressed in the person's reference frame (typically Polar with the team
"around" and access rights as Roses - what I call "the bubble").

Since I have been exploring this "reference frame shift" for nearly
twenty years (and will only launch the Ligne de vie this year), I can
say that what is at stake in the bubble is actually not a record, but
plainly a project manager (means the dual concept project + team) and
that "your history" is by far more accurately told this way than it
would be in any record.

As 

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

> because the structures take care of all data points, not just coded
> ones. But your /fils guides/ are rather special - they do the same
> thing, unlike an ordinary grammar, so it's not really an argument. In
> fact I would say that today we could derive a computable
> transformation from the trees <=> ADL2 archetypes.

Yes... it just means adding the ADL concepts inside the ontology.

>
>>
>> Such concept is described in a (already) 10 years old document
>> (http://philippe.ameline.free.fr/download/texts/LigneDeVieForPrevention.pdf).
>
> yes this is an excellent document - it even has the distinction
> between archetypes and (what we call) templates - the heading
> 'Federating heterogeneous information'.

I was fed at the proper source ;-)

Philippe
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

ing clinical data for the very long
> term.
>
> As far as I can see we have the most technologies/tools to support
> these new purposes. Now we need the developers to use it. I see a rich
> future for software development.
>
> Best regards
> Bert 
>
> Op 13 mrt. 2018 21:55 schreef "Philippe Ameline"
> <philippe.amel...@free.fr <mailto:philippe.amel...@free.fr>>:
>
> Le 13/03/2018 à 18:01, Bert Verhees a écrit :
>
> > On 13-03-18 17:45, Philippe Ameline wrote:
> >> in my own terms, it means that it is not the proper component for
> >> modern applications.
> >
> > Wasn't it Voltaire who said that the best is the enemy of the good?
>
> Bert, I get your point and I can perfectly understand that if
> Snomed can
> get used to do what you need done, you are plainly entitled to use it,
> even if "not perfect".
>
> But the issue could be stated differently: we are living a very
> specific
> moment since, at the same time, we become part of a genuine
> information
> society AND are engaged in a turn from acute to chronic care.
> It means that we should all be trashing the "good old systems" and
> dedicate ourselves to building risk management systems that allow
> multidisciplinary teams to manage patients' health journeys over time.
>
> Do you think that HL7 and Snomed are the proper components for
> this kind
> of innovation or that they are stuck in the ancient world?
> Do you think that using endemic technologies (components that only
> exist
> in the medical domain) can be of any use when it comes to health...
> that's to say operating in person's "bio-psycho-social bubble", a
> place
> where education, employment, social issues are as important as medical
> information, and are all plain contributors to risk management?
>
> It is not about "good" versus "perfect", but about having a whole
> domain
> (and its practitioners) get stuck in a dead arm of the information
> society.
>
> Best,
>
> Philippe
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> <mailto:openEHR-technical@lists.openehr.org>
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

>   * So the question is: if we have formal models of the structured
> form such as archetypes (maybe even FHIR profiles), why bother
> with the grammar strings?
>
>

This is a pivotal question, but you may remember that I am used to
putting it the other way around: if you can tell something using a
vocabulary and a grammar, why bother having a formal model of structured
forms? ;-)

Such concept is described in a (already) 10 years old document
(http://philippe.ameline.free.fr/download/texts/LigneDeVieForPrevention.pdf).

Philippe
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 13/03/2018 à 18:01, Bert Verhees a écrit :

> On 13-03-18 17:45, Philippe Ameline wrote:
>> in my own terms, it means that it is not the proper component for
>> modern applications.
>
> Wasn't it Voltaire who said that the best is the enemy of the good?

Bert, I get your point and I can perfectly understand that if Snomed can
get used to do what you need done, you are plainly entitled to use it,
even if "not perfect".

But the issue could be stated differently: we are living a very specific
moment since, at the same time, we become part of a genuine information
society AND are engaged in a turn from acute to chronic care.
It means that we should all be trashing the "good old systems" and
dedicate ourselves to building risk management systems that allow
multidisciplinary teams to manage patients' health journeys over time.

Do you think that HL7 and Snomed are the proper components for this kind
of innovation or that they are stuck in the ancient world?
Do you think that using endemic technologies (components that only exist
in the medical domain) can be of any use when it comes to health...
that's to say operating in person's "bio-psycho-social bubble", a place
where education, employment, social issues are as important as medical
information, and are all plain contributors to risk management?

It is not about "good" versus "perfect", but about having a whole domain
(and its practitioners) get stuck in a dead arm of the information society.

Best,

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Thomas,

Since, in that domain (terminologies, classification, ontologies...), it
is not that easy to understand someone else's explanation without a
sketching tool available, do you think I betray your thoughts if I sum
it up as "Snomed should not be licensed as a "one size fits all" package
but should be mainly usable as a set of tools and services in support of
localized adaptations by national organizations"?

It is certainly a good thing to be discussed in order to have Meriterm
fill the gap.

Besides, as you probably remember, the main reason I don't like Snomed
is because it is structured like a coding system and not a "narration
ontology".

As an example, I would say that a narration ontology should contain
atomic concepts, like "fracture", "location", "right ankle", but should
let "fracture of the right ankle" be built as a description structure
(say a small tree that express that the fracture is located at the right
ankle). Snomed inherited the incorporation of meta-concepts from its
history as a coding system (the kind of component that is to be used in
systems where information are stored in simple value-pair slots that
don't allow for elaborated description structures), as would be the
vocabulary of a massively agglutinating language... Since our languages
are not massively agglutinating ones (we built sentences), each group
has to invest a very long time selecting the subset that fits their
"local language" (for example the subset for GPs).

I have always seen Snomed as a system that could be fit to "fill slots
in forms" but not as a proper vocabulary to tell a patient's health
story... in my own terms, it means that it is not the proper component
for modern applications.

Philippe


Le 13/03/2018 à 15:21, Thomas Beale a écrit :
>
>
> The killer move would be to do something I advocated for years
> unsuccessfully: *separate SNOMED technology from content *and allow
> them to be independently licensable and used. Here, technology means
> representation (RF2 for example), open source programming libraries
> for working with ref-sets, specs and implems for e..g the constraint
> language, URIs and so on.
>
> It should be possible for a country (the one I am most familiar with
> w.r.t. to terminology today is Brazil) to create an empty 'SNOMED
> container' of its own, and put its existing terminologies in there -
> typically procedure lists, drug codes, lab codes, devices & prosthesis
> codes, packages (chargeable coarse-grained packages like childbirth
> that you get on a health plan) and so on. There are usually < 20k or
> even 10k such codes for most countries (UK and US would an exception),
> not counting lab analyte codes (but even there, 2000 or so codes would
> take care of most results). But the common situation is that nearly
> every country has its own version of these things, and they are far
> smaller than SNOMED. Now, SNOMED's version of things is usually better
> for /some /of that content, but in some cases, /it is missing concepts/.
>
> The ability to easily create an empty SNOMED repo, fill it with
> national vocabularies, have it automatically generate non-clashing
> (i.e. with other countries, or the core) concept codes and mappings,
> and then serve it from a standard CTS2 (or other decent standard)
> terminology service would have revolutionised things in my view. This
> pathway has not been obviously available however, and has been a real
> blockage. The error was not understanding that the starting point for
> most countries isn't the international core, it's their own vocabularies.
>
> The second killer feature would have been to *make creating and
> managing ref-sets for data/form fields much easier*, based on a
> subsetting language that can be applied to the core, and tools that
> implement that. Ways are needed to make the local / legacy
> vocabularies that have been imported, to look like a regular ref-set.
>
> The third killer feature would have been to *make translation tools
> work *on the basis of legacy vocabulary and new ref-sets, not on the
> basis of the huge (but mostly unused) international core.
>
> I think IHTSDO's / SNOMED International's emphasis has historically
> been on curating the core content, and making/buying tools to do that
> (the IHTSDO workbench, a tool that comes with its own PhD course),
> rather than promulgating SNOMED technology and tooling to enable the
> mess of real world content in each country to be rehoused in a
> standard way, and incrementally joined up by mapping or other means to
> the core. I think the latter would have been more helpful.
>
> There is additionally an elephant in the room: *IHTSDO (now SNOMED
> International) has been tied to a single terminology - SNOMED CT*, but
> it would have been better to have had a terminology standards org that
> was independent of any particular terminology, and worked to create a
> truly terminology-independent technology ecosystem, along with
> technical means of connecting 

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 13/03/2018 à 12:32, GEORGE, John (NHS DIGITAL) a écrit :

>  
>
> I am get the impression that SNOMED CT is hard to implement, and
> therefore wondered if we are at some kind of tipping point, like where
> HL7v3 was a few years ago, and some bright spark came along, and now
> we have FHIR that is gaining great traction in the health community
> due to the ease at which it can be implemented.
>

Hi John,

The tipping point will only get reached when a sufficient amount of
Snomed users will state that it is uselessly hard to implement... and
when someone will invent a smart way to simplify it... not there yet ;-)

But I really insist on the two orthogonal issues at stake:
1) a component should ease your job and not kill your project (detect
"dead horses" early),
2) a component should not keep you stuck in the wrong (ancient)
reference frame.

No need to say that FHIR is easier to put at work than the plain RIM,
but it still keeps its community in a system where "boxes that saw the
patient passing by can exchange information" when we should (due to both
the chronic turn and the information society era) be dedicated to
organize multidisciplinary teamwork around patients.

Best,

Philippe
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Grahame,

What you state is plainly valid, and the "it exists" argument is not to
be considered lightly.

However, as an engineer and a developer, I always try to measure the
payload of a component when I consider using it. Where does it fit in
the "pair of wings" to "dead horse" range?
IMHO, HL7 and Snomed are not on the right side and adopting such
components is like drilling in concrete: it never becomes easier.

When it is about considering costs, I can argue that something that is
"not well born" will cost considerably more than necessary during its
entire life span. Any such technique is hard to build, hard to integrate
and hard to maintain. As a guy that built and operate a self made 54000
atomic terms ontology, I can tell you that addressing this issue in the
proper way can save considerable amount of money and (this is the most
important part of it) free considerable energy that can be invested in
reinventing health instead of plaguing practitioners with new burdens.

My aim with this "troll" was just to tell that this kind of questioning
exists and also that some "fools" are currently joining to create what
they think could be "well born components".

I have the feeling that it is high time we "leapfrog" in being able to
"organize the journey" from the patient's "bio-psycho-social bubble"
instead of getting dedicated to "siloed care center boxes"... and that
HL7 and Snomed will keep their users in the wrong reference frame.

Time will tell... but interesting times ahead!

Philippe


Le 13/03/2018 à 11:05, Grahame Grieve a écrit :
> hi Philippe
>
> No one who's actually tried to use Snomed CT could think that in it's
> current form it's the answer to everything.
> But anyone who's tried to work on real terminologies must also be
> aware of just how much work is involved in these things.
>
> So there's very much a glass half full/empty thing here. I understand
> not being thrilled with Snomed CT as a choice, but as the french
> government, for instance, actually confronted how much more it will
> cost to do something else? 
>
> There's more than one kind of club to have that wastes money
>
> I've had a quick look at Meriterm... like all good rdf, it's not
> easily penetrable. But it looks like the authors are not informed
> about Cimino's desiderata... which brings us back to the wasting money
> thing...
>
> Grahame
>
>
>
> On Tue, Mar 13, 2018 at 8:19 PM, Philippe Ameline
> <philippe.amel...@free.fr <mailto:philippe.amel...@free.fr>> wrote:
>
> Pablo, I wish you sincerely all the best.
>
> IMHO, the question is not really to enroll but to deliver... and
> considering the tremendous amount of money that was invested in
> HL7 and Snomed (both to elaborate and try to implement) and the
> actual societal return, there is such a discrepancy that the
> hypothesis that, due to missing the "information society" turn,
> health systems are entering terrible crisis times is to be
> considered seriously.
>
> In current "information society", you have two options when
> considering "health information systems":
> 1) You dedicate yourself to "medical information systems" instead,
> and can freely build for (inter-connected) silos,
> 2) You consider "health" in its genuine meaning and you have to
> realize that it is a complex domain fully opened to all other
> societal issues... hence should ban components that are endemic to
> medicine.
>
> Maybe (and I really mean it for Latin America), it should be high
>     time to leapfrog, not to join the "dollars wasting club" ;-)
>
> Philippe
>
>
> Le 12/03/2018 à 18:17, Pablo Pazos a écrit :
>> In Latin America is all the contrary, more countries are becoming
>> SNOMED members and adopting SNOMED at the govt level.
>>
>> On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline
>> <philippe.amel...@free.fr <mailto:philippe.amel...@free.fr>> wrote:
>>
>> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>>
>> > IMO we should focus on SNOMED.
>>
>> Hi,
>>
>> There is currently some kind of interesting momentum against
>> Snomed.
>>
>> It can come from governments that refuse to pay for it
>> (current mood in
>> France), of from practitioners who, after having been asked
>> by their gov
>> to "sort out their Snomed subset" came to the conclusion that
>> it doesn't
>> exist.
>>
>> 

Re: SV: [Troll] Terminology bindings ... again

[Philippe Ameline]

Interesting times indeed :-)

Le 12/03/2018 à 18:06, Birger Haarbrandt a écrit :

> Please never underestimate the Germans...
>
> Am 12.03.2018 um 14:54 schrieb Mikael Nyström:
>> Will France as usual be the last country that adopt something that originate 
>> from Great Britain? :-)
>>
>>  Regards
>>  Mikael
>>
>>


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Pablo, I wish you sincerely all the best.

IMHO, the question is not really to enroll but to deliver... and
considering the tremendous amount of money that was invested in HL7 and
Snomed (both to elaborate and try to implement) and the actual societal
return, there is such a discrepancy that the hypothesis that, due to
missing the "information society" turn, health systems are entering
terrible crisis times is to be considered seriously.

In current "information society", you have two options when considering
"health information systems":
1) You dedicate yourself to "medical information systems" instead, and
can freely build for (inter-connected) silos,
2) You consider "health" in its genuine meaning and you have to realize
that it is a complex domain fully opened to all other societal issues...
hence should ban components that are endemic to medicine.

Maybe (and I really mean it for Latin America), it should be high time
to leapfrog, not to join the "dollars wasting club" ;-)

Philippe


Le 12/03/2018 à 18:17, Pablo Pazos a écrit :
> In Latin America is all the contrary, more countries are becoming
> SNOMED members and adopting SNOMED at the govt level.
>
> On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline
> <philippe.amel...@free.fr <mailto:philippe.amel...@free.fr>> wrote:
>
> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>
> > IMO we should focus on SNOMED.
>
> Hi,
>
> There is currently some kind of interesting momentum against Snomed.
>
> It can come from governments that refuse to pay for it (current
> mood in
> France), of from practitioners who, after having been asked by
> their gov
> to "sort out their Snomed subset" came to the conclusion that it
> doesn't
> exist.
>
> Some also predict that the most certain result of keeping up
> trying to build systems using such shitty fully endemic components
> is to
> have medical doctors disappear from missing the "information society"
> turn.
>
> Have some of you been aware of the Meriterm (European) project?
>
> Best,
>
> Philippe
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> <mailto:openEHR-technical@lists.openehr.org>
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>
>
>
>
> -- 
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>
> +598 99 043 145
> skype: cabolabs
>   <http://cabolabs.com/>
> http://www.cabolabs.com <http://www.cabolabs.com/>
> https://cloudehrserver.com <https://cloudehrserver.com/>
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

[Troll] Terminology bindings ... again

[Philippe Ameline]

Le 12/03/2018 à 01:38, Pablo Pazos a écrit :

> IMO we should focus on SNOMED.

Hi,

There is currently some kind of interesting momentum against Snomed.

It can come from governments that refuse to pay for it (current mood in
France), of from practitioners who, after having been asked by their gov
to "sort out their Snomed subset" came to the conclusion that it doesn't
exist.

Some also predict that the most certain result of keeping up
trying to build systems using such shitty fully endemic components is to
have medical doctors disappear from missing the "information society"
turn.

Have some of you been aware of the Meriterm (European) project?

Best,

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Blockchain

[Philippe Ameline]

Bert,

I just found this image on Twitter and it made me remember this trend
where you tried to argue in favor of the blockchain in front of naysayers.
https://twitter.com/MalwareTechBlog/status/932649133256597505
https://twitter.com/MalwareTechBlog/stathttps://twitter.com/MalwareTechBlog/status/932649133256597505us/932649133256597505

https://twitter.com/MalwareTechBlog/status/932649133256597505

Besides, it doesn't confuse anything. It plainly states "if you don't
build a crypto-currency, then don't use a blockchain, and if you do,
then please stop".
Summed up, it means something as "never use a blockchain", but it is
simply a humorous picture.

Best,

Philippe

Le 22/11/2017 à 17:37, Bert Verhees a écrit :
> Phillippe, in the image on your blog, you make the same mistake as
> many make. You confuse crypto-currency with blockchain.
> It is the same as confusing asphalt with a parking spot before the
> bank.  An asphalted road, however can lead you somewhere (if you have
> a car or a bike, of course).
>
> Blockchain, in a special way, facilitates crypto-currency, but there
> are more ways of blockchain, and completely other things which can be
> facilitated by it.
>
> Best regards,
> Bert
>
>
> On 22-11-17 15:49, Philippe Ameline wrote:
>>
>> I was just trying to add some level of humor; sorry if it appeared
>> ironic.
>>
>> However, if you are asking me what mistake major players and
>> governments make, I have an easy answer: they all consider addressing
>> continuity of care through a "record of records" when the only
>> reasonable way (IMHO) is to enable multidisciplinary group work in
>> the patient's "bio-psycho-social bubble".
>>
>> It is a very painful process to see, years after years, the same
>> wrong idea being expensively tested again and again with more and
>> more powerful (and/or exotic) techniques.
>> As goes a French saying from the ancient TV comics "Les Shadoks":
>> "They pumped and pumped and nothing happened... but they kept on
>> pumping for fear that something worse could happen".
>>
>> Best,
>>
>> Philippe
>>
>> PS: I can provide (for free) a demonstration (with reasonably simple
>> concepts from knowledge management) of the reason why a "record of
>> record" is a wrong idea.
>> But I know it is useless since, in France, our technocrats have been
>> trying to do it with the "DMP" for 13 years... and going... since,
>> these days, there is a new attempt... and they are very optimistic
>> since, after carefully listening to the MDs, they built a user
>> interface with less clicks.
>>
>>
>> Le 22/11/2017 à 12:01, Bert Verhees a écrit :
>>>
>>> How do you explain that mayor players in government and
>>> healthcare-ict industry do not agree with this?
>>>
>>> Which mistake do they make?
>>>
>>>
>>> Op wo 22 nov. 2017 11:38 schreef Philippe Ameline
>>> <philippe.amel...@free.fr <mailto:philippe.amel...@free.fr>>:
>>>
>>> Hi to all,
>>>
>>> Just discovered a decision tree about using Blockchain that
>>> pretty well
>>> sums up our discussion:
>>> http://philippe.ameline.free.fr/wordpress/?p=1979
>>>
>>> Best,
>>>
>>> Philippe
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> <mailto:openEHR-technical@lists.openehr.org>
>>> 
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Blockchain

[Philippe Ameline]

I was just trying to add some level of humor; sorry if it appeared ironic.

However, if you are asking me what mistake major players and governments
make, I have an easy answer: they all consider addressing continuity of
care through a "record of records" when the only reasonable way (IMHO)
is to enable multidisciplinary group work in the patient's
"bio-psycho-social bubble".

It is a very painful process to see, years after years, the same wrong
idea being expensively tested again and again with more and more
powerful (and/or exotic) techniques.
As goes a French saying from the ancient TV comics "Les Shadoks": "They
pumped and pumped and nothing happened... but they kept on pumping for
fear that something worse could happen".

Best,

Philippe

PS: I can provide (for free) a demonstration (with reasonably simple
concepts from knowledge management) of the reason why a "record of
record" is a wrong idea.
But I know it is useless since, in France, our technocrats have been
trying to do it with the "DMP" for 13 years... and going... since, these
days, there is a new attempt... and they are very optimistic since,
after carefully listening to the MDs, they built a user interface with
less clicks.


Le 22/11/2017 à 12:01, Bert Verhees a écrit :
>
> How do you explain that mayor players in government and healthcare-ict
> industry do not agree with this?
>
> Which mistake do they make?
>
>
> Op wo 22 nov. 2017 11:38 schreef Philippe Ameline
> <philippe.amel...@free.fr <mailto:philippe.amel...@free.fr>>:
>
> Hi to all,
>
> Just discovered a decision tree about using Blockchain that pretty
> well
> sums up our discussion:
> http://philippe.ameline.free.fr/wordpress/?p=1979
>
> Best,
>
> Philippe
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> <mailto:openEHR-technical@lists.openehr.org>
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Blockchain

[Philippe Ameline]

Hi to all,

Just discovered a decision tree about using Blockchain that pretty well
sums up our discussion:
http://philippe.ameline.free.fr/wordpress/?p=1979

Best,

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Aw: Re: Blockchain

[Philippe Ameline]

Le 14/11/2017 à 16:39, Grahame Grieve a écrit :

> In the healthcare related blockchain ideas or prototype
> implementations I have heard about so far something different than
> proof of work is used, for example proof of authority. That has
> other drawbacks and challenges, but it does not suffer from the
> same power consumption problems.
>
>
> that's true. But I don't see s sweet spot there; either you end up
> falling back to a central authority after all - in which case you
> might as well just trust the central authority and design a more
> efficient solution, or you have something that's less secure - but
> doesn't - as far as I can figure out - have less of a reason to need
> security. The one possible exception I've seen, which I've seen in
> production, is closed trading schemes around tracking payments between
> a group of entities.

Agreed, but a third party that would just be in charge of making certain
that the blockchain is unaltered has nothing to do with the business
involved. It is a technical trusted party, and there is no true reason
it should be expensive (for example, it could publish the hash of the
blockchain at every growing stages, so that anybody can check if
currently published blockchain is trustable).

It has nothing in common with a Ministry of Health or any other "bag of
technocrats" (just kidding, of course).

Philippe
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Aw: Re: Blockchain

[Philippe Ameline]

Le 14/11/2017 à 12:31, Karsten Hilbert a écrit :

>> A Blockchain is a public (or at least shared) digital notary.
> ...
>> transactions are more expensive without a third party, because you need
>> to make the process of adding a new block "expensive enough" in order to
>> make sure that the one doing it can not deploy enough computing power to
>> hack the existing blocks during the process.
> And, one needs to remind oneself, "expensive enough" can only ever mean 
> "today".

Hi Karsten,

This is the reason why, at least in the Bitcoin universe, adding a block
is organized as a competition between miners.
Hence a bad guy who intends to use the addition of a new block as an
opportunity to modify some already existing blocks would need to process
this much more complex task quicker than the other miners who simply
concentrate on adding a block.

It can currently been argued that this competition led to concentrating
miners in China... but what could possibly go wrong? ;-)

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

dictionary

[Philippe AMELINE]

Hi Mikael,

You are right, there is no controversy on that... and no controversy at all.

Regards,

Philippe

Mikael Nystr?m a ?crit :

 Hi Philippe,

My answer was written from the pure computer science and engineering
perspective. I meant that openEHR have worked with the structure of the
electronic health records, but not built any medical terminology systems by
their own (as far as I know).

   Regards,
   Mikael Nystr?m



-Original Message-
From: owner-openehr-technical at openehr.org
[mailto:owner-openehr-technical at openehr.org] On Behalf Of Philippe AMELINE
Sent: den 9 februari 2006 15:37
To: openehr-technical at openehr.org
Subject: Re: dictionary

Hi Mikael,

I would be very sorry to have this conversation become too formal or appear
as some criticism. I am much willing to learn, and I think that, as a master
thesis supervisor, you teach Mattias not just to be happy with established
concepts but to have a push on it and check if it is a stone basement or
just a theater set.

My questions : are you certain that a structure can host any terminology,
what is the discourse complexity level you can address 
are of the have a push on it kind.

My feeling is that the good order to ask questions (and answer it) is :
Why do you want to communicate ?
What discourse complexity level can allow to address these needs ?
What discourse representation technology fits these required language ?

So, you may already have answered questions 1 and 2, and that it is possible
to answer Q3 with a discourse structure that can host any existing
terminology.
But at large, I don't agree that such a concept can address any answer to
questions 1 and 2. My personal opinion is even that, as a bottom-up
strategy, it constraints the system to a very specific range of
environments.

By the way, the term terminology itself would demand to be made more
accurate. It is often used to describe coding systems, classifications,
dictionaries, standardized vocabularies, ontologies...
All these components can actually appear somewhere in a discourse structure,
but at a specific place !
One can say, for example : The patient complains from a terrible abdominal
pain 2 hours after meal. We can classify it as D01 in ICPC
But not : The patient complains from a terrible (D01 in ICPC) 2 hours after
meal.

This is certainly a multi-axial discussion. I hope I make my point of view
understandable.

Cheers,

Philippe

Mikael Nystr?m a ?crit :

  

Hi Philippe,

From my point of view is the lack of communicable structure between
different EHR systems the main problem openEHR?s archetypes tries to solve.
I think this is what Mattias tries to say with his letter. In general 
medical informatics is it of cause also a large need for medical 
terminology systems of good quality, but openEHR?s archetypes don?t try 
to solve this problem by themselves. Instead you are able to link your 
archetypes to the medical terminology systems of the flavor you prefer, 
like SNOMED CT, ICD-10, ICF, ICPC, NCSP or something built by yourself. 
(At least in Sweden there exist maybe too many ?home built? medical 
terminology systems.)

  Regards,
  Mikael Nystr?m
  Mattias? and Johan?s master thesis supervisor



-Original Message-
From: owner-openehr-technical at openehr.org
[mailto:owner-openehr-technical at openehr.org] On Behalf Of Philippe 
AMELINE
Sent: den 9 februari 2006 12:34
To: openehr-technical at openehr.org
Subject: Re: dictionary

Hi Mattias,

The more I work on medical information systems, and the less I believe 
that the structure is more important than the terminology.

To be a little bit more accurate, my opinion is that any health 
information system is there to tell stories.
I started in the domain 20 years ago with endoscopy reports : the story 
to tell was a 10 to 20 minutes medical act. Now, for many reasons (but 
it would be too long to explain it there), the big thing is 
continuity of care, and the challenge is to be able to tell someone's whole


medical journey.
  

So, how can we tell these stories (from a 10 minutes encounter to the 
whole life and the fighting strategies to remain as healthy as possible) ?
The answer is rather simple (at least to express) : we need to make 
sentences. And to make sentences requires a grammar (the discourse
structure) and a vocabulary (to populate the discourse structure).

Is it possible to have a discourse structure that can host any 
terminology ?
My personal answer is 'no', but maybe I try to tell more complex 
stories than you intend, or maybe you have a more powerful technological


solution.
  

At large, I can ask you a question : do you think that you could 
communicate using the english grammar and let people choose any other 
language's vocabulary to populate it ?
You can answer that natural language is more complex that formal 
language, but I can say that the more complex the story you intend to 
tell and the closer they need to be.

Regards,

Philippe

dictionary

[Philippe AMELINE]

Thomas Beale a ?crit :


 My feeling is that the good order to ask questions (and answer it) is :
 Why do you want to communicate ?
 What discourse complexity level can allow to address these needs ?
 What discourse representation technology fits these required 
 language ?

 I think it is problematic to think only in terms of linguistic 
 discourse; we need to think in terms of conceptual truths as well. 
 Infection with plasmodium parasite leads to malaria, no matter what 
 language it is written in; certain kinds of polyps in the colon 
 increase the risk of bowel cancer, no matter what language.  
 Ontologies of reaility as I call them should be (more or less) 
 linguistically independent. The problem is to agree on one or more 
 good quality ones. Then archetypes have something to work with. 
 Unfortunately, I fear that the Snomed-ct developers are losing sight 
 of what a good terminology is and trying to jam many incorrect 
 concepts into it.

Hi Tom,

Aren't we talking on orthogonal axis ?

What I meant with discourse structure is, for example, the formal way 
you can describe a colonoscopy report. It is a huge Archetype, or rather 
a set of linked Archetypes.
The reason why I call it discourse structure is because I really think 
it is important to see any medical information as a story part, in 
some kind of fractal way : the polyp (and its description, maybe its 
ablation) is a very small story inside the colonoscopy larger story, 
inside the patient history journey.
So, thinking in term of discourse structure just means you envision 
all this, and take care to be homogeneous at any level.

Of course, this terminology is close from the natural language one. My 
vision is that a good natural language translation system must have two 
levels : an analysis layer that transform the input discourse into a 
formal language independent representation (FLIR), than a synthesis 
layer that transform this FLIR into an output natural language. In my 
opinion, our goal really is to see the medical information we store as a 
FLIR.

The FLIR is made from a discourse structure populated with terms from an 
ontology.
This ontology can be:
a concept list (level 0 : no predicate)
a semantic network (level 1 : level 2 predicates : isA(colitis, 
inflammatory disease))
or more complex relationships ; I think that your Ontology of reality 
is of the kind.

Currently, I must confess that my ideas are just clear enough concerning 
the semantic network. Because it is a genuine root component you can 
use everywhere.

 From my point of view, more complex ontologies become very specific to 
a given decision support system (DSS) technology. To be more accurate, 
for the examples you gave, you could want to address the follow up of 
this bad polyp by instantiating a Bayesian network or just a decision 
tree. The formal representation is much different.
My idea has been to build a formal description, like the FLIR of a 
medical encyclopedia entry for this polyp. It is (quite) easy and useful 
for drugs, because you can get standard chapters such as indications, 
contra-indications, bad interactions. But for symptoms or diseases, it 
is much harder.
Currently I decided no longer to work on that, and use a band of smart 
agents, each one with its specific knowledge and its specific DSS 
technology, rather than building a more general expert system using a 
level X ontology.

Well, quite a long post. Sorry to take your time when you release V 1.0. 
And felicitations to the openEHR team for this.

Cheers,

Philippe

dictionary

[Philippe AMELINE]

Hi Mikael,

I would be very sorry to have this conversation become too formal or 
appear as some criticism. I am much willing to learn, and I think that, 
as a master thesis supervisor, you teach Mattias not just to be happy 
with established concepts but to have a push on it and check if it is 
a stone basement or just a theater set.

My questions : are you certain that a structure can host any 
terminology, what is the discourse complexity level you can address 
are of the have a push on it kind.

My feeling is that the good order to ask questions (and answer it) is :
Why do you want to communicate ?
What discourse complexity level can allow to address these needs ?
What discourse representation technology fits these required language ?

So, you may already have answered questions 1 and 2, and that it is 
possible to answer Q3 with a discourse structure that can host any 
existing terminology.
But at large, I don't agree that such a concept can address any answer 
to questions 1 and 2. My personal opinion is even that, as a bottom-up 
strategy, it constraints the system to a very specific range of 
environments.

By the way, the term terminology itself would demand to be made more 
accurate. It is often used to describe coding systems, classifications, 
dictionaries, standardized vocabularies, ontologies...
All these components can actually appear somewhere in a discourse 
structure, but at a specific place !
One can say, for example : The patient complains from a terrible 
abdominal pain 2 hours after meal. We can classify it as D01 in ICPC
But not : The patient complains from a terrible (D01 in ICPC) 2 hours 
after meal.

This is certainly a multi-axial discussion. I hope I make my point of 
view understandable.

Cheers,

Philippe

Mikael Nystr?m a ?crit :

 Hi Philippe,

From my point of view is the lack of communicable structure between
different EHR systems the main problem openEHR?s archetypes tries to solve.
I think this is what Mattias tries to say with his letter. In general
medical informatics is it of cause also a large need for medical terminology
systems of good quality, but openEHR?s archetypes don?t try to solve this
problem by themselves. Instead you are able to link your archetypes to the
medical terminology systems of the flavor you prefer, like SNOMED CT,
ICD-10, ICF, ICPC, NCSP or something built by yourself. (At least in Sweden
there exist maybe too many ?home built? medical terminology systems.)

   Regards,
   Mikael Nystr?m
   Mattias? and Johan?s master thesis supervisor



-Original Message-
From: owner-openehr-technical at openehr.org
[mailto:owner-openehr-technical at openehr.org] On Behalf Of Philippe AMELINE
Sent: den 9 februari 2006 12:34
To: openehr-technical at openehr.org
Subject: Re: dictionary

Hi Mattias,

The more I work on medical information systems, and the less I believe that
the structure is more important than the terminology.

To be a little bit more accurate, my opinion is that any health information
system is there to tell stories.
I started in the domain 20 years ago with endoscopy reports : the story to
tell was a 10 to 20 minutes medical act. Now, for many reasons (but it would
be too long to explain it there), the big thing is continuity of care, and
the challenge is to be able to tell someone's whole medical journey.

So, how can we tell these stories (from a 10 minutes encounter to the whole
life and the fighting strategies to remain as healthy as possible) ?
The answer is rather simple (at least to express) : we need to make
sentences. And to make sentences requires a grammar (the discourse
structure) and a vocabulary (to populate the discourse structure).

Is it possible to have a discourse structure that can host any terminology
?
My personal answer is 'no', but maybe I try to tell more complex stories
than you intend, or maybe you have a more powerful technological solution.

At large, I can ask you a question : do you think that you could communicate
using the english grammar and let people choose any other language's
vocabulary to populate it ?
You can answer that natural language is more complex that formal language,
but I can say that the more complex the story you intend to tell and the
closer they need to be.

Regards,

Philippe

  

The important thing in openEHR archetypes is the structure of them. As 
long as there is a structure that is equal for both Weight and 
Bodyweight, it shouldn't be a problem. The allowed information model 
structures in archetypes is what really matters and the terms can 
always be bound to external terminologies to create a mutual 
understanding.

Regards,

Mattias Forss









  

difficulties starting an implementation

[Philippe AMELINE]

Hi,

It seems to me you are turning around a really subtle and complex concept.

Like a building, information systems must have some hard parts (to stand 
up) and a flexible content (so you can live in it).

The usual way is to have the hard parts being whether a database model 
or some pieces of code, or the both of them. The flexibility is very 
low, and I am used to saying that these systems can only tell one story, 
but it is neat and usual for programmers.

Now comes the 2 levels systems, where what can be told is not mixed 
with what can tell it.

Some examples of components of the kind I have been working on :
- Archetypes, of course, to separate the data model from the code and 
the database
- Data querying, with such tools as the Pilot that uses XML scripts to 
describe a query workflow, instead of hard programming SQL or Corba or 
Web services connectors
- Security components, with such a project as MP6 where the rules are 
expressed in a predicate language with a genuine abstraction from the 
software code

One of the key advantage (among many others) of these 2 levels systems 
is that we can build proof components for the model itself and not 
just test if the software is bug free. This is the genuine hard part 
of our modern buildings.

Thomas is trying to express that Eiffel is not used as a programing 
language here (even if it could be, but it can be confusing) but as a 
way to express and validate some concepts.

However, living in Paris, I can assess that Eiffel is such a good 
programing language that we have here a quite impressive monument raised 
to glorify it. And we don't have any Java tower or C++ tower or any 
other tower of the kind.

Cheers,

Philippe



Thomas Beale a ?crit :

 Bert Verhees wrote:


 example
 A class has an interface, this what it makes visible to other 
 classes. A property is some characteristic of a class.
 F.e a class Person has a property bodyLength. This can be in inches 
 or centimeters. For example bodyLength can give you centimeters or 
 inches, depending on which Local is configured:

 In java one publishes the getters and setters, they do not use 
 properties often,though it could be possible.
 In object pascal one publishes the property, and private implements 
 the getters and setters, they do not  have to be public or published, 
 the compiler arranges the connection. One can also publish the 
 getters and setters in object pascal
 In Eiffel I don't know.
  

 In Eiffel you can do what you want, but you normally publish 
 attributes and setter routines. Getter and setter routines are bad 
 programming practice, since they destroy any proper connection of the 
 code with a model. For example if the model is (pascal-style):

 class PERSON
name: String
 end

 then you can just add the setter to the class to have an operational 
 class:

 class PERSON
name: String
set_name(a_str: String) is
   do
   end
 end

 But with the getter/setter style you end up with classes like:

 class PERSON
   get_name: String is
   do
   end

set_name(a_str: String) is
   do
   end
 end

 which is ridiculous in terms of modelling - there is no sensible 
 property of a PERSON called a get_name. Sadly this kind of 
 programming has become commonplace.

 As you can see on the pseudo-code below, I am used to Pascal, Java 
 and C(++), I mix them so anyone can understand. I call it Jascal++ ;-)
  

 even I can understand it

 const BRITISH = 0;
 const OTHER=1;

 class Person{
 publicproperty bodyLength:Integer read getLength;
 public property Local write setLocal;
 privatefunction getLength:Integer;
 private procedure setLocal(value:Integer);
 privatefLength:Integer;
 privatefLocal:Integer;
 }

 procedure Person.SetLocal(val:Integer);
 {
 fLocal:=val;
 }

 function Person.getLength:Integer{
 if fLocal=BRITISH then Result := fLength/2.54
 else Result := fLength
 }
 /example

 In a case tool, only the class-interfaces is mentioned, and in a 
 short way, eventually documentation added.
 In a case tool a class would look like

 Person
 
 bodyLength:Integer
 Local:Integer;

 comment
 (In XMI one would get about the same (but then in XML). A case-tool 
 can load the XMI, and generate code following the syntax and 
 programming standards of that particular language.
 I know there are shortcomings in XMI, but still I think, it is better 
 then nothing, in accompanying docs, want could explain the 
 shortcomings. Most of the classes and their particularities can be 
 expressed in XMI)
 /comment

 The implementation-part is in the code, never seen 
 implementation-parts in a case-tool. It is possible, but rarely done.

 When you use a case-tool which is at the same time a 
 programming-enviroment, then you can eventually compile the code, but 
 there will be no implementation behind the class-properties/methods, 
 and in the compiled product, it is hard to discover which 

{Filename?} Proposed major change to ADL archetype syntax

[Philippe AMELINE]

Hi Tom,

The XML file didn't pass through Chime's cerberus ;o)

Philippe
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

The Uncertainty Decision was: Dr R LONJON Confidence indicator !

[Philippe AMELINE]

Hi,

I agree with Thomas, probably because we are engineers and ask ourselves 
If they don't record this information for further action, why do they 
record it anyway ?.

I can perfectly understand the way Gerard thinks to it, in an EHRcom way 
: I use this EHR for myself, and I can send you a part of MY EHR record 
to complete yours (sorry Gerard if it seems over-simple).

 From my own point of view (at least for the kind of systems I am 
working on), the members of a patient's health team are contributors on 
a common working place, and, (if we don't ask them to be God) we expect 
for more involvment and accuracy in the process.

Cheers,

Philippe

Thomas Beale wrote:

 Gerard Freriks wrote:

 The EHR is not invented to describe the real actual health status of 
 the patient.
 It is there to document what clinicians deemed important to say ABOUT 
 the health status of the patient.
 It always is an opinion of a professional about something.


 yes, hopefully we all agree with this philosophy.

 But we need to add (contradict me if I'm wrong;-) that it is what 
 clinicians wanted to say which they deemed relevant to next steps - 
 either diagnostic or intervention. What to do next is not just based 
 on the doctor's confidence about what the symptoms might mean, but 
 also on:
 - the urgency of treatment of that condition (cases like cerebral 
 meningitis, malaria...)
 - the severity of the condition (e.g. cystic fibrosis)
 - the severity of the consequences of the condition on others (CF, 
 huntington's, ...)

 ...so it seems to me that the indicator of what to do next when a 
 differential diagnosis is recorded relates strongly to the innate 
 characteristics of the conditions recorded, not just the doctor's 
 opinion of how likely it might be. If angina pectoris is a possible 
 diagnosis for burning chest pain at 5%, with the most probable 
 diagnosis (in the opinion of the physician) being gastric reflux at 
 95%, and it is a 55-yo with a family history of coronary heart 
 disease, I presume that the angina pectoris possibility is the one 
 that drives the next steps? How are the confidences really decided?

 How are we to bridge the gap between the physician-recorded confidence 
 factor and the total list of factors which drive the next steps? What 
 do we need in the EHR? Is this just a decision support problem 
 (where the physician will be performing the decision support)?


 He, himself, always makes statements with varying degrees of certainty.
 Physicians are no gods that know everything.


 What? And I thoughtoh no, my whole world is shattered...:-)

 - thomas

 -
 If you have any questions about using this list,
 please send a message to d.lloyd at openehr.org



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Confidence indicator [was Flavour of null]

[Philippe AMELINE]

Hi Tom,

I agree with you.

My idea was that if we express the process quality, and consider data 
measured during this process, we end up with a range of data qualities - 
from plain to not measurable - and this last one leads to a Null value.

For example, if I say that my echocardiography (the process) was globaly 
of poor quality due to patient's overweight, I can however correctly 
measure some information, have some other evaluated as approximate but 
with a value provided, and some other being Null.

So, as a summary, I would say that :
1) confidence applys only when there is a value, it can be a numerical 
rating (0 to 100% in Odyssee)
2) Null value can have an explanation for null
3) The process itself should have a quality descriptor, and it would be 
nice to have a relationship between this global information and local 
data confidence.

What led me to think that way is that among the reasons for Null that 
were proposed in former messages, most of them where indead qualifiers 
for the process at a whole (and I can even say that some where qualifier 
for the workflow (the process above the process) - I wonder how we can 
chain the quality indicators in the workflow-process-data sequence - 
for example, an exam can be technically good, but lead to wrong 
information because it was performed too early or too late in a worflow).

Cheers,

Philippe

 Philippe AMELINE wrote:

 Hi Koray,

 Don't you think that Null is not a singularity (I mean an isolated 
 point), but the extreme value of a linear cursor we could name 
 validity or confidence.

 To give a matter of fact example, I could say that :

 I can provide a value without any comment : I am confident in the 
 quality level of the measurement process
 I can provide a value saying that an average (or poor) level of 
 quality must be noticed when using this information
 I can decide not to provide a value and explain why


 Hi Philippe,

 our analysis in GEHR/openEHR has always been that confidence are 
 null-flavour are two different things:
 - null / data quality - indicates that some datum was not obtainable
 - confidence is likelihood of being correct a datum is, in the opinion 
 of the health care professional (or maybe someone else); it can only 
 be set when there is a value

 - thomas

 -
 If you have any questions about using this list,
 please send a message to d.lloyd at openehr.org



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Confidence indicator [was Flavour of null]

[Philippe AMELINE]

Hi Koray,

Don't you think that Null is not a singularity (I mean an isolated 
point), but the extreme value of a linear cursor we could name 
validity or confidence.

To give a matter of fact example, I could say that :

I can provide a value without any comment : I am confident in the 
quality level of the measurement process
I can provide a value saying that an average (or poor) level of quality 
must be noticed when using this information
I can decide not to provide a value and explain why

This is close from error bars in scientific papers ; I don't mean you 
must provide a calculated accuracy level (it is usually not possible), 
but that when an information was not obtained with the usual level of 
precision, it should always be noticed. For example, some calculated 
values use measured value power 3 - you can imagine how errors are 
raised at a high level.

So, maybe we should always provide room for a validity indicator (that 
would become the list of reasons for null when flavours of null 
replace the asked value).

Cheers,

Philippe

So my proposal in short is:
1) Examine the possible data values to be expected in a particular field: If
can be solved with a simple True/False then assign a bit.
2) If not then employ the Essential Flavours of Null which should appear
as a separate Data Type I believe
3) If extra contextual information is needed at the time of design or will
probably be needed in future (This requires a careful study by taking into
consideration all viewpoints: legal, epidemiological and etc.) then assign
Knowledge-Enabled Contextual Archetype Plug-Ins and provide mappings to
the essential ones. 

That is my simple solution proposal that I had been deeply thinking on for
some years!

Best regards,

Dr. Koray Atalag
METU Informatics Institute
Ph.D. Candidate on Information Systems

  


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Age

[Philippe AMELINE]

Gerard,

 From all the messages, it seems to me we can define 3 kind of values :

1) Values with a genuine relationship with date of birth : youth, middle 
age, elderly...
Those who can manage fuzzy sets will do it that way, while others will 
have to use simple time intervals based on date of birth.
Can we define these fuzzy sets or intervals as standards ? Maybe we 
should work on it.

2) Values somewhat related to age, but with a non linear/standard 
relationship : date of conception, date of first flue, date of first walk...
These dates should be recorded somewhere, as unrelated informations.

3) Values whose name includes the term age, but are, in fact, ratios : 
mental age, growth age...
These informations are neither dates, nor time intervals, but only some 
comparisons versus a standard developpement ; from my point of view, 
they are some kind of ratios and have little to do with this discussion.

Cheers,

Philippe

 Dear all,

 It is fine for me when we can agree that we mean by 'Age' time after 
 birth.

 How will we name and define concepts like: youth, post conception, 
 post gestation, middel aged, elderly?

 Gerard
 --  private --
 Gerard Freriks, arts
 Huigsloterdijk 378
 2158 LR Buitenkaag
 The Netherlands

 +31 252 544896
 +31 654 792800
 On 31 Jan 2005, at 19:10, William E Hammond wrote:

 For an age, I agree that the date of birth is adequate as long as you
 remember people do not age after they die.  It is also convenient to 
 have a
 reference time mark for many things, including conception, start of a
 course of treatment.  Adjectives and nouns are difficult to put into
 algorithms unless the definitions are precise.

 Ed Hammond


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype vs. ontology

[Philippe AMELINE]

 a Fil guide will do. You 
 have many Fils guides in a big bag, and when the user is somewhere, 
 you find the more relevant Fil guide (if any) : more relevant means 
 the one whose path is the semantically closest from user actual 
 current path. But the Fils guides are just oppostunistic description 
 support in a non deterministic domain. So the data don't remember the 
 Fil guide they come from.

 This (too) long description to explain that Fils guides neither 
 belong to the reference model, nor to the ontology, but are interface 
 components in a knowledge management system.

 Currently, we have nearly 3500 Fils guides, but most of them are used 
 for our report management system and should be replaced with archetypes.

 By the way, the Fil guide engine, that decides which Fil guide to 
 throw, can also decide to throw an Arcehtype if the user has entered 
 a part of domain where a deterministic description should occur. And 
 you also can go beyond the leaves of an Archetype using Fils guides 
 (or just using the ontology by hand).

 I hope that all this is understandable ;o)

 Philippe AMELINE


 Hi,


 I just forgot to tell you that our ontology has only 50 000 terms 
 (it means less than 50 000 concepts, since a concept can be 
 represented by several terms). As you may have understood, the 
 ontology contains only basic concepts, since complex concepts are 
 expressed through a small tree.
 50 000 is more than a standard medical dictionary (say a dictionary 
 + anatomical terms + drugs international standard names), so it 
 really represent the words used in the medical domain.


 to clarify a bit: in Philippe's system, there are 50,000 concepts in 
 a compositional terminology, as well as the fils guides (guide 
 paths) whch are little structured post-coordination rules defining 
 legal ways to put the 50,000 concepts together in coordinated tree 
 structures. This combination of a small, clean lexicon, and the fils 
 guides are what makes Philippe's approach to terminology so 
 exciting, in my view. Philippe - one question I have never asked - 
 how many fils guides do you have currently?

 - thomas



 -
 If you have any questions about using this list,
 please send a message to d.lloyd at openehr.org





-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR and Odyssee

[Philippe AMELINE]

Hi,

Since nobody on the list seems to speak french (some kind of satanic 
langage however ;o)) ), I will try to find some time writing a text in 
english (anyway the french text on the nautilus site is absolutely not up 
to date and I can't write in Latin !).

Thanks for your interest...

Philippe

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR and Odyssee

[Philippe AMELINE]

Hi to all,

Odyssee keeps on, and our Lignes de vie server is now (quite) ready ; 
quite means that the code is wrtitten and the server works, but it is not 
tested enough to host genuine patients. We are working hard on that.

I am convinced that openEHR and Odyssee are working on very similar 
concepts. We are building the very same kind of building, except that the 
concrete used to keep things together is based on Archetypes in openEHR, 
while it is based on an ontology inside Odyssee. However Odyssee already as 
its specific Archetypes engine, and openEHR could evolve toward an 
integrated ontology to acertain a common semantic.

Till now, both project are evolving side by side, with just enough 
knowledge of each other to take what seems good ; I think that we could 
join efforts in a more elaborated way.
The best way I can explain it is that Odyssee currently has two components 
running : a smart client, and a continuity of care server, while openEHR is 
working on health organization servers. Put together, we get a complete system.

Regards,

Philippe AMELINE

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

RFC CR-000101 - request for comments - deadline 23 july 2004

[Philippe AMELINE]

Hi, Karsten and Christian,

Nice brain pingpong match ;o)

Don't you think that your vision depends on the feeling you get and the 
tools you are familiar with ?

In a pure object oriented model, dealing with hierarchies of object is natural.

However when it comes to knowledge management, it is more natural to shift 
to predicates, for example semantic networks.
Because it is usually not possible to define THE hierarchy : to keep on 
with the brain, you may succed in building an anatomical hierarchy, but 
when you will consider brain functions or brain diseases, you will have to 
build new hierarchies. All this hierarchical trees are inter-connected, and 
you have better replacing hierarchical traits with named traits (ie 
predicates).

I don't know if all this is relevant with openEHR ? (I mean does a system 
need to mimic what it should manage)

Regards

Philippe

  physical brain == carrier of knowledge == neurons, synapses etc. == 
 real world
But they are not interconnected in a hierarchy only, to the
best of my knowledge.

  The mind knows about itself and its physical carrier, the brain. But the
  functioning of the brain has nothing to do with the abstract concepts
  build within it.
I tend to think that Nature had no abstract concepts
in mind when building the brain. Rather abstract concepts
are what we with our limited ability to comprehend use to
reduce complex things to something we *can* understand, no ?
Eg. the brain simply IS but we use abstract concepts to
*describe* what we understand of it. Unless you want to reduce
those abstract concepts to Laws of Nature - which have nothing
much to do with why or whether the brain is internally connected
hierarchially or web-like.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

IS Models (was HISTORY DATA SET IN EPR)

[Philippe AMELINE]

Hi,

The clincial analysis process is pretty much standard all over and this will
find acceptability (hopefull). The data so captured can be used for a
descision support system.

This is  an add on to your thaughts and maybe you can now look at your
suggested solution in the light of what would find acceptance with a
clinician.

I must agree, since it was our starting point several years ago. That's the 
reason why we created an ontology.

But we discovered it was useless trying to work on a decision support 
system if we only had the local datas (since you can far more easyly help a 
doctor by analysing what others produced... he usually can work well on 
what he recorded himself).

So we worked on concepts in the continuity of care domain. But we 
discovered that the success key for continuity of care is the patient 
acceptance, but we had to present him with an acceptable system.

So we worked on the Patient Health Project, an health management concept.

Now we are quite happy with that, and we have nearly adapted a Blackboard 
(an Artificial Intelligence component) to our system.

10 lines to tell a 10 years story ;o)

Philippe 

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

HISTORY DATA SET IN EPR

[Philippe AMELINE]

I agree with Karsten - there is a basic principle here (and in openEHR). 
The physician must be able to write what they want. Now...if they want to 
write a sentence with the words possible Dengue Fever infection then the 
software may be able to code Dengue Fever using Snomed or some other 
ontology; the result would be narrative with key coded terms. Peter 
Elkin's group at Mayo have shown how they do the reverse (what Gerard 
Freriks mentioned also) - a post hoc coding  structuring of the text.

Philippe Ameline's Odyssee product on the other hand uses a structured 
input system for recording endoscopy investigations, and the specialists 
are happy with it. But - he has a nice, detailed lexicon of terms to draw 
on, and it seems it has everything they want; when it doesn't, they just 
write a free text field. Even so, the principle i mention above seems to 
be preserved.

So - how structured the input I suspect depends more on the type of 
medicine or specialty than some overarching rule.

Hi,

We sold our first Endoscopic report generator in 1987 - so we now have some 
feed back ;o)

You have to understand that a report from a specialist is primarily 
intended to have the others health professionals know something.
The quality factors here are :
- completness : you should not forget to mention something - a structured 
interface has proven to be a plus compared with free dictation
- process oriented : don't be elusive, call a cat a cat (it is a common 
reflex with free dictation to be not as accurate as it should be)
- terms repeatability : the same aspect should be described in the same way 
- it is a place where the process of reducing the term set is a plus ; 
elsewhere the same aspect will be described in very different ways - even 
in the same team.
- defined corpus : if you know the corpus, you also know what could have 
been said, and has not been said (not easy however - but this concept is 
certainly in the Archetypes)
- ready now : the report should leave with the patient

It might be a french drawback, but very, very few free text reports I have 
seen are ok from this point of view.

I am myself convinced that free text analysis is a dead way, since you 
usually can't structure afterward what has not been structured immediatly.
To give an example, some time ago, I was installing my system in an 
hospital ; an endoscopist just ended an exam, and had hand-written his 
result on a paper. We took it as a learning model to make the report with 
the generator.
Roughly, it was written something as :
20 cm from the teeth, there is a wide erythematous area
Let's process it :
20 cm from the teeth, with this kind of endoscop, we are in the 
oesophagus (not so easy, even for a human being... you must know the size 
of anatomical parts)
The wide erythematous area is our lesion.
It is all right, we have the lesion, and we know where it is ; but 
unfortunately, in the report generator, you have to choose between 
oesophagitis or simple mucosa aspect. So the question is is it an 
oesophagitis ? (well, it is an interesting question anyway when it will be 
time to give some drugs to the patient - the process oriented part of the 
report).

And we had to ask the question to the guy who saw the lesion, since even 
the network of 5 human brains in the room could not guess it.

I perfectly understand Karsten's point about fuziness. But once again, you 
must behave differently in a local/personnal system and in a collective 
process oriented system. You can publish there is still fuzziness 
somewhere, you can't publish fuzzy datas.

Best regards,

Philippe 

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

HISTORY DATA SET IN EPR

[Philippe AMELINE]

Hi,

 From last Picnic meeting in Paris, I mainly remember the confucius 
sentence on a presentation from Ireland : May you live interesting times.

In the field of health information systems we certainly are living 
interesting time since we are those who will allow the move from Office 
keeping + databases to Patient Health Project.

It means several HUGE changes, the main one is to distinguish between the 
local and/or personnal datas (situated in the health professional 
referential) from the continuity of care/health management datas (situated 
in the patient referential).

The management of these 2 referentials means that you now have to manage 
differently (and handle with different tools) the datas with a time 
duration (they may get changed by someone else) and the datas of the 
instantaneous picture kind (it is what YOU noticed and reported at a 
given time).

Lots of work remains ;o)

Philippe AMELINE

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Philippe AMELINE]

Hi,

I must confess I didn't read very carefully each message on this thread ; 
however, I think that I may contribute by explaining the direction we are 
currently following.

First I think we must distinguish between care coordination (inside an 
openEHR node) and continuity of care.
Continuity of care means that you manage to index every  contributions for 
a single patient (these contributions can be openEHR contributions or other 
systems contribution, or even data here and there).

The acces rules must be very different in both cases since :
- inside a node (care coordination) the system belongs to the team and/or 
the careplace (say it is a domain, maybe a meta-domain) and see patients 
passing through (from in to out).
- a continuity of care system necesseraly belongs to the patient (when you 
consider a wide period of time, it is the only stable user) and see medical 
teams passing through.

To adress this change of point of view (from a steady referential to a 
moving referential), we are building a system with the following rules :
- the continuity of care system is an index of existing contributions and 
is granted access rights to the nodes
- inside the continuity of care system, people that may access data are 
given a position inside the patient health team : the position depends on 
the people job (doctor, other health professional, family, social worker) 
and depends on his distance from the patient (usual care giver vs unusual 
one).

Hence the access rights to the contribution are determined for each 
possible position and depends on the current role inside the personal halth 
team at the very moment.

You can like the way we do it or not, however, I don't think you can make 
proper access rights if you don't adress the issue of steady referential 
(care coordination - or groupware) vs moving referential (continuity of 
care - every episod of care for every care team).

Philippe


Hi Thomas,

Thomas Beale wrote:


/snip/

  So. What do we know?
  - role-based access control is required. To make it work properly in a
  shared care community context (e.g. a hospital, 50 GPs, aged care homes,
  nursing care, social workers etc etc) then the roles need to be defined
  congruently. I seem to remember some Canadian project coming to the
  conclusion that really the roles need to be defined the same across the
  entire (national) health care system. I think this is both correct and a
  the same time unrealistic.

With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
correct.  (Pragmatism R Us ;-) )

I'd like to offer food for thought.  The fundamental assumption at work here
seems to be that care givers will access the same system, thus driving the
need for all users of the system to be assigned roles that are defined
congruently.  Let's consider an alternative model.

When I travel from the U.S. to the U.K., I (the physical being) move from
one socio-cultural-legal model to another.  That does not change who / what
I am, but it does change my behavior because I operate under a different set
of norms and mores in the new environment.  I accept new forms of
interaction and find that familiar forms are no longer available.

Why should it be any different for the information about me than it is for
me?

If we work from a perspective that posits that health information will move
from system to system and be used / modified based on the rule sets in place
within the various systems, does that make the problem more amenable to
solution?

  I think we will be able to find ways of
  having diversely defined roles without every health care facility having
  incompatible definitions of consultant, treating physician etc.
  Bernd's work on this area is pretty detailed.

I thank Bernd for opening my eyes to what should have been obvious to me at
a much earlier stage.  The security problem with EHR systems is
fundamentally the same problem faced in OLAP databases.  Or perhaps I should
say that it's the OLAP security problem with a twist.  At least OLAP
databases are typically confined to one environment / business.  It's clear
that the EHR problem is more difficult in that EHR's must, IMO, be capable
of moving between environments.  Perhaps, by requiring a more generalized
solution, the EHR problem will actually be easier to solve.

I don't know if you've checked out Mike Mair's paper but it implicitly poses
a very interesting question.  Is a biologically-based security model
fundamentally better aligned with the needs of an information system about
biological entities than alternative models?  I'm hopeful the list will
have some comments on Mike's paper.  I think the question is worth some
thought / discussion.

/snip/

Best regards,
Bill

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Philippe AMELINE]

Hi Paul, hi the list,

Thanks for your post - I thought nobody took the time to read mine ;o)

I tried to keep my post in the range of openEHR, however, since you are 
pushing me one step further, I need to tell that, from my point of view, 
continuity of care is probably a step to cross, but not the ultimate goal.

Once you agree that the patient is the owner of a system (say the EHR in 
the taxonomy you are proposing), you have to ask yourself : when, why and 
by who shall this system get used ?. If you think that Electronic Health 
Record is the right concept for continuity of care, it is probably because 
you realized that Health doesn't mean no disease, and that even people 
with chronic disease are most often managing their health than they are 
subject of care.

The conclusion we made is that if the system belongs to the patient, it 
must be a tool for the person (and not only the patient). So, this very 
tool must be a he health capital manager. Since the system we are working 
on is problem oriented, and it allows to establish health objectives - and 
not only records, we called it : Individual Health Project.

Now the taxinomy is richer, with three acronyms EMR, EHR and IHP ;o)

Philippe

Philippe,

The approach you have identified makes a lot of sense to me and goes a 
long ways toward clarifying ownership of the record.  I do think it 
would be helpful to develop standard taxonomy for distinguishing the two: 
EMR signifying within a closed health care system, and EHR signifying the 
continuity of care record which is the property of the patient.  It seems 
to me that if this distinction is not made, ownership is going to boil 
down to issues like intellectual property.   The way I see it, ownership 
and access are two, separate, albeit, overlappying issues.  Did I hear 
somebody mention Napster?

  Philippe AMELINE philippe.ameline at nautilus-info.com 04/29/03 
 12:54AM 
Hi,

I must confess I didn't read very carefully each message on this thread ;
however, I think that I may contribute by explaining the direction we are
currently following.

First I think we must distinguish between care coordination (inside an
openEHR node) and continuity of care.
Continuity of care means that you manage to index every contributions for
a single patient (these contributions can be openEHR contributions or other
systems contribution, or even data here and there).

The acces rules must be very different in both cases since :
- inside a node (care coordination) the system belongs to the team and/or
the careplace (say it is a domain, maybe a meta-domain) and see patients
passing through (from in to out).
- a continuity of care system necesseraly belongs to the patient (when you
consider a wide period of time, it is the only stable user) and see medical
teams passing through.

To adress this change of point of view (from a steady referential to a
moving referential), we are building a system with the following rules :
- the continuity of care system is an index of existing contributions and
is granted access rights to the nodes
- inside the continuity of care system, people that may access data are
given a position inside the patient health team : the position depends on
the people job (doctor, other health professional, family, social worker)
and depends on his distance from the patient (usual care giver vs unusual
one).

Hence the access rights to the contribution are determined for each
possible position and depends on the current role inside the personal halth
team at the very moment.

You can like the way we do it or not, however, I don't think you can make
proper access rights if you don't adress the issue of steady referential
(care coordination - or groupware) vs moving referential (continuity of
care - every episod of care for every care team).

Philippe


 Hi Thomas,
 
 Thomas Beale wrote:
 
 
 /snip/
 
   So. What do we know?
   - role-based access control is required. To make it work properly in a
   shared care community context (e.g. a hospital, 50 GPs, aged care homes,
   nursing care, social workers etc etc) then the roles need to be defined
   congruently. I seem to remember some Canadian project coming to the
   conclusion that really the roles need to be defined the same across the
   entire (national) health care system. I think this is both correct and a
   the same time unrealistic.
 
 With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
 correct. (Pragmatism R Us ;-) )
 
 I'd like to offer food for thought. The fundamental assumption at work here
 seems to be that care givers will access the same system, thus driving the
 need for all users of the system to be assigned roles that are defined
 congruently. Let's consider an alternative model.
 
 When I travel from the U.S. to the U.K., I (the physical being) move from
 one socio-cultural-legal model to another. That does not change who / what
 I am, but it does change my behavior because I operate under a different 
 set

Introduction

[Philippe AMELINE]

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

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org