Share this page:

file The September 2021 CA Edition is now available in the SNOMED International Browser!

  • Posts: 50
2 years 6 months ago #7245 by Anibal Jodorcovsky
I would like to have such a call. I'm getting more and more involved with Terminology Services within my group and I'm working on several tools to automate our processes which means more contact with the official releases of the CA Edition. Having more access to the experts and technical people will be greatly appreciated.

Please Log in or Create an account to join the conversation.

  • Posts: 432
2 years 6 months ago #7244 by Linda Parisien
Hi Gabor,
Thank you for providing additional information on this axiom topic. This is quite technical and I wonder if it would make sense to get together to discuss this further with Guillermo.

For you and other stakeholders that have provided feedback in this conversion, would it worthed to schedule a webinar on the different challenges you are experiencing in implementing the CA Edition of SNOMED CT? This could help us in understanding better the tools you are using and the limitations you have. It could also be a very good oportunity for you to get more information on the CA Edition dependencies, technical and teminological decisions taken and implementation options for you to meet your requirements.

Please Log in or Create an account to join the conversation.

  • Posts: 2
2 years 6 months ago #7243 by Gábor Nagy
Hi all,

I'm writing in the name of the company providing terminology tooling to Debbie and her team at Alberta Health Services. We have just finished our extensive investigation regarding the issue that blocked the import of the 2021-09-30 SNOMED CT Canada Edition release into our tooling.

The error message that was shown to Debbie could indeed be more descriptive but I would like to summarize what has happened actually in the background.

In the recent release of the SNOMED CT Canada Edition there are two OWL Expression reference set members which were created to convert two regular class axioms into GCI axioms the following way:

0199b0ce-50c0-cae8-b314-34c558501195	20210930	0	20621000087109	733073007	844580005	SubClassOf(:844580005 :27841000087102)
3a6f0f27-adf8-50a6-af49-4488bf1884f7	20210930	1	20621000087109	733073007	27841000087102	SubClassOf(:844580005 :27841000087102)
51a8f312-980e-0df3-d685-b3cf68bfb974	20210930	0	20621000087109	733073007	23021000087106	SubClassOf(:23021000087106 :27841000087102)
1e07e7e1-1ac3-754c-bbbd-199e90bff17d	20210930	1	20621000087109	733073007	27841000087102	SubClassOf(:23021000087106 :27841000087102)

Both of these members are related to the concept 27841000087102 |Antigen of non-live Human alphaherpesvirus 3 (substance)|

When these members were imported into our application another tool was involved in the processing of the members. This is a tool of SNOMED International called SNOMED OWL Toolkit and is widely used to convert OWL expressions to a representation similar to relationships. During this conversion process the SNOMED OWL Toolkit converted these supposedly GCI axioms to simple class axioms which eventually led to the error that Debbie had to face.

After some digging we realized that there is a gap in the documentation of GCI axioms and how the OWL toolkit handles them. We consulted with SNOMED International on the matter and got a very useful response from Yong (Senior Terminologist) that answers the odd behavior of the SNOMED OWL Toolkit and also why this concept is represented seemingly wrong in the SNOMED CT Browser.

Here is Yong's words:

It is not a good idea to use GCI axiom for such a requirement as it is in the later change below:

Referenced component id: 27841000087102
OWL expression: SubClassOf(:844580005 :27841000087102)

There is a section on the "Referenced component for an Axiom" in the OWL Guide . We have specified how the referenced component should be allocated for each axiom. The referenced component of a GCI axiom can be in the following two situations. It is explicitly stated that C is not a precoorinated concept, but the concept 84458005 is a precoordinated concept. Therefore, this is not a GCI axiom.

  • If an axiom is in the form of SubClassOf(C D) where concept C is NOT a precoordinated concept and D is a precoordinated concept. This is a General Concept Inclusion (GCI) axiom. Because concept C is a sufficient but not necessary condition for concept D, the concept ID of D should be the referencedComponentId for this axiom.
  • If an axiom is in the form of SubClassOf(C D) or EquivalentClasses(C D) where both C and D are NOT precoordinated concepts, this is a GCI axiom and the referencedComponentId should be 733929006 |General concept inclusion axiom (metadata)|.
Our technical team asked me a similar question if C could be a precoordinated concept when they were implementing GCI axioms. I think we can make the OWL Guide more explicit to state what is not allowed as well to avoid potential misinterpretation, such as:

If C is a precoordinated concept, this SubclassOf axiom is NOT a GCI axiom and the concept D should not be assigned as the referencedComponentId. This would be a normal SubclassOf axiom and C is the referenced component.

The referencedComponentId has no impact on the semantics of the axioms and it is not used for any reasoning. The international tool follows the above statements. Therefore, it is correct that the axioms are still represented as multiple subclasses axioms against the concept 84458005.

However, we could introduce a QA in our toolset to check if C is a precoordinated concept. If it is not, concept D should not be assigned as a referencedComponentId. This will identify the issues you reported here and provide feedback on axioms promoted from extensions.


To simplify this for everyday authoring:

An axiom is considered to be a GCI axiom only when the left hand side is an expression or in other words the axiom contains at least one IS-A relationship and at least one attribute.

This is a rule enforced both by the Authoring Platform of SNOMED International and by our tooling - Snow Owl - as well. Here is the validation rule used by the Authoring Plaform.

The reason why this particular concept looks weird in the SNOMED CT Browser is because it is backed by Snowstorm, which also uses the SNOMED OWL Toolkit under the hood. Upon loading the latest SNOMED CT Canada Edition into that tool, the toolkit silently converts such axioms to simple class axioms, which eventually leads to the erroneous representation noted in the comments previously.

Yong also mentioned that the original approach of having a simple class axiom on the international concept do conform to the SNOMED CT extension authoring rules:

The original modelling is correct because it is an additional axiom for the concept 844580005 from the international release. This approach conforms to the axiom addition without inclusion in the OWL Guide as below:

Axiom without inclusion - a new axiom without inclusion of the axiom from the international release as part of the extension axiom. For example:

  • SubClassOf(A C) is an axiom in the international release.
  • SubClassOf(A D) is a new axiom in the extension.


Regardless of the issues noted with the axioms we will provide a patch for Debbie and her team to let them import the latest Canada release as is. The OWL representation of the ontology should still be OK, because OWL reasoners do not have any issues with such axioms, but I suppose the aforementioned axioms will need to be corrected at some point.

I'm sharing our findings here hoping that the community can benefit from it later on.

Let me know if you have any questions.

Regards,

Gábor

Senior Software Engineer
B2i Healthcare

Please Log in or Create an account to join the conversation.

  • Posts: 11
2 years 6 months ago #7219 by Guillermo Reynoso
Quick update about the GCI display anomaly in SNOMED International Browser discussed with Jon: we believe at this time that there is an anomaly in SnowStorm import algorithm for GCIs with a single subclass statement and no additional properties, we will discuss the issue with SNOMED International technical team, and will post an update. The Canadian RF2 files are compliant with the specification, but the SNOMED CT implementation for GCIs might require a workaround to recognize them (instead of interpreting them as sel references) in some tools.

Please Log in or Create an account to join the conversation.

  • Posts: 11
2 years 6 months ago - 2 years 6 months ago #7215 by Guillermo Reynoso
Hi Jon, Debbie,

The primitive concept 27841000087102 |Antigen of non-live Human alphaherpesvirus 3 (substance)| is a Canadian concept that groups antigens of non-live forms of this virus. This concept was required to model the Canadian vaccine hierarchy, but it is more general than existing core concepts (SNOMED CT International Edition) that are more specific. This "non-live" distinction is not made in the International Release and is still under discussion at the Vaccine project group (because of the negation and the lack of support in the model).

Since national extensions should avoid changing International Release definitions affecting their meaning, the modelers considered two options:
  • Add another subclass axiom to the core concept 844580005 |Antigen of inactivated whole Human alphaherpesvirus 3 (substance)|, in the Canadian extension module. This approach is compliant with extension management policies.
  • Avoid modifying the core concept and just add two General Concept Inclusion (GCI) axioms to the Canadian primitive concept 27841000087102 |Antigen of non-live Human alphaherpesvirus 3 (substance)|, representing that the Canadian concept is a superclass of the core concept (instead of saying that the core concept is a subclass of the Canadian grouper).
The 20210930 release of the Canadian extension uses the latter approach, GCIs. After classification, the NNF (necessary normal form) will represent the desired outcome where the more specific core concept aggregates under the more general Canadian grouper without changing the core concept definition.

In the OWL reference set, the primitive concept 27841000087102 |Antigen of non-live Human alphaherpesvirus 3 (substance)| has three axioms (I hope the image displays correctly here):

https://drive.google.com/file/d/1fu0aRr3YxYy6s_kkkkif37620XG6BPzo/view?usp=sharing

However, as Jon points out, the SI browser diagram represents this inconsistently:

https://drive.google.com/file/d/1NEYUjRux5JgBogabwTLERlgSGLTQrrB4/view?usp=sharing

However, the selection of the Expression tab in the browser will list the three axiom definitions:
SubClassOf(
	:27841000087102 |Antigen of non-live Human alphaherpesvirus 3 (substance)|
	:260214004 |Antigen of Human alphaherpesvirus 3 (substance)|
)
SubClassOf(
	:23021000087106
	:27841000087102 |Antigen of non-live Human alphaherpesvirus 3 (substance)|
)
SubClassOf(
	:844580005
	:27841000087102 |Antigen of non-live Human alphaherpesvirus 3 (substance)|
)

The original semantics represented in the GCI (with the complex expression on the left side and the pre-coordinated concept on the right side) is usually represented in SNOMED CT OWL Refset file in inverted form to associate it with the pre-coordinated concept referenced in the GCI on the left side (instead of leaving this general assertion unrelated to a particular class but still part of the ontology -the way Protege represents GCIs). I assume this might be one possible reason the diagram illustrates the GCI like a standard subclass axiom with some confounding semantics.

Then, we can consider at least three lines of action:
  1. We will research what might be different in this concept definition compared with IE concept definitions containing GCIs, confusing the browser, and tools importing the axioms. I will follow up on that matter in one or two business days after the long weekend. Note that the inferred form is correct. Only the axiom representation seems to be confusing in some tool implementations.
  2. The use case (grouping a core concept under an extension concept) pattern has been used elsewhere in national extensions. Still, we can discuss whether the preferred pattern to represent the intended semantics would be through GCIs or secondary axioms at the Vaccines working group.
  3. Debbie has previously reported problems with her tooling importing Canadian definitions. We have been researching those reports and will review this one. Some of the patterns that cause problems were discontinued in the current version of the extension, even if they are semantically correct and conformant with the specifications (to give time for further evaluation and discussion). A few others might require collaboration with all parties involved to understand the best way better forward.

Finally, the message reported by Debbie would require some explanation from the tool provider. A "focus" concept is a notion derived from SNOMED CT compositional grammar rather than the OWL representation under discussion here. My understanding is that current versions of compositional grammar might not directly support GCI representation. The assertion "[focus] concept A is a superclass of B" (with the axiom attached to concept A) is represented in inverted form like "concept B is a subclass of concept A" (with the axiom still attached to concept A rather than to concept B ), making it difficult to distinguish a GCI from a standard subclass axiom in OWL expressions, except that the referenced concept is in the opposite side of the expression.

I hope this helps to promote a shared understanding of the use case and the modeling rationale, so we can research and build consensus around this matter. This preliminary comment addressing Jon's request for clarification in no way is a final answer; we will research and test the issue and will follow up after the weekend.

Kind regards,

Guillermo
Last edit: 2 years 6 months ago by Guillermo Reynoso.

Please Log in or Create an account to join the conversation.

  • Posts: 13
2 years 6 months ago #7214 by Jon Zammit
Hi Debbie,

Thanks for sharing this. I'm intrigued by the concept you referenced in your message - 27841000087102 |Antigen of non-live Human alphaherpesvirus 3 (substance)|

I'm wondering if the issue relates to its place in the hierarchy because the stated view from Sept 2020 shows the concept with 2 subtypes while the stated view from Sept 2021 shows no subtypes. Meanwhile the inferred view from 2021 shows the concept has two subtypes.

Also in looking at the diagrammatic view (stated defintion), the concept appears to be a subtype of itself. I wish I could insert an attachment here to show you what I'm talking about but if you go to the diagram tab and click on "stated", you'll see what I mean.

I'm interested in learning more about this concept and I look forward to any explanations other people can offer.

Regards,

Jon

Please Log in or Create an account to join the conversation.

InfoCentral logo

Improving the quality of patient care through the effective sharing of clinical information among health care organizations, clinicians and their patients.