Re: openEHR-technical Digest, Vol 80, Issue 12
Hi all, It's been a while since I've seen it but I think Pablo Pazos has some quite good work for that topic on EHRServer, at least for subsumption [ https://ppazos.github.io/cabolabs-ehrserver/ mentions "Support of SNOMED CT Expressions on openEHR queries (simplifies complex queries)"]. There is also a demonstration video on YouTube. With regards to binding to the model, though, things might be tricky. Cheers, Ricardo Gonçalves. Em seg, 19 de nov de 2018 às 17:21, < openehr-technical-requ...@lists.openehr.org> escreveu: > Send openEHR-technical mailing list submissions to > openehr-technical@lists.openehr.org > > 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 > openehr-technical-requ...@lists.openehr.org > > You can reach the person managing the list at > openehr-technical-ow...@lists.openehr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openEHR-technical digest..." > > > Today's Topics: > >1. Re: Postcoordinated terminology expressions in openEHR > (Thomas Beale) >2. Re: Postcoordinated terminology expressions in openEHR > (Ian McNicoll) > > > -- > > Message: 1 > Date: Mon, 19 Nov 2018 15:38:52 + > From: Thomas Beale > To: openehr-technical@lists.openehr.org > Subject: Re: Postcoordinated terminology expressions in openEHR > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > I mostly agree with Ian, but with the small caveat that for very > specific and well-known cases such as body laterality, you just /might > consider/ post-coordination on body site e.g. > > * 56459004 |foot structure| : 272741003 |laterality| = 7771000 |left|) > > However, even here, laterality often seems to be divided out in various > ways depending on what you are talking about. E.g. anything to do with > eyes, the whole exam is per-eye rather than each finding being marked as > being on the 'eye, left' or 'eye, right'. In other places, 'left' and > 'right' don't even have symmetrical meanings e.g. the heart (think > left-branch bundle etc). > > Nevertheless, for those body sites where findings are reported as being > on some X+left or right, I think we probably should consider > post-coordination of the site and the laterality at some point. For > everything else, it's a nice idea but forget it in data models. > > Where it could be used is via a /mapping formula /for multiple data > points, e.g. in an archetype. The archetype data would be defined > populated as a structure (as today), but a 'post-coordination formula' > that indicates how to bind the values of particular coded elements > together to obtain a Snomed expression could be used to generate such > expressions from the data, for consumption by inference engines. This is > the only place where they can be usefully computed with, in my opinion. > > Such a formula might look like this: > > * 47933007 |$pain_finding| : 363698007 |finding_site| = ( > $finding_site: 272741003 |laterality| =? $laterality) > > where $pain_finding, $finding_site and $laterality are bound to paths in > the archetype. > > If the formula were evaluated, it might give this: > > * 22253000 |pain| : 363698007 |finding site| = ( 56459004 |foot > structure| : 272741003 |laterality| = 7771000 |left| ) > > With minor adjustments in the binding part of the ADL2 grammar, such > formula bindings could be accommodated fairly easily I would think. > > Note: this is speculation, and has never been tried as far as I know. > Even if it does, it's only for SNOMED, unless the SNOMED model of > post-coordinated expressions is adopted by other terminologies... > > - thomas > > > On 19/11/2018 13:32, Ian McNicoll wrote: > > Basically - don't!! > > > > The UK has been trying to do this for over 20 years without success. > > It is a terminologists?dream but implementers?nightmare. > > > > Make a start with high-value use cases e.g Allergy agent "Allergic > > to?+ causative?agent" - so that you do not have to generate a new > > Snomed code for every potential allergen. > > > > Perhaps consider laterality. Beyond that, you risk delaying SNOMED?CT > > implementation, as has happened in the UK. > > > > Post-coordination is like nuclear fusion - a damned good idea but > > tricky to do without blowing everything up. > > > > Ian > > Ian &g
Re: [Troll] Terminology bindings ... again
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, openehr-technical-requ...@lists.openehr.org <openehr-technical-requ...@lists.openehr.org> wrote: Send openEHR-technical mailing list submissions to openehr-technical@lists.openehr.org 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 openehr-technical-requ...@lists.openehr.org You can reach the person managing the list at openehr-technical-ow...@lists.openehr.org 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: openehr-technical@lists.openehr.org 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
Re: openEHR-technical Digest, Vol 72, Issue 4
On the "putting together a web frontend and a Java backend" topic, it may be interesting to look at Vaadin, which is an open source framework to build web applications using Java (you code everything in Java, an equivalent GUI is generated and all behavior that comes from user interaction is actually triggered on the backend through a protocol like RPC; pretty much like the old GWT but smarter and with less boilerplate code). They also have a dev preview on something called Flow, which is supposed to give a Java backend direct access to the DOM, somewhat similar to real-time server-side rendering but with an optimised communication protcol instead (no need to care about APIs, REST, whatever). Anyway, since we're already on a Java ecosystem, those may be easier than modeling APIs and adopting JavaScript frameworks that may or may not be alive tomorrow. Att., Ricardo Gonçalves. On 06/02/2018 15:00:31, openehr-technical-requ...@lists.openehr.org <openehr-technical-requ...@lists.openehr.org> wrote: Send openEHR-technical mailing list submissions to openehr-technical@lists.openehr.org 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 openehr-technical-requ...@lists.openehr.org You can reach the person managing the list at openehr-technical-ow...@lists.openehr.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openEHR-technical digest..." Today's Topics: 1. Re: Announcing Archie version 0.4 (Thomas Beale) -- Message: 1 Date: Mon, 5 Feb 2018 19:04:35 -0300 From: Thomas Beale To: openehr-technical@lists.openehr.org Subject: Re: Announcing Archie version 0.4 Message-ID: <5e6cf155-c2ea-cf69-a8d0-402ed025c...@openehr.org> Content-Type: text/plain; charset="utf-8"; Format="flowed" yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. Just that JS/TS are the languages that seem to be popular for web app development these days, and Java for the back-end. The connection between front and back-end that people seem to prefer these days is REST APIs, which both Java and JS can do easily enough. - thomas On 03/02/2018 07:56, Peter Gummer wrote: > On 1 Feb 2018, at 05:13, Thomas Beale > > wrote: >> >> ... But the main interest is that we will be able to build new tools >> such as a Java/JS replacement for the ADL Workbench, and of course >> things like a high-quality, BMM-driven runtime archetype validating >> kernel for EHR systems, workflow implementations and many other >> components. >> > > Hi Thomas, does ?JS? stand for JavaScript? If so, I don?t understand > how Archie (written in Java, disappointingly) would enable JavaScript > implementations. JavaScript has nothing in common with Java (apart > from the name). > > Peter > > > > ___ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Thomas Beale Principal, Ars Semantica Consultant, ABD Team, Intermountain Healthcare Management Board, Specifications Program Lead, openEHR Foundation Chartered IT Professional Fellow, BCS, British Computer Society Health IT blog | Culture blog -- next part -- An HTML attachment was scrubbed... URL: -- Subject: Digest Footer ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- End of openEHR-technical Digest, Vol 72, Issue 4 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
