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::80146002Appendectomy424226004Usingdevice86174004Laparoscope]>
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.
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
o wrong
o replicating the same thing in another archetype
o 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?
I believe that Luis original question was about term binding and not
necessarily constraint binding. However I'm not sure what you say
subset definitions being wrong, replicated... is different from
current local subset definitions available in mostly all current
archetypes.
For solving Luis problem, we probably just need to relax current
constraint on term bindings to be able to accept any string and not
prohibit some characters. I think that Harold proposal could be even
supported right now, as currently QueryBindingItem accepts any URI
already.
Yes, my question was about the term binding and the possibility to attach post-coordinated expressions. As Diego mentions, it seems that merely by relaxing the constraints, proper SNOMED-CT expressions with alphanumeric characters, bars, parenthesis and curly braces could be attached.
What I don’t know is if there was a reason for not allowing this. I guess Thomas answer points in that direction.
In my view, I agree with the problem of maintenance of expressions when SNOMED-CT is updated. However, I think that the problem is already there when using value sets. Regarding “replicating the same thing in another archetype”, in my view, it will happen in some cases, but I do not really see how this can be a problem. Could you please set any example?
The local subsets for which eye does the observation refer to is
actually repeated in current CKM archetypes (with different local
terms for each one of the codes, and in some of them there is no
terminology binding). How is this any better solution?
Thanks Thomas, although I meant an example stating in which scenario the replication of value sets can be problematic. I see maintenance of archetypes using replicated value sets as a matter of good practice in the management and governance of archetypes (i.e. CKM).
Nevertheless, just to summarize, my main question was support to post-coordinated expressions in ADL not based on URIs. I assume this won’t be possible and the approach agreed for ADL 2.0 is referencing URIs. Please let me know if I am wrong
We’re intending to use the IHTSDO syntax (or the idea) for semantic annotation of computational physiology models - using other domain specific languages like CellML, FieldML, SBML etc. There are semantic tools like SemGen or openCOR which support linking model items to external terminology/ontology similar to Archetypes. The idea is to couple clinical data and related physiological models to create personalised/predictive decision support tools using shared knowledge resources and I think this syntax has a great merit.
Back to to problem presented by Luis, I think he is completely right. I can’t find any reason why the code part of the term binding CodePhrase isn’t just a String that accepts any symbol without limitations. Currently it is defined (at least at the Java parser) as accepting letters, numbers, “-”, “.” and "". Why these and not others such as “|”, “#”, “(”, “)” or “/”?
So, we can find in the CKM mappings to LOINC such as the following, because the hyphen symbol is allowed: [“at0031”] = <[LOINC::48332-1]>
But we cannot introduce something like: [“at0056”] = <[LOCALTEMINOLOGY::352/03]> or [“at0056”] = <[LOCALTEMINOLOGY::352#03]>
ADL/AOM specifications must serve to all use cases, we never know which formats will use any (local) terminology out there. And supporting this will also allow supporting SNOMED CT postcoordinated expressions.
