Didn't say otherwise, just that expressions should be preferable ;D 2016-09-11 19:15 GMT+02:00 Ian McNicoll <[email protected]>:
> 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-ex >>> pression-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-co >>> nstraints-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 >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
