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] >> <mailto:[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] >> <mailto:[email protected]>> On Behalf Of Mikael >> Nyström >> Sent: Friday, March 23, 2018 10:06 AM >> To: For openEHR technical discussions <[email protected] >> <mailto:[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] >> <mailto:[email protected]>] För Thomas Beale >> Skickat: den 23 mars 2018 01:06 >> Till: [email protected] >> <mailto:[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] >> <mailto:[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] >> <mailto:[email protected]> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >> >> >> >> -- >> <https://htmlsig.com/t/000001C268PZ> >> <https://htmlsig.com/t/000001C47QQH> >> <https://htmlsig.com/t/000001C4DPJG> <https://htmlsig.com/t/000001BZTWS7> >> Diego Boscá Tomás / Senior developer >> [email protected] <mailto:[email protected]> >> [email protected] <mailto:[email protected]> >> VeraTech for Health SL >> +34 961071863 <tel:+34%20961%2007%2018%2063> / +34 627015023 >> <tel:+34%20627%2001%2050%2023> >> www.veratech.es <http://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] <mailto:[email protected]>. >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> <mailto:[email protected]> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> <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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
