<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    > I agree there is a need to be able to create archetypes much
    more quickly based on device specifications. We need to work on
    that.<br>
    <br>
    If you are looking for device specifications, I guess you are aware
    of the medical device information model and the nomenclature of ISO
    EN IEEE 11073?<br>
    <a class="moz-txt-link-freetext" href="http://11073.org/">http://11073.org/</a>, especially<br>
    <a class="moz-txt-link-freetext" href="https://standards.ieee.org/develop/wg/PHD.html">https://standards.ieee.org/develop/wg/PHD.html</a><br>
    11073:10101 is the nomenclature standard.<br>
    <br>
    They have "Device Specialisations" for blood pressure, blood sugar,
    medication dispensers, ... <br>
    This is heavily used by many, including Bluetooth, NFC, .... <br>
    This is also used in FHIR: <br>
    <br>
    <a class="moz-txt-link-freetext" href="http://build.fhir.org/devicemetric.html">http://build.fhir.org/devicemetric.html</a><br>
    This is Maturity Level 1, so not fully stable ("Trial Use     Use
    Context: Not Intended for Production use")<br>
    Work seems to be ongoing, I see very recent changes there.<br>
    <br>
    <br>
    Hope this helps, <br>
    greetings,<br>
    <pre class="moz-signature" cols="72">Stefan </pre>
    <div class="moz-cite-prefix">Am 28.06.2018 um 17:19 schrieb Bert
      Verhees:<br>
    </div>
    <blockquote type="cite"
      cite="mid:8518c054-5446-b7e2-aae9-b167ccae7ea1@rosa.nl">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class="moz-cite-prefix">On 28-06-18 10:33, Thomas Beale
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:19c39121-a8a1-b0ac-b280-3650bbb31a19@openehr.org">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8">
        <br>
        <div class="moz-cite-prefix">On 27/06/2018 13:00, Bert Verhees
          wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:4878bbec-25c2-734b-79c4-76a307ba5990@rosa.nl">
          <meta http-equiv="Content-Type" content="text/html;
            charset=utf-8">
          <div class="moz-cite-prefix">Dear Seref, I do not agree with
            this without having explored all the possibilities. I think
            it is important not to jump to conclusions and keep the
            discussion open.<br>
            I have some ideas how to keep it interoperable. I like to
            discuss that with an open mindset.<br>
            <br>
            Talking about interoperability. <br>
            <br>
            By the way, how do you create FHIR messages from
            OpenEhr-compositions? Or how do you create
            Openehr-compositions from FHIR messages?<br>
            You have to create a template manually, fitting that item to
            that datapoint, isn't it?<br>
          </div>
        </blockquote>
        <br>
        that is correct, because FHIR imposes its own model. This is the
        basic reason why one should not really use message standards to
        interoperate over systems whose data are already transparently
        structured. However, some organisations want to pay for these
        pointless conversions, so people do them.<br>
      </blockquote>
      <br>
      <font color="#3333ff">Stability and Mapping:<br>
        I think FHIR is good, because it is a stable model, and mapping
        to/from FHIR can be used for long time, and FHIR is also much
        used, so mappings can be used in more occasions. There are also
        disadvantages, like the HTTP-REST protocol which it
        incorporated. Google is now planning a GRPC protocol for FHIR,
        and that is promising, because every datatype can have its own
        GRPC field predefined, and the performance can really improve
        very much, maybe even 100 times as fast. As a rule of thumb one
        could say: Never use REST/JSON/HTTP1.1 for stable models, it is
        throwing away a lot of performance.<br>
        <br>
        Transparancy:<br>
        Data must not only be transparent in a way that people can
        understand them, but they must also be transparent in a way that
        the software-internals of the sender and receiver can handle
        them. For that purpose they need to be mapped from and to these
        internal processes. If a GP receives a FHIR message and maps it
        to his own EHR-tables, then the data from that message become
        available in the normal working screens of the doctor. That is
        transparency that is needed.</font><br>
      <br>
      <br>
      <blockquote type="cite"
        cite="mid:19c39121-a8a1-b0ac-b280-3650bbb31a19@openehr.org"> <br>
        <blockquote type="cite"
          cite="mid:4878bbec-25c2-734b-79c4-76a307ba5990@rosa.nl">
          <div class="moz-cite-prefix"> Even within two parties using
            OpenEhr. You are only automagically interoperable when two
            parties use exact the same archetypes, else you need to
            puzzle the dataitems.<br>
          </div>
        </blockquote>
        <br>
        they only need to use the same data points of those archetypes,
        or else any specialised derivative. This isn't hard to achieve;
        pretty clearly all systems using openEHR today use the same
        vital signs archetypes or derivatives to record vital signs.
        There is no point doing otherwise.<br>
      </blockquote>
      <font color="#3333ff">I don't know if that is true, but if you say
        so, I accept that statement, also because it is restricted to
        vital signs. <br>
        <a class="moz-txt-link-freetext"
          href="https://en.wikipedia.org/wiki/Vital_signs"
          moz-do-not-send="true">https://en.wikipedia.org/wiki/Vital_signs</a></font><br>
      <br>
      <blockquote type="cite"
        cite="mid:19c39121-a8a1-b0ac-b280-3650bbb31a19@openehr.org"> <br>
        <blockquote type="cite"
          cite="mid:4878bbec-25c2-734b-79c4-76a307ba5990@rosa.nl">
          <div class="moz-cite-prefix"> <br>
            The same things you have to do when you need to handle a
            generated archetype. But it will not be that hard. Don't
            expect much complexity from these generated archetypes.<br>
          </div>
        </blockquote>
        <br>
        I've missed some of the earlier discussion, but unless you are
        dealing with genuinely novel measurements or orders, you won't
        have any 'generated archetypes' for most Observations or
        Instructions or Actions. You might have some for novel
        questionnaires or other kinds of assessment tools (new kind of
        score etc). But for the vast majority of cases, I would think
        the real need is for runtime <i>matching</i> of data points
        from <i>existing</i> archetypes to create on-the-fly templates,
        something we've known about for 15 years.<br>
      </blockquote>
      <br>
      <font color="#3333ff">I agree, there are not an endless number of
        data-points-types. They could also be predefined. We would need
        sport-coaches, athletes and so on to help us with that.<br>
      </font>
      <blockquote type="cite"
        cite="mid:19c39121-a8a1-b0ac-b280-3650bbb31a19@openehr.org"><font
          color="#3333ff"> </font><br>
        <blockquote type="cite"
          cite="mid:4878bbec-25c2-734b-79c4-76a307ba5990@rosa.nl">
          <div class="moz-cite-prefix"> I called them before,
            micro-archetypes, containing only one datapoint, or a few
            closely related datapoints.<br>
          </div>
        </blockquote>
        <br>
        Let's assume some of these are created, for the reasons
        mentioned above; pretty soon you are going to want to curate
        them properly and add them to the library. Over time, the number
        of 'generated archetypes' will fall to nearly zero, and it will
        be the matching process that is the main challenge when
        encountering data not planned for.<br>
        <br>
        <blockquote type="cite"
          cite="mid:4878bbec-25c2-734b-79c4-76a307ba5990@rosa.nl">
          <div class="moz-cite-prefix"> With machine learning
            algorithms, it must not be hard to interpret them.<br>
            <br>
            Don't understand me wrong, I like OpenEhr, because of the
            archetyped system, and the flexibility it offers. It is not
            by accident that I discuss it here and not in a HL7 group,
            although that would bring more money.<br>
            <br>
            But if flexibility is slowed down by years of review,
            discussing and consensus over the whole world for a set of
            archetypes, then there is not much flexibility left.<br>
          </div>
        </blockquote>
        <br>
        it is slowed down, that's true, and it could be faster. But I
        don't see how that reduces flexibility.<br>
      </blockquote>
      <br>
      <font color="#3333ff">The inflexibility is in giving the
        proceedings out of hands, losing control, having to deal with
        changes which are not asked for or wanted. The data-points would
        need to be as simple as possible, mostly in ELEMENT-structure
        instead of CLUSTER, or only very simple CLUSTERS when 1
        data-point is not sufficient. No deep structures, I would
        advise.<br>
      </font><br>
      <blockquote type="cite"
        cite="mid:19c39121-a8a1-b0ac-b280-3650bbb31a19@openehr.org"> <br>
        <blockquote type="cite"
          cite="mid:4878bbec-25c2-734b-79c4-76a307ba5990@rosa.nl">
          <div class="moz-cite-prefix"> This can work very good for the
            archetypes which are in CKM, but all those new devices, all
            those new datatypes, all this new protocols, which cannot
            wait for these review-procedures, because the market will be
            jumped far ahead by then.<br>
          </div>
        </blockquote>
        <br>
        I agree there is a need to be able to create archetypes much
        more quickly based on device specifications. We need to work on
        that.</blockquote>
      <br>
      <font color="#3333ff">Yes, I agree<br>
        <br>
        Bert</font><br>
      <!--'"--><br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
openEHR-clinical mailing list
<a class="moz-txt-link-abbreviated" href="mailto:openEHR-clinical@lists.openehr.org">openEHR-clinical@lists.openehr.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org">http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>