IMO what gives context is the OPT that constrains the underlying reference model, queries are based on archetypes and paths defined in OPTs and SNOMED expressions are just a way of creating semantically complex criteria for querying, nothing more.
That is why SNOMED alone can't be used for querying. On Sat, Feb 17, 2018 at 7:21 AM, GF <gf...@luna.nl> wrote: > Hi, > > In order to reach full interoperability and interpretability we need a > clearcut separation between constituting models that are part of the > Interoperability standards stack. > It is the function of a Terminology to create a system of concepts that > coherently defines concepts in a domain. > And that is and must be the only function of SNOMED. > > When it comes to queries we need to take into account data values in a > context, the epistemology. > SNOMED will NEVER be able to model, contain the full temporal and spacial > epistemology. > That context/epistemology is defined by meta-data in COMPOSITION that as > committed to databases and documents. > In addition the world of databases is the domain of what is called the > Closed World Assumption and Terminologies like SNOMED are part of the Open > Worlds Assumption domain. > Mixing these two creates severe problems. > > So I oppose the thought to crate search engines in the SNOMED Terminology > domain. > CIMI has adopted this fines, sharp divide between the worlds of Archetypes > and Terminology. > > > > Gerard Freriks > +31 620347088 <+31%206%2020347088> > gf...@luna.nl > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > > On 17 Feb 2018, at 08:57, A Verhees <bert.verh...@rosa.nl> wrote: > > Hi, sorry to interfere, if II understand well, > > I think a possible problem could be that respiratory infection caused by a > virus can return some derived codes to be returned although in this case it > are not so many. > > However to use this mechanism generally, it can happen that really many > derived codes will be returned from the SNOMED engine, and in that case the > AQL query would need to be executed many times. Once for each possible > derived code. > > One could also consider to hand over the result set from AQL to the SNOMED > engine to see if it is derived, which could cause less executions. > > But in both cases it is datamining which is always difficult to estimate > what the best strategy in a specific case is. > > A good idea maybe to design an intelligent query-strategy-decision engine > which offers advice to see what works best. This engine could execute > limited queries, for example, with a count operator so that it does not > need to go all the way when a limit is reached. > > It is true what you write that datamining queries seldom are expected to > return in real time, but I have seen situations in marketing were they ran > for hours and queried almost one million dossiers, we even created in > between databases. > > That decision engine could also be an external service. > > It is good to hear that you think about separated services anyway. That > works in the advantage of a microservices architecture. > > Bert > > > > _______________________________________________ > 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
