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 <[email protected]>: > 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: > [email protected]] *För *Bert Verhees > *Skickat:* den 23 mars 2018 20:01 > > > *Till:* [email protected] > *Ä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 < > [email protected]>: > > 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 <[email protected]> *On > Behalf Of *Mikael Nyström > *Sent:* Friday, March 23, 2018 10:06 AM > *To:* For openEHR technical discussions < > [email protected]> > *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:[email protected] > <[email protected]>] *För *Thomas Beale > *Skickat:* den 23 mars 2018 01:06 > *Till:* [email protected] > *Ä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:[email protected]] > > (another 3x) > > [image: cid:[email protected]] > > [image: cid:[email protected]] > > > 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, [email protected] 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 > [email protected] > > 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 > [email protected] > [email protected] > > *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 [email protected]. > > > > > _______________________________________________ > > openEHR-technical mailing list > > [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
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
