IMHO the clearness of the query should not depend on the AQL code, but the metadata associated with the query, like the ADL header and ontology, the AQL would be the "definition" of the query. To share queries between systems the AQL is not enough. We need a declaration of intent, purpose, use, misuse, etc and description of the query in natural language.
Also, to manage queries we need something like the CKM and an editor. Good AQL should not rely only on clearness and readability, but on specifying exactly what results we need. I think both options are valid: SCT expressions and just codes in AQL, but since I'm not an expert in SCT, I prefer someone else that knows SCT defines the expressions and relationships in the terminology server so I can create queries just using codes. Sent from my LG Mobile ------ Original message------ From: Diego Boscá Date: Sun, Sep 11, 2016 11:57 To: For openEHR technical discussions; Subject:Re: SV: More generic reference model I'm not a real fan of having just codes instead of expressions.. Expressions are far more readable and may help in the understanding of the archetype. Just a single code representing the subset won't be as clear. El 11/9/2016 16:49, "pablo pazos" <pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>> escribió: Hi Bert, I was thinking about integrating SCT with path-based queries (I'm not in AQL yet), but maintaining the complexity of the SCT relationships and expressions on the terminology service (TS) side, so on queries there are just simple codes (specific concept ids, subsets or expressions identified just by one code). Then when evaluating a query, with the TS we can get all the terms and concept ids that match all the is_a relationships or subsets of expressions. I talked with several TS providers and hopefully we can build an integration next year to create and evaluate queries with SCT. What I'm saying is that I prefer to delegate the complexity of SCT to the TS and create simpler queries in AQL or path-based queries, but your idea is interesting. One problem though is that query creators need to be experts in SCT. What do you think? Sent from my LG Mobile ------ Original message------ From: Bert Verhees Date: Sat, Sep 10, 2016 13:14 To: For openEHR technical discussions; Subject:Re: SV: More generic reference model Hi Pablo, sorry I was bit slow with thinking through my plans. The way I see it now, there is no change necessary in the reference model to integrate the potential of SCT largely. Even you can keep on using the semantic rich entry types like Observation, etc. See my post in my blog. http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/ If you, however, limit yourself to the Generic entry type, which even gives a better integration while keeping all OpenEhr functinality alive. http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/ I am interested in what you think about that. Best regards Bert Verhees Op 10 sep. 2016 05:03 schreef "pablo pazos" <pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>>: Hi all, Regarding the genericity of the openEHR IM, from the implementation point of view we have at least 3 models: + the implementation information model + the persistence information model + and the reference / canonic information model (the openEHR IM) Others might have more than these 3 models on their openEHR implementations. I think some simplifications can still be done to the openEHR IM without losing semantics, like removing ITEM_STRUCTURE and using just CLUSTER/ELEMENT (we have a discussion about this on the wiki started some years ago). IMO we should not try to make the reference model simpler just in sake of simplifying the implementation, since the other 2 models are for that. In my systems I have different implementation models that are over simplified openEHR IM implementations, and also very specific / optimized / generic persistence information models compatible with the openEHR IM. And I think the implementation / persistence models are the ones we can simplify and adjust to our needs, but not the reference model, since it's role is that: be the reference for all implementations. -- Kind regards, Eng. Pablo Pazos Guti??rrez http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos> ________________________________ From: openEHR-technical <openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>> on behalf of Mikael Nyström <mikael.nyst...@liu.se<mailto:mikael.nyst...@liu.se>> Sent: Friday, September 9, 2016 4:15:53 AM To: For openEHR technical discussions Subject: SV: SV: More generic reference model Hi, A related activity that might be useful to know is the “RFP for LOINC - SNOMED CT Cooperation Project”.http://www.ihtsdo..org/news-articles/rfp-for-loinc--snomed-ct-cooperation-project<http://www.ihtsdo.org/news-articles/rfp-for-loinc--snomed-ct-cooperation-project> . Regards Mikael Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]FörBert Verhees Skickat: den 9 september 2016 08:42 Till: openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org> Ämne: Re: SV: More generic reference model Op 9-9-2016 om 8:37 schreef Bjørn Næss: But in addition to that we need to map terms from different other terminologies like SNOMED-CT, LOINC and also Disease Ontologies. There is a mapping effort by IHTSDO en Regenstrief, they started that a few years ago, and it will be finished, next year, I think. http://www.ihtsdo.org/about-ihtsdo/partnerships/loinc _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org<mailto: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<mailto: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
