Maybe a match-table which matches pre coordinated expressions to all possible post coordinated expressions which have the same meaning will be necessary.
How can you else find data-entries of a specific meaning by filtering on SNOMED? Bert Op 23 mrt. 2018 10:35 schreef "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 <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- > [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... > > (another 3x) > > > 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 >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
