Hi Diego, We really need both as many real-world SNOMED-CT subsets do not align to particular hierarchies or expressions.
Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 11 September 2016 at 15:56, Diego Boscá <[email protected]> wrote: > 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" <[email protected]> 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" <[email protected]>: >> >>> 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 <[email protected]> >>> on behalf of Mikael Nyström <[email protected]> >>> *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 . >>> >>> >>> >>> Regards >>> >>> Mikael >>> >>> >>> >>> *Från:* openEHR-technical [mailto:openehr-technical-boun >>> [email protected]]*För *Bert Verhees >>> *Skickat:* den 9 september 2016 08:42 >>> *Till:* [email protected] >>> *Ä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 >>> [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 >> > > _______________________________________________ > 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
