What I say is that legacy applications or current systems usually offer limited options with the knowledge available when they were created. These options were decided back in the day and usually fit with precoordinated terms. And defining this subsets helps on going forward
El sáb., 31 mar. 2018 22:14, Philippe Ameline <philippe.amel...@free.fr> escribió: > Some people (count me in) strictly ban what you call precoordination (that > I call "aglutinating language") because they believe that there is a nearly > infinite set of them and such a system is born to "explode" as the frog > that wanted to mimic the ox. > > To put it differently: you cannot express all possible discourses as > predetermined concepts. > > Do I interpret your answer correctly if I say that you have an optimist > vision in the form "there is a limited number of clinically sound > precoordinations so that SNOMED expansion will reach an asymptote that keep > being manageable"? > > Le 31/03/2018 à 20:55, Diego Boscá a écrit : > > What I was referencing was one way in which current systems (or more > exactly, their developers) could use codes already available in Snomed to > create subsets of their forms, regardless their input forms have > precoordinated options or use some kind of postcoordination mechanism. By > defining these subsets, you are making this form comparable with other > similar forms (that use other approaches to store similar information). It > isn't about making doctors in the same organization being able to have > *new* ways of encoding things, is about taking the forms they currently use > and encode them in order to be comparable with data in other organizations > (and in principle, they don't even need to be aware of this codification). > With this, we can make data have a meaning outside their original systems. > > This is why I say that precoordination in snomed is a good thing. They are > terms that have been put in a form somewhere, and having them as is, and at > the same time having their undelying equivalent postcoordinated expression > helps in softening the boundary problem IMHO. > I'm always up to go into the future inventing new cool things, but at > least in healthcare we are not allowed to lose data already available in > current systems. > > 2018-03-31 11:38 GMT+02:00 Philippe Ameline <philippe.amel...@free.fr>: > >> Diego, >> >> IMHO your contribution is orthogonal to what Thomas very accurately >> explained. Building subset is a symptom of the issue, not a solution. >> >> As I tried to explain in my initial post, we are currently facing two >> generation of technologies in medicine: >> - systems that record information as trees of atomic concepts, in the >> same way we are all exchanging in "globish" by inserting English concepts >> in a grammatical structure, >> - systems that still rely on a fixed database schema and usually have a >> "discourse system" limited to field/value pairs. >> >> When I try to explain all this to lesser tech-savvy people (means, who >> don't belong to this list ;-) ), I usually explain that: >> - usual systems (with an information schema tied to a database schema) >> are like a printed form. The day after you received the 5000 printed sheet >> you ordered, you will realize that there are several design flaws that you >> will have to endure while the stock is not empty, >> - openEHR is a flexible schema, similar to a set of stamps that lets you >> build forms dynamically from blank paper. If your design has to evolve, you >> just have to adapt one of the stamps. >> - in my system, based on an ontology and a dependency grammar, you can >> use stamps (archetypes like) and/or "write" freely. >> >> I have always understood openEHR as a link, a step, between the "good old >> way" (discourse range hard coded into a database schema) and a modern >> approach where you can really "tell a patient story" using a genuine >> (structured, processable) language. 15 years ago, Thomas and I spent hours >> discussing the opportunity for openEHR to include a reference ontology in >> its kernel ; this decision was not made for very good reasons, but I guess >> that it still remains a necessary evolution. >> >> Thomas very accurately explained why SNOMED is a deceptive candidate for >> such a reference ontology. And, unfortunately, it is deep rooted in its >> origins as a coding system. I can hear all the arguments about "legacy >> system" and even "legacy medicine" (the one still fully organized for >> siloed acute care at a time our society already entered the information age >> and suffers from chronic diseases). The question remains to guess if SNOMED >> is a component that lets you stuck in the past or helps you disrupt the >> legacy craps. >> >> Now, let's imagine a modern system that would allow you to "tell a >> patient medical story" from the various viewpoints of a multidisciplinary >> patient centered team. What would be the point about having "local >> vocabulary subsets"? Do you think that a GP shouldn't use the word "mitral >> leak" or any other "specialized" word in the medical vocabulary? >> >> My feeling is that selected subset is a solution when using SNOMED as a >> coding system. The subset being the global list of values that are legal >> for the fields in the existing schema, in the same way you will select >> subsets in a billing system. But when it comes to "telling a story" using a >> language, in my opinion subsets are a non-sense. We don't use "vocabulary >> subsets" when we talk, and each contributor in a patient's team would >> mechanically get exposed to a super-set; subset is actually only fit for >> silos... and at a time when medicine is already becoming a narrow silo in >> health, I really don't see it as a sound strategy. >> >> Best, >> >> Philippe >> >> Le 23/03/2018 à 10:49, Diego Boscá a écrit : >> >> 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... >>> >>> (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, 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: LinkedIn] >> <https://htmlsig.com/t/000001C4DPJG> [image: Maps] >> <https://htmlsig.com/t/000001BZTWS7> >> >> 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 >> listopenEHR-technical@lists.openehr.orghttp://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 >> > > > > -- > > [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ> > > [image: Twitter] <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn] > <https://htmlsig.com/t/000001C4DPJG> [image: Maps] > <https://htmlsig.com/t/000001BZTWS7> > > 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 > listopenEHR-technical@lists.openehr.orghttp://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
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
