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 <[email protected]>: > Please see below, > > On Mon, Apr 2, 2018 at 6:17 PM, GF <[email protected]> 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> >> [email protected] >> >> Kattensingel 20 >> 2801 CA Gouda >> the Netherlands >> >> On 2 Apr 2018, at 20:02, Pablo Pazos <[email protected]> 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 <[email protected]> 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> >>> [email protected] >>> >>> Kattensingel 20 >>> 2801 CA Gouda >>> the Netherlands >>> >>> On 2 Apr 2018, at 01:11, Pablo Pazos <[email protected]> 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 <[email protected]> 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> >>>> [email protected] >>>> >>>> Kattensingel 20 >>>> 2801 CA Gouda >>>> the Netherlands >>>> >>>> On 1 Apr 2018, at 14:41, Thomas Beale <[email protected]> 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 >>>> [email protected] >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>>> >>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> [email protected] >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> >>> >>> >>> -- >>> Ing. Pablo Pazos Gutiérrez >>> [email protected] >>> +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 >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> >> >> >> -- >> Ing. Pablo Pazos Gutiérrez >> [email protected] >> +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 >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > > -- > Ing. Pablo Pazos Gutiérrez > [email protected] > +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 > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
