Archetype modelling and the use of SNOMED pre- and/or post-coordination Gerard Freriks +31 620347088 [email protected]
Kattensingel 20 2801 CA Gouda the Netherlands > On 3 Apr 2018, at 09:31, A Verhees <[email protected]> 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 <[email protected] > <mailto:[email protected]>>: > Please see below, > > On Mon, Apr 2, 2018 at 6:17 PM, GF <[email protected] <mailto:[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 <tel:+31%206%2020347088> > [email protected] <mailto:[email protected]> > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > >> On 2 Apr 2018, at 20:02, Pablo Pazos <[email protected] >> <mailto:[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] <mailto:[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 <tel:+31%206%2020347088> >> [email protected] <mailto:[email protected]> >> >> Kattensingel 20 >> 2801 CA Gouda >> the Netherlands >> >>> On 2 Apr 2018, at 01:11, Pablo Pazos <[email protected] >>> <mailto:[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] <mailto:[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 <tel:+31%206%2020347088> >>> [email protected] <mailto:[email protected]> >>> >>> Kattensingel 20 >>> 2801 CA Gouda >>> the Netherlands >>> >>>> On 1 Apr 2018, at 14:41, Thomas Beale <[email protected] >>>> <mailto:[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] >>>> <mailto:[email protected]> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>>> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> <mailto:[email protected]> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >>> >>> >>> >>> -- >>> Ing. Pablo Pazos Gutiérrez >>> [email protected] <mailto:[email protected]> >>> +598 99 043 145 <tel:099%20043%20145> >>> skype: cabolabs >>> <http://cabolabs.com/> >>> http://www.cabolabs.com <http://www.cabolabs.com/> >>> https://cloudehrserver.com <https://cloudehrserver.com/> >>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> <mailto:[email protected]> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> <mailto:[email protected]> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >> >> >> >> -- >> Ing. Pablo Pazos Gutiérrez >> [email protected] <mailto:[email protected]> >> +598 99 043 145 <tel:099%20043%20145> >> skype: cabolabs >> <http://cabolabs.com/> >> http://www.cabolabs.com <http://www.cabolabs.com/> >> https://cloudehrserver.com <https://cloudehrserver.com/> >> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> <mailto:[email protected]> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > > _______________________________________________ > openEHR-technical mailing list > [email protected] > <mailto:[email protected]> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > > > > -- > Ing. Pablo Pazos Gutiérrez > [email protected] <mailto:[email protected]> > +598 99 043 145 > skype: cabolabs > <http://cabolabs.com/> > http://www.cabolabs.com <http://www.cabolabs.com/> > https://cloudehrserver.com <https://cloudehrserver.com/> > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > _______________________________________________ > openEHR-technical mailing list > [email protected] > <mailto:[email protected]> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > <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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
