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:[email protected]]
För Heather Leslie
Skickat: den 22 mars 2018 08:01
Till: For openEHR technical discussions <[email protected]>
Ä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
<[email protected]<mailto:[email protected]>>
On Behalf Of [email protected]<mailto:[email protected]>
Sent: Thursday, 22 March 2018 11:26 AM
To:
[email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>>
on behalf of Heather Leslie
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>>
On Behalf Of Mikael Nyström
Sent: Thursday, 22 March 2018 1:00 AM
To: For openEHR technical discussions
<[email protected]<mailto:[email protected]>>
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 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:[email protected]]
För Thomas Beale
Skickat: den 21 mars 2018 14:17
Till:
[email protected]<mailto:[email protected]>
Ä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
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
--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Team, Intermountain
Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR
Foundation<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer
Society<http://www.bcs.org/category/6044>
Health IT blog<http://wolandscat.net/> | Culture
blog<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
