Op di 3 apr. 2018 09:43 schreef GF <gf...@luna.nl>: > Archetype modelling and the use of SNOMED pre- and/or post-coordination >
You too have a nice day > > > Gerard Freriks > +31 620347088 > gf...@luna.nl > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > > On 3 Apr 2018, at 09:31, 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 >> 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 > > > _______________________________________________ > 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
