Hi Bert, I posted a similar question last year. I paste it below.
After some developments in the topic [1] my view is that archetypes are not
the place for hosting post-coordinated expressions. Rather they should
point with a URL to a server in the cloud that hosts them (following Linked
Data principles). I recall that recently there was a ticket in openEHR
openedhr for including URLs in archetypes...but I cannot find it. Let me
know if you want to discuss this...

[1]       Marco-Ruiz L, Pedrinaci C, Maldonado JA, Panziera L, Chen R,
Bellika JG. Publication, discovery and interoperability of Clinical
Decision Support Systems: A Linked Data approach. Journal of Biomedical
Informatics 2016;62:243–64. doi:10.1016/j.jbi.2016.07.011.
----

Hi,

I am trying to annotate a set of archetypes with SNOMED-CT. I have noticed
that in the archetype editor, when I introduce a postcoordinated
expressions, the editor deletes the bars and creates a continuous
alphanumeric string. Do you know if postcoordinated expressions can be set
in the ontology section of the archetype? What are current approaches to
overcome this?

A solution could be to insert an id representing the postcoordinated
expression and resolve it in my terminology server. However, this would
hide knowledge to other implementations based on that archetype outside the
domain of my server.



Example: Let’s assume (without caring about the correctness of it) that we
had an archetype for the concept “Laparoscopic appendectomy” and we
annotate at000 with (80146002*|*Appendectomy*|*:424226004|Using device*|*
=86174004*|*Laparoscope*|*).

The result in the ADL is: ["at0000"] = <[SNOMED-CT::80146002Appendect
omy424226004Usingdevice86174004Laparoscope]>


 Thanks,

Luis
Diego Boscá <yamp...@gmail.com>
28/4/15
para For, openeh
inglés
español

Traducir mensaje
Desactivar para: inglés
Hello Luis,

I think having available a terminology service is some kind of a
prerequisite (which I don't agree with). I think openEHR should
probably assume the IHTSDO postcoordination syntax for these cases. It
would be interesting to know if someone has used or is planning to use
this syntax for other terminologies.
> _______________________________________________
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.
openehr.org

_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr
.org
Thomas Beale <thomas.be...@oceaninformatics.com>
28/4/15
para openehr-implem.
inglés
español

Traducir mensaje
Desactivar para: inglés
The original design of ADL in this area (influenced by my 4y on IHTSDO
standing committees, of which 2 on the Technical committee) was that:

   - we should not embed subset definitions inside archetypes, because they
   might be
   - wrong
      - replicating the same thing in another archetype
      - need to be developed and maintained by a terminology specialist
      - in any case, we couldn't assume any particular syntax for subset
   definitions; the current IHTSDO syntax applies only to SNOMED-CT.

I happen to like the IHTSDO syntax, but I think unless people here can
convince themselves that all of the above is not true, it shouldn't go
directly in archetypes. However... terminology technology and use has
advanced far more slowly than many of us expected, and availability /
uptake of usable tools from IHTSDO has been a particularly limiting factor
(e.g. the IHTSDO Workbench is like an aircraft carrier, but what were
needed were speedboats).

In ADL 2, with help from Harold Solbrig@ Mayo (who has worked intensively
on terminology over the years, and is at IHTSDO in CPH as I write), we have
changed the method of referencing terminology concepts to URIs. These
'concepts' can be real concepts, or value-sets, whose definition is
somewhere in terminology land.

Just to be clear, I don't have a personal issue with going one way or the
other on this, but I think people need to understand the issues - above are
some. There may be more of which I am not aware.

A challenge is that establishing new value set definitions in IHTSDO's
model implies having a SNOMED CT extension. Now, maybe what we should do as
openEHR is to do that - apply for an extension and start using it. Who
would be interested in doing this?

- thomas

2017-01-24 12:45 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>:

> Hi,
>
> Last week, I mentioned on this list that the Ocean archetype-editor does
> not allow post-coordinated SNOMED expressions in terminology-bindings. I
> also made some JIRA calls for this, also for an abnormality which was
> related to this.
>
> I also found out that the LinkEHR archetype-editor has the same problem.
>
> So that made me suspicious, and I looked at the ADL 1.4 specifications,
> and there it was, it is not allowed in ADL 1.4 tot use post-coordinated
> SNOMED expressions in terminology-bindings.
>
> I think a repair is necessary, so I made also a JIRA call for this. But I
> did not get any reaction at all. I think however, it is an urgent problem,
> and it is not hard to repair. It is just a matter of allowing some extra
> characters in the terminology-binding, and to do it right, changing the
> spec a bit.
>
> Make it ADL 1.4.x (I saw there is a ADL 1.4.2)
>
> It is urgent because ADL 2.x won' t be active on the market very soon.
> Most knowledge with modelers and tooling will be on ADL 1.4 for some more
> time.
> It is urgent because the Netherlands is very pro-SNOMED and many other
> countries are also, and post-coordination is the way to create bindings for
> items for which is no concept, and it is a future proof binding, because,
> even, when the will come a concept for that expression, that expression
> will remain valid.
>
> We really need it.
>
> Best regards
> Bert Verhees
>
>
> _______________________________________________
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_lists.openehr.org
>
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Reply via email to