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

[Mikael Nyström]

Hi tom,

I can agree with you that if SNOMED CT was created when all patients in the 
world already had all information in their health record recorded using 
cleverly built and structured information models (like archetypes, templates 
and similar), but that is not the case. Instead SNOMED CT also tries to help 
healthcare organizations to do something better also with their already 
recorded health record information, because that information to a large extent 
still belongs to living patients.

It would be interesting to have your opinion about why it is a real problem 
with the "extra" pre-coordinated concepts in SNOMED CT in general and not only 
for the use case of creating archetypes or what would be nicest in theory.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Thomas Beale
Skickat: den 23 mars 2018 01:06
Till: openehr-technical@lists.openehr.org
Ämne: Re: SV: [Troll] Terminology bindings ... again


I have made some attempts to study the problem in the past, not recently, so I 
don't know how much the content has changed in the last 5 years. Two points 
come to mind:


1. the problem of a profusion of pre-coordinated and post-coordinatable 
concepts during a lexically-based choosing process (which is often just on a 
subset).
 this can be simulated by the lexical search in any of the Snomed search 
engines, as shown in the screen shots below. Now, the returned list is just a 
bag of lexical matches, not a hierarchy. But - it is clear from just the size 
of the list that it would take time to even find the right one - usually there 
are several matches, e.g. 'blood pressure (obs entity)', 'systemic blood 
pressure', 'systolic blood pressure', 'sitting blood pressure', 'stable blood 
pressure' and many more.

I would contend (and have for years) that things like 'sitting blood pressure', 
'stable blood pressure', and 'blood pressure unrecordable' are just wrong as 
atomic concepts, each with a separate argument as to why. I won't go into any 
of them now. Let's assume instead that the lexical search was done on a subset, 
and that only observables and findings (why are there two?) show up, and that 
the user clicks through 'blood pressure (observable entity)', ignoring the 30 
or more other concepts. Then the result is a part of the hierarchy, see the 
final screenshot. I would have a hard time building any ontology-based argument 
for even just this one sub-tree, which breaks basic terminology rules such as 
mutual exclusivity, collective exhaustiveness and so on. How would the user 
choose from this? If they are recording systolic systemic arterial BP, lying, 
do they choose 'systemic blood pressure', 'arterial blood pressure', 'systolic 
blood pressure', 'lying blood pressure', or something else.

Most of these terms are pre-coordinated, and the problem would be solved by 
treating the various factors such as patient position, timing, mathematical 
function (instant, mean, etc), measurement datum type (systolic, pulse, MAP 
etc), subsystem (systemic, central venous etc) and so on as post-coordinatable 
elements that can be attached in specific ways according to the ontological 
description of measuring blood pressure on a body. This is what the blood 
pressure archetype does, and we might argue that since that is the model of 
capturing BP measurements (not an ontological description of course), it is the 
starting point, and in fact the user won't ever have to do the lexical choosing 
above. Now, to achieve the coding that some people say they want, the archetype 
authors would have the job of choosing the appropriate codes to bind to the 
elements of the archetype. In theory it would be possible to construct paths 
and/or expressions in the archetype and bind one of the concepts from the list 
below to each one. To do so we would need to add 40-50 bindings to that 
archetype. But why? To what end? I am unclear just who would ever use any of 
these terms.

The terms that matter are: systemic, systolic/diastolic, terms for body 
location, terms for body position, terms for exertion, terms for mathematical 
function, and so on. These should all be available separately, and be usable in 
combination, preferably via information models like archetypes that put them 
together in the appropriate way to express BP measurement. Actually creating 
post-coordinated terms is not generally useful, beyond something like 'systemic 
arterial systolic BP', or just 'systolic BP' for short, because you are always 
going to treat things like exertion and position separately (which is why these 
are consider 'patient state' in openEHR), and you are usually going to ignore 
things like cuff size and measurement location (things considered as 
non-meaning modifying 'protocol' in openEHR).

2. similar problems in the authoring phase, i.e. addition of concepts to the 
terminology in the first place.  If more 

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

[Mikael Nyström]

Hi Heather,

SNOMED International collaboration site is nowadays located at the address 
https://confluence.ihtsdotools.org/ . (It seems unfortunately that the link is 
more clicks away from the start page than before. :-( ) At that address, you 
can click "Spaces" in the upper left corner of the page and then "Space 
directory". You will then find a long list with the collaboration space for 
different groups and other resources. To my knowledge there aren't any group 
called exactly "information modelling group", but there are several groups that 
work will modelling, so maybe the group has another name? If you only would 
like to read the material, I think that you don't need any account on the site, 
but if you would like to participate a little closer, you can apply for an 
account on the Confluence site.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Heather Leslie
Skickat: den 22 mars 2018 08:01
Till: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Ämne: RE: SV: [Troll] Terminology bindings ... again

HI Michael,

I have no idea what teleconferences are happening. I don't know how to engage. 
It's not easy from the outside!

Heather

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of michael.law...@csiro.au<mailto:michael.law...@csiro.au>
Sent: Thursday, 22 March 2018 11:26 AM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: SV: [Troll] Terminology bindings ... again




Hi Heather,



In general, anyone is welcome to participate in the work; you don't need to be 
one of the small number of Advisory Group members.  That helps with travel 
costs, but most of the real work is done on teleconferences, not so much at the 
face to face meetings.



I would be very interested to hear people's articulations of where they think 
the boundary should be for this boundary line.  I'd also be interested to 
understand better what people think the problem is with having "extra" / 
unnecessary pre-coordinated concepts; what advantage is to be gained from 
removing them, and what is the perceived scale of the problem.



michael


--
Dr Michael Lawley
Research Group Leader, Health Informatics
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Heather Leslie 
<heather.les...@atomicainformatics.com<mailto:heather.les...@atomicainformatics.com>>
Sent: Thursday, 22 March 2018 9:46 AM
To: For openEHR technical discussions
Subject: RE: SV: [Troll] Terminology bindings ... again

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 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Mikael Nyström
Sent: Thursday, 22 March 2018 1:00 AM
To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
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. However, I and several other people that are involved in the 
SNOMED CT  community are quite tired of people that argue that SNOMED CT is bad 
based on inco

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

[Mikael Nyström]

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. However, I and several other people that are involved in the 
SNOMED CT  community are quite tired of people that argue that SNOMED CT is bad 
based on incorrect facts and/or SNOMED CT is bad because it isn’t optimized for 
their narrow use case.

 Regards
 Mikael

Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Thomas Beale
Skickat: den 21 mars 2018 14:17
Till: openehr-technical@lists.openehr.org
Ämne: Re: SV: [Troll] Terminology bindings ... again




Nevertheless, I think it would have been good to move / remove the 
pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable core, 
which would actually look a lot more like Philippe's (much smaller) terminology.

This relates to the old debate on reference v interface terminology, and just 
throwing out precoord concepts is probably not right - they need to be in a 
completely different hierarchy.

The post-coordination grammar in SCT is good, its theoretical challenge is the 
concept meta-model, i.e. what things like 'morphology', 'laterality' you can 
mention, and in what relationship. But this is hard for all of us, and requires 
some serious ontology work (Mikael and other experts know all about this of 
course).

What I would say is this: in a similar way that I think SNOMED should have 
separated out 'SNOMED technology' (representation, APIs etc) from content, I 
think the concept meta-model should have been / could be made a separate 
artefact, maybe even an OBO ontology - at the moment it is too hidden inside 
the giant content artefact. If that were done, we could work more effectively 
on aligning with information / content models, whose attribute names should, 
generally speaking relate to (or be the same as) the meta-model ontology 
entities. If we pursued this line, the ontology would instantly be expanded by 
examination of archetypes, and conversely, many archetypes could be fixed where 
they contain errors or questionable attribute names.

THis isn't to criticise experts or work done in SNOMED per se, but we should be 
perfectly happy to critique SNOMED, as long as that critique is collegial, and 
above all intelligent. (BTW maybe Philippe was not entirely diplomatic, but he 
did implement a very nice post-coordinating terminology and clinical noting 
system, so he knows a thing or two).

So in that sense, I stand by my earlier comments that it would have helped (and 
still would help) if SNOMED International would consider some of my suggestions 
on separation of technology from content, separate the meta-model, and also a 
more serious effort to help connect terminology to information models / content 
models.  We are slowly solving this on our side, but strategic cooperation 
would be better.

One thing is clear: terminology is not a standalone proposition.

- thomas

On 21/03/2018 13:48, Mikael Nyström wrote:

Hi Philippe,



I think that you have missed that SNOMED CT is created for multiple use cases.



Your use case that you describe as "a modern approach" is a good use case that 
I like. In that use case SNOMED CT can be used in the way you describe using 
SNOMED CT's concepts a little higher up in the hierarchies together with SNOMED 
CT Compositional Grammar and SNOMED CT's concept model.



Another use case, that many implementers consider is important but you don't 
seem to care about, is the ability to handle legacy data to be able to keep a 
life-long  health record. Most people alive today where born when simple health 
records that only used simple coding where in massive use. (When that era 
started and (potentially) ended is up to the reader to decide...) To cater for 
information that are more of legacy information, SNOMED CT also has concepts 
that can represent that kind of information. But SNOMED CT also has a machinery 
to transform between the different representations.  Your example "fracture of 

SV: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Philippe,

I think that you have missed that SNOMED CT is created for multiple use cases.

Your use case that you describe as "a modern approach" is a good use case that 
I like. In that use case SNOMED CT can be used in the way you describe using 
SNOMED CT's concepts a little higher up in the hierarchies together with SNOMED 
CT Compositional Grammar and SNOMED CT's concept model.

Another use case, that many implementers consider is important but you don't 
seem to care about, is the ability to handle legacy data to be able to keep a 
life-long  health record. Most people alive today where born when simple health 
records that only used simple coding where in massive use. (When that era 
started and (potentially) ended is up to the reader to decide...) To cater for 
information that are more of legacy information, SNOMED CT also has concepts 
that can represent that kind of information. But SNOMED CT also has a machinery 
to transform between the different representations.  Your example "fracture of 
the left ankle" is not possible to express using a single concept from SNOMED 
CT, but if it had been possible it had been possible to automatically transform 
that concept to the expression below, which seems like to be what you argue for 
in your "modern approach" use case.

64572001 | Disease (disorder) | :
   {  363698007 |Finding site| = 
 {33696004 |Bone structure of ankle (body structure)| : 272741003 
|Laterality| = 7771000 |Left (qualifier value)|}, 
  116676008 |Associated morphology| = 72704001 |Fracture (morphologic 
abnormality)| 
   }

I therefore find your arguments against SNOMED CT equally relevant as arguments 
of the type

"SNOMED CT is useless, because it contains the concepts 285336007 | Background 
radiation (physical force) |, 60638008 | Planetary surface craft, device 
(physical object) | and 242250006 | Crash landing of spacecraft (event) | and I 
don't need that kind of concepts at my clinic."

because the simple solution is to not use what you don't need.

Regards
Mikael


-Ursprungligt meddelande-
Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Philippe Ameline
Skickat: den 15 mars 2018 16:18
Till: openehr-technical@lists.openehr.org
Ämne: Re: [Troll] Terminology bindings ... again

Le 15/03/2018 à 00:34, Mikael Nyström a écrit :

> Hi Philippe
>
> It seems like you are making a big deal of that SNOMED CT is an ancient 
> product, but I would like to see your explicit arguments about that instead 
> of only negative generalizations. From my point of view it is quite modern 
> with an OWL based ontology with additional features for terminology and 
> versioning, which basically is what SNOMED CT are.
>
>   Regards
>   Mikael

Hi Mikael,

The question will always remain "what component do you need at a given 
technological moment?"

If what you want to do is what has been done since 1980, that's to say fill 
forms inside a care place and exchange it with other care places, I guess that 
Snomed CT is the proper component.
Since it was born a coding system, you can create complicated meta-concepts in 
a single code (of course, it means you will have to find your own subset inside 
an always expanding universe, but ease comes with a price) and it is very 
convenient to fill the good old set of attribute–value pairs.

On the contrary, if you estimate that a modern approach would be to tell and 
organize a patient's journey, you have to exhibit more modern structures 
because in order to "tell something", you need not only a terminology (say a 
vocabulary) but also a grammar. A proper grammar (at least the one I use) can 
be a "dependency grammar" in the form of a graph or trees.
Now that you can tell elaborated things using a vocabulary (the
ontology) and a grammar (the graph of trees), the "agglutinating"
structure of Snomed rapidly sucks. Because now that "fracture of the left 
ankle" can be expressed as the branch "fracture" "located at" "left ankle", 
there is no longer a need for the hundred of thousand (and
counting) "codes" that where convenient for ancient systems but are now a 
genuine problem.

Do you imagine a natural language that would be so massively agglutinating that 
it would contain words like "FractureOfTheLeftAnkleThatWasTreatedButStillHurts"?
I guess that, due to a terrible learning curve, the children would speak at six 
;-)

To sum it up, Snomed is probably convenient for application with a structure 
schema that can only handle a coding system (hey, it also comes with a semantic 
network) but is not fit as a formal language vocabulary.

Best,

Philippe



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

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Philippe

It seems like you are making a big deal of that SNOMED CT is an ancient 
product, but I would like to see your explicit arguments about that instead of 
only negative generalizations. From my point of view it is quite modern with an 
OWL based ontology with additional features for terminology and versioning, 
which basically is what SNOMED CT are.

Regards
Mikael


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Philippe Ameline
Sent: den 13 mars 2018 21:54
To: openehr-technical@lists.openehr.org
Subject: Re: [Troll] Terminology bindings ... again

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
___
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

[Mikael Nyström]

Hi Philippe,

If you only would like to use some of the basic concepts as building blocks in 
post-coordinated expressions using for example the SNOMED CT Compositional 
Grammar Specification and Guide (http://snomed.org/scg) and skip the more 
complex/combined concepts you are more than welcome to do so. It is very easy 
to automatically translate between the post-coordinated expressions and the 
more complex concepts if we need to transfer information between information 
systems that uses the two different approaches.

One of the main reasons why the complex concepts are there is that is gives the 
possibility to easily associate the complex concepts with two or more terms 
that describe the concepts, which many implementers and users appreciate very 
much.

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Philippe Ameline
Sent: den 13 mars 2018 17:45
To: openehr-technical@lists.openehr.org
Subject: Re: [Troll] Terminology bindings ... again


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 

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Pablo,

I totally agree with you.

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pablo Pazos
Sent: den 13 mars 2018 19:01
To: For openEHR clinical discussions 
Cc: For openEHR technical discussions 
Subject: Re: [Troll] Terminology bindings ... again

" but in some cases, it is missing concepts"
Shouldn't we contribute?
Is the same as openEHR, there are missing archetypes and we need the community, 
users, clinical modelers and engineers to contribute.

LOINC also misses concepts, and when I asked them how can I contribute, they 
sent me the process and some templates for requesting a new concept to be 
added, pretty simple, formal and open!
IMO we can't expect perfection, is a bad strategy and a move towards isolation. 
I think pragmatism is better and go with "this is the best we can expect for". 
We are the ones that should push towards the ideal, but as a guide not as a 
goal (getting a little philosophical here...).
The same idea applies to tooling, anyone can create tools to manage the 
terminology better. In our own backyard we have tools that need improvement, 
but we accept them because there is no better alternative.


On Tue, Mar 13, 2018 at 11:21 AM, Thomas Beale 
> wrote:



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 terminologies to each other, without particularly favouring any one 
of them. It's just a fact that the world has LOINC, ICDx, ICPC, ICF and 
hundreds of other terminologies that are not going anywhere. What would be 
useful would be to:

  *   classify them according to meta-model type - e.g. multi-hierarchy 
(Snomed); single hierarchy (ICDx, ICPC, ... ); multi-axial (LOINC); units 
(UCUM, ...), etc

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Tom,

I don’t see that your “first killer move” by separating SNOMED CT technology 
from content would make that much sense. The specification and technology you 
are describing in quite many sentences in your e-mail seems to be quite much 
like the EN 14463 Classification Markup Language (ClaML) specification and the 
ecosystem around that specification. However, that specification and the 
associated tools are not that well known or well used, so why would it be a 
“first killer move” to separate SNOMED CT technology from content? If it was a 
killer move someone had already created EN 14463 Association and competed out 
SNOMED CT and SNOMED International …

Instead it seems to be the collaboration and pooling of resources to create, 
extend and improve the common content in SNOMED CT that is possible to share 
among different countries that is the driving force for countries to join 
SNOMED International. The members would like to move away of the situation 
where each country spend large resources to create similar terminology products 
covering the same kind of clinical findings, anatomy, substances and much more. 
Instead they would like to focus on the things that are truly specific for each 
country. However, spending large resources to create similar things in each 
country doesn’t seem to be a problem in your argumentation, Tom?

Your “second killer feature” seems to be the existing SNOMED CT Expression 
Constraint Language - Specification and Guide (http://snomed.org/ecl) and the 
supporting tooling, or do you mean something else?

In your “third killer feature” I don’t really understand what you mean by that 
the translation tools should work on “the basis of legacy vocabulary”. But your 
second claim seems to be that it should be possible to use the tools to only 
translate parts of SNOMED CT and that is a function in all SNOMED CT 
translation tools I have heard of.

I don’t think that anyone would say that IHTSDO Workbench was a success, but 
more as a result of a few quite wrecked IT-projects made under various external 
less than optimal circumstances. To judge an organization’s will from the 
functions of the final IHTSDO Workbench, which you seem to do, is therefore 
quite unfair. (The IHTSDO Workbench was replaced with better adapted software 
quite quickly, so I think nowadays quite few people in the SNOMED International 
community remember the IHTSDO Workbench .)

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 13 mars 2018 15:21
To: openehr-technical@lists.openehr.org; For openEHR clinical discussions 

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




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 

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi,

Of cause it is possible to create something that is easier to use. ICD-10 is a 
good example of something that have similarities with SNOMED CT and is both 
(for some use cases) easier to implement and more widespread. But I if you want 
something that is based on logic, because you want to use logic functions when 
you use the system, it comes with the complexity of logic. And it is not that 
complex to implement SNOMED CT. The problem is probably that we have fewer 
trained people in health informatics (including in for example SNOMED CT and 
openEHR) that in other informatics areas.

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Philippe Ameline
Sent: den 13 mars 2018 13:32
To: openehr-technical@lists.openehr.org
Subject: Re: [Troll] Terminology bindings ... again


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

SV: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi,

Have anybody ever heard about  a health-it-project that hadn't a smaller or 
larger group of sceptic people that try to build momentum against the project? 
:-)

For SNOMED CT the trend at least seems to be that fewer and fewer people 
belongs to the sceptic group, and about half of the European Union member 
countries seems to be member in SNOMED International 
(https://www.snomed.org/members).

Will France as usual be the last country that adopt something that originate 
from Great Britain? :-)

Regards
Mikael


-Ursprungligt meddelande-
Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Philippe Ameline
Skickat: den 12 mars 2018 14:19
Till: openehr-technical@lists.openehr.org
Ämne: [Troll] Terminology bindings ... again

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
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: Terminology bindings ... again

[Mikael Nyström]

Hi,

It depends on what you mean by scope … There is an agreement between SNOMED 
International and Regenstrief Institute to not batch include concepts that 
directly match LOINC codes in SNOMED CT. However, in general SNOMED CT can have 
concepts that represent the same or similar ideas as LOINC codes.

 Regards
 Mikael



Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] För 
GF
Skickat: den 12 mars 2018 08:54
Till: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>
Kopia: Thomas Beale <openehr-technical@lists.openehr.org>
Ämne: Re: Terminology bindings ... again

The scope of LOINC is NOT the same as the scope of SNOMED.

Gerard   Freriks
+31 620347088
  gf...@luna.nl<mailto:gf...@luna.nl>

Kattensingel  20
2801 CA Gouda
the Netherlands


On 12 Mar 2018, at 08:39, Mikael Nyström 
<mikael.nyst...@liu.se<mailto:mikael.nyst...@liu.se>> wrote:

Hi,

I do that too. It seems like more and more people are moving away from the 
position that SNOMED CT is complex and expensive to a position that SNOMED CT 
is manageable and an affordable way of getting rid of local terminologies and 
add value.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Pablo Pazos
Skickat: den 12 mars 2018 08:28
Till: For openEHR clinical discussions 
<openehr-clini...@lists.openehr.org<mailto:openehr-clini...@lists.openehr.org>>
Kopia: Openehr-Technical 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Ämne: Re: Terminology bindings ... again

Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms of 
clinical terminology towards SNOMED CT.

On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström 
<mikael.nyst...@liu.se<mailto:mikael.nyst...@liu.se>> wrote:
Hi,

Yes, it is correct that expressions include single code binding. Those kinds of 
bindings are just the simplest variants of expressions. :-)

I think that in a few years’ time nearly all implementations of SNOMED CT not 
only implement the international version, but also one are a few international, 
national or local extensions, so this use case is probably the normal use case 
and not the exceptional use case.

 Regards
 Mikael
 (Among other things SNOMED CT Implementation 
Advisor)

Från: openEHR-clinical 
[mailto:openehr-clinical-boun...@lists.openehr.org<mailto:openehr-clinical-boun...@lists.openehr.org>]
 För Pablo Pazos
Skickat: den 12 mars 2018 01:39
Till: For openEHR clinical discussions 
<openehr-clini...@lists.openehr.org<mailto:openehr-clini...@lists.openehr.org>>
Kopia: Openehr-Technical 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Ämne: Re: Terminology bindings ... again

Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.
About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.
I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:

term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

 target = <http://snomedct.info/id/169895004> -- Apgar score at 1 
minute

 notes = <"some notes">

  

SV: Terminology bindings ... again

[Mikael Nyström]

Hi,

I do that too. It seems like more and more people are moving away from the 
position that SNOMED CT is complex and expensive to a position that SNOMED CT 
is manageable and an affordable way of getting rid of local terminologies and 
add value.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Pablo Pazos
Skickat: den 12 mars 2018 08:28
Till: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>
Kopia: Openehr-Technical <openehr-technical@lists.openehr.org>
Ämne: Re: Terminology bindings ... again

Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms of 
clinical terminology towards SNOMED CT.

On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström 
<mikael.nyst...@liu.se<mailto:mikael.nyst...@liu.se>> wrote:
Hi,

Yes, it is correct that expressions include single code binding. Those kinds of 
bindings are just the simplest variants of expressions. :-)

I think that in a few years’ time nearly all implementations of SNOMED CT not 
only implement the international version, but also one are a few international, 
national or local extensions, so this use case is probably the normal use case 
and not the exceptional use case.

 Regards
 Mikael
 (Among other things SNOMED CT Implementation 
Advisor)

Från: openEHR-clinical 
[mailto:openehr-clinical-boun...@lists.openehr.org<mailto:openehr-clinical-boun...@lists.openehr.org>]
 För Pablo Pazos
Skickat: den 12 mars 2018 01:39
Till: For openEHR clinical discussions 
<openehr-clini...@lists.openehr.org<mailto:openehr-clini...@lists.openehr.org>>
Kopia: Openehr-Technical 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Ämne: Re: Terminology bindings ... again

Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.
About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.
I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:

term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

 target = <http://snomedct.info/id/169895004> -- Apgar score at 1 
minute

 notes = <"some notes">

 min_version = <"2017-02-01">

 etc = <"etc">

  >

["id26"] = (CONSTRAINT_BINDING) <

   target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">

  min_version = <"2017-04-01">

   notes = <"some notes">

   etc = <"etc">

   >

>

>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint express

SV: Terminology bindings ... again

[Mikael Nyström]

Hi,

Yes, it is correct that expressions include single code binding. Those kinds of 
bindings are just the simplest variants of expressions. :-)

I think that in a few years’ time nearly all implementations of SNOMED CT not 
only implement the international version, but also one are a few international, 
national or local extensions, so this use case is probably the normal use case 
and not the exceptional use case.

 Regards
 Mikael
 (Among other things SNOMED CT Implementation 
Advisor)

Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] För 
Pablo Pazos
Skickat: den 12 mars 2018 01:39
Till: For openEHR clinical discussions 
Kopia: Openehr-Technical 
Ämne: Re: Terminology bindings ... again

Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.
About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.
I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:



term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

 target =  -- Apgar score at 1 
minute

 notes = <"some notes">

 min_version = <"2017-02-01">

 etc = <"etc">

  >

["id26"] = (CONSTRAINT_BINDING) <

   target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">

  min_version = <"2017-04-01">

   notes = <"some notes">

   etc = <"etc">

   >

>

>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.
I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need a better idea of what meta-data 
are needed. E.g.:

  *   something to do with (min) version of terminology required for the 
reference to be valid
  *   something to do with purpose?
  *   other notes - a tagged list of basic types?
I would like to get a better idea of the requirements.

- thomas

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog

___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org



--
Ing. Pablo Pazos Gutiérrez

SV: SV: More generic reference model

[Mikael Nyström]

Hi,

A related activity that might be useful to know is the "RFP for LOINC - SNOMED 
CT Cooperation Project". 
http://www.ihtsdo.org/news-articles/rfp-for-loinc--snomed-ct-cooperation-project
 .

 Regards
 Mikael

Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Bert Verhees
Skickat: den 9 september 2016 08:42
Till: openehr-technical@lists.openehr.org
Ämne: Re: SV: More generic reference model

Op 9-9-2016 om 8:37 schreef Bjørn Næss:
But in addition to that we need to map terms from different other terminologies 
like SNOMED-CT, LOINC and also Disease Ontologies.

There is a mapping effort by IHTSDO en Regenstrief, they started that a few 
years ago, and it will be finished, next year, I think.

http://www.ihtsdo.org/about-ihtsdo/partnerships/loinc
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: More generic reference model

[Mikael Nyström]

Hi,



My more recent impressions from inside the SNOMED CT community are not entirely 
in line with Tom's impression below.



The people that believe that SNOMED CT is on its own are nowadays quite few. My 
impression is that most people understand that SNOMED CT needs to be 
implemented using powerful information models (or data structures) to achieve 
all its benefits. However, the problem is that there are so many information 
models for health records around and some of them are (more or less) 
standardized and some of them are ad hoc and some of them are proprietary so 
there is difficult to interact and engage with all of them.



IHTSDO's primary focus is their member countries (and potential member 
countries) and IHTSDO therefore focus on solving the terminology and ontology 
needs in these countries. In these member countries are SNOMED CT a large part 
of the terminology and ontology solution for the health care system. IHTSDO 
therefore focus on SNOMED CT and collaborations with other terminologies and 
classifications that are well used in the member countries, like ICD and LOINC. 
However, it is understandable that for people in non-member countries it seems 
like IHTSDO assumes that the whole world uses SNOMED CT.



 Regards

 Mikael





Thomas Beale wrote:



Indeed. Ideally we would work more closely with IHTSDO on this (I spent 4 y on 
standing committees there), but I think there is not yet the interest in this. 
There are still people who believe that a) SNOMED CT on its own, with only 
trivial data structures is all that is needed (that's a categorical error of 
thinking) and/or b) that the whole world uses SNOMED CT and that therefore the 
only terminology approach is SNOMED CT (an error today, and I suspect for years 
to come).


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

RE: SNOMED

[Mikael Nyström]

hy'?

The record hierarchy just doesn't belong in SNOMED CT. IAO / OBI maybe.

I would have much less of a problem if the 'use status' of these hierarchies 
was clearer, but as far as I can see, it is not - there is no lifecycle state 
(other than for properly obsoleted terms)...
- thomas
On 29/04/2016 20:20, Mikael Nyström wrote:
Hi Tom,

Most of the concepts in the situation hierarchy had probably been added because 
they have been useful in EHR systems without advanced information models and 
without the possibility to post-coordinate and they are probably still in 
SNOMED CT because some of these EHR systems are still in use. However, if you 
have the possibility to use better EHR systems there are no need to use these 
concepts. I therefore doesn't see any real problem with them.

The concepts in the qualifier value hierarchy are no longer in use to the same 
extent as they were when SNOMED CT was new 2002 and will probably be cleaned up 
in the future.

I agree that the Record artefact hierarchy could be more useful, but I guess 
that this hierarchy to a quite large extent needs to be filled with content on 
the national level, because a quite large part of the administrative concepts 
are country dependant.

However, I believe these kinds of complains about the content in SNOMED CT are 
less useful. It is more like complains about openEHR because there are some 
outdated or draft archetypes of lesser usefulness in the CKM. This kind of 
content is always possible to ignore to use. Much more useful complains would 
be complains about lack of content or incorrect modelled content in areas that 
are central for the healthcare system. These kinds of complains can improve the 
content and make SNOMED CT easier and better to use. Please submit them in the 
SNOMED CT International Request Submission (SIRS) System at the address 
https://sirs.nlm.nih.gov/ .

 Regards
 Mikael


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

RE: SNOMED

[Mikael Nyström]

Hi Ian,

My comments were not directed to you. Sorry. My intention was more to shift 
focus from looking for strange concepts and comment to looking for potential 
improvements and make suggestions about these improvements in general. (And as 
many non-native English speakers I lack some of the nuances in the language.)

 Regards
 Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: den 29 april 2016 23:05
To: For openEHR technical discussions
Subject: Re: SNOMED

Hi Mikael,

I really did not intend my remarks about the 'missing' content in SNOMED-CT to 
be seen as a complaint, or criticism. I fully understand that this, by 
definition, is work in progress and there is a perfectly good change request 
mechanism to have new terms added.

I was only responding to Bert's suggestion that most of the needed terms were 
already there, particularly for 'names' of nodes.

Actually I had thought that 'record artefacts' might be what we use in the 
future to identify archetypes.

I agree with you about 'situation with explicit context' but there was a time 
not so long ago in the UK when this was seen as a key part of fully defining 
clinical content as part of the Logical Record Architecture project.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 29 April 2016 at 21:20, Mikael Nyström 
<mikael.nyst...@liu.se<mailto:mikael.nyst...@liu.se>> wrote:
Hi Tom,

Most of the concepts in the situation hierarchy had probably been added because 
they have been useful in EHR systems without advanced information models and 
without the possibility to post-coordinate and they are probably still in 
SNOMED CT because some of these EHR systems are still in use. However, if you 
have the possibility to use better EHR systems there are no need to use these 
concepts. I therefore doesn’t see any real problem with them.

The concepts in the qualifier value hierarchy are no longer in use to the same 
extent as they were when SNOMED CT was new 2002 and will probably be cleaned up 
in the future.

I agree that the Record artefact hierarchy could be more useful, but I guess 
that this hierarchy to a quite large extent needs to be filled with content on 
the national level, because a quite large part of the administrative concepts 
are country dependant.

However, I believe these kinds of complains about the content in SNOMED CT are 
less useful. It is more like complains about openEHR because there are some 
outdated or draft archetypes of lesser usefulness in the CKM. This kind of 
content is always possible to ignore to use. Much more useful complains would 
be complains about lack of content or incorrect modelled content in areas that 
are central for the healthcare system. These kinds of complains can improve the 
content and make SNOMED CT easier and better to use. Please submit them in the 
SNOMED CT International Request Submission (SIRS) System at the address 
https://sirs.nlm.nih.gov/ .

 Regards
 Mikael


From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 On Behalf Of Thomas Beale
Sent: den 29 april 2016 19:22
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: SNOMED




Hi Mikael,
right... but the usual idea is that these codes would be used in a 
post-coordinated expression. I think most of those expressions are problematic 
as well.

Aside: quite what 'Abuse counselling for non-offending parent (situation)' is 
doing there is another question. Or 'Both parents misuse drugs (situation)'...

But the problem is more widespread than Situation with explicit context.

The 'Qualifier value' hierarchy is also problematic, particularly 'Context 
values', and the 'Temporal context' sub hierarchy. Having all this under 
'Qualifiers' is an information recording view of things, not an ontological 
view. Also terms like 'Current - time specified' don't really make sense.

'Descriptors' - a huge bag of ontologically different things lumped together... 
none of these would be usefully computable as far as I can see, since they are 
not connected to meaningful parents.

Then we have 'Record artifact', also informational in nature, and specifying an 
ad hoc set of headings. I can't see what use this is.


- thomas
On 29/04/2016 16:37, Mikael Nyström wrote:
Hi,

I can just add that those entities Tom mentions below

RE: SNOMED

[Mikael Nyström]

Hi Tom,

Most of the concepts in the situation hierarchy had probably been added because 
they have been useful in EHR systems without advanced information models and 
without the possibility to post-coordinate and they are probably still in 
SNOMED CT because some of these EHR systems are still in use. However, if you 
have the possibility to use better EHR systems there are no need to use these 
concepts. I therefore doesn't see any real problem with them.

The concepts in the qualifier value hierarchy are no longer in use to the same 
extent as they were when SNOMED CT was new 2002 and will probably be cleaned up 
in the future.

I agree that the Record artefact hierarchy could be more useful, but I guess 
that this hierarchy to a quite large extent needs to be filled with content on 
the national level, because a quite large part of the administrative concepts 
are country dependant.

However, I believe these kinds of complains about the content in SNOMED CT are 
less useful. It is more like complains about openEHR because there are some 
outdated or draft archetypes of lesser usefulness in the CKM. This kind of 
content is always possible to ignore to use. Much more useful complains would 
be complains about lack of content or incorrect modelled content in areas that 
are central for the healthcare system. These kinds of complains can improve the 
content and make SNOMED CT easier and better to use. Please submit them in the 
SNOMED CT International Request Submission (SIRS) System at the address 
https://sirs.nlm.nih.gov/ .

 Regards
 Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 29 april 2016 19:22
To: openehr-technical@lists.openehr.org
Subject: Re: SNOMED




Hi Mikael,
right... but the usual idea is that these codes would be used in a 
post-coordinated expression. I think most of those expressions are problematic 
as well.

Aside: quite what 'Abuse counselling for non-offending parent (situation)' is 
doing there is another question. Or 'Both parents misuse drugs (situation)'...

But the problem is more widespread than Situation with explicit context.

The 'Qualifier value' hierarchy is also problematic, particularly 'Context 
values', and the 'Temporal context' sub hierarchy. Having all this under 
'Qualifiers' is an information recording view of things, not an ontological 
view. Also terms like 'Current - time specified' don't really make sense.

'Descriptors' - a huge bag of ontologically different things lumped together... 
none of these would be usefully computable as far as I can see, since they are 
not connected to meaningful parents.

Then we have 'Record artifact', also informational in nature, and specifying an 
ad hoc set of headings. I can't see what use this is.


- thomas
On 29/04/2016 16:37, Mikael Nyström wrote:
Hi,

I can just add that those entities Tom mentions below as

"The waters are muddied further by the attempts to represent informational, 
timing and context-related entities in SNOMED CT."

Are the clearly separated sub-hierarchy called "Situation with explicit 
context" 
(http://browser.ihtsdotools.org/?perspective=full=243796009=en-edition=v20160131=http://browser.ihtsdotools.org/api/snomed=9000509007)
 and that sub-hierarch contains only 1 % of the concepts in SNOMED CT. It is 
therefore no problem to use SNOMED CT without these concepts for those who want 
to do it.

 Regards

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

RE: SNOMED

[Mikael Nyström]

Hi,

I can just add that those entities Tom mentions below as

"The waters are muddied further by the attempts to represent informational, 
timing and context-related entities in SNOMED CT."

Are the clearly separated sub-hierarchy called "Situation with explicit 
context" 
(http://browser.ihtsdotools.org/?perspective=full=243796009=en-edition=v20160131=http://browser.ihtsdotools.org/api/snomed=9000509007)
 and that sub-hierarch contains only 1 % of the concepts in SNOMED CT. It is 
therefore no problem to use SNOMED CT without these concepts for those who want 
to do it.

 Regards
 Mikael



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 29 april 2016 16:43
To: openehr-technical@lists.openehr.org
Subject: Re: SNOMED


Hi Bert
Erik and Ian partly answered this, but it is always worth remembering that 
SNOMED CT, if based on proper ontological principles, contains assertions that 
represent entities in the real world. This means taxonomy (IS-A) and 
properties, qualities, possible relationships and so on (see BFO2 

 for a modern top-level ontology providing these ideas). These are properties, 
qualities and relationships of real things in the real world, i.e. actual 
hearts, cardiac arrests, disease types and so on.

The openEHR RM and derivative archetypes are built to represent information 
'about' these real things. The relationship is often written as 'is-about'. 
There are important differences to be aware of:

  *   what information is written 'about' many things can sometimes resemble a 
description of the thing itself, e.g. parts of a colonoscopy report tend to 
follow anatomical structure of colon and things found in it;
  *   sometimes it relates to a surrogate phenomenon, e.g. an archetype for 
heart rate that actually records pulse; a great deal of clinical observation is 
of surrogates e.g. state of skin, palpation, heart sounds, asking about pain, 
blood glucose etc, but they are actually about something else;
  *   what gets recorded can be what is cheap and painless to record; consider 
that we don't do an echocardiogram every time you want simple BP or heart rate.
  *   what gets recorded about X can be culturally determined; different in 
other ways from 'how X really is' in nature.
  *   most important: most clinical data recordings don't replicate 'textbook' 
relationships found in an ontology, e.g. the fact that there are 5 heart 
Korotkoff sounds at different phases of the cardiac cycle will never be written 
down by a physician, neither will the fact that systolic BP is-a pressure of 
blood in a vessel is-a pressure of fluid in a vessel etc. So if we were to 
generate an information structure from part of an ontology representing the 
heart / CV system, it would generate numerous useless data points and 
relationships on the information side.
How well or how much SNOMED CT follows underlying ontologies like BFO2 or 
Biotoplite or whatever is another question. I am not up to date on the 
progress, but I am fairly sure that most of SNOMED has not been validated 
against these kinds of ontologies. The waters are muddied further by the 
attempts to represent informational, timing and context-related entities in 
SNOMED CT.

Thus, my view is that: in principle, generating information structures straight 
from an ontology (even a perfectly built one) will simply never work, for the 
reasons in the list above; in practice, what you would get from SNOMED CT, 
given its imperfect adherence to ontology would be even harder to understand or 
use.

- thomas
On 29/04/2016 07:50, Bert Verhees wrote:
Hi,

I got an idea when reading the nice story from Heather on LinkedIn. In fact it 
is hers idea, but in a opposing way.
https://www.linkedin.com/pulse/journey-interoperability-part-i-heather-leslie
https://www.linkedin.com/pulse/journey-interoperability-part-ii-heather-leslie

I wonder in how far it is feasible and useful to create archetypes from SNOMED 
concepts, it would be possible to generate them, with attributes and so on.
In a few hours time, one would have a complete forest with archetypes, 
including ontology in more languages.
Maybe some smart handling, filtering, combining can create a better collection, 
also looking at the paths, so that there are similar paths for similar 
situations, to keep the number of different datapoints low, which can help 
creating a faster key-value storage.

I don't know how it is about copyright, with members, and licensing, that 
should be looked at.

The argument that SNOMED is fragmented should not count, I think (however 
without having an expertise on this), 

SV: Any work on PHR?

[Mikael Nyström]

Hi Koray,

We are involved in a project where we are going to integrate information from 
sensors, EHR and PHR and we will use openEHR (and SNOMED CT) for parts of the 
project. Some information can be found at the project website 
http://ecareathome.se/ .

 Regards
 Mikael


Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] För 
Koray Atalag
Skickat: den 7 mars 2016 00:16
Till: For openEHR clinical discussions (openehr-clini...@lists.openehr.org) 
; For openEHR technical discussions 
(openehr-technical@lists.openehr.org) 
Ämne: Any work on PHR?

Hi, are you aware of any openEHR based personal health record project?

The aim would be to capture wellness type of information integrated with  
recent wearable/smart phone based sensor data.
Preferably open source.

Cheers,

-koray

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

RE: Archetype relational mapping - a practical openEHR persistence solution

[Mikael Nyström]

Hi Birger,

It might be this paper you are thinking of.

Freire S, Sundvall E, Karlsson D, Lambrix P. Performance of XML Databases for 
Epidemiological Queries in Archetype-Based EHRs. Scandinavian Conference on 
Health Informatics 2012; October 2-3; Linköping; Sweden. P 51-57. Linköping 
Electronic Conference Proceedings.

http://www.ep.liu.se/ecp/070/009/ecp1270009.pdf
http://www.ep.liu.se/ecp_article/index.en.aspx?issue=070;article=009

 Regards
 Mikael



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Birger Haarbrandt
Sent: den 25 januari 2016 22:57
To: Bert Verhees; For openEHR technical discussions
Subject: Re: Archetype relational mapping - a practical openEHR persistence 
solution


Actually, we use such mappings to promote some "important" elements to 
relational tables to get sort of indices on the data. Otherwise, I don't think 
we would be able to do efficient ad-hoc cross-patient queries directly on the 
database. Exporting data to I2B2 or SSAS would be inconvenient sometimes and 
SQL still has some advantages.

BTW, is there an AQL implementation that is optimized for such "epidemiolocial 
querying"? I think Erik Sundvall mentioned a hadoop-based research project a 
while ago.

Best,

Birger


Bert Verhees > hat am 25. 
Januar 2016 um 18:42 geschrieben:

Another problem is you have to convert your object oriented model (which RM is) 
to a relational model, which becomes complex in converting templates/aql to 
SQL. I have been that way. More then five years ago I left it. It is difficult 
doable, if you want a full featured openehr kernel. I would never recommend 
going this way, unless someone has a really smart idea.

It can work for a light featured openehr light derived application model.

Best regards
Bert
Op 25 jan. 2016 15:26 schreef 
"pazospa...@hotmail.com" 
>:

I talked about this approach with a colleague from China during MEDINFO. The 
problem is your schema grows with your archetypes. Also, that storing data from 
many templates that don't use all the fields in the archetype, will generate 
sparse tables (lots of null columns). I told him it was easier to do an ORM 
from the IM, because the schema doesn't change and allows to store data from 
any archetype/template. But they already have a system working this way.



Sent from my LG Mobile

-- Original message--

From: Ian McNicoll

Date: Mon, Jan 25, 2016 10:06

To: For openEHR technical discussions;

Subject:Archetype relational mapping - a practical openEHR persistence solution
Interesting paper from China

http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

___
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

SV: Archetype publication question - implications for implementers

[Mikael Nyström]

Hi all,

As long as someone in the world performs medical research, our knowledge about 
medicine will increase and change. This imply that changes in our information 
models and ontologies due to new knowledge (and pervious errors) are something 
constant and something every implementer needs to plan for. I therefore think 
that openEHR needs to make it as easy as possible for the implementers to 
implement updates to the archetypes in their systems, but also communicate that 
archetypes will change regularly and that is something the implementers need to 
live with.

To give some perspective, I can mention that during the first releases of 
SNOMED CT, the mechanism for versioning in the release format was quite simple 
and probably not enough helpful for the implementers to manage the regular 
updates. Quite large resources were therefore spent on creating a new release 
format, which is more helpful for implementers when handling updates in SNOMED 
CT, and switch from the old release format (called Release Format 1) to the new 
release format (called Release Format 2). The SNOMED CT license also require 
all implementers to regularly update to new versions of SNOMED CT.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Ian McNicoll
Skickat: den 7 oktober 2015 13:27
Till: For openEHR clinical discussions 
Kopia: For openEHR technical discussions ; 
For openEHR implementation discussions 
Ämne: Re: Archetype publication question - implications for implementers

Hi all,

This is IMO, a very important issue for the openEHR community and many thanks 
to Heather for providing such a clear exposition of the issues and choices, 
faced by any community building products and tools based on open-source 
distribution and governance principles. As such, I do not think these 
challenges are unique to openEHR.

It is particularly important for vendors and implementers, who as well as 
trying build great systems are also building an ecosystem, one of whose 
strengths and sales-points  is the ability to use 'shared components' 
out-of-the-box.

openEHR is well -engineered to support controlled change to new versions of 
artefacts and there is no question that we will regularly have to make such 
changes, even breaking changes as new clinical safety issues or new 
requirements emerge. One can perhaps see this as 'market-driven' change - 
suppliers will say - "we need a new data point", or "the V1 archetype is no 
longer fit-for-purpose, we accept the need for a V2 and will manage the upgrade 
process".

The example Heather has given around the Blood pressure archetype is a good 
example of what we might call 'modeller-driven/best practice change'. Some 
perfectly reasonable issues have been detected in the V1 BP archetype, and 
'best modelling practice/ best semantics' would suggest that we create a V2. 
However, I doubt if there is any real demand for this from the vendor community 
.. very few will be using the Tilt element which contains the error and the 
other issue is more about modelling style- what is there at the moment works ok.

So, in reality, I suspect there are very few drivers to push implementers to 
use V2, and we will end up (for now) with a 'best-practice' V2 and a V1 that 
continues to be used by the vast majority of implementations. One can argue 
that this is how the system is supposed to work .. put the variations out there 
and let the market decide, but new entrants to that market, and existing 
vendors working in multiple national markets will find that they are being 
asked to develop against both V1 and V2.

Again, no-one disputes that this will happen for perfectly good reasons where 
V2 solves some real problems for implementers but I am anxious that we do not 
create unnecessary market confusion, purely to fix some rather obscure, if real 
problems.

Heather quite reasonably asks the question 'Is it the role of the international 
modelling team to take such issues into consideration, or should the CKM 
efforts be purely driven by quality and technical correctness'.

I think it is very important that we get feedback from Industry on this. Please 
give us your input.

Ian









Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 2 October 2015 at 12:46, Sebastian Garde 
>
 wrote:

From a governance point of view, 

RE: Archetype publication question - implications for implementers

[Mikael Nyström]

Hi Ian,

I should probably clarify that the versioning mechanism in SNOMED CT is more 
than a technical thing. The versioning mechanism also includes guidelines about 
how to handle the changes in the receiving system. However, the guidelines are 
distributes in a form that is machine (and human) readable and processable, 
which might at a first look seem just to be a technical thing.

 Regards
 Mikael



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: den 7 oktober 2015 17:22
To: For openEHR clinical discussions
Cc: For openEHR technical discussions; For openEHR implementation discussions
Subject: Re: Archetype publication question - implications for implementers

Hi Vebjørn,

I hope I did not give the impression that I was in any way suggesting that the 
Norwegian clinical reviewers were being obscure or unreasonable and causing 
problems, or that tilt is not used in some applications. The review team have 
done exactly what we ask of them - to point out issues and errors and the 
'iconic' status of BP does not give it any special privileges :).

Just so that people understand this issue - the potentially breaking change in 
the BP archetype is that the unit of measure for the angle of Tilt is defined a 
degree symbol  =  °
which is the printable version of the UCUM unit and not the official UCUM unit 
which is  = DEG or deg.

If the Oslo University Arena implementation was perhaps 10 years down the 
track, with perhaps hundreds of thousands of BP records, including a small 
proportion with Tilt measurements using the ° unit already captured, it would 
be interesting to consider whether the cost of correcting this issue was felt 
to be worthwhile or whether we could 'live with' using the older version.

@Mikael - the capacity to re-version and version is now quite capably built 
into openEHR (and we learnt quite a bit from SNOMED CT experience with 
namespacing). This is really not a technical question and it is always assumed 
that new archetypes ,new revisions and new versions (breaking) will always be 
required and supported.

The question for us as modellers is whether we should take any account of the 
potential downsides of forking an archetype on implementers in our publication 
process or whether we should at least ask ourselves whether the overall 
benefits outweigh the potential disadvantages.

As I said, I don't think this is unique to openEHR, it will apply to any 
formalism which has constraints or dependencies which over time need to be 
adjusted.

Ian






Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 7 October 2015 at 15:12, Vebjørn Arntzen 
> wrote:
Hi

I've not been involved in the revision of the Norwegian Blood pressure 
archetype, so I do not posess any ownership of the changes proposed. They can 
be looked upon as minor, but still they have arised after a review. I know 
personally several of the reviewers, and can assure they are very competent 
clinicians. In that perspective, I'm not happy about some of the comments 
below. Like "Who's using Tilt anyway" and suggestions of the Norwegian 
community to create obscure problems.


1)  Using Tilt: Oslo university hospital is close to implement DIPS Arena 
with the BP archetype. Fairly soon there will be departements that will use 
Tilt. If Tilt was an element not necessary, why is it there in the first place? 
It might not be important for most users, but I have a remembrance of Maximum 
Data Sets.

2)  Obscure problems: Why should not the correct unit be available to the 
users?

3)  Blood pressure as a iconic flag ship: Wouldn't it be great to show the 
world that openEHR is able to update even the "dear baby archetype" when it is 
needed? Even our dearest babies grow up.

Outside our small community, there are a great skepticism towards how openEHR 
will solve versioning of archetypes. It's important that we will not be ruled 
by impractical thoughts like "not invented here", and "doesn't matter for the 
major part of us".


Regards
Vebjørn Arntzen
Enterprise architect, ICT-dept, Oslo universitetssykehus HF
Tlf +47 4143 7589

-
Advarsel: Hvert sekund du lever forkorter livet tilsvarende.
Warning: Every second you live, shortens your life equivalently.

Fra: openEHR-clinical 
[mailto:openehr-clinical-boun...@lists.openehr.org]
 På vegne av Jussara 

SV: openEHR and IHTSDO (SNOMED CT)

[Mikael Nyström]

Hi,

My impression is that IHTSDO prioritize collaboration with organizations with 
products that are actively used in IHTSDO:s member countries. I guess that 
might be the reason why collaboration with for example WHO (ICD, ICF), 
Regenstrief Institute (LOINC) and International Council of Nurses (ICNP) have 
been prioritized in favor of openEHR. Proprietary information models are also 
more common than openEHR models and collaboration with the organizations 
(companies) behind the proprietary information models are probably done via 
IHTSDO's Vendor Liaison Forum.

Regards
Mikael


-Ursprungligt meddelande-
Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] För 
Hardiker Nicholas
Skickat: den 28 september 2015 18:58
Till: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>
Ämne: RE: openEHR and IHTSDO (SNOMED CT)

While the reasons for collaboration may be different, I felt like I should 
report that we have been working very successfully under a collaboration 
agreement between the International Council of Nurses and IHTSDO on the 
development of equivalency tables between the International Classification for 
Nursing Practice (ICNP) and SNOMED CT. I have no reason to doubt the 
possibility a similar arrangement between the openEHR Foundation and IHTSDO. 

With best wishes
 
Nick
 
Nick Hardiker RN PhD FACMI
Professor of Nursing and Health Informatics | Associate Dean (Research & 
Innovation) School of Nursing, Midwifery, Social Work & Social Sciences MS1.12, 
Mary Seacole Building, University of Salford, Salford  M6 6PU
t: +44 (0) 161 295 7013
n.r.hardi...@salford.ac.uk | www.salford.ac.uk 
www.seek.salford.ac.uk/profiles/HARDIKER514.jsp
 
Director, eHealth Programme, International Council of Nurses Professor 
(Adjunct), College of Nursing, University of Colorado Denver, USA 
Editor-in-Chief, Informatics for Health and Social Care
 



-Original Message-
From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Mikael Nyström
Sent: 27 September 2015 17:08
To: For openEHR clinical discussions; Openehr-Technical
Subject: RE: openEHR and IHTSDO (SNOMED CT)

Hi Tom,

I found the responsible person at IHTSDO for the collaboration with openEHR 
Foundation. According to her, there are active discussions to be able to soon 
sign a collaborative agreement between IHTSDO and openEHR and then continue to 
work with how SNOMED CT and openEHR artefacts practically can be used together.

IHTSDO also states over and over again that SNOMED CT needs to be implemented 
together with good information models to reach its full potential and IHTSDO 
hosted (at least) the CIMI autumn meeting in Amsterdam last year. I therefore 
don't understand your very negative attitude towards IHTSDO collaboration Tom.

Regards
Mikael


-Original Message-
From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 26 september 2015 06:36
To: openehr-clini...@lists.openehr.org; Openehr-Technical
Subject: Re: openEHR and IHTSDO (SNOMED CT)


A number of approaches have been made in the recent past by openEHR and CIMI, 
led by Dr stan Huff. The outcome is that IHTSDO do not appear to be currently 
interested in a formal working relationship with the content modelling 
communities (openEHR, Intermountain Healthcare, CIMI, ISO 13606, ...).

I personally don't understand why, but this is the line they are taking. 
I'm not aware of any new plans.

None of this precludes openEHR actively using IHTSDO-issued standards and 
specifications, which we do. ADL / AOM 2 and tooling has now been converted to 
using IHTSDO concept referencing URIs for example.

- thomas

On 25/09/2015 18:26, Mikael Nyström wrote:
> Hi,
>
> I wonder if there are any current collaborations or collaboration 
> plans between openEHR Foundation and IHTSDO (which is the organisation 
> that owns and maintains SNOMED CT.)
>
>   Regards
>   Mikael
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.opene
> hr.org
>


___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.op

RE: openEHR and IHTSDO (SNOMED CT)

[Mikael Nyström]

Hi Tom,

I found the responsible person at IHTSDO for the collaboration with openEHR 
Foundation. According to her, there are active discussions to be able to soon 
sign a collaborative agreement between IHTSDO and openEHR and then continue to 
work with how SNOMED CT and openEHR artefacts practically can be used together.

IHTSDO also states over and over again that SNOMED CT needs to be implemented 
together with good information models to reach its full potential and IHTSDO 
hosted (at least) the CIMI autumn meeting in Amsterdam last year. I therefore 
don't understand your very negative attitude towards IHTSDO collaboration Tom.

Regards
Mikael


-Original Message-
From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 26 september 2015 06:36
To: openehr-clini...@lists.openehr.org; Openehr-Technical
Subject: Re: openEHR and IHTSDO (SNOMED CT)


A number of approaches have been made in the recent past by openEHR and CIMI, 
led by Dr stan Huff. The outcome is that IHTSDO do not appear to be currently 
interested in a formal working relationship with the content modelling 
communities (openEHR, Intermountain Healthcare, CIMI, ISO 13606, ...).

I personally don't understand why, but this is the line they are taking. 
I'm not aware of any new plans.

None of this precludes openEHR actively using IHTSDO-issued standards and 
specifications, which we do. ADL / AOM 2 and tooling has now been converted to 
using IHTSDO concept referencing URIs for example.

- thomas

On 25/09/2015 18:26, Mikael Nyström wrote:
> Hi,
>
> I wonder if there are any current collaborations or collaboration 
> plans between openEHR Foundation and IHTSDO (which is the organisation 
> that owns and maintains SNOMED CT.)
>
>   Regards
>   Mikael
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.opene
> hr.org
>


___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

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

openEHR and IHTSDO (SNOMED CT)

[Mikael Nyström]

Hi,

I wonder if there are any current collaborations or collaboration plans between 
openEHR Foundation and IHTSDO (which is the organisation that owns and 
maintains SNOMED CT.)

Regards
Mikael

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

[openEHR-announce] roadmap 2014 meeting streaming

[Mikael Nyström]

Hi Tom,

It sounds that HL7 Brazil uses Adobe Connect, 
http://www.adobe.com/products/adobeconnect.html . It is at least the software 
the universities in Sweden uses for online meetings and some online teaching 
and I think that it works quite well.

 Regards
 Mikael

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 21 september 2014 10:55
To: For openEHR technical discussions
Subject: Re: [openEHR-announce] roadmap 2014 meeting streaming


Hi Bert,

DIPS, who provided the meeting venue and catering had to change the location a 
few days earlier to one outside of their offices, in a town called Lillestrom, 
near Oslo. So we were in a culture centre with its own wifi etc, not under DIPS 
control, and the best we could manage collectively was using their office Lync 
from one of their computers. We also had no real control over mics and sound. 
We didn't do Skype because we wanted video as well.

In the future we will need to use something that works universally, and be more 
prepared. Two suggestions I had from people were:

Roger Erens: Ericom Cloud Internet Explorer for Chrome could be of use on Mac 
or Linux.

Jussara: vydio app

I don't know much about this technology, so if someone has a proposal for the 
next meeting, let us know. My preference for how it should work is how HL7 
Brazil does its online courses - they use some Adobe platform, and broadcast is 
voice + slides and/or webcam, moderators have voice and video, and the main 
audience asks questions and comments via a chat panel. It's all integrated. 
This costs money obviously, but functionally I think it's very good.

Anyway, we're doing our best to get all the outcomes documented, and we may yet 
get the recorded files up online.

- thomas

On 17/09/2014 00:20, Bert Verhees wrote:
It didn't work on Linux, though the opening screen was confusing. It wouldn't 
work, it said, but still it invited to fill in my name. I did, and it didn't 
work.

Just for fun, I looked at the supported platforms, first the 128 versions of 
Windows, and in the end was Macintosh. I never heard about that OS. But Linux 
was not on the list. You can see which platform they hate most. It is because. 
reason we all know. Microsoft hates open. It hates interoperability.

But in the meantime, my whole Eco-system is running on Linux, my databases, my 
Tomcat, my Eclipse, my Oxygen, my github, my five consoles which remember the 
git-commands I do ten times a day. Everything stable and fine.

I cannot go to another platform to watch a meeting. I am really sorry for that.

Suggestions about what to use? I guess you considered Google. I used it a few 
times. Or Skype, works also fine.

I hope someone has an idea. But, please, never again Mixrosoft, that is asking 
for trouble.


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140922/d1d0790d/attachment-0001.html

New ADL/AOM proposals to solve some old problems

[Mikael Nyström]

Hi Tom,

That sounds really nice.

 Regards
 Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 29 april 2013 12:33
To: openehr-technical at lists.openehr.org
Subject: Re: New ADL/AOM proposals to solve some old problems

On 29/04/2013 09:01, Mikael Nystr?m wrote:
Hi Tom,

Is the intention that the new data type TERMINOLOGY_CODE also can contain a 
post-coordinated code so it, for example, can contain a expression in SNOMED CT 
compositional grammar? (See 
www.snomed.org/tig?t=rfg_expression_scghttp://www.snomed.org/tig?t=rfg_expression_scg
 for more details about SNOMED CT compositional grammar.)

yes exactly. Technically I suppose it should be called TERMINOLOGY_CODE_PHRASE 
or TERMINOLOGY_CODE_STRING or something like that. It's the same idea as the 
openEHR CODE_PHRASE, the point here is to have an AOM type that is minimal, and 
just can represent a basic constrainable terminology code idea, and be easily 
mapped to actual RMs.

- thomas
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130429/fd552c9f/attachment.html

constraint binding error

[Mikael Nyström]

Hi Thomas,

I would disagree that the version of ICD-10 is 10. Even terminology systems 
like ICD-10 are revised (for example in Sweden once a year) and released in 
different releases. I therefore think that is fair to handle ICD-9 and ICD-10 
as different systems in the same way as SNOMED RT and SNOMED CT are.

 Greetings,
 Mikael



From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: den 21 februari 2011 12:36
To: openehr-technical at openehr.org
Subject: Re: constraint binding error

On 21/02/2011 04:14, pablo pazos wrote:
Hi Michael,

Not every terminology version is a date. In ICD 10, the version is 10. I 
think the version to be a valid date is not a problem here.
most people consider ICD10 as simply a different terminology from ICD9. There 
are variants like ICD10AM, ICD9CM and so on... and in theory, there are no 
'versions' of these terminologies, at least as far as I know - WHO issues once 
and that's it (not sure about the AM and CM releases though).

- thomas
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/5668713b/attachment.html

openEHR and iPhone/iPad anyone?

[Mikael Nyström]

Hello,

It is two separate projects. The project I describe is a research and
education project performed by Erik Sundvall, Martin Eneling, Marie
Sandstr?m, Rong Chen, H?kan ?rman, Daniel Karlsson and myself at Department
of Biomedical Engineering at Link?ping University in Sweden. Erik will
probably send out some more information about the project soon.

Greetings,
Mikael


-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Tomas
Sn?ckerstr?m
Sent: den 6 oktober 2010 17:03
To: For openEHR technical discussions
Subject: RE: openEHR and iPhone/iPad anyone?

No offence but I prefer not to top-post. Specially considering this
thread is moving a bit OT.

Please comment below.



ons 2010-10-06 klockan 11:24 +0200 skrev Mikael Nystr?m:
 Hello,
 
 It is correct that we in Link?ping currently work on an implementation of
 openEHR using the REST approach. The implementation will be open source
when
 the implementation is ready. (In fact Erik and Marie are currently
 discussing the latest commit to the project just outside my office door!)

I'm not familliar with what Mikael is involved in but I can tell that at
least the major integration project IFK2 is heavily inspired by the
REST philosophy.

The project adresses the possibility to integrate care documentation
applications (i.e. the journal) with quality-metrics systems. (In Sweden
there are several national wide registers dedicated to QA for certain
care processes) 

For several reasons we developed a model where we separate the semantics
of the content from the model of the communication. Essentially we want
an interaction model that is dependent on the operations in the register
rather than the semantics of the domain objects.

Access is going to be governed via a SAML-ticket architecture against a
large user and service directory and services are accessed through a
MULE based service bus. The registers develop and publish changes to
their data requests on a regular basis. Hence it is nessecary to
decouple the services provided by the registers from the data requested
by the service.

For other reasons, we use a normal SOA architecture but, essentially
there are only operations defined for normal CRUD actions. One might
have the right to read but not write, create but not modify, et.c.

The semantics of the content is then packed to an (unpractically large)
CLOB wich is marshalled and validated on the end node.

This way, templates can be updated w/o the need to redefine the
services.

Project is being delivered for evaluation but there are some tecnical
conclusions being written for intended publication by the end of the
year.

Very REST, but a bit Off Topic in the dicussion on how I am to
professionally motivate my employer to purchase me an iPad... ;-)

Regards
Tomas

/.../



___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

IHTSDO meeting - term binding presentation available

[Mikael Nyström]

Hi,

I can add that the workflows are possible to customize, so it is up to each
user (or the organization the user works for) to create and/or select the
workflows to use.

Greetings,
Mikael


-Original Message-
From: openehr-technical-boun...@chime.ucl.ac.uk
[mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of
Michael.Lawley at csiro.au
Sent: den 6 maj 2010 22:53
To: openehr-technical at chime.ucl.ac.uk
Cc: openehr-clinical at openehr.org; openehr-clinical at chime.ucl.ac.uk;
openehr-technical at openehr.org
Subject: RE: IHTSDO meeting - term binding presentation available


Yes, the workflow stuff is just a tool feature.  The RF2 spec is merely a
file format and the spec has nothing to say about how such files may/should
be generated.

Regarding the clinical metadata elements you mention, these are not defined
as part of RF2, but it should be possible to represent them using RF2 as it
was designed to be an extensible format.

michael


Dr Michael Lawley
Principal Research Scientist
The Australia e-Health Research Centre http://aehrc.com/
+61 7 3253 3609; 0432 832 067


From: openehr-technical-boun...@chime.ucl.ac.uk
[openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Ian McNicoll
[Ian.McNicoll at oceaninformatics.com]
Sent: Thursday, 6 May 2010 11:16 PM
To: For openEHR technical discussions
Cc: openehr-clinical at openehr.org; openehr-clinical at chime.ucl.ac.uk;
openehr-technical at openehr.org
Subject: Re: IHTSDO meeting - term binding presentation available

Thanks Michael,

Can I ask if the workflow/process elements of the Workbench are regarded as
separate from the Refset 2 specifications, or within other offical IHTSDO
specs? Or is this just intended as a local feature of the workbench?

Although the Refset2 sepcifications define a greate deal of 'metadata', as
far as I can tell , other than Refset name, this is almost wholly technical
in nature and clinical metadata elements e.g use, misuse, purpose, authoring
details are not defined - is this correct?

Ian

Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.commailto:ian.mcnicoll at 
oceaninformatics.com
ian at mcmi.co.ukmailto:ian at mcmi.co.uk

Clinical Analyst  Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.orghttp://www.phcsg.org
/ BCS Health Scotland



On 6 May 2010 13:22, Michael.Lawley at csiro.au wrote:

I would add to Eric's point 3 that (based on the content of an IHTSDO
webinar) the workflow/process implemented in the IHTSDO workbench involves
an explicit manual approval step for every item in the generated static
refset.  I don't know how/if there is any special support for dealing with
re-generating the refset based on a new SNOMED release or a modified set of
specification queries.

m


Dr Michael Lawley
Principal Research Scientist
The Australia e-Health Research Centre http://aehrc.com/
+61 7 3253 3609; 0432 832 067


From:
openehr-technical-bounces at chime.ucl.ac.ukmailto:openehr-technical-bounces 
at c
hime.ucl.ac.uk
[openehr-technical-bounces at chime.ucl.ac.ukmailto:openehr-technical-bounces@
chime.ucl.ac.uk] On Behalf Of Eric Browne
[eric.browne at montagesystems.com.aumailto:eric.browne at 
montagesystems.com.au
]
Sent: Thursday, 6 May 2010 9:20 PM
To: For openEHR clinical discussions
Cc: For openEHR clinical discussions; Openehr-Technical
Subject: Re: IHTSDO meeting - term binding presentation available

Hi Sebastian,

If I can give my own perspective on this, having been peripherally involved
for some time..

1. Unfortunately, the IHTSDO (www.ihtsdo.orghttp://www.ihtsdo.org), who is
responsible for the ongoing management and development of SNOMED CT, is
still a somewhat closed and traditional standards development organisation.
It has no publicly accessible wiki of resources ? la openEHR. It does,
however, have a substantial community of individuals from member countries
and affiliate organisations and several collaborative websites and mailing
lists where ideas, contributions, new specifications etc. are documented and
evolve. I would guess that the majority of participants are either active in
other standards development organisations, or staff/affiliates of member
nation health informatics programs such as the UK's NHS Connecting for
Health Program, Canada's Infoway, Australia's National E-Health Transition
Authority, etc.

2. For many years prior to IHTSDO taking over SNOMED CT from the College of
American Pathologists, SNOMED CT embraced a mechanism and format for
producing subsets of SNOMED CT. About 18 months ago, proposals for a new
SNOMED release format and a new Reference Set format (to replace the old
subset mechanism) emerged and evolved. These two proposals morphed into a
single umbrella specification called Release Format 2, which has now 

IHTSDO meeting - term binding presentation available

[Mikael Nyström]

Hi All,

As written below most of IHTSDO:s activities are currently performed inside
IHTSDO:s Collaborative space (also known as Basecamp). This
Collaborative space is a legacy system from before IHTSDO acquired SNOMED?CT
and probably not the best system due to the current needs, but the system is
still there because of lack of time to change system. However, there are now
ongoing discussions and there seems to be a new project initiated to
supplement or replace the current Collaborative space to make it easier for
people outside IHTSDO:s groups to get information and share resources.

More information about how to get access to the Collaborative space is, as
written below, available at
http://www.ihtsdo.org/about-ihtsdo/collaborative-space/. The currently
existing Special Interest Groups at the Collaborative space are:

Anesthesia Special Interest Group
Concept Model Special Interest Group
Education Special Interest Group
Implementation SIG
International Pathology  Laboratory Medicine SIG
Machine  Human Readable Concept Model Project
Mapping SNOMED CT to ICD-10 Project
Nursing Special Interest Group
Pharmacy Special Interest Group
Primary Care Special Interest Group
Translation Special Interest Group

And the currently existing project groups are:

Anatomy Model Project
Collaborative Editing Project Group
Enhanced Release Format, Interchange Format  RefSet PG
Event, Condition and Episode Model Project
Workbench RefSet Module Project
Observable and Investigation Model Project
Organism  Infectious Disease Model Project
Pre-coordination Roadmap Project
Request Submission Project
Substance Hierarchy Redesign Project
Translation Standard Processes Project

There are also a affiliate forum.

Greetings,
Mikael


-Original Message-
From: openehr-clinical-boun...@chime.ucl.ac.uk
[mailto:openehr-clinical-bounces at chime.ucl.ac.uk] On Behalf Of Eric Browne
Sent: den 6 maj 2010 13:20
To: For openEHR clinical discussions
Cc: For openEHR clinical discussions; Openehr-Technical
Subject: Re: IHTSDO meeting - term binding presentation available

Hi Sebastian, 

If I can give my own perspective on this, having been peripherally involved
for some time..

1. Unfortunately, the IHTSDO (www.ihtsdo.org), who is responsible for the
ongoing management and development of SNOMED CT, is still a somewhat closed
and traditional standards development organisation. It has no publicly
accessible wiki of resources ? la openEHR. It does, however, have a
substantial community of individuals from member countries and affiliate
organisations and several collaborative websites and mailing lists where
ideas, contributions, new specifications etc. are documented and evolve. I
would guess that the majority of participants are either active in other
standards development organisations, or staff/affiliates of member nation
health informatics programs such as the UK's NHS Connecting for Health
Program, Canada's Infoway, Australia's National E-Health Transition
Authority, etc.

2. For many years prior to IHTSDO taking over SNOMED CT from the College of
American Pathologists, SNOMED CT embraced a mechanism and format for
producing subsets of SNOMED CT. About 18 months ago, proposals for a new
SNOMED release format and a new Reference Set format (to replace the old
subset mechanism) emerged and evolved. These two proposals morphed into a
single umbrella specification called Release Format 2, which has now reached
Draft for Trial Use status within the IHTSDO. One of the specification
documents covers Reference Set formats and is available in part 2 of RF2 at:
http://www.ihtsdo.org/publications/draft-for-review-and-trial-use/ .  This
draft specification includes support for language refsets, which may be of
particular interest to you. Access to the collaborative space where these
documents are made available is described at:
http://www.ihtsdo.org/about-ihtsdo/collaborative-space/ .

3. To my knowledge there is no formal IHTSDO proposal for a query language
to express Refset membership specifications. However, the IHTSDO Terminology
Workbench does incorporate quite a sophisticated mechanism for building
refsets using an underlying ( and evolving) query-based expression language.
Note: these refsets do not necessarily need to be specific to SNOMED. The
refset specifications, however, are currently designed to  construct  static
files for distribution alongside the SNOMED core and national extension
files, rather than for producing dynamically evaluated termsets for  local
needs, as might be supported for openEHR templates, say.

eric


On 2010-05-06, at 5:48 PM, Sebastian Garde wrote:

 Hi Thomas,
 
 do you know if there is a formal way of how RefSets (=the resulting Snomed
CT codes etc.) and the RefSet query (=the query on Snomed CT to get to the
RefSet) are expressed and shared?
 Similar to what is described here but based on RefSets:
http://www.openehr.org/wiki/display/term/Ocean+Terminology+Query+Language+%2
8TQL%29 
 
 I 

SNOMED CT RF2 ref sets - UML and meta-data diagrams

[Mikael Nyström]

Hi Thomas,

 

Since January 2010 is the status ?Limited? is handled as an inactive value.
(See SNOMED CT Technical Reference Guide Appendix B.)

 

 Greetings,

 Mikael

 

 

From: openehr-technical-boun...@chime.ucl.ac.uk
[mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Thomas Beale
Sent: den 16 mars 2010 17:02
To: Openehr-Technical
Subject: SNOMED CT RF2  ref sets - UML and meta-data diagrams

 


As part of reviewing SNOMED CT Release Format 2 (RF2) and Reference Sets
specifications, I have created some diagrams which are available here:
http://www.openehr.org/wiki/pages/viewpageattachments.action?pageId=10387459

So far I have a class diagram, and semantic net diagrams of the SNOMED
meta-data hierarchy. The latter is really a meta-model hierarchy, used to
define the model of other parts of Snomed.

I am still refining the original .vsd, but it is available if anyone wants
it.

- thomas beale

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100317/f379251d/attachment.html

Term bindings in archetypes and templates

[Mikael Nyström]

Thomas Beale wrote:

 On 10/03/2010 22:16, Mikael Nystr?m wrote: 

 I belong to a group that, except for openEHR related research, also do
 research about terminology systems and terminology systems mapping.
 During mapping from one terminology system to another terminology
 system is it quite common to be unable to map properly, because the two
 terminology systems have divided the domain in different ways. This
 problem appears even when mapping to SNOMED?CT, which have a broad
 coverage and a concept model allowing a broad set of relationships. My
 view is that the same problem will appear when finalized archetypes are
 bound to existing terminology systems.

 it will certainly appear. The question is: for those archetype nodes that
 it is useful to bind to terminology (likely to be 10% or less), how close
 is the match? For example, in labs, it should be nearly spot on. For
 anatomy, it should be pretty close. For diseases, the disease concept in
 an archetype will assume that it is coded in the first place by
 terminology, so the only problem there is mapping problems from ICD to SCT
 etc. I think we need to look at the actual size of the concrete problem,
 not its theoretical worst case.

I agree that we have to wait and see how much problems we will get. That was
also my reason to reply to Sebastian's e-mail which told that there is no
problem to add terminology bindings after the archetypes are finalized.

However, I didn't refer to theoretical worst case. I referred to actual
problems that have appeared for us during both our research work and in our
national SNOMED?CT project in Sweden.

Greetings,
Mikael

Term bindings in archetypes and templates

[Mikael Nyström]

Sebastian Garde wrote:

Hi,

 2) Another question is in relation to templates. If a significant
 number of term bindings happen at the template rather than Archetype
 level, are term bindings in Archetypes optional and open to further
 constraint even after an archetype is released in CKM?
  
 Term bindings can certainly added after the content of an archetype
 is published in CKM - no problem and exactly what we intend to do.
 Where possible, simple term bindings should be at archetype level,
 but terminology subsets you would probably rather expect on template
 level.
 Ian or Thomas may want to add (or contradict me ;-) )

I should probably add that there exist different views in the openEHR
community about how easy it is to add terminology bindings to already
modelled archetypes.

I belong to a group that, except for openEHR related research, also do
research about terminology systems and terminology systems mapping. During
mapping from one terminology system to another terminology system is it
quite common to be unable to map properly, because the two terminology
systems have divided the domain in different ways. This problem appears even
when mapping to SNOMED?CT, which have a broad coverage and a concept model
allowing a broad set of relationships. My view is that the same problem will
appear when finalized archetypes are bound to existing terminology systems.

Greetings,
Mikael

informal poll: openEHR conference

[Mikael Nyström]

Hi,

 

We from Link?ping University are preliminary interested.

 

 Greetings,

 Mikael

 

 

From: openehr-technical-boun...@chime.ucl.ac.uk
[mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Thomas Beale
Sent: den 27 november 2009 17:25
To: Openehr-Technical; For openEHR clinical discussions
Subject: informal poll: openEHR conference

 


This is an initial informal question to the community about interest in an
openEHR conference / meeting, probably initially located in Europe. Possibly
activities:

*   presentations / papers on commercial  academic projects
*   technical working design sessions for major upcoming specifications
*   clinical modelling design sessions / presentations / discussions /
debates
*   meetings aimed at making decisions about the running  governance of
openEHR, enabling future organisational improvement
*   professional and academic networking activities
*   some purely social activities.

purely as an example of a nice location at which social and outdoor
activities can take place, Lake Bled in Slovenia has been suggested, of
course there are many other wonderful locations. I have heard many requests
for a conference over the last few years, so I wonder what the reaction 
interest of the community to this suggestion would be.

- thomas beale



-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091130/7ed4d777/attachment.html

informal poll: openEHR conference

[Mikael Nyström]

I guess that the social activities would be quite important for the
community and they are hard to organize on airports and train stations. I
therefore vote for other locations than airports and train stations.

 

  Greetings,

  Mikael

 

 

From: openehr-technical-boun...@chime.ucl.ac.uk
[mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Bert Verhees
Sent: den 27 november 2009 17:38
To: openehr-technical at openehr.org
Subject: Re: informal poll: openEHR conference

 

An international airport/train station nearby would be good, it saves days
of traveling.

Bert

Op 27-11-09 17:25, Thomas Beale schreef: 


This is an initial informal question to the community about interest in an
openEHR conference / meeting, probably initially located in Europe. Possibly
activities:

*   presentations / papers on commercial  academic projects
*   technical working design sessions for major upcoming specifications
*   clinical modelling design sessions / presentations / discussions /
debates
*   meetings aimed at making decisions about the running  governance of
openEHR, enabling future organisational improvement
*   professional and academic networking activities
*   some purely social activities.

purely as an example of a nice location at which social and outdoor
activities can take place, Lake Bled in Slovenia has been suggested, of
course there are many other wonderful locations. I have heard many requests
for a conference over the last few years, so I wonder what the reaction 
interest of the community to this suggestion would be.

- thomas beale





 
 
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
  

 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091127/f3b05807/attachment.html

Improving Translation_details and other_contributors ?

[Mikael Nyström]

Dear Carol,
 
I agree that we need to be able to support both approaches and my proposal
is formed to support both approaches.
 
However, I do not agree that the national translation approach will take
forever in all countries. For example it would not surprise me if Swedish
Association of Local Authorities and Regions (Sveriges Kommuner och
Landsting) or Swedish National Board of Health and Welfare (Socialstyrelsen)
sooner than later make official Swedish translations of essential
archetypes.
 
Regards,
Mikael
 

  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Dra Carola
Hullin Lucay Cossio
Sent: den 23 juni 2009 21:58
To: For openEHR technical discussions
Subject: RE: Improving Translation_details and other_contributors ?
Importance: High


Dear All,

I do agree with a more national or collective approach, however, these
initiatives take longer to adopt among the right people due to the lack of
understanding from authorities at that level about clinical concepts. They
see clinical models as part of a simple health business or another workflow
within healthcare. 

Consequently, for this type of work and the time frame required for
archetypes, both approaches are acceptable but they must have the both
options, since the later ( National or accreditation approach) may take for
ever. Politicians and government authorities may not see this as a priority
for information systems design or development.



Sincerely, Carol

Dr Hullin
Senior Business Analysts
HeatlhSmart Initiative 
Office of Information Systems
Department of Human Services
Victoria Australia








  _  

From: mi...@imt.liu.se
To: openehr-technical at openehr.org
Subject: RE: Improving Translation_details and other_contributors ?
Date: Tue, 23 Jun 2009 11:39:16 +0200



Dear Sebastian,

 

Translations of medical (health) archetypes have parts in common with
translations of medical (health) terminology systems.

 

One example of translation projects of medical terminology systems is the
Swedish SNOMED CT translation project. The project is approximately halfway
of the translation of all active descriptions of the type ?preferred term?
from English to Swedish. The number of descriptions the project has to
translate is around 300,000.

 

In this project is normally each description translated by one translator.
The translation is then first inspected by one other translator and then
inspected by a translation editorial office. The translation is then
verified by relevant health care personnel.

 

As far as I know will the translated descriptions be marked as part of the
Swedish National Board of Health and Welfare?s official translation of
SNOMED CT. However, the names of the people involved in the translation and
which organisations they belong to will only be known inside the translation
project. It seems also to be the same case for other translations of
terminology system into Swedish.

 

I therefore think that in some cases are the accreditation association much
more important than the name and demographic information about the
translators.

 

I therefore think that a more proper model is

 


accreditation : String 

0..1 

-- 

 

Accreditation of translator, usually a national translator?s association id 


translation_contributors :
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700091
70_630396_833Report.html HashString,String,String 

0..1 

-- 

 

Role, name and other demographic details for contributors in the translation
process 

 

Regards,

Mikael

 


  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde
Sent: den 23 juni 2009 10:25
To: For openEHR technical discussions
Subject: Improving Translation_details and other_contributors ?


Dear all,

Ian, Heather and I have raised an issue at
http://www.openehr.org/issues/browse/SPECPR-24 for improving the
Translation_details and other_contributors.

What seems to be current practice is that a translation will be done by more
than one person and documenting this is not really supported by the model:

TRANSLATION_DETAILS 

accreditation : String
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11095841383
49_959314_1900Report.html   1   --  Accreditation of
translator, usually a national translator?s association id  
author : Hash
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700091
70_630396_833Report.html String,String1   --
Translator name and other demographic details   

Only one translator is available.
The easiest change would be to make author repeatable, but accreditation
(which seems to be somewhat detached from the author anyway) would need to
be changed then as well - is accreditation that important that it couldn't
be captured as part of the author Hash or what is the reason for having it

Improving Translation_details and other_contributors ?

[Mikael Nyström]

Dear Sebastian,

 

Translations of medical (health) archetypes have parts in common with
translations of medical (health) terminology systems.

 

One example of translation projects of medical terminology systems is the
Swedish SNOMED CT translation project. The project is approximately halfway
of the translation of all active descriptions of the type ?preferred term?
from English to Swedish. The number of descriptions the project has to
translate is around 300,000.

 

In this project is normally each description translated by one translator.
The translation is then first inspected by one other translator and then
inspected by a translation editorial office. The translation is then
verified by relevant health care personnel.

 

As far as I know will the translated descriptions be marked as part of the
Swedish National Board of Health and Welfare?s official translation of
SNOMED CT. However, the names of the people involved in the translation and
which organisations they belong to will only be known inside the translation
project. It seems also to be the same case for other translations of
terminology system into Swedish.

 

I therefore think that in some cases are the accreditation association much
more important than the name and demographic information about the
translators.

 

I therefore think that a more proper model is

 


accreditation : String 

0..1 

-- 

 

Accreditation of translator, usually a national translator?s association id 


translation_contributors :
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700091
70_630396_833Report.html HashString,String,String 

0..1 

-- 

 

Role, name and other demographic details for contributors in the translation
process 

 

Regards,

Mikael

 


  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde
Sent: den 23 juni 2009 10:25
To: For openEHR technical discussions
Subject: Improving Translation_details and other_contributors ?


Dear all,

Ian, Heather and I have raised an issue at
http://www.openehr.org/issues/browse/SPECPR-24 for improving the
Translation_details and other_contributors.

What seems to be current practice is that a translation will be done by more
than one person and documenting this is not really supported by the model:

TRANSLATION_DETAILS 

accreditation : String
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11095841383
49_959314_1900Report.html   1   --  Accreditation of
translator, usually a national translator?s association id  
author : Hash
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700091
70_630396_833Report.html String,String1   --
Translator name and other demographic details   

Only one translator is available.
The easiest change would be to make author repeatable, but accreditation
(which seems to be somewhat detached from the author anyway) would need to
be changed then as well - is accreditation that important that it couldn't
be captured as part of the author Hash or what is the reason for having it
separate?

The other problem we have is with other_contributors not sticking to the
same format (i.e. we only have a list of contributors without more formal
metadata):

RESOURCE_DESCRIPTION 

original_author : Hash
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700091
70_630396_833Report.html String,String1   --
Original author of this resource, with all relevant details, including
organisation.   
other_contributors : List
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700090
80_492027_712Report.html String   0..1--  Other
contributors to the resource, probably listed in ?name ? form.  

I think I understand why it is modelled as it is, but why not allow
other_contributors to be 0..* Hash
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700091
70_630396_833Report.html String,String  ?

Maybe, we need to look into formalising what an author/translator is a bit
more in the model?

Are there any suggestions for a better model of this?
Or something from DCM or CDA or others on which we could base such a model
to be compatible with?

Regards
Sebastian


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090623/737b97b6/attachment.html

Representing knowledge in Archetypes/Templates or external rules

[Mikael Nyström]

Dear Pariya,

 

I would vote for the first alternative. If we start to mix up the
information model and the decision support rules too much we will end up
with a quite chaotic system.

 

Regards,

Mikael

 


  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Pariya Kashfi
Sent: den 1 juni 2009 10:12
To: For openEHR technical discussions
Subject: Representing knowledge in Archetypes/Templates or external rules


Dear All, 
I have encountered a question regarding knowledge representation during
archetype designing.
Let's say a list of some special drugs that patient has used is important
for Evaluation. I have two options here: First, to apply one external rule
during the data entry, and mark the patient as e.g X-affected. Secondly, to
represent this knowledge in Templates/Archetypes I am designing. It can be
in the form of an Item-Tree-Medication-List using internal codes ( to
specify medications that may be selected in the drug list). And to check
this node at runtime or during evaluation of EHR for storage.
It may even be a third option that I have not been considers so far i.d
using internal rules (First Order Logic) within archetypes.
The first option, sounds more general to me, and the benefit is that
whenever I want to update rules, I don't need to change the
arcehtypes/templates. And the second option sounds more natural to me in
that I express the knowledge in archetypes directly, makes it more
understandable for clinicians and can be modeled by themselves.
Which one is more acceptable based on openEHR concepts?Do you see any flaws
in these solutions?Is there any better idea?

Regards
Pariya

MSc; PhD Candidate
Department of Computing  Science and Engineering 
Chalmers University of Technology
http://www.chalmers.se/cse/EN/people/kashfi-hajar






-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090601/06e0c458/attachment.html

text and description

[Mikael Nyström]

Hi Grahame,

You are right that the compositional grammar don?t solve the whole problem.
I just meant that the compositional grammar probably is a part of the
solution for binging to SNOMED CT (and maybe other systems that is possible
to postcoordinate.)

Greetings,
Mikael 


-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Grahame Grieve
Sent: den 2 december 2008 23:23
To: For openEHR technical discussions
Subject: Re: text and description

Hi Mikael

I've not seen the final specification, but in it's original
draft, it was extremely limited in scope. For instance, the
language would have made the grammar unsuitable for use in
OpenEHR, though there was no technical reason for this.
Apparently there's going to be a new draft shortly.

However even in it's revised form, the document will almost
certainly only specify a syntax for building single concepts.
It will not provide a syntax or a grammar that deals with
conformance and binding, though one of these is surely needed.

Grahame


Mikael Nystr?m wrote:
 Hi,
 
 Some days after 2008-12-09 IHTSDO probably release a draft of a
 compositional grammar for SNOMED CT expressions which can be used for
 terminology bindings to SNOMED CT. This draft can probably be a basis for
 discussions of terminology bindings.
 
   Greetings,
   Mikael

text and description

[Mikael Nyström]

Hi,

Some days after 2008-12-09 IHTSDO probably release a draft of a
compositional grammar for SNOMED CT expressions which can be used for
terminology bindings to SNOMED CT. This draft can probably be a basis for
discussions of terminology bindings.

Greetings,
Mikael
 

-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel
Sent: den 2 december 2008 10:27
To: erisu at imt.liu.se; 'For openEHR technical discussions'
Subject: RE: text and description

Erik,
I don't see the difference.  The same approach can be used with different
query parameters and terminology identifiers.  We just need to find a way to
uniquely identify local terminology ids, some sort of namespacing mechanism
such as a terminology source organisation UID should do the trick.  This
would not be that much different to uniquely identifying templates which is
also under development.

Heath

 -Original Message-
 From: e.sundvall at gmail.com [mailto:e.sundvall at gmail.com] On Behalf Of 
 Erik
 Sundvall
 Sent: Tuesday, 2 December 2008 7:03 PM
 To: For openEHR technical discussions
 Cc: Heath Frankel; hugh.grady at oceaninformatics.com
 Subject: Re: text and description
 
 Hi!
 
 I know that there are suggestions for defining terminology
 queries/subset-selections using URIs. We discussed this a bit in a
 conference paper that was selected for republication in BMC:
 Integration of tools for binding archetypes to SNOMED CT freely
 available at http://www.biomedcentral.com/1472-6947/8/S1/S7
 
 This kind of URI-encoded queries with semantics have come and gone and
 seem to be coming again in openEHR discussions. Sometimes the URIs
 have contained semantics similar to what you describe below. Sometimes
 they have just contained ID's of queries that have their semantics
 hidden, sorry I mean stored/maintained, in some query server. See
 especially the appendix in the paper above for discussion and
 references.
 
 However, my recent question/suggestion did not have much to do with
 those URI-encoded terminology queries.
 
 Instead, I was asking about two specific use-cases:
 1. directly pointing out single codes/concepts that already have URIs and
 2. a way of creating local bindings using URIs as unique identifiers.
 
 Please re-read the previous post and feel free to ask more if I have
 not made the difference clear enough.
 
 Best regards,
 Erik Sundvall
 erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579
 
 
 
 On Mon, Dec 1, 2008 at 22:28, Heath Frankel
 heath.frankel at oceaninformatics.com wrote:
  Hi Erik,
  As you know Ocean has been doing a lot of work making terminology and
  openEHR Archetype work.  Hugh Grady is the best to describe this but in
  summary we are proposing the use of terminology URIs for bindings.
 
  Bindings can reference a whole terminology, a branch of a terminology
  hierarchy or a complex query which extracts specific subset of a
  terminology.
 
  To identify these there at least four identifiers; terminology ID,
subset
  ID, query name and query version id.  There are other parameters such as
  language and terminology version.
 
  In simply cases where you just want to reference a terminology it might
look
  something like the following
  (NOTE: these are examples to illustrate the point and are certainly not
a
  final proposal).
 terminology:snomed-ct?language=en-GB
 
  or for a specific version of SNOMED
 terminology:snomed-ct(2003)?language=en-GB
 
  For a hierarchy of a terminology it might look something like
 terminology:snomed-ct(2003)/hierarchy?rootConcept=28374832
 
  and for a pre-specified query
 terminology:snomed-ct(2003)/query?name=AllBacteria
 
  There are also more specific URIs for terminology queries by using
subset
  and query version identifiers (UIDs) mentioned above.
 
  I believe this work is ongoing and is being proposed through IHTSDO.  I
  suggest we wait for that work to conclude but I thought I would let you
know
  that Erik's thinking is certainly the way things are being proposed.
 
  Heath
 
  -Original Message-
  From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
  bounces at openehr.org] On Behalf Of Erik Sundvall
  Sent: Monday, 1 December 2008 11:20 PM
  To: For openEHR technical discussions
  Subject: Re: text and description
 
  Hi!
 
  Would it be a good or bad idea to have URI:: as a valid terminology
  prefix in openEHR terminology bindings, with the intention to host...
 
  1. local bindings that are not foreseen to be of public general use:
 
URI::http://www.cs.chalmers.se/~oloft/terminologies/odont-123/local-Mucos-
  txtur
 
  2. Potentially universally interesting terminologies that already have
  official URIs but do not (yet?) have openEHR-defined prefix:
  URI::urn:miriam:obo.go:GO%3A0045202
 
  I guess opening up for any URIs would lead to a risk of having double
 

SNOMED/LOINC mapping

[Mikael Nyström]

Greg Caulton wrote:

 The problem with SNOMED mapping ([...]) is that I assume (perhaps
 incorrectly) that the OpenEHR foundation could not distribute the
 mapping without the recipients first getting some kind of license
 for the SNOMED - not insurmountable but that does complicate things. [...]

A fare as I know there have not been any precedent about what is legal and
what is not to do with derivates of SNOMED CT without a license. But it
seems that people involved in IHTSDO?s work think it is ok to handle
references to SNOMED CT without a licence.

Mikael Nystr?m
Department of Biomedical Engineering
Link?ping University

Member of IHTSDO?s technical committee

openEHR Querying specifications

[Mikael Nyström]

 Mikael Nystr?m wrote:
 
 If for example the change between the first and second version is a
change
 in a position value set from sitting, standing and other to
sitting,
 standing, lying and other. If then a query is written for the first
 version of the archetype searching for all cases where the position is
not
 sitting and not standing the query will search for the position
other
 and return a correct answer.
 
 If we implement Rong's suggestion the query will work also with the
second
 version of the archetype, but it will return another answer than the
 intended, namely the cases where the position is not sitting and not
 standing and not lying instead of the intended not sitting and not
 standing.
 
 
 Micke, what if you keep the original search criteria not sitting and
not
 standing instead of searching others, will you get expected result with
 both versions?
 
Yes, that works, and that is the proper way to do it. My example was an
example of how people quite often do without realizing the consequences.
They think that if something works in a specific version it will work in the
subsequent versions. I think I have seen these kinds of problems too often
in other areas in medical informatics (like the ?not elsewhere
classified?-problem in ICD) and I therefore think that people will do things
without realizing the consequences also when they query archetypes.

Greetings,
Mikael
 


  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen
Sent: den 4 juni 2008 22:07
To: For openEHR technical discussions
Subject: Re: openEHR Querying specifications


On Tue, Jun 3, 2008 at 11:26 PM, Mikael Nystr?m mikny at imt.liu.se wrote:


I disagree with Rong.

 

If for example the change between the first and second version is a change
in a position value set from sitting, standing and other to sitting,
standing, lying and other. If then a query is written for the first
version of the archetype searching for all cases where the position is not
sitting and not standing the query will search for the position other
and return a correct answer.

 

If we implement Rong's suggestion the query will work also with the second
version of the archetype, but it will return another answer than the
intended, namely the cases where the position is not sitting and not
standing and not lying instead of the intended not sitting and not
standing.



Micke, what if you keep the original search criteria not sitting and not
standing instead of searching others, will you get expected result with
both versions?

I was thinking on the potential broken paths between changes when I made my
guess. Since archetypes are expressed more as maximum datasets now, it
seems the changes of removing parts of the archetype will be kept minimum.
Most of changes will perhaps be additions to allow more relevant data
entries. If this is the case, the original path should remain valid through
versions. I was too quick about broken path failing silently. The RM
PATHABLE.item_at_path function (underlying path based query support in RM)
requires path to be valid. Would this mean during query execution phase any
invalid path in the query should result in stop of execution or exclusion of
the current data instance from the result set? I think we need to make this
clear in the query specification.

The idea of hiding version number can be achieved if the Query generator
tool will be smart enough to tell for a given set of versions of archetypes,
a query should be not only valid with paths, but also semantically
consistent across all versions. We probably want to have similar validation
on the queries once they hit query engines.
 
Cheers,
Rong


 

I therefore think that excluding the version information can result in a
mess.

 

  /Micke

 

 


  _  


From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen
Sent: den 3 juni 2008 22:54
To: For openEHR technical discussions
Subject: Re: openEHR Querying specifications

 

I suspect changes between version could potentially break the paths in WHERE
clause. So maybe the version information isn't significant here since either
the path works and the criteria are checked or the path doesn't work and
fails silently.

/Rong

On Tue, Jun 3, 2008 at 10:36 PM, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:

Fair point. Perhaps AQL should support ranges of version numbers to
simplify the query as in many cases the query will not be affected by
a structrural change to the archetype

e.g.


 FROM EHR [ehr_id/value=$ehrUid]

 CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v[BETWEEN 1.5 AND
2]
 CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v[=1]

 WHERE (
 obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value =
 140

Versions and revisions would need to be handled.

Ian

2008/6/3 Greg Caulton caultonpos at 

openEHR Querying specifications

[Mikael Nyström]

I disagree with Rong.

 

If for example the change between the first and second version is a change
in a position value set from ?sitting?, ?standing? and ?other? to ?sitting?,
?standing?, ?lying? and ?other?. If then a query is written for the first
version of the archetype searching for all cases where the position is ?not
sitting? and ?not standing? the query will search for the position ?other?
and return a correct answer.

 

If we implement Rong?s suggestion the query will work also with the second
version of the archetype, but it will return another answer than the
intended, namely the cases where the position is ?not sitting? and ?not
standing? and ?not lying? instead of the intended ?not sitting? and ?not
standing?.

 

I therefore think that excluding the version information can result in a
mess.

 

  /Micke

 

 

  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen
Sent: den 3 juni 2008 22:54
To: For openEHR technical discussions
Subject: Re: openEHR Querying specifications

 

I suspect changes between version could potentially break the paths in WHERE
clause. So maybe the version information isn't significant here since either
the path works and the criteria are checked or the path doesn't work and
fails silently.

/Rong

On Tue, Jun 3, 2008 at 10:36 PM, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:

Fair point. Perhaps AQL should support ranges of version numbers to
simplify the query as in many cases the query will not be affected by
a structrural change to the archetype

e.g.


 FROM EHR [ehr_id/value=$ehrUid]

 CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v[BETWEEN 1.5 AND
2]
 CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v[=1]

 WHERE (
 obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value =
 140

Versions and revisions would need to be handled.

Ian

2008/6/3 Greg Caulton caultonpos at gmail.com:


 --

 Message: 2
 Date: Tue, 03 Jun 2008 16:39:37 +0100
 From: Thomas Beale thomas.beale at oceaninformatics.com
 Subject: openEHR Querying specifications
 To: Openehr-Technical openehr-technical at openehr.org
 Message-ID: 484565B9.6030805 at oceaninformatics.com
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed


 The current material is therefore intended as a resource for discussion
 and definition of a query language for openEHR. A team can be defined
 after sufficient time for the community to react to this material and
 determine if it makes sense to use AQL as the basis or to seek other
 solutions or candidates.

 - thomas beale



 Perhaps this has been answered but as the archetypes change version is it
 expected that the AQL will need to keep up with that - I assume our
historic
 data would be specific to the archetype version - not 'upgraded' ?

 i.e. after v1:

 FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION
 [openEHR-EHR-COMPOSITION.encounter.v1]
 CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
 WHERE
obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
= 140

 after v2:

 FROM EHR [ehr_id/value=$ehrUid]
 CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1]
 CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v2]
 CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
 CONTAINS OBSERVATION obs2 [openEHR-EHR-OBSERVATION.blood_pressure.v2]
 WHERE (
 obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value =
 140  OR

obs2/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
= 140  )

 not sure if that is exactly right.

 thanks!

 Greg


 http://www.patientos.org

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical






--
Dr Ian McNicoll
office +44(0)141 560 4657
fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll

Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com
Consultant - IRIS GP Accounts

Member of BCS Primary Health Care Specialist Group ? http://www.phcsg.org


___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/362e1406/attachment.html

openEHR Querying specifications

[Mikael Nyström]

The difference I mentioned is an addition of a value to a value set and not
a renaming. It is just another variant of the classical ?not elsewhere
classified?-problem in classifications like ICD.
 
We probably have to be even more aware of the problem with varying value
sets when data is reused when we use queries to retrieve value sets from
external terminologies instead of include the value sets in the archetype.
 
Greetings,
Mikael


  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Stef Verlinden
Sent: den 4 juni 2008 08:58
To: For openEHR technical discussions
Subject: Re: openEHR Querying specifications


I'm not a technical person but to me it seems very cumbersome if such
'differences' could exist between 2 versions of the same archetypes. This
would mean that for every query one has to go into detail of every version
of that AT which could mean al lot of work. 

To my understanding versions of AT's should be 'backward compatible'. One
can only add (and maybe remove) items, but never rename an existing item.
Only then a lot of unnecessary work for 'query-makers' can be avoided.

Is this assumption indeed correct?

Cheers,

Stef


Op 3-jun-2008, om 23:26 heeft Mikael Nystr?m het volgende geschreven:


I disagree with Rong.



If for example the change between the first and second version is a change
in a position value set from ?sitting?, ?standing? and ?other? to ?sitting?,
?standing?, ?lying? and ?other?. If then a query is written for the first
version of the archetype searching for all cases where the position is ?not
sitting? and ?not standing? the query will search for the position ?other?
and return a correct answer.



If we implement Rong?s suggestion the query will work also with the second
version of the archetype, but it will return another answer than the
intended, namely the cases where the position is ?not sitting? and ?not
standing? and ?not lying? instead of the intended ?not sitting? and ?not
standing?.



I therefore think that excluding the version information can result in a
mess.



  /Micke






  _  


From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen
Sent: den 3 juni 2008 22:54
To: For openEHR technical discussions
Subject: Re: openEHR Querying specifications



I suspect changes between version could potentially break the paths in WHERE
clause. So maybe the version information isn't significant here since either
the path works and the criteria are checked or the path doesn't work and
fails silently.

/Rong

On Tue, Jun 3, 2008 at 10:36 PM, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:

Fair point. Perhaps AQL should support ranges of version numbers to
simplify the query as in many cases the query will not be affected by
a structrural change to the archetype

e.g.


 FROM EHR [ehr_id/value=$ehrUid]

 CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v[BETWEEN 1.5 AND
2]
 CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v[=1]

 WHERE (
 obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value =
 140

Versions and revisions would need to be handled.

Ian

2008/6/3 Greg Caulton caultonpos at gmail.com:


 --

 Message: 2
 Date: Tue, 03 Jun 2008 16:39:37 +0100
 From: Thomas Beale thomas.beale at oceaninformatics.com
 Subject: openEHR Querying specifications
 To: Openehr-Technical openehr-technical at openehr.org
 Message-ID: 484565B9.6030805 at oceaninformatics.com
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed


 The current material is therefore intended as a resource for discussion
 and definition of a query language for openEHR. A team can be defined
 after sufficient time for the community to react to this material and
 determine if it makes sense to use AQL as the basis or to seek other
 solutions or candidates.

 - thomas beale



 Perhaps this has been answered but as the archetypes change version is it
 expected that the AQL will need to keep up with that - I assume our
historic
 data would be specific to the archetype version - not 'upgraded' ?

 i.e. after v1:

 FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION
 [openEHR-EHR-COMPOSITION.encounter.v1]
 CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
 WHERE
obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
= 140

 after v2:

 FROM EHR [ehr_id/value=$ehrUid]
 CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1]
 CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v2]
 CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
 CONTAINS OBSERVATION obs2 [openEHR-EHR-OBSERVATION.blood_pressure.v2]
 WHERE (
 obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value =
 140  OR

obs2/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
= 140  )

 not sure if that is exactly right.

MIE-2008

[Mikael Nyström]

I have already counted you in when I applied for us at Link?ping University.
:-)

 

  /Micke

 

 

  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen
Sent: den 31 maj 2008 00:22
To: For openEHR technical discussions
Subject: Re: MIE-2008

 

Sam,
I am interested to join this list.
/Rong

On Fri, May 30, 2008 at 9:58 PM, Paria Kashfi hajar.kashfi at chalmers.se
wrote:

sounds great!

we are at least 3 persons interested in this issue in Chalmers and Sk?vde

 

paria

 

On May 30, 2008, at 4:19 PM, Sam Heard wrote:

 

I wonder if we should have a particular list for people who are interested
in working with openEHR from a decision support point of view. This may not
be appropriate just yet but I believe it will generate a considerably
different intellectual space. I wonder what others think?
Sam

P?ria Kashfi wrote: 

Hi all,
As you may find in my signature, I'm a PhD student at Chalmers  
University of Technology, Sweden.
The idea of having a conference related wiki page would be great for  
me, but not in entering related papers yet!
MIE2008 was an amazing opportunity for me to get more familiar with  
openEHR and I've just starting investigating it for our projects.
As a part of Pragmatic Pattern project, I'll design and develop an  
Evidence Based Clinicla Decision Support System
You may find more information about our projects here:
 
http://www.cs.chalmers.se/proj/medview/website/medview/omMedView.html
http://www.his.se/templates/vanligwebbsida1.aspx?id=29549
 
I hope discussing issues on this mailing list, or getting access to  
resources in the Wiki will help me find the best way of utilizing this  
standard.
Finally, It was so nice to meet you- Rong,Beatriz,Ian and Heather - in  
MIE2008 :)
 
Regards
paria
 
 
 
 
 
 
On May 30, 2008, at 11:48 AM, Thomas Beale wrote:
 
  

Lisa Thurston wrote:


Andrew Patterson wrote:
 
  

Actually, is it possible to have a conferences page on the wiki
that is a bit of a one-stop shop for documenting openEHR related
contributions to conferences. Somewhere where authors could
attach their presentations from last years Medinfo, the MIE 2008 etc
- and maybe also lists of future conferences of interest to
openEHR folks.
 
I know I can create pages myself on the wiki but I'm still a bit  
unsure
where things are supposed to go in the wiki tree.
 
 


Andrew, I think this is a really good idea. A link from the  
homepage or
static part of the website into a place on the wiki where users can
upload papers and continue the discussion has potential as both a
reference and a way to provide feedback and/or engage in discussion  
on
each paper in one location.
 
 
  

*I am fine with that - I don't think we had the wiki running when we  
did
the MedInfo pages. Probably we should move that to the wiki as well  
and
make a small web page. How do others feel about this. Note, if we go
this way, I am likely to leav it up to conference paper-writers to put
their own entries up in the relevant pages!
 
Can we have reactions from a few more people - if the response is
positive, I will organise the conference material onto the wiki.
 
- thomas beale
 
*
 
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
  

 

-- 


OceanInformaticsl.JPG

 

Dr Sam Heard
Chief Executive Officer
Director, openEHR Foundation
Senior Visiting Research Fellow, University College London


 

 

 


214 Victoria Avenue
Chatswood, NSW, 2067
Phone: +61 2 9415 4994
Mobile: +61 4 1783 8808

21 Chester Cres
London E8 2PH
Phone: +44 20 7249 7085
Mobile: +44 77 9871 0980

 

 

 

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 

PhD Student 

IDC | Interaction Design Collegium 

Department of Computing  Science and Engineering 

Chalmers University of Technology

 

Email: hajar.kashfi at chalmers.se

Office:+46 (0)31 7725407 

Mobile Phone: +46 (0)707222815 

Postal adress:

IT University of G?teborg

412 96 G?teborg, Sweden 

Visit: Room Simula B, House Svea, Campus Lindholmen

 


___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080531/cd6c7568/attachment.html

MIE-2008

[Mikael Nyström]

It is a good idea. You can probably count all of us at Link?ping University
in.

 

/Micke


  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard
Sent: den 30 maj 2008 16:20
To: For openEHR technical discussions
Cc: Barretto, Sistine
Subject: Re: MIE-2008


I wonder if we should have a particular list for people who are interested
in working with openEHR from a decision support point of view. This may not
be appropriate just yet but I believe it will generate a considerably
different intellectual space. I wonder what others think?
Sam

P?ria Kashfi wrote: 

Hi all,

As you may find in my signature, I'm a PhD student at Chalmers  

University of Technology, Sweden.

The idea of having a conference related wiki page would be great for  

me, but not in entering related papers yet!

MIE2008 was an amazing opportunity for me to get more familiar with  

openEHR and I've just starting investigating it for our projects.

As a part of Pragmatic Pattern project, I'll design and develop an  

Evidence Based Clinicla Decision Support System

You may find more information about our projects here:



http://www.cs.chalmers.se/proj/medview/website/medview/omMedView.html

http://www.his.se/templates/vanligwebbsida1.aspx?id=29549



I hope discussing issues on this mailing list, or getting access to  

resources in the Wiki will help me find the best way of utilizing this  

standard.

Finally, It was so nice to meet you- Rong,Beatriz,Ian and Heather - in  

MIE2008 :)



Regards

paria













On May 30, 2008, at 11:48 AM, Thomas Beale wrote:



  

Lisa Thurston wrote:



Andrew Patterson wrote:



  

Actually, is it possible to have a conferences page on the wiki

that is a bit of a one-stop shop for documenting openEHR related

contributions to conferences. Somewhere where authors could

attach their presentations from last years Medinfo, the MIE 2008 etc

- and maybe also lists of future conferences of interest to

openEHR folks.



I know I can create pages myself on the wiki but I'm still a bit  

unsure

where things are supposed to go in the wiki tree.







Andrew, I think this is a really good idea. A link from the  

homepage or

static part of the website into a place on the wiki where users can

upload papers and continue the discussion has potential as both a

reference and a way to provide feedback and/or engage in discussion  

on

each paper in one location.





  

*I am fine with that - I don't think we had the wiki running when we  

did

the MedInfo pages. Probably we should move that to the wiki as well  

and

make a small web page. How do others feel about this. Note, if we go

this way, I am likely to leav it up to conference paper-writers to put

their own entries up in the relevant pages!



Can we have reactions from a few more people - if the response is

positive, I will organise the conference material onto the wiki.



- thomas beale



*



___

openEHR-technical mailing list

openEHR-technical at openehr.org

http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical





___

openEHR-technical mailing list

openEHR-technical at openehr.org

http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical





  


-- 


Dr Sam Heard
Chief Executive Officer
Director, openEHR Foundation
Senior Visiting Research Fellow, University College London

214 Victoria Avenue
Chatswood, NSW, 2067
Phone: +61 2 9415 4994
Mobile: +61 4 1783 8808  21 Chester Cres
London E8 2PH
Phone: +44 20 7249 7085
Mobile: +44 77 9871 0980


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080530/680f2e5e/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanInformaticsl.JPG
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080530/680f2e5e/attachment.JPG

Looking for the LiU Archetype Editor authors

[Mikael Nyström]

Dear Adam,

Then you should contact my colleague Erik Sundvall. He has the
e-mail-address erisu at imt.liu.se .

Mikael Nystr?m
Medical Informatics
Departmed of Biomedical Engineering
Link?ping University
Sweden
 

-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Adam Flinton
Sent: den 29 november 2007 16:22
To: openEHR technical discussions
Subject: Looking for the LiU Archetype Editor authors

Dear all,

Has anyone got the email addresses etc of the authors of the LiU 
Archetype Editor?

I would like to get in touch with them as I may be able to help with the 
code.

Adam

**
This message  may  contain  confidential  and  privileged information.
If you are not  the intended  recipient please  accept our  apologies.
Please do not disclose, copy or distribute  information in this e-mail
or take any  action in reliance on its  contents: to do so is strictly
prohibited and may be unlawful. Please inform us that this message has
gone  astray  before  deleting it.  Thank  you for  your co-operation.

NHSmail is used daily by over 100,000 staff in the NHS. Over a million
messages  are sent every day by the system.  To find  out why more and
more NHS personnel are  switching to  this NHS  Connecting  for Health
system please visit www.connectingforhealth.nhs.uk/nhsmail
**

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

software development starting out

[Mikael Nyström]

Hi,

I recommend that you start reading the Architecture Overview which gives a
overview of the ideas behind openEHR. You can find the current version at
the URL
http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/architect
ure/overview.pdf .

If you would like to have a little ?hands on? experience of archetypes is it
probably a good idea to download an archetype editor and play around with
it. The Link?ping University Archetype Editor can be found at the URL
http://www.imt.liu.se/mi/ehr/tools/ and the Ocean Archetype editor at the
URL http://downloads.oceaninformatics.com/products/archetypeeditor/ .

Greetings,
Mikael Nystr?m
Medical Informatics
Department of Biomedical Engineering
Link?ping University
Sweden


-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Greg Caulton
Sent: den 18 oktober 2007 21:15
To: openehr-technical at openehr.org
Subject: software development  starting out

Hi,

As someone who is an OpenEHR novice can you give me any tips - there
is so much information on the website it is difficult to know where to
start.

While I have yet to understand the full potential of the framework, I
would like to start with something simple.

Suppose a surgeon signs onto my system and wishes to create a new
progress note.  On paper he may have written (swapping out the )


age, sex with ESLD admitted with dehydration

Received n ml/kg of volume resuscitation last night.  Went to OR for
CVL placement, transferred to ICU for management after OR.

a)  Send bacterial infection if stooling
b)  Re|start med for wound infection
c)  Check weights
d) etc.
_

How does OpenEHR come into play with this action -

Should provide lookups or force sentence structure?
Should it be used to define and store the content into discrete data?
What data source or service would my code interact with?

I guess I have many questions, and I apologize in advance if I miss
some concepts.

thanks!

Greg

Boston, MA
http://www.patientos.org
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[archetypes.com.au] Functionality to compare two archetypes

[Mikael Nyström]

Hi Sebastian,

 

Nice work!

 

I, who quite often work with medical information in more than one language,
think it would be nice to add a column with the language code for each line
when it is suitable and maybe the possibility of selecting to only show the
differences for one of the languages in the archetype. Otherwise it can be
quite annoying to compare archetypes which contain many languages.

 

Greetings,

Mikael

 


  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde
Sent: den 10 september 2007 10:12
To: openehr-technical at openehr.org
Subject: [archetypes.com.au] Functionality to compare two archetypes



Dear all,

 

We have added prototype functionality to the Archetypefinder to compare two
versions/revisions of an archetype at
http://www.archetypes.com.au/archetypefinder/compare.html. This
functionality will later be integrated into the appropriate tools, but can
be useful on its own too.

 

You can upload two archetypes and then see what changes have been made
between the two versions of an archetype. Also, the type of the changes with
regard to compatibility of the two archetypes (e.g. ?compatible with
revision?, ?requires new version? or ?descriptive change?) is shown.

 

Have a look - USAGE:

You can use URLs to archetypes as well as upload archetypes directly from
your local system  .

For example, you can use a modified blood pressure archetype and compare it
with the current blood pressure archetype from the openEHR site. For this
just 

1. Go to http://www.archetypes.com.au/archetypefinder/compare.html, 

2. Copy the URL
http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observ
ation/openEHR-EHR-OBSERVATION.blood_pressure.v1.adl and paste it into the
webform as URL for the original archetype (1st row, last column) 

3. Copy the URL
http://healthinformatics.cqu.edu.au/archetypefinder/openEHR-EHR-OBSERVATION.
blood_pressure.v1.adl and paste it into the webform as URL for the modified
archetype (2nd row, last column) 

4. Click the ?Compare Archetypes?-button

 

Please note that this is a prototype. We would be glad about any feedback,
bug reports, ideas, discussion.

Especially, if you disagree with some of the conclusions about the
compatibility of two archetypes you submitted, please drop me an email or
discuss via this list!

 

It is important to make the compatibility of archetypes explicit, so that
archetype-enabled software can decide this - we want to settle this issue
once and for all!

 

Many thanks to Stefan Fuchs from the UMIT in Austria for heaps of hard work
on this during an internship with us! 

 

Best regards,

Sebastian

 

Dr Sebastian Garde 

Dr. sc. hum., Dipl.-Inform. Med, FACHI

 

Research Fellow

Faculty of Business and Informatics, Central Queensland University

Austin Centre for Applied Clinical Informatics, Austin Health

Heidelberg Vic 3084, Australia

s.garde at cqu.edu.au

Ph: +61 (0)3 9496 4040

Fax: +61 (0)3 9496 4224  

http://healthinformatics.cqu.edu.au http://healthinformatics.cqu.edu.au/  

http://www.acaci.org.au http://www.acaci.org.au/ 

Visit the new open access electronic Journal of Health Informatics (eJHI):
http://ejhi.net http://ejhi.net/   

 

 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070912/b56bf131/attachment.html

[archetypes.com.au] Functionality to compare two archetypes

[Mikael Nyström]

Hi Sam,

 

Of course it improves the risk for the user to unconsciously hide the
changes the user is looking for, but in general I believe that it is a good
thing to implement useful functionality even if it improves the risk for a
beginner to do to something wrong.

 

(I believe that we non native English speakers think about managing
information in multiple languages as a more complex task than native English
speakers.)

 

Greetings,

Mikael

 


  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard
Sent: den 12 september 2007 22:05
To: For openEHR technical discussions
Subject: Re: [archetypes.com.au] Functionality to compare two archetypes


Hi everyone

We need to be careful here as this will show the changes and if there have
(inadvertently) been changes in other languages then we do want the author
to know. There should not be changes in more than one language for most of
the archetype...

I am not sure a dynamic filter will be easy at this stage. Ajax?

Cheers, Sam

Mikael Nystr?m wrote: 

Hi Sebastian,



Nice work!



I, who quite often work with medical information in more than one language,
think it would be nice to add a column with the language code for each line
when it is suitable and maybe the possibility of selecting to only show the
differences for one of the languages in the archetype. Otherwise it can be
quite annoying to compare archetypes which contain many languages.



Greetings,

Mikael





  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde
Sent: den 10 september 2007 10:12
To: openehr-technical at openehr.org
Subject: [archetypes.com.au] Functionality to compare two archetypes



Dear all,



We have added prototype functionality to the Archetypefinder to compare two
versions/revisions of an archetype at
http://www.archetypes.com.au/archetypefinder/compare.html. This
functionality will later be integrated into the appropriate tools, but can
be useful on its own too.



You can upload two archetypes and then see what changes have been made
between the two versions of an archetype. Also, the type of the changes with
regard to compatibility of the two archetypes (e.g. ?compatible with
revision?, ?requires new version? or ?descriptive change?) is shown.



Have a look - USAGE:

You can use URLs to archetypes as well as upload archetypes directly from
your local system  .

For example, you can use a modified blood pressure archetype and compare it
with the current blood pressure archetype from the openEHR site. For this
just 

1. Go to http://www.archetypes.com.au/archetypefinder/compare.html, 

2. Copy the URL
http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observ
ation/openEHR-EHR-OBSERVATION.blood_pressure.v1.adl and paste it into the
webform as URL for the original archetype (1st row, last column) 

3. Copy the URL
http://healthinformatics.cqu.edu.au/archetypefinder/openEHR-EHR-OBSERVATION.
blood_pressure.v1.adl and paste it into the webform as URL for the modified
archetype (2nd row, last column) 

4. Click the ?Compare Archetypes?-button



Please note that this is a prototype. We would be glad about any feedback,
bug reports, ideas, discussion.

Especially, if you disagree with some of the conclusions about the
compatibility of two archetypes you submitted, please drop me an email or
discuss via this list!



It is important to make the compatibility of archetypes explicit, so that
archetype-enabled software can decide this - we want to settle this issue
once and for all!



Many thanks to Stefan Fuchs from the UMIT in Austria for heaps of hard work
on this during an internship with us! 



Best regards,

Sebastian



Dr Sebastian Garde 

Dr. sc. hum., Dipl.-Inform. Med, FACHI



Research Fellow

Faculty of Business and Informatics, Central Queensland University

Austin Centre for Applied Clinical Informatics, Austin Health

Heidelberg Vic 3084, Australia

s.garde at cqu.edu.au

Ph: +61 (0)3 9496 4040

Fax: +61 (0)3 9496 4224  

http://healthinformatics.cqu.edu.au http://healthinformatics.cqu.edu.au/  

http://www.acaci.org.au http://www.acaci.org.au/ 

Visit the new open access electronic Journal of Health Informatics (eJHI):
http://ejhi.net http://ejhi.net/   







  _  


___

openEHR-technical mailing list

openEHR-technical at openehr.org

http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

  


-- 

 Dr Sam Heard
Chief Executive Officer
Ocean Informatics

Director, openEHR Foundation
Adj. Professor, Central Queensland University
Senior Visiting Research Fellow, University College London
Aus: +61 4 1783 8808
UK: +44 77 9871 0980 
-- next part --
An HTML attachment was scrubbed...
URL: 

Language tags within archetypes

[Mikael Nyström]

Hi Huge,

 

In SNOMED CT languages and dialects are coded in the following way

 

First, a mandatory language code from ISO639-1 ?Codes for the representation
of names of languages? for representation of the language.

 

After the ISO639-1 code is it possible to add dash and an upper-case string
that identify the dialect. If the dialect is general in a whole country then
a code from ISO3166 ?Codes for the representation of names of countries? is
used. If the dialect is not general for a country then a code from Internet
Assigned Numbers Authority, IANA, is used. The documentation says that this
approach is similar to the approach used by W3C.

 

I think this is quite similar to what you have found.

 

/Mikael


  _  

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Hugh Leslie
Sent: den 9 juli 2007 02:34
To: For openEHR technical discussions
Subject: Language tags within archetypes


Ocean has been recently doing some work in translating archetypes into
Chilean Spanish which is proceeding well.  We have come across a minor issue
with standards for language tags and wanted to get the groups opinion and
consensus about where we should go with this.  

The current ocean archetype editor creates language tags with ISO639-1
coding i.e. [ISO639-1::es].  This becomes incorrect when a user selects a
more specific language such as es-CL and we get [ISO639-1::es-CL].  This is
incorrect, because ISO639-1 is only the 2 digit language code.

I have done a little bit of research and it appears that what is generally
used is the IETF language tags which are related to ISO but not the same.
(See http://en.wikipedia.org/wiki/IETF_language_tag).  

Windows (the .net framework at least) seems to support IETF language tags,
however they also seem to use a method of combining culture name in the
format languagecode2-country/regioncode2, where languagecode2 is a
lowercase two-letter code derived from ISO 639-1 and country/regioncode2
is an uppercase two-letter code derived from ISO 3166.  This seems to be  a
problematic thing.

Java also seems to support the IETF tags at some level.

Does anyone have an easy solution to this one?  IETF is the only thing I
have seen that seems to relate directly to language.

Hugh


-- 

 
Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI 
Ocean Informatics Pty Ltd 
M: +61 404 033 767   E: hugh.leslie at oceaninformatics.biz  W:
www.oceaninformatics.biz 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070709/f526916c/attachment.html

removal of data

[Mikael Nyström]

Thomas Beale wrote:

 Technically, deletion is easy, but there are consequences for consistency
 and legal value of the data. So making it harder to do is sensible. We
 have to realise that all such legislation as has been mentioned here is
 written as if we were in 1850, still writing everything on paper.

The Swedish Health Record Law is from 1985 and has been revised several
times since then. The law is written to be media and technique neutral and
describe what the society demand from a health record. Then is it up to the
suppliers to use their technique so the health records keeps up to the
society?s demands before they sell the health record systems to the health
care providers. In this case can it be burnable health record papers or
electronic health record systems with good functionality to completely
remove entered data.

I therefore don?t think that we shall talk about the laws in a fashion of
non modern laws written for a previous media, but instead of how we
technicians can satisfy the society?s demand on health records whatever
technique we use.

 Even then it was not watertight - anyone could make a written copy, and
 it was not long before photography and typewriters made that job a lot
 faster.

Of cause is it possible to copy data from a paper based health record, but
in Sweden we then note where we send the copy. It is still possible to do
with electronic health records.

/Mikael Nystr?m

removal of data

[Mikael Nyström]

I know that it is very hard to completely remove (parts of) an electronic
health record, but the law is still the law and we therefore must follow it.
It happens now and then in Sweden that we must remove (parts of) an
electronic health record completely (and not only logically). The removal is
mainly done manually and to a high cost. In Sweden we therefore also need to
record where we send electronic health record data and where we back the
data up.

/Mikael Nystr?m 




From: owner-openehr-techni...@openehr.org
[mailto:owner-openehr-technical at openehr.org] On Behalf Of Gerard Freriks
Sent: den 17 april 2006 08:28
To: openehr-technical at openehr.org
Subject: Re: removal of data


I agree that is very seldom. 


For many (technical) reasons it is completely impossible to remove all
information as if it was never written.


for example:
- The information is communicated with others before it has to be removed
- the information is part of an archive on CD-ROM
- the information is indexed somewhere


Laws (as far as I know) cannot force healthcare providers to change the
history of things.
Each healthcare provider has the obligation to document itself.
The law, my personal opinion, most often is written by legal persons.
Therefor what they prescribe is legally correct but many times impossible to
execute.


My solution is to translate the legal terms in a requirement to LOGICALLY
remove the information,
It is there.
But it is not used any longer.


Gerard

persistence layer

[Mikael Nyström]

Hi all,

Karsten Hilbert wrote:
 
 Mikael Nystr?m wrote:
 
 If we are talking about small data driven systems can I accept the ?pure
 Java guy?s alternative? and do most of the processing in Java. But if we
 would like to have large data driven systems this alternative is needs in
 most cases to large resources to work, and we then need to use the
 ?database engineer?s alternatives? instead.

 Well, even in a GP EMR system we want decision support. I
 don't think there's any such thing as a small system in
 your sense. It's rather a question of what the system is
 going to be used for no matter large or small.

I used small and large in a broad sense. If anyone feel more comfortable
to read small as low usage and large as high usage or not
intensive and intensive or few users and many users or similar things
is it ok for me. :-) I just need to be able compare two alternatives with
different demands.

Greetings,
Mikael Nystr?m

persistence layer

[Mikael Nyström]

Hi all,

Rong Chen wrote:
 Mikael Nystr?m wrote:
 Rong Chen wrote:

 Do you have any specific need for queries? If you don't need to query 
 the internals of the objects (or tree of them), it will be quite 
 simple to just serialize the whole object.

 I agree with Rong that in simple cases is it enough with serialized
objects.
 (But I must say that the alternative with applications like real time 
 data driven decision support systems is much more scientifically 
 interesting and fun. Otherwise we probably not use the full potential 
 of openEHR.)
   
 This could be achieved by querying in-memory objects, why it has to be
done
 in the persistence layer? Maybe you can give some example, Mikael.

A data driven real time system (in this example a decision support system)
relies heavily on fast and full access to the data. The systems often works
with rules like ?if parameter A and parameter B is  C then check if
parameter D1, D2, D3, D4, D5 and D6 is  10 and in that case trigger rules
R1, R2, R3, R4, R5, R6 and R7?.

Of cause it is possible to implement data driven systems completely in Java
and only relies on a database management system to store serialized data
objects in BLOBs. For every parameter the system needs to check the system
then needs to take the path to the object which contain the parameter the
system needs, ask the database management system to retrieve the serialized
Java object from its BLOB-storage in the database, deserialize the object to
a readable form, store the object it in the computer memory, read the
parameter you need from the object, invalidate your newly created object and
not get back the memory used for the object until the garbage collector run
it?s next turn. But this strategy needs large resources to run.

If the parameters are stored in direct readable form in the database
management system it is possible for the application to just ask for the
single data it needs and haven?t the need to spend time on deserializing of
BLOBs into readable objects, store large object instead of just the needed
parameter in the computer?s memory and the need for large object to be
garbage collected.

An even more efficient alternative is to implement the rules directly in the
database management system as triggers. Then the rules are applied by the
database management system in the same native way as the data are handled in
the database management system. But this alternative is only possible when
the database management system is able to read the single data values and
not, as in the serialized objects alternative, know that the single data
values are inside a BLOB.

If we are talking about small data driven systems can I accept the ?pure
Java guy?s alternative? and do most of the processing in Java. But if we
would like to have large data driven systems this alternative is needs in
most cases to large resources to work, and we then need to use the ?database
engineer?s alternatives? instead.
 
 A generic, full-featured query service is tricky enough to do, so why
 not separate the persistence concern from query related logic.

I can accept that it is trickier to implement a good persistence layer
without any serialized objects, but it is definitely not rocket science to
do it. So why not try, so we are able to use the data in more effective
ways?

 Well, I would prefer to see a generic, all-purpose persistence layer,
defined
 by clear interface. Of course, the characteristics will be different
 depending which implementation is actually used. Applications should be
 probably built on top of EHR services, which are also generic,
all-purposed.
 So I wouldn't agree that the persistence layer should be very much defined
 by any particular application. These two, application and persistence,
 should be rather decoupled, and the services layer will be in between.

I agree that we need one well defined independent and good persistence layer
interface. We therefore need to design the persistence layer interface for
the most demanding applications.

Greetings,
Mikael

FW: persistence layer

[Mikael Nyström]

Dear all,

I think before we discuss how we are going to build a persistence layer we
need to discuss how we are going to use it. Is it to support a simple
electronic healthcare record application which only collects basic
information, print the information on a computer screen or on a paper on a
small center for primary health care? Or is it to support an information
system for electronic healthcare record information used everywhere on a
large hospital (or a country!) and where the system is able to amongst
others support data intensive applications like real time data driven
decision support systems? If it is the first case the persistence layer can
be built in many different ways and where some of the ways are simple and
fast to build. If it is the second case there are much fewer ways to build
the persistence layer and probably none of them are simple and fast to
build.

Regards,
Mikael

Mikael Nystr?m
M Sc in Computer Science and Engineering
Ph D student in Medical Informatics
Department of Biomedical Engineering
Link?ping University

persistence layer

[Mikael Nyström]

Dear all,

I think before we discuss how we are going to build a persistence layer we
need to discuss how we are going to use it. Is it to support a simple
electronic healthcare record application which only collects basic
information, print the information on a computer screen or on a paper on a
small center for primary health care? Or is it to support an information
system for electronic healthcare record information used everywhere on a
large hospital (or a country!) and where the system is able to amongst
others support data intensive applications like real time data driven
decision support systems? If it is the first case the persistence layer can
be built in many different ways and where some of the ways are simple and
fast to build. If it is the second case there are much fewer ways to build
the persistence layer and probably none of them are simple and fast to
build.

Regards,
Mikael

Mikael Nystr?m
M Sc in Computer Science and Engineering
Ph D student in Medical Informatics
Department of Biomedical Engineering
Link?ping University

persistence layer

[Mikael Nyström]

Dear all,

I think before we discuss how we are going to build a persistence layer we
need to discuss how we are going to use it. Is it to support a simple
electronic healthcare record application which only collects basic
information, print the information on a computer screen or on a paper on a
small center for primary health care? Or is it to support an information
system for electronic healthcare record information used everywhere on a
large hospital (or a country!) and where the system is able to amongst
others support data intensive applications like real time data driven
decision support systems? If it is the first case the persistence layer can
be built in many different ways and where some of the ways are simple and
fast to build. If it is the second case there are much fewer ways to build
the persistence layer and probably none of them are simple and fast to
build.

Regards,
Mikael

Mikael Nystr?m
M Sc in Computer Science and Engineering
Ph D student in Medical Informatics
Department of Biomedical Engineering 
Link?ping University

dictionary

[Mikael Nyström]

 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-techni...@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

  

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, 

dictionary

[Mikael Nyström]

 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-techni...@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