Hi Bert,
This is going to sound controversial but ...
I am a big fan of SNOMED-CT and at some pint in the far distant
future, what you are proposing (or something like it) will happen.
However, I have seen endless similar proposals/projects in the UK and
beyond, entranced by the potential of post-coordination, repeatedly
falling over, wasting huge amounts of resource and energy and
achieving nothing. That includes CIMI, which has, IMO, been largely
stalled by setting itself the goal of labelling all CIMI nodes as
SNOMED terms, and for archetypes being 'iso-semantic' with
post-coordinated SNOMED expressions.
Whilst this is a laudable goal, it is hugely complex and it is, I
think significant that where progress has been made (openEHR and FHIR)
both have largely taken a prgamatic and limited approach to use of
SNOMED-CT.
SNOMED is a primarily an ontology of biomedical fact, not of clinical
practice/documentation. Used
@Erik - we have only just been asked to resume discussion with IHTSDO.
The view of the MB is that it is not our place to police the use of
SNOMED-CT by end-user systems. All SNOMED-CT bindings in openEHR
artefacts are optional mappings. We are happy to add a boilerplate
license to each archetype (as for any third-party IP) that
implementers must ensure that any use of SNOMED-CT is allowed. There
is no intention to otherwise adapt or strip-out content for unlicensed
consumers, as I think you were suggesting. If IHTSDO feel the need to
enforce more onerous terms than a simple boilerplate "Please respect
IP" statement, I think we might find that very problematic.
Regards,
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: [email protected] <mailto:[email protected]>
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation [email protected]
<mailto:[email protected]>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On 29 April 2016 at 15:45, Bert Verhees <[email protected]
<mailto:[email protected]>> wrote:
Thanks Erik, for your reply. I did some more thinking in the meantime.
In SNOMED you have disorders, and they have attributes, and we all
know there are thousands of them. Writing so many archetypes is
impossible, and probably not necessary, but when you take in
account to limit the number of used paths, (this helps also
limiting the length key-index for a key value store), and you
really think smart how to do it, so it can be generated.
Because SNOMED is in fact a description of many clinical meanings
with post-coordinate expressions and allowable attributes, just
like archetypes are a way to describe the same, it seems quite a
potential, especially because it can be used to generate
archetypes, I had never thought of the idea until yesterday. So I
haven't worked it out.
I don't know which part is of high quality and how you define high
quality, (or do "they" define it?), and also to consider, are
archetypes always of high quality?
Archetypes are version-able, so, they could follow SNOMED
versions. You cannot build the world in one day. It has to grow,
but a lot of work can be done in one major blow.
In the Netherlands we can use SNOMED for free, so that is a good
thing.
By the way, the semantics which are baked in the OpenEHR RM make
it a bit more difficult. I think that a data-storage, modeled like
CEN13606 would make it easier to do this. But it may also be
possible in OpenEHR, we must work it out, to find it out.
Bert
On 29-04-16 14:15, Erik Sundvall wrote:
You can do some very clever things with Snomed CT especially if
using "post-coordination" in a good way. Sadly many current
EHR-systems can't utilize that power of Snomed CT fully. Clever
archetyping with e.g. some built in post-coordination-generating
logic combined with some extended (AQL?)querying-capabilities in
openEHR storage systems could help openEHR-based systems jump
ahead of a lot of the EHR competitors regarding efficient Snomed
CT use...
It is often good to look at Snomed CT when designing archetypes.
Especially the high quality parts of Snomed CT (there is constant
maintenance and cleanup going on). I believe this is happening
more already when designing archetypes today.
Regarding licensing I believe there has been a discussion going
on between IHTSDO and the openEHR foundation for a long
time, perhaps the management board has an update?
I believe we might need to add a function to
repositories/CKMs that removes Snomed bindings/codes from
archetypes if downloaded by non-licensed users. (A lot of the
structure/content itself is based on (non protected) general
medical knowledge and I believe IHTSDO concludes it can be partly
reused without license, thus not stopping global use
of Snomed-inspired archetypes.)
Others will surely add more to the discussion.
//Erik Sundvall
Sent from mobile...
fredag 29 april 2016 skrev Bert Verhees <[email protected]
<mailto:[email protected]>>:
Part two is of course, generating templates, and we almost
have the GUI's in place.
It is the enormous collection of medical datastructures which
can be the source of many generated EPD-software.
Bert
On 29-04-16 08: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),
because, when working with handwritten archetypes will
always be incomplete and fragmented.
Bert
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Sent from mobile.
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
