Hi everyone, After following this thread for a few days, I decided to jump in with my two cents because either things got too rethorical while looking for a state of art solution matching particular experiences or I'm missing the point more than I should.
Historically, statistical classifications such as ICD10 and ICPC2 have been used in health [informatics] (even on handwritten forms, for ranking purposes). They are as easy to understand/use as their taxonomy allows them to be, but the added value is limited to such scope. They are also pretty close to the way generic binding is currently handled (matching and validating code/term pairs). SNOMED CT is not perfect and is not simple, but we cannot demand to oversimplify such a complex matter. It encompasses a lot of work to achieve a formal ontology that allows both people and machines to understand | fracture | : | finding site | = | ankle | in multiple idioms. I think it's quite effective as a "language" (yet not trivial, but again, to get the mass to accelerate, some force must be applied). In spite of the meaning on it's own, that expression can also be easily computed to a preecoordinated concept (if one exists and is required, e.g. | fracture of ankle |) or to a set of concepts that match the described meaning (even if you don't know all of them beforehand, but just some basic/critical defining attributes/relationships) so the professional can get filtered suggestions (supported by a capable health application/system, just like they already do with statistical classifciations/coding systems). It also allows you to query/retrieve the same data point despite being coded as (| fracture | : | finding site | = | ankle |) or | fracture of ankle |. Actually, it allows even more due to customization and localization. I too want to look at the the future and picture a state of art component and hopefully a [health] technological utopia, but a lot of work led us to what is currently available. Are we taking that to try/improve things and get somewhere? Are we holding back until something more mature, more usable, more future-alike comes up? Which path is more likely to bring us closer to the goal? Best regards, Ricardo Gonçalves. On 15/03/2018 13:00:06, [email protected] <[email protected]> wrote: Send openEHR-technical mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of openEHR-technical digest..." Today's Topics: 1. Re: [Troll] Terminology bindings ... again (Philippe Ameline) ---------------------------------------------------------------------- Message: 1 Date: Thu, 15 Mar 2018 16:17:51 +0100 From: Philippe Ameline To: [email protected] Subject: Re: [Troll] Terminology bindings ... again Message-ID: Content-Type: text/plain; charset=utf-8 Le 15/03/2018 ? 00:34, Mikael Nystr?m a ?crit?: > Hi Philippe > > It seems like you are making a big deal of that SNOMED?CT is an ancient > product, but I would like to see your explicit arguments about that instead > of only negative generalizations. From my point of view it is quite modern > with an OWL based ontology with additional features for terminology and > versioning, which basically is what SNOMED CT are. > > Regards > Mikael Hi Mikael, The question will always remain "what component do you need at a given technological moment?" If what you want to do is what has been done since 1980, that's to say fill forms inside a care place and exchange it with other care places, I guess that Snomed CT is the proper component. Since it was born a coding system, you can create complicated meta-concepts in a single code (of course, it means you will have to find your own subset inside an always expanding universe, but ease comes with a price) and it is very convenient to fill the good old set of attribute?value pairs. On the contrary, if you estimate that a modern approach would be to tell and organize a patient's journey, you have to exhibit more modern structures because in order to "tell something", you need not only a terminology (say a vocabulary) but also a grammar. A proper grammar (at least the one I use) can be a "dependency grammar" in the form of a graph or trees. Now that you can tell elaborated things using a vocabulary (the ontology) and a grammar (the graph of trees), the "agglutinating" structure of Snomed rapidly sucks. Because now that "fracture of the left ankle" can be expressed as the branch "fracture" "located at" "left ankle", there is no longer a need for the hundred of thousand (and counting) "codes" that where convenient for ancient systems but are now a genuine problem. Do you imagine a natural language that would be so massively agglutinating that it would contain words like "FractureOfTheLeftAnkleThatWasTreatedButStillHurts"? I guess that, due to a terrible learning curve, the children would speak at six ;-) To sum it up, Snomed is probably convenient for application with a structure schema that can only handle a coding system (hey, it also comes with a semantic network) but is not fit as a formal language vocabulary. Best, Philippe ------------------------------ Subject: Digest Footer _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ------------------------------ End of openEHR-technical Digest, Vol 73, Issue 47 *************************************************
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
