Thomas, I agree with your opinions.
In summary: Model 1- Ontological models define primitive concepts in Terminologies. Concepts that one can expect to see in a dictionary. Model 2- Archetypes define compound concepts using primitive concepts from terminologies. Archetypes are models that model a concept and its epistemology/context. Archetypes are agreed re-usable patterns and are like sentences constructed using syntax and words from a dictionary. This is the level where post-coordination takes place. Model 3- Templates are specific models composed of Archetypes defining the content of an interface (database, screen, clinical reasoner, etc) Templates are temporal, locally defined, chapters and paragraphs defining/documenting patient data obtained in the healthcare process. Model 4- For specific reasons users might want to see pre-coordinated terms on screens, or statistical reporting demand it. This means that raw data obtained using Model 3 can be converted to pre-coordinated terms from a Terminology. It is a User Interface issue. All models are orthogonal to each other and intersect at well defined places. Models can not be mixed and overlap. When they do, the problem is intractable. Next to these 4 models we need additional models: - Healthcare Process (ContSys) - Documentation process (Observation Process, Evaluation Process, Planning Process, Ordering process, Execution Process, Administrative processes) - … Gerard Freriks +31 620347088 [email protected] Kattensingel 20 2801 CA Gouda the Netherlands > On 23 Mar 2018, at 01:06, Thomas Beale <[email protected]> wrote: > > 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... > > <ppjianhjhcodalbd.png> > (another 3x) > <kkchmaphadmcmdfa.png> > <igenjofddgondidi.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>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
