Gerard, I like your rule (build a grammar that coordinates a vocabulary of "atomic concepts" instead of agglutinating meta-concepts in the vocabulary), but not your "left eye" example ;-)
In my own "universe", the "left eye" is a true physical object (when "eye" is a concept). I would say the same thing about the "left common carotid artery" which is something you can actually "touch". Representing this concept as an artery which belongs to the carotid network on the left part of the body is not pre-coordination but rather what could be expressed by a semantic network. I agree with your "blue eye" example since it is simply "an eye which color is blue". To answer Mikael Nyström in the same message, I would be OK with his conclusion about "the simple solution is to not use what you don't need" if : - this task had not been unsuccessfully tested by Belgian GPs, who literally spent years trying to select a subset with no avail, - this "language" was not advertised as a communication system... which actually keeps you exposed to the full set unless everyone agrees to a common subset (using Tom's proposals and Gerard's rule, for example). Mikael is right when he says that it would be unfair to say that Snomed "is bad because it isn’t optimized for [one's] narrow use case"... unless there are lots of narrows use cases needed and unless one of these narrow use cases is key to the next mainstream use case. If innovators (typically the ones with weird use cases) consider Snomed as a millstone around their necks, it is actually an issue worth considering. As pointed before in this thread, this conversation is closely related to HL7 V3 and its RIM before it was "fhired". Best, Philippe Le 22/03/2018 à 14:26, GF a écrit : > One simple rule solves the boundary problem. > > In my words. > In principle models we use in the Semantic Stack are autonomous and > orthogonal to each other. Meaning that at _precisely_ defines points > the intersect, > SNOMED is an ontology defining terms for concepts. > Concept can be primitive or compound. > Primitive concept examples are: Left and Right and Eye, White, Red and > Blue. All terms one expects in a dictionary. > Compound concepts are pre-co-ordinated concepts: Left Eye, Right Eye. > Eye White coloured Red, ‘Blue eye’. All terms one expects in a > pattern/standard phrase using words from a dictionary in a syntax. > > The rule is: > Pre-coordination is done via Archetype/Patterns using Primitive concepts. > Pre-coordination is not done via an ontology/terminology. > > Off course clinicians on their screens or doing statistics need > Compound concepts and therefor need pre-coorodinated terms. > These pre-coordinated terms must never be used to store, retrieve, > interpret raw health data inside Health IT-systems. > > > Gerard Freriks > +31 620347088 > gf...@luna.nl <mailto:gf...@luna.nl> > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > >> On 22 Mar 2018, at 00:46, Heather Leslie >> <heather.les...@atomicainformatics.com >> <mailto:heather.les...@atomicainformatics.com>> wrote: >> >> Hi Mikael, >> >> What efforts are being made to resolve the boundary problem? >> >> I applied to get involved with the SNOMED information modelling >> group but wasn’t successful, to try to engage on exactly that point. >> >> I’m not aware of any work going on. I’d be very pleased to get >> involved if I could. It’s a fiendish problem and we need cooperation >> and collaboration from both sides of the fence. >> >> Regards >> >> Heather >> >> *From:* openEHR-technical >> <openehr-technical-boun...@lists.openehr.org >> <mailto:openehr-technical-boun...@lists.openehr.org>> *On Behalf >> Of *Mikael Nyström >> *Sent:* Thursday, 22 March 2018 1:00 AM >> *To:* For openEHR technical discussions >> <openehr-technical@lists.openehr.org >> <mailto:openehr-technical@lists.openehr.org>> >> *Subject:* SV: SV: [Troll] Terminology bindings ... again >> >> Hi Tom, >> >> I believe that you proposal to ”move / remove the pre-coordinated >> codes out of SNOMED” is very appealing in theory. However it is very >> difficult in reality to agree on where the line between a suitable >> pre-coordinated concept and a concept that is better to >> post-coordinate or handle in another way are. The line between the >> two alternatives also seem to be use case dependent, which makes it >> even more difficult, and of cause also related to the boundary >> problem. However, until there is a strong agreement on where the line >> should be I continue to believe that it is better so include the >> concepts in the same pile and let each use case decide how to select >> the concepts they need and transform between the different >> representations. >> >> I like discussions about SNOMED CT and I don’t have any problems at >> all with critical comments as long as they are fair. Those kinds of >> criticism quite often makes me writing change requests. I am also >> happy to answer questions about SNOMED CT. However, I and several >> other people that are involved in the SNOMED CT community are quite >> tired of people that argue that SNOMED CT is bad based on incorrect >> facts and/or SNOMED CT is bad because it isn’t optimized for their >> narrow use case. >> >> Regards >> Mikael >> >> *Från:* openEHR-technical >> [mailto:openehr-technical-boun...@lists.openehr.org] *För *Thomas Beale >> *Skickat:* den 21 mars 2018 14:17 >> *Till:* openehr-technical@lists.openehr.org >> <mailto:openehr-technical@lists.openehr.org> >> *Ämne:* Re: SV: [Troll] Terminology bindings ... again >> >> >> >> >> Nevertheless, I think it would have been good to move / remove the >> pre-coordinated codes out of SNOMED, and leave a pure >> post-coordinatable core, which would actually look a lot more like >> Philippe's (much smaller) terminology. >> >> This relates to the old debate on reference v interface terminology, >> and just throwing out precoord concepts is probably not right - they >> need to be in a completely different hierarchy. >> >> The post-coordination grammar in SCT is good, its theoretical >> challenge is the concept meta-model, i.e. what things like >> 'morphology', 'laterality' you can mention, and in what relationship. >> But this is hard for all of us, and requires some serious ontology >> work (Mikael and other experts know all about this of course). >> >> What I would say is this: in a similar way that I think SNOMED should >> have separated out 'SNOMED technology' (representation, APIs etc) >> from content, I think the concept meta-model should have been / could >> be made a separate artefact, maybe even an OBO ontology - at the >> moment it is too hidden inside the giant content artefact. If that >> were done, we could work more effectively on aligning with >> information / content models, whose attribute names should, generally >> speaking relate to (or be the same as) the meta-model ontology >> entities. If we pursued this line, the ontology would instantly be >> expanded by examination of archetypes, and conversely, many >> archetypes could be fixed where they contain errors or questionable >> attribute names. >> >> THis isn't to criticise experts or work done in SNOMED per se, but we >> should be perfectly happy to /critique/ SNOMED, as long as that >> critique is collegial, and above all intelligent. (BTW maybe Philippe >> was not entirely diplomatic, but he did implement a very nice >> post-coordinating terminology and clinical noting system, so he knows >> a thing or two). >> >> So in that sense, I stand by my earlier comments that it would have >> helped (and still would help) if SNOMED International would consider >> some of my suggestions on separation of technology from content, >> separate the meta-model, and also a more serious effort to help >> connect terminology to information models / content models. We are >> slowly solving this on our side, but strategic cooperation would be >> better. >> >> One thing is clear: terminology is not a standalone proposition. >> >> - thomas >> >> >> On 21/03/2018 13:48, Mikael Nyström wrote: >> >> Hi Philippe, >> >> >> >> I think that you have missed that SNOMED CT is created for >> multiple use cases. >> >> >> >> Your use case that you describe as "a modern approach" is a good >> use case that I like. In that use case SNOMED CT can be used in >> the way you describe using SNOMED CT's concepts a little higher >> up in the hierarchies together with SNOMED CT Compositional >> Grammar and SNOMED CT's concept model. >> >> >> >> Another use case, that many implementers consider is important >> but you don't seem to care about, is the ability to handle legacy >> data to be able to keep a life-long health record. Most people >> alive today where born when simple health records that only used >> simple coding where in massive use. (When that era started and >> (potentially) ended is up to the reader to decide...) To cater >> for information that are more of legacy information, SNOMED CT >> also has concepts that can represent that kind of information. >> But SNOMED CT also has a machinery to transform between the >> different representations. Your example "fracture of the left >> ankle" is not possible to express using a single concept from >> SNOMED CT, but if it had been possible it had been possible to >> automatically transform that concept to the expression below, >> which seems like to be what you argue for in your "modern >> approach" use case. >> >> >> >> 64572001 | Disease (disorder) | : >> >> { 363698007 |Finding site| = >> >> {33696004 |Bone structure of ankle (body structure)| : >> 272741003 |Laterality| = 7771000 |Left (qualifier value)|}, >> >> 116676008 |Associated morphology| = 72704001 |Fracture >> (morphologic abnormality)| >> >> } >> >> >> >> I therefore find your arguments against SNOMED CT equally >> relevant as arguments of the type >> >> >> >> "SNOMED CT is useless, because it contains the concepts 285336007 >> | Background radiation (physical force) |, 60638008 | Planetary >> surface craft, device (physical object) | and 242250006 | Crash >> landing of spacecraft (event) | and I don't need that kind of >> concepts at my clinic." >> >> >> >> because the simple solution is to not use what you don't need. >> >> >> >> Regards >> >> Mikael >> >> >> >> >> -- >> 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 >> <mailto: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
