Creating subsets is the case in the Netherlands.
However they are published in different fashions:
* As national extensions in SnomedCT online
* On Nictiz art decor for projects as perinatology (varied sets for
data and for valuesets)
* On zorginformatiebouwstenen
* On the FHIR publication sites
* On project sites
* On github Detailed Clinical Models in individual DCMs
* And probably more.
Dr William Goossen
Directeur
Results 4 Care bv
Tel +31654614458
*Van: *openehr-technical-requ...@lists.openehr.org
<mailto:openehr-technical-requ...@lists.openehr.org>
*Verzonden: *maandag 26 maart 2018 08:26
*Aan: *openehr-technical@lists.openehr.org
<mailto:openehr-technical@lists.openehr.org>
*Onderwerp: *openEHR-technical Digest, Vol 73, Issue 86
Send openEHR-technical mailing list submissions to
openehr-technical@lists.openehr.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
or, via email, send a message with subject or body 'help' to
openehr-technical-requ...@lists.openehr.org
You can reach the person managing the list at
openehr-technical-ow...@lists.openehr.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openEHR-technical digest..."
Today's Topics:
1. Re: SV: [Troll] Terminology bindings ... again (A Verhees)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Mar 2018 06:25:19 +0000
From: A Verhees <bert.verh...@rosa.nl>
To: For openEHR technical discussions
<openehr-technical@lists.openehr.org>
Subject: Re: SV: [Troll] Terminology bindings ... again
Message-ID:
<cafl--x9otb+k-zef1lvzbjp8j6bge6d3dtq_pnc0hclkp92...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Mikael, very interesting. I will check if they do that in the
Netherlands too.
Bert
Op ma 26 mrt. 2018 08:10 schreef Mikael Nystr?m <mikael.nyst...@liu.se>:
> Hi Bert,
>
>
>
> Most countries (or big organizations) that start to use SNOMED CT
creates
> those kinds of subsets of SNOMED CT to make it more manageable. See for
> example NHS in England
> https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40 .
>
>
>
> Regards
>
> Mikael
>
>
>
>
>
> *Fr?n:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *F?r *Bert Verhees
> *Skickat:* den 23 mars 2018 20:01
>
>
> *Till:* openehr-technical@lists.openehr.org
> *?mne:* Re: SV: [Troll] Terminology bindings ... again
>
>
>
> Diego, this is a wise thought!!!
> It seems logical, but that is often in good ideas, they seem like:
why did
> no one ever think about this.
>
> No clinician handles the complete medical science/SNOMED repository
in his
> profession. Some even use a very small sub-part, think about a
dentist, a
> physiotherapist, a midwife
> For some is it also the case that not only the subjects are
different, but
> also how deep the details must go. For some professions it is not
> interesting to know if blood-pressure was measured lying or sitting.
>
> It looks like a good idea if the SNOMED repository will be split up for
> professions, maybe that needs to be done on national level, because the
> clinical profession-structure can differ in countries.
> The rest of the database should be there for second searches, for
> interpreting codes which come from other professions.
>
> I hope someone will pick up this idea, because it is hardly to be
done for
> individuals. It needs to be done by national SNOMED maintenance teams.
>
> Bert
>
>
> On 23-03-18 10:49, Diego Bosc? wrote:
>
> IMO having both representations (pre and postcordinated) is not bad
per se
> (in fact, knowing that they are equivalent is pretty good). The main
> problem is that technical people (including myself) shouldn't just
dump the
> entire snomed ct into a data field and call it a day. To design
better and
> useful systems you need a first "curation" phase where you define your
> relevant subsets that fit your system. The boundary problem is less of a
> problem if even if different terms were used when the record was
created we
> can assess that they are in fact the same thing.
>
> I think people are a little unaware of this step and causes problems as
> the ones you and Thomas mentioned
>
> 2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no>:
>
> I read Thomas? reply with great interest, and I generally agree that
with
> a well thought out information model, the very detailed precoordinated
> expressions are redundant. At the same time I understand Mikael?s
point of
> view too. BUT, what I?m often met with is that because these
precoordinated
> expressions exist (like for example ?lying blood pressure? and ?sitting
> blood pressure?), we should use them INSTEAD OF using our clever
> information models (that we do have) for recording new data.
>
>
>
> In my opinion this is wrong because it doesn?t take into account that
> healthcare is unpredictable, and this makes recording more difficult for
> the clinician. How many different variations would you have to
select from?
> Take the made up example ?sitting systolic blood pressure with a medium
> cuff on the left upper arm?; this will be a lot of possible
permutations,
> especially if you take into account all the different permutations where
> one or more variable isn?t relevant.
>
>
>
> So while I don?t think the existence of these precoordinated terms in
> itself is a problem, it?s a potential problem that people get a bit
> overzealous with them.
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical
<openehr-technical-boun...@lists.openehr.org> *On
> Behalf Of *Mikael Nystr?m
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>
>
>
> 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
> <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 or less any manner of
> pre-coordinated terms is allowed, with the precoordinations
cross-cutting
> numerous ontological aspects (i.e. concept model attribute types), what
> rules can even be established as to whether the next proposed
concept goes
> in or not? It is very easy to examine the BP hierarchy, and suggest
dozens
> of new pre-coordinated terms that would fit perfectly alongside the
> arbitrary and incomprehensible set already there...
>
> [image: cid:image001.png@01D3C4D9.150EDFC0]
>
> (another 3x)
>
> [image: cid:image002.png@01D3C4D9.150EDFC0]
>
> [image: cid:image003.png@01D3C4D9.150EDFC0]
>
>
> I've picked just the most obvious possible example. We can go and
look at
> 'substances' or 'reason for discharge' or hundreds of other things, and
> find similar problems. I don't mind that all these pre-coordinated
concepts
> exist somewhere, but they should not be in the primary hierarchies,
which
> really, in my view should look much more like an ontology, i.e. a
> description of reality which provides a model of what it is possible to
> say. If that were the case, the core would be much smaller, and the
concept
> model much larger than it is today.
>
> - thomas
>
> On 22/03/2018 00:26, michael.law...@csiro.au wrote:
>
>
>
> 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
>
>
>
>
>
> --
> 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
> openEHR-technical@lists.openehr.org
>
>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ>
>
> [image: Twitter] <https://htmlsig.com/t/000001C47QQH>[image:
> https://s3.amazonaws.com/htmlsig-assets/spacer.gif] [image: LinkedIn]
> <https://htmlsig.com/t/000001C4DPJG>[image:
> https://s3.amazonaws.com/htmlsig-assets/spacer.gif] [image: Maps]
> <https://htmlsig.com/t/000001BZTWS7>[image:
> https://s3.amazonaws.com/htmlsig-assets/spacer.gif]
>
> [image: https://s3.amazonaws.com/htmlsig-assets/spacer.gif]
>
> *Diego Bosc? Tom?s* / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> *VeraTech for Health SL*
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su direcci?n de correo electr?nico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF
B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a
La Ley
> Org?nica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificaci?n, cancelaci?n y, en su caso oposici?n, enviando una
solicitud
> por escrito a verat...@veratech.es.
>
>
>
>
> _______________________________________________
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20180326/e043d587/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 30114 bytes
Desc: not available
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20180326/e043d587/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 20006 bytes
Desc: not available
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20180326/e043d587/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 20446 bytes
Desc: not available
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20180326/e043d587/attachment-0002.png>
------------------------------
Subject: Digest Footer
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
------------------------------
End of openEHR-technical Digest, Vol 73, Issue 86
*************************************************
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
