<div dir="ltr"><div><div><div><div><div>" but in some
      cases, <i>it is missing concepts</i>"<br><br></div>Shouldn't we contribute?<br><br></div>Is the same as openEHR, there are missing archetypes and we need the community, users, clinical modelers and engineers to contribute.<br><br><br></div>LOINC also misses concepts, and when I asked them how can I contribute, they sent me the process and some templates for requesting a new concept to be added, pretty simple, formal and open!<br><br></div>IMO we can't expect perfection, is a bad strategy and a move towards isolation. I think pragmatism is better and go with "this is the best we can expect for". We are the ones that should push towards the ideal, but as a guide not as a goal (getting a little philosophical here...).<br><br></div>The same idea applies to tooling, anyone can create tools to manage the terminology better. In our own backyard we have tools that need improvement, but we accept them because there is no better alternative.<br><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 13, 2018 at 11:21 AM, Thomas Beale <span dir="ltr"><<a href="mailto:thomas.beale@openehr.org" target="_blank">thomas.beale@openehr.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <p>The killer move would be to do something I advocated for years
      unsuccessfully: <b>separate SNOMED technology from content </b>and
      allow them to be independently licensable and used. Here,
      technology means representation (RF2 for example), open source
      programming libraries for working with ref-sets, specs and implems
      for e..g the constraint language, URIs and so on.</p>
    <p>It should be possible for a country (the one I am most familiar
      with w.r.t. to terminology today is Brazil) to create an empty
      'SNOMED container' of its own, and put its existing terminologies
      in there - typically procedure lists, drug codes, lab codes,
      devices & prosthesis codes, packages (chargeable
      coarse-grained packages like childbirth that you get on a health
      plan) and so on. There are usually < 20k or even 10k such codes
      for most countries (UK and US would an exception), not counting
      lab analyte codes (but even there, 2000 or so codes would take
      care of most results). But the common situation is that nearly
      every country has its own version of these things, and they are
      far smaller than SNOMED. Now, SNOMED's version of things is
      usually better for <i>some </i>of that content, but in some
      cases, <i>it is missing concepts</i>. <br>
    </p>
    <p>The ability to easily create an empty SNOMED repo, fill it with
      national vocabularies, have it automatically generate non-clashing
      (i.e. with other countries, or the core) concept codes and
      mappings, and then serve it from a standard CTS2 (or other decent
      standard) terminology service would have revolutionised things in
      my view. This pathway has not been obviously available however,
      and has been a real blockage. The error was not understanding that
      the starting point for most countries isn't the international
      core, it's their own vocabularies.<br>
    </p>
    <p>The second killer feature would have been to <b>make creating
        and managing ref-sets for data/form fields much easier</b>,
      based on a subsetting language that can be applied to the core,
      and tools that implement that. Ways are needed to make the local /
      legacy vocabularies that have been imported, to look like a
      regular ref-set.<br>
    </p>
    <p>The third killer feature would have been to <b>make translation
        tools work </b>on the basis of legacy vocabulary and new
      ref-sets, not on the basis of the huge (but mostly unused)
      international core.</p>
    <p>I think IHTSDO's / SNOMED International's emphasis has
      historically been on curating the core content, and making/buying
      tools to do that (the IHTSDO workbench, a tool that comes with its
      own PhD course), rather than promulgating SNOMED technology and
      tooling to enable the mess of real world content in each country
      to be rehoused in a standard way, and incrementally joined up by
      mapping or other means to the core. I think the latter would have
      been more helpful.</p>
    <p>There is additionally an elephant in the room: <b>IHTSDO (now
        SNOMED International) has been tied to a single terminology -
        SNOMED CT</b>, but it would have been better to have had a
      terminology standards org that was independent of any particular
      terminology, and worked to create a truly terminology-independent
      technology ecosystem, along with technical means of connecting
      terminologies to each other, without particularly favouring any
      one of them. It's just a fact that the world has LOINC, ICDx,
      ICPC, ICF and hundreds of other terminologies that are not going
      anywhere. What would be useful would be to:</p>
    <ul>
      <li>classify them according to meta-model type - e.g.
        multi-hierarchy (Snomed); single hierarchy (ICDx, ICPC, ... );
        multi-axial (LOINC); units (UCUM, ...), etc<br>
      </li>
      <li>build / integrate technology for each major category - I would
        guess < 10<br>
      </li>
      <li>help the owning orgs slowly migrate their terminologies to the
        appropriate representation and tools<br>
      </li>
      <li>embark on an exercise to graft in appropriate upper level
        ontology/ies, i.e. BFO2, RO, and related ontologies (this is
        where the <10 comes from by the way)<br>
      </li>
      <li>specify standards for URIs, querying, ref-sets that <i>work
          across all terminologies</i>, not just SNOMED CT<br>
      </li>
    </ul>
    <p>A further program would look at integrating units (but not by the
      current method of importing to SNOMED, which is a complete error
      because of the different meta-models), drugs and substances (same
      story), lab result normal and other range data, and so on. None of
      this can be done without properly studying and developing the
      underlying ontologies, which are generally small, but subtle.<br>
    </p>
    I'll stop there for now. I suspect I have kicked the hornet's nest,
    but since Grahame kicked it first, and I can run faster than him, I
    feel oddly safe. Probably an illusion.<span class="HOEnZb"><font color="#888888"><br>
    <br>
    - thomas</font></span><div><div class="h5"><br>
    <br>
    <div class="m_-3178280082416675698moz-cite-prefix">On 13/03/2018 12:12, Grahame Grieve
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="white" link="blue" vlink="purple" lang="EN-GB">
                <div class="m_-3178280082416675698m_-8410538321765948978WordSection1">
                  <p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1f497d"> </span></p>
                  <p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1f497d">I
                      am get the impression that SNOMED CT is hard to
                      implement, and therefore wondered if we are at
                      some kind of tipping point, like where HL7v3 was a
                      few years ago, and some bright spark came along,
                      and now we have FHIR that is gaining great
                      traction in the health community due to the ease
                      at which it can be implemented.</span></p>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>this is very true, and I wish that someone would stick
              their neck out and do this at scale with </div>
            <div>a community behind them. Many of the parameters for how
              it could be done are obvious around </div>
            <div>free and crowd-support etc. But the big problem is that
              there is no capacity for it to happen as a </div>
            <div>palace revolution; it must be a full civil war first.</div>
            <div><br>
            </div>
            <div>Grahame</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="m_-3178280082416675698mimeAttachmentHeader"></fieldset>
      <br>
      </div></div><span class=""><pre>______________________________<wbr>_________________
openEHR-technical mailing list
<a class="m_-3178280082416675698moz-txt-link-abbreviated" href="mailto:openEHR-technical@lists.openehr.org" target="_blank">openEHR-technical@lists.<wbr>openehr.org</a>
<a class="m_-3178280082416675698moz-txt-link-freetext" href="http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org" target="_blank">http://lists.openehr.org/<wbr>mailman/listinfo/openehr-<wbr>technical_lists.openehr.org</a></pre>
    </span></blockquote>
    <br>
    <div class="m_-3178280082416675698moz-signature">-- <br><span class="">
      <small>
        Thomas Beale<br>
        Principal, <a href="http://www.arssemantica.com" target="_blank">Ars Semantica</a><br>
        Consultant, ABD Team, <a href="https://intermountainhealthcare.org/" target="_blank">Intermountain
          Healthcare</a><br>
        Management Board, Specifications Program Lead, <a href="http://www.openehr.org" target="_blank">openEHR Foundation</a><br>
        Chartered IT Professional Fellow, BCS, <a href="http://www.bcs.org/category/6044" target="_blank">British Computer
          Society</a><br>
        <a href="http://wolandscat.net/" target="_blank">Health IT blog</a> | <a href="http://wolandsothercat.net/" target="_blank">Culture blog</a>
      </small></span></div>
  </div>

<br>______________________________<wbr>_________________<br>
openEHR-clinical mailing list<br>
<a href="mailto:openEHR-clinical@lists.openehr.org">openEHR-clinical@lists.<wbr>openehr.org</a><br>
<a href="http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org" rel="noreferrer" target="_blank">http://lists.openehr.org/<wbr>mailman/listinfo/openehr-<wbr>clinical_lists.openehr.org</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><table style="border-collapse:collapse;border-spacing:0px;font-family:'Times New Roman';text-align:start;border:0px;margin:10px"><tbody><tr><td style="margin:0px;padding:10px"><font color="#000066">Ing. Pablo Pazos Gutiérrez<br><a href="mailto:pablo.pazos@cabolabs.com" target="_blank">pablo.pazos@cabolabs.com</a><br>+598 99 043 145<br>skype: cabolabs<br></font></td><td style="margin:0px;padding:10px;vertical-align:bottom;text-align:center"><font color="#000066"><a href="http://cabolabs.com/" target="_blank"><img src="https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ" width="200" height="25"></a><br><a href="http://www.cabolabs.com/" target="_blank">http://www.cabolabs.com</a><br><a href="https://cloudehrserver.com/" target="_blank">https://cloudehrserver.com</a><br><a href="http://eepurl.com/b_w_tj" target="_blank">Subscribe to our newsletter</a><br></font></td></tr></tbody></table></div></div></div></div></div></div></div></div></div></div></div>
</div>