Okay. Do you have a technical description of what you are talking about? Thanks Bert
Op za 31 mrt. 2018 12:31 schreef GF <gf...@luna.nl>: > In my opinion there is something essential missing, so far. > What is missing is a collection of standard Cluster archetypes/Patterns > that can be used to create any story, describing the > observation/evaluation/planning/ordering and action processes including all > the possible contexts. > All the Archetype Patterns create one Documentation ontology. > > That Documentation ontology as grammar combined with a terminology like > SNOMED and LOINC looks like Phillipe's system. > > > Gerard Freriks > +31 620347088 > gf...@luna.nl > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > > On 31 Mar 2018, at 11:38, Philippe Ameline <philippe.amel...@free.fr> > wrote: > > 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... >> > <image001.png> >> >> (another 3x) >> >> <image002.png> >> >> <image003.png> >> > >> 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 > > _______________________________________________ > 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
