Sorry, I am reading on my phone and it seems I missed an email. I read further day after tomorrow when I have a descent email client.
Best regards Bert Op za 31 mrt. 2018 13:06 schreef A Verhees <[email protected]>: > Okay. Do you have a technical description of what you are talking about? > > Thanks > Bert > > Op za 31 mrt. 2018 12:31 schreef GF <[email protected]>: > >> 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 >> [email protected] >> >> Kattensingel 20 >> 2801 CA Gouda >> the Netherlands >> >> On 31 Mar 2018, at 11:38, Philippe Ameline <[email protected]> >> 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 < >> [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... >>> >> <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, [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: LinkedIn] >> <https://htmlsig.com/t/000001C4DPJG> [image: Maps] >> <https://htmlsig.com/t/000001BZTWS7> >> >> 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 >> [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 > >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
