<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Thomas, <br>
      <br>
      On 03-09-16 21:30, Thomas Beale wrote:<br>
    </div>
    <blockquote
      cite="mid:eedc165b-5649-2634-f6f4-e707ddc9966e@openehr.org"
      type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      I'm not sure if it was clear from the above - the WHERE clause is
      testing for membership of a code in some EHR data in a SNOMED ref
      set, i.e. a value set of cancer diagnoses (or you could make it
      Lung cancer if you want). The (fake) concept code
      42570301000090487 stands for an evaluated ref set, assumed to be
      known inside whatever terminology service the AQL service talks
      to. How the membership comparison is done may vary, with many
      possible implementations.<br>
    </blockquote>
    <br>
    I am not sure that I understand you, but to keep it short, I just
    tell you how I think it should be implemented. The picture is not
    complete yet.<br>
    <br>
    In my idea, it would be best implemented like this.<br>
    For example, to define a subsumption test, which is part of
    functionality ECL (expression constraint language). The best thing
    is when it is possible to adapt the ECL literally, and in
    interaction with the data in the data-set, return information if a
    concept used in the data-set satisfies the ECL constraint.<br>
    Because ECL can be very complicated, and we need to give all freedom
    to the users, we must be able to implement the full ECL syntax in an
    embedded part of AQL.<br>
    <br>
    Then you offer more, and in a very elegant way, than most of the
    competition can offer. I think, this will really get the oohhh's and
    aaahhhh's at presentations.<br>
    It will cost some engineering. But with help of ANTLR, maybe six
    months maximum for one experienced programmer.<br>
    I could do that, but unfortunately, I have to earn money, this year,
    so far, was not so good for me.<br>
    <br>
    So I am happy when someone else will do this, and opensource the
    thing. It is not really rocket science, the definitions are more
    important.<br>
    <br>
    OpenEHR happens to have many prerequisites ready, but some need to
    be added.<br>
    <br>
    Let me do some shooting:<br>
    We need a syntax to literally embed ECL in AQL.<br>
    We need a syntax to map data-paths to parameters for doing
    constraint-tests in ECL<br>
    <br>
    And then, coming back to what Daniel Karlsson wrote.<br>
    There must be predictable locations (reachable by AQL) in archetypes
    where SNOMED codes are to be found, because these are needed for
    doing the constraint-tests. For example, in a problem-diagnosis
    archetype, where always a clinical finding is the lead, there must
    be a path to that clinical finding-concept ID, that is the easy
    part. But a clinical finding can have attributes, maybe some of them
    are also included in the archetype, they also can have conceptID's,
    they must also be found.<br>
    <br>
    <blockquote
      cite="mid:eedc165b-5649-2634-f6f4-e707ddc9966e@openehr.org"
      type="cite">some of the needed 'attributes' can potentially
      derived from the SNOMED concept model and data might even be
      represented using SNOMED expressions. But, don't forget, openEHR
      is for the whole world, not just the SNOMED world. Much of the
      world doesn't use SNOMED CT. So such mappings have to be done in
      archetypes, and only directly represented in data for those
      locations that really do have SNOMED. We have not worked out all
      the tricks to make it work for both worlds.<br>
    </blockquote>
    <br>
    What you are saying is that OpenEHR must also work without SNOMED. I
    agree with that. So the syntaxes and options needed for SNOMED
    integration must be optional. Maybe in a later stage, one can enrich
    archetypes in new versions to add SNOMED integration. We should
    think about that when formulating the SNOMED syntax requirements. <br>
    <br>
    <blockquote
      cite="mid:eedc165b-5649-2634-f6f4-e707ddc9966e@openehr.org"
      type="cite">Indeed. Ideally we would work more closely with IHTSDO
      on this (I spent 4 y on standing committees there), but I think
      there is not yet the interest in this. There are still people who
      believe that a) SNOMED CT on its own, with only trivial data
      structures is all that is needed (that's a categorical error of
      thinking) and/or b) that the whole world uses SNOMED CT and that
      therefore the only terminology approach is SNOMED CT (an error
      today, and I suspect for years to come).<br>
    </blockquote>
    <br>
    Now we come to opinions on the position of SNOMED. So, my points of
    view.<br>
    <br>
    Point a)<br>
    A lot of work is in when too many people are involved, and they all
    may have different interests and opinions. <br>
    I am afraid that working with IHTSDO can result in slow processing,
    these kind of things always go too slow in my opinion. I am always
    amazed how slow organizations work on standards. <br>
    <br>
    But you can also see when there is a benevolent dictator, things can
    really speed up. (Microsoft took less then one year to ISO-certify
    the OpenXML standard, and Malta (400.000 inhabitants) became a
    voting ISO member for this occasion).<br>
    Let me say it another way. We know the syntax from ECL (in this
    version), so we can implement it. Nothing is standing in the way. We
    are not talking about a new standard, but about a SNOMED
    implementation in a software definition.  It is nothing big, but
    very important for OpenEHR.<br>
    <br>
    FHIR is another case, it aspires to become a worldwide standard and
    is going through all the painful stages. They need to talk with all
    stakeholders, also at IHTSDO.<br>
    <br>
    Point b)<br>
    SNOMED is not the only terminology in the world, from worldwide
    perspective. But for the Netherlands it will become very soon the
    only terminology in the world, we will have SNOMED, LOINC and legacy
    (and some small things like UCUM, etc), and the legacy will be
    mapped to SNOMED. Kaiser Permanente based their CMT on SNOMED, the
    number of member countries is growing. When OpenEHR discloses the
    potential of SNOMED, this will be a unique selling point, the best
    opportunity for growth in last ten years and five years to come.<br>
    <br>
    <blockquote
      cite="mid:eedc165b-5649-2634-f6f4-e707ddc9966e@openehr.org"
      type="cite"> <br>
      But there are certainly things we can do to improve on our side,
      including:<br>
      <ul>
        <li>tracking the outcomes of CIMI term-binding and applying them
          where possible</li>
        <li>reviewing recent <a moz-do-not-send="true"
href="http://wiki.hl7.org/index.php?title=Binding_Syntax#Current_Working_Material">HL7
            term binding thinking </a>and using what we can</li>
        <li>making sure we use all the IHTSDO new standards we can, e.g.
          URIs, Constraint language as per above discussion etc.</li>
      </ul>
      <p>Principally I think we need some openEHR community members to
        work on some of this and make recommendations for improvements
        to AQL and archetype terminology binding.</p>
    </blockquote>
    <br>
    Although I am not familiar with what CIMI has for us, and the HL7
    term binding thinking, but it seems a good start, I hope the OpenEHR
    community, especially those people who are familiar with this kind
    of thinking, will do this very soon, so the implementation can
    start, and over a year by now, we amaze the world by having it
    running. I suggest someone takes the lead on this.<br>
    <br>
    If I can be of any help, please let me know<br>
    <br>
    Bert<br>
  </body>
</html>