my fault - didn't read the front page properly - the things we need are mooted for next release. But now I agree with Diego...

The expression constraint "< 404684003|Clinical finding|: < 47429007|Associated with| = < 79654002 |Edema|"

 * http

that is seriously unreadable. In a different universe, we would have hoped for something like:


but of course that is illegal in URI syntax.

In terms of what we put in archetype bindings, I start to wonder. Could it make sense to allow:

 * proper URIs for single terms, value set refs, module refs etc (all
   the URIs that only include a single SCT code)
 * post-coordinated expressions in their syntax form
 * constraint expressions in their syntax form

where the latter two would be understood as standing for their equivalent URIs? That's an awful hack though.

A more consistent argument would be to revert to not using URIs in bindings, and use just codes and expressions.

The problem with doing that is that the ID concept URIs include useful things like /id, /module, /field, etc.

If we just go with the kind of URIs like the above, archetype bindings will cease to be self-documenting. I am starting to think we need an expression syntax that covers all of:

 * single term references, including to SNOMED codes, modules,
   versions, ....
 * SNOMED post-coordinated expressions
 * SNOMED constraint expressions
 * and... the equivalent for non-SNOMED codes, e.g. LOINC, ICDx, ICF,
   etc etc

We still don't have a universal terminology referencing mechanism, but it's what I think we need. It could in theory be achieved with the use of a new 'terminology' scheme space, thus:

< 19829001|Disorder of lung| <http://snomed.info/id/19829001> and < 301867009|Edema of trunk| <http://snomed.info/id/301867009>


terminology:/snomed-ct/ecf/value="< 19829001|Disorder of lung| <http://snomed.info/id/19829001> and < 301867009|Edema of trunk|" <http://snomed.info/id/301867009>

(I won't try to work out the nicest syntax, let's just say we agree that we could find one)

This would allow URIs of the form


and so on.

The sole purpose of a terminology scheme space might just be to establish a universal id space whose ids are readable, structured strings, that can be machine-converted to real URIs for SNOMED, but also LOINC, ICDx, HL7, and all the other terminologies.

- thomas

On 03/05/2017 12:09, Daniel Karlsson wrote:
See this page:
Please consider the language used when posting.

On May 3, 2017 13:03, Bert Verhees <bert.verh...@rosa.nl> wrote:

    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
                and Expression Constraint Language
                specs, is how to create a URI (which is the type of a
                term binding in ADL2
                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
        but it doesn't address URIs for expressions either.

        (All the SNOMED language specs appear to be here
        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.



openEHR-technical mailing list

Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org/category/6044> Health IT blog <http://wolandscat.net/> | Culture blog <http://wolandsothercat.net/>
openEHR-technical mailing list

Reply via email to