Check the initial messages on the thread. Basically how to use SNOMED in openEHR, and in a specific area: data querying. AQL support for SNOMED codes and expressions was an initial part of the topic.
We are trying to solve a basic problem: how to get data out the systems in a smart way. This is because archetypes are good but don't have context that terminologies have, and AQL is good but only queries what is defined by models. So we need something to query over terminologies in combination with querying over models. Reasoning, interpretation and modeling approaches are other orthogonal problems. This is a very specific problem for the openEHR specs and ITS, is not a general problem to solve. On Tue, Apr 3, 2018 at 4:31 AM, A Verhees <bert.verh...@rosa.nl> wrote: > Can we specific define in about ten words which problem is talked about in > this discussion? > > Maybe we can then use that definition as a guideline to keep the > discussion focussed. > > Best regards > Bert Verhees > > Op di 3 apr. 2018 01:19 schreef Pablo Pazos <pablo.pa...@cabolabs.com>: > >> Please see below, >> >> On Mon, Apr 2, 2018 at 6:17 PM, GF <gf...@luna.nl> wrote: >> >>> Is that so? >>> >>> There will be systems that allow pre-coordinated codes. There will be >>> systems that use as many pre-coordinated codes. And several in between >>> solutions. >>> >> >> I agree, there will be systems that allow and use pre and post >> coordinated codes, that is a fairly normal requirement in clinical >> information systems and openEHR specs supports that. >> >> >>> This means that reasoners will be used to create transformations. >>> >> >> It doesn't mean that, I don't see where that is implied. >> >> Some systems might use reasoners using ontologies, rules, codes and other >> content, to infer some "facts", and the results should be interpreted in >> the same context as the ontologies, rules, clinical records and codes are >> created, managed and used. Inferred facts are context dependent. >> >> Some other systems might not use any reasoners or ontologies at all, and >> define programmatic rules that use SNOMED codes and expressions (pre and >> post coordinated), and other contextual clinical / demographic / >> administrative information to evaluate those rules and get some result (an >> alert, a recommendation, a reminder, etc.) >> >> And other systems might not have rules at all and just use codes, >> expressions and contextual data to create some visual representation of the >> patient's status, to be presented to a clinician and make him/her evaluate >> the data and make a decision. This is the most basic area we should cover, >> and what originally generated this discussion: how to use SNOMED in openEHR >> queries. >> >> Use cases are many, we can't focus on just one area and generalize from >> there. >> >> >>> It is likely that ontological servoces will be used, And then we will >>> have a potential problem. >>> >> >> That will really depend on specific implementations. I don't think >> proposing a combination of standards with a lot of potential will cause any >> issues per se. >> >> >> >>> But perhaps solvable with the correct precautions. >>> One being that ontological servoces are NOT used and that ad hoc rules >>> do the transform. >>> >> >> That is exactly my point from above, automatic conclusions from a >> reasoner or any AI can be interpreted as a general truth on any context. >> Those conclusions should be interpreted in the same context as data and >> knowledge was created. And semantics should be given by humans on a >> per-context basis. >> >> >> >>> What possible solution is the canonical one? which is the ‘golden truth’. >>> >> >> Since all that ^ is context-dependent, I don't think there is any >> canonical form or golden truth. >> >> >>> >>> When we add to all this that only part of the epistemology can be >>> pre-coordinated it means that part of the temporal aspects for instance can >>> NOT be dealt with in SNOMED, then we have the situation that part of the >>> epistemology is in SNOMED and part defined in the Archetype/Template. >>> >> >> I agree and that is a good example of what I call "context" (how and >> where knowledge and information is defined, managed and used, very related >> to epistemology :) >> >> >>> >>> >>> Gerard Freriks >>> +31 620347088 <+31%206%2020347088> >>> gf...@luna.nl >>> >>> Kattensingel 20 >>> 2801 CA Gouda >>> the Netherlands >>> >>> On 2 Apr 2018, at 20:02, Pablo Pazos <pablo.pa...@cabolabs.com> wrote: >>> >>> Yes, but the main topic here is the use of SNOMED inside openEHR, so >>> there is no terminology world separated from the content modeling and data >>> recording world. We will use SNOMED inside the openEHR context, so the >>> SNOMED meaning will be constrained by the openEHR meaning when recording >>> clinical information. We should be constraint to that context. >>> >>> On Mon, Apr 2, 2018 at 6:01 AM, GF <gf...@luna.nl> wrote: >>> >>>> Pablo, >>>> >>>> It is as Thomas and I wrote. >>>> >>>> *Open world Assumption:* Ontologies declare absolute truths >>>> irrespective of geographical location and point in time. >>>> >>>> *Closed World Assumption*: Archetypes help express what an author >>>> wants to document. These are very subjective truths at a point in time. >>>> >>>> This subtle but important distinction is only one of the reasons to >>>> refrain from the use of pre-coorodinated SNOMED terms. Things like these >>>> matter when we start to reason about the documented patient data. >>>> >>>> Gerard Freriks >>>> +31 620347088 <+31%206%2020347088> >>>> gf...@luna.nl >>>> >>>> Kattensingel 20 >>>> 2801 CA Gouda >>>> the Netherlands >>>> >>>> On 2 Apr 2018, at 01:11, Pablo Pazos <pablo.pa...@cabolabs.com> wrote: >>>> >>>> I'm sorry but "...no cancer was, is, or will be present." doesn't even >>>> make sense. No system can record what can or can't happen in the future, >>>> and that concept is not part of any terminology AFAIK. >>>> >>>> On Sun, Apr 1, 2018 at 7:35 PM, GF <gf...@luna.nl> wrote: >>>> >>>>> Thomas, >>>>> >>>>> OpenEHR and 13606 deal with Closed World Assumption systems. >>>>> And therefor both mean in the case of 'No Cancer' that Cancer was not >>>>> found in the database or that No Cancer was the documented result of an >>>>> evaluation. >>>>> Both statements are documented things in a Template that according to >>>>> the author cancer is not found. >>>>> But any time in the future it might. >>>>> >>>>> 'No Cancer' as pre-coordinated term in the case of SNOMED means that >>>>> no cancer was, is, or will be present. >>>>> >>>>> Gerard Freriks >>>>> +31 620347088 <+31%206%2020347088> >>>>> gf...@luna.nl >>>>> >>>>> Kattensingel 20 >>>>> 2801 CA Gouda >>>>> the Netherlands >>>>> >>>>> On 1 Apr 2018, at 14:41, Thomas Beale <thomas.be...@openehr.org> >>>>> wrote: >>>>> >>>>> >>>>> On 01/04/2018 13:16, GF wrote: >>>>> >>>>> Pre-coordinated SNOMED codes are like classifications, in that they >>>>> are used at the user level, the User Interface, >>>>> The Ontology behind SNOMED allows the pre-ordinated codes to be >>>>> decomposed in its constituents. >>>>> These decomposed primitive codes can be used in structures like >>>>> archetypes at the proper places. >>>>> In this way the pre-coorodinated SNOMED codes are iso-semantic. >>>>> >>>>> But we keep the semantic differences codes expressed using the SNOMED >>>>> ontology and the Archetype and its codes. >>>>> Ontologies have the Open World Assumption. A pre-corodinated code >>>>> like: No-Cancer means never there was, is or will be cancer. Ontologies >>>>> describe reality. >>>>> In archetypes that use the Closed World Assumption Diagnosis=cancer, >>>>> PresenceModifier=No means No Cancer found but perhaps they are. It just >>>>> was >>>>> not found. Presence of absence in a database are described. >>>>> >>>>> >>>>> I'm unclear why you call this a use of the closed world assumption: >>>>> the entire openEHR framework is for building HISs that enable reporting of >>>>> reality as it is known to those working in it. So if they put 'No cancer' >>>>> that just means that the current clinical thinking for some patient, *with >>>>> respect to some investigation*, is that the original presenting >>>>> problem is not cancer. >>>>> >>>>> That never means that the patient doesn't have cancer in their body >>>>> somewhere, it just means that the currently investigated signs and >>>>> symptoms >>>>> don't relate to cancer, according to the the investigation carried out. >>>>> Even that can be overturned later. But everyone assumes this - the EHR is >>>>> always understood as an 'open world' system, where absence of X doesn't >>>>> mean negation of X, it just means that no-one has investigated X. >>>>> >>>>> - thomas >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Ing. Pablo Pazos Gutiérrez >>>> pablo.pa...@cabolabs.com >>>> +598 99 043 145 <099%20043%20145> >>>> skype: cabolabs >>>> <http://cabolabs.com/> >>>> http://www.cabolabs.com >>>> https://cloudehrserver.com >>>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Ing. Pablo Pazos Gutiérrez >>> pablo.pa...@cabolabs.com >>> +598 99 043 145 <099%20043%20145> >>> skype: cabolabs >>> <http://cabolabs.com/> >>> http://www.cabolabs.com >>> https://cloudehrserver.com >>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Ing. Pablo Pazos Gutiérrez >> pablo.pa...@cabolabs.com >> +598 99 043 145 <099%20043%20145> >> skype: cabolabs >> <http://cabolabs.com/> >> http://www.cabolabs.com >> https://cloudehrserver.com >> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >> _______________________________________________ >> 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 > -- Ing. Pablo Pazos Gutiérrez pablo.pa...@cabolabs.com +598 99 043 145 skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
