Classification of Post Coordinated Expressions

[Eneuman]

We are developing a EHR system with Snomed as it's core.

When a user want to store "Life threatening allergy to peanut", we created a postcoordinated expression

91935009 | Allergy to peanut |: 246112005 | Severity |= 442452003 | Life threatening severity |

an then calculated the normal form for the expression. We stored this in a expression repository.

Since the stated relationships have moved to use OWL, we now need to calculate the NNF instead.

We can see that there are functionality to calculate NFF in OWL Toolkit, but have not found any example (or method) that can be used to go from a postcoordinated expression to NFF.
There are some documentation here https://github.com/IHTSDO/snomed-owl-toolkit/blob/master/documentation/calculating-necessary-normal-form.md but it's use case (and code) seems to be when converting RF2 files.

Are there any example/code that describes how to convert a postcoordinated expression to NFF to be able to store it in a expression repository?

Any help would be much appreciated!

[kaicode]

Hi @Eneuman,

We don't have any code or example of how to classify post coordinated expressions yet.

I think this would be a helpful feature for a growing number of people who are interested in post coordinated expressions for data analysis and would play into some work we have planned next year regarding an expression repository.

Next week I will put together a rough plan of how this should work and pull together some resources including the post coordinated expression syntax file we have so a parser can be generated in Java. I think the syntax is in ABNF but we tend to convert them to ANTLR and generate a parser using a specific version that we know works. I can't make any promises about when SNOMED International will assign resource to this but I would like to get the ball rolling anyway.

Thanks for getting in touch.
Kai

[kaicode]

@Eneuman, I think I need to check your requirements.

There is a more complete explanation of the Necessary Normal Form and how to generate it here.

Creating the NNF for post coordinated expressions would involve classifying them using a reasoner and then removing redundant relationships. This OWL toolkit would be a good fit for this functionality but I just wanted to check that this is what you require?

P.S. I found the expression parser I was looking for - https://github.com/IHTSDO/snomed-scg-parser

[Eneuman]

Hi @kaicode

We are building a multi tenant cloud native SAAS application.
It will have a terminology service that all tenants use to retrive snomed ct data for the user interface.
To find the right data, we use Snomed QL (draft) together with a custom parser and SQL compiler.

The workflow (briefly explained) for storing data is going to looks something like this:
Gui -> post coordinated expression -> Terminology Service -> Create NNF -> Create Caonical form -> Send information back to tenant -> Store NFF components in Repository DB and create Unique Id -> Store Unique Id in patient health record together with the Postcoordinated expression.

The requirements we have to be able to do this:

• Quickly identify if a expression already exists in the repository database
• Query a patient health records (Entries in health records are linked to reprository) using maby Snomed QL
• Create NFF from post-coordinated expressions without the use of the .zip files
• When new Snomed CT releases are imported, identify the changes and using that information, identify what repository information that needs to be re-classified.

There are many more requiriements that we can discuss. If you want we can setup a Skype meeting? :)
We have no legacy to handle so we want Snomed fully and correctly integrated in the system.

The ideal solution for us would be if the https://github.com/IHTSDO/classification-service was extended with a method that classifies post-coordinated expressions and a docker build file was added to the repo.

The second best would be a code sample that only relies on a created Snomed .OWL file (and maby some needed refset files). A settings object could hold the location of the files.

Regards
Per

[Eneuman]

@Eneuman, I think I need to check your requirements.

There is a more complete explanation of the Necessary Normal Form and how to generate it here.

Creating the NNF for post coordinated expressions would involve classifying them using a reasoner and then removing redundant relationships. This OWL toolkit would be a good fit for this functionality but I just wanted to check that this is what you require?

P.S. I found the expression parser I was looking for - https://github.com/IHTSDO/snomed-scg-parser

Lets say I want to create the NNF for this expression:
91935009 | Allergy to peanut |: 246112005 | Severity |= 442452003 | Life threatening severity |

Do you think this would work?

1. Use OWL-API and load the generated Snomed .OWL file.
2. Add the following Axiom to :91935009 |Allergy to peanut (finding)|

ObjectSomeValuesFrom(
			:609096000 |Role group (attribute)|
			ObjectIntersectionOf(
				ObjectSomeValuesFrom(
					:246112005 |Severity (attribute)|
					:442452003 |Life threatening severity (qualifier value)|
				)
			)
		)

3. Run the classifier
4. Generate the inferred view for 91935009
5. Generate the Canonical form for 91935009

[kaicode]

Hi @Eneuman, Happy New Year.
Yes this looks sensible. We plan to add incremental classification functionality to the OWL Toolkit and Classification Service this year with work currently planned for February. This new functionality will enable a SNOMED CT release to be held in memory which would enable expressions to be classified instantly. I'm sorry I can't provide a more aggressive or accurate timeline on this work but I'll keep you in the loop when there is something available in the develop branch.
Kind regards,
Kai

[Eneuman]

Hi @kaicode and Happy New Year to you to :)

That sounds very interesting and the time plan is no problem for us.

It would be great if I also could choose not to “commit” the changes to the ontology but only get the changes out of the ontology.

This way I could add a postcoordinated expression, run the classification and get the new infered view without changing anything.

It would need to be thread safe though :)

[kaicode]

Yes that's no problem. In fact adding the expressions to the Ontology would cause interesting problems and would not be supported, at least not initially.

[Eneuman]

Has there been any discussion about adding docker support (docker file and dist) to the release of the classification service? :)

Everyone is running Kubernetes these days so adoption to SNOMED would be easier with a supported scenario :)

[kaicode]

We would love to have all our tools containerised but it has not been a priority for the internal team because we have no use case for it at the moment. We welcome contributions in this area.

[kaicode]

In April this year SNOMED International published a practical guide to postcoordination https://snomed.org/postcoordination
I published a reference implementation within the SnowstormX project: https://github.com/IHTSDO/snowstorm-x/releases/tag/snowstorm-x-8.3.0
SnowstormX uses new functionality within the "incremental" branch of this snomed-owl-toolkit project. The ClassificationContainer class can be used to build a hot version of the SNOMED CT terminology that can be incrementally classified.