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 [email protected] Kattensingel 20 2801 CA Gouda the Netherlands > On 17 Feb 2018, at 08:57, A Verhees <[email protected]> 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 [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
