Actually it not just a local terminology expression library we need. I think we also need context / artefact specific synonyms for search. The RCPA have done a lot of work trying to subset evaluation procedures/lab procedures in SNOMED CT in the context of Lab ordering (e.g. GP/FP/Specialist to Lab, Aged Care facility to Lab). If we arranged for the Australian NRC to add all of these synonyms it would certainly `pollute` the reference terminology. An example might be 'AA' for Amino Acids. I'm sure all of you could come up with a number of concepts that would abbreviate to 'AA' e.g. Aortic Aneurysm. But in context, AA is quite a useful shortcut to find Amino Acids in a short (<400) list of Lab orders concepts.
On 4 May 2017 at 00:44, <[email protected]> wrote: > Send openEHR-technical mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openEHR-technical digest..." > > > Today's Topics: > > 1. Re: SNOMEDCT - correct representation (Bert Verhees) > 2. Re: SNOMEDCT - correct representation ([email protected]) > 3. Re: SNOMEDCT - correct representation (Thomas Beale) > 4. Re: SNOMEDCT - correct representation (Thomas Beale) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 May 2017 14:40:38 +0200 > From: Bert Verhees <[email protected]> > To: For openEHR technical discussions > <[email protected]> > Subject: Re: SNOMEDCT - correct representation > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 03-05-17 14:20, Thomas Beale wrote: > > that is seriously unreadable. > > I don't think that is a problem, all programming languages have > libraries to en/decode that kind of strings, so archetype-tooling can do > that without much programming effort, and also this can be done when > copy and pasting to a clear-text editor. > > Who is reading clear text ADL anyway? The people I know who are working > on archetypes never care to see ADL text. > > I would not advise going away from the URI-allowed syntax, because, that > can cause incompatibilities on unexpected situations, maybe in the future > > Bert > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 3 May 2017 13:04:53 +0000 > From: <[email protected]> > To: <[email protected]> > Subject: Re: SNOMEDCT - correct representation > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > I think this thread has gone a little off the rails. > > There are predefined (by FHIR) URIs for value sets that are defined just > as descendants of a single concept, or members of a reference set. > > For an enumeration of concepts and/or a snomed ECL expression, then you > can use a Fhir ValueSet and give it a URI. ValueSets also generalise > beyond just SNOMED (LOINC for example). > > Furthermore, there are existing tools to expand them to the set of member > concepts, you can include metadata, manage versions etc. This is much more > than you get just by encoding ECL in a URI. > > In case anyone wants to play with ECL expressions and their evaluation you > can go here for an interactive page: > https://ontoserver.csiro.au/shrimp/ecl.html > > Also, some brief documentation and click-through examples here > https://ontoserver.csiro.au/shrimp/ecl_help.html > > Regards > > Michael > > Sent from my iPhone > > On 3 May 2017, at 9:08 pm, Diego Bosc? <[email protected]<mailto:yamp > [email protected]>> wrote: > > Seems like the only way right now is creating refsets and referencing them > with standard URIs... > > 2017-05-03 13:02 GMT+02:00 Bert Verhees <[email protected]<mailto:b > [email protected]>>: > On 03-05-17 12:53, Thomas Beale wrote: > On 03/05/2017 11:40, Bert Verhees wrote: > On 03-05-17 12:36, Thomas Beale wrote: > > The only missing part, now that I look at the SNOMED Compositional Grammar< > https://confluence.ihtsdotools.org/display/DOCSCG> and Expression > Constraint Language<https://confluence.ihtsdotools.org/display/DOCECL> > specs, is how to create a URI (which is the type of a term binding in ADL2< > http://www.openehr.org/releases/AM/latest/docs/AOM2/ > AOM2.html#_terminology_package>) from a post-coordinated expression or > constraint expression. This should be trivial, but I don't see where SNOMED > has specified it. > > True, I was looking for that also, a few days ago. I don't have time to > read much now, but there is a document on the SNOMED site on URI's, maybe > it is in there? > I can take a look later or look in my documentation, I have course > materials. I come back to this tomorrow if not someone else already has. > > The URI spec is here<https://confluence.ihtsdotools.org/display/SLPG/ > SNOMED+CT+URI+Standard>, but it doesn't address URIs for expressions > either. > > (All the SNOMED language specs appear to be here<https://confluence. > ihtsdotools.org/display/SLPG/SNOMED+CT+Computable+Languages> these days - > nice and convenient, and also nicely published. We probably should go back > to linking to them somewhere on the openEHR site). > > I checked my course materials from last year, lucky I found it quickly, > there is not any mentioning of URI's for expressions, so I guess it does > not yet exist. > > Stupid. > > Bert > > _______________________________________________ > openEHR-technical mailing list > [email protected]<mailto:openEHR- > [email protected]> > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > > > > -- > > [VeraTech for Health SL]<https://htmlsig.com/t/000001C268PZ> > > [Twitter] <https://htmlsig.com/t/000001C47QQH> [LinkedIn] < > https://htmlsig.com/t/000001C4DPJG> [Maps] <https://htmlsig.com/t/ > 000001BZTWS7> > > [https://s3.amazonaws.com/htmlsig-assets/spacer.gif] > > Diego Bosc? Tom?s / Senior developer > [email protected]<mailto:[email protected]> > [email protected]<mailto:[email protected]> > > VeraTech for Health SL > +34 961071863<tel:+34%20961%2007%2018%2063> / +34 627015023 > <tel:+34%20627%2001%2050%2023> > www.veratech.es<http://www.veratech.es/> > > Su direcci?n de correo electr?nico junto a sus datos personales forman > parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511) > cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley > Org?nica 15/1999, usted puede ejercitar sus derechos de acceso, > rectificaci?n, cancelaci?n y, en su caso oposici?n, enviando una solicitud > por escrito a [email protected]<mailto:[email protected]>. > > _______________________________________________ > openEHR-technical mailing list > [email protected]<mailto:openEHR- > [email protected]> > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.openehr.org/pipermail/openehr-technical_ > lists.openehr.org/attachments/20170503/d50b5798/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Wed, 3 May 2017 15:31:00 +0100 > From: Thomas Beale <[email protected]> > To: [email protected] > Subject: Re: SNOMEDCT - correct representation > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > > On 03/05/2017 13:31, Diego Bosc? wrote: > > Or just use the "Long syntax" as described in point 5.2 from > > Expression Constraint Language, which keeps things readable enough > > http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus| > > > > at the very least, a %20 is needed for the spaces, and %7C for the > pipes, i.e. > > http://snomed.info/ecl/descendantOrSelfOf%2073211009% > 20%7CDiabetes%20mellitus%7C > > i.e. ... not readable... > > - thomas > > > > ------------------------------ > > Message: 4 > Date: Wed, 3 May 2017 15:43:18 +0100 > From: Thomas Beale <[email protected]> > To: [email protected] > Subject: Re: SNOMEDCT - correct representation > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > > > On 03/05/2017 14:04, [email protected] wrote: > > I think this thread has gone a little off the rails. > > > > There are predefined (by FHIR) URIs for value sets that are defined > > just as descendants of a single concept, or members of a reference set. > > > > For an enumeration of concepts and/or a snomed ECL expression, then > > you can use a Fhir ValueSet and give it a URI. ValueSets also > > generalise beyond just SNOMED (LOINC for example). > > > > Furthermore, there are existing tools to expand them to the set of > > member concepts, you can include metadata, manage versions etc. This > > is much more than you get just by encoding ECL in a URI. > > right - but this is the argument that the definition of structured value > sets (i.e. intensional ref-sets) should live in terminology services > somewhere, and not in archetypes or other source model locations (a view > I espoused for many years, and not very popular...). The > counter-argument is that while this is fine for subsets like 'blood > phenotype' or whatever, no-one wants to pollute terminology services > with thousands of ECL expressions that are purely local to an > information artefact (i.e. some very specific permutation, also very > common). > > I am starting to think that we need a new artefact which is a kind of > local terminology expression 'library' - probably just a file - that is > associated with any collection of archetypes of similar information > artefacts. > > The specific problem we are trying to solve here is 'terminology > binding', not just terminology expressions, which I think are pretty > well defined. Where bindings live is not a simple question, because the > answer depends on what the binding is to. > > - thomas > > Aside: the ontoserver tool is very nice, people should have a look if > they have not already. > > > > > > In case anyone wants to play with ECL expressions and their evaluation > > you can go here for an interactive page: > > https://ontoserver.csiro.au/shrimp/ecl.html > > > > Also, some brief documentation and click-through examples here > > https://ontoserver.csiro.au/shrimp/ecl_help.html > > > > Regards > > > > Michael > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > > ------------------------------ > > End of openEHR-technical Digest, Vol 63, Issue 9 > ************************************************ > -- Michael Osborne
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
