Difficulty Integrating SNOMED CT APIs into Healthcare Application about snowstorm HOT 2 OPEN

Thanks for reaching out!

Semantic Ambiguity

You are absolutely right. When searching the whole of SNOMED CT for a term like "fever" there will be responses from many hierarchies including findings, disorders, organisms and procedures. This is because SNOMED CT is a broad terminology that covers many areas of healthcare. For this reason it is essential to limit the scope of search for any specific field. This process, known as terminology binding, is traditionally done by creating value-sets or lists of codes that are applicable to a specific field. However with SNOMED CT it's possible to create the value-sets in real time using the SNOMED query language ECL (section 6 has lots of example). ECL is the recommended approach if possible in your situation. We also recommend using the FHIR API because this is a standardised API implemented by many terminology servers. Snowstorm has a native API that is used by the browser but this is not recommended for integrating with healthcare systems.

Let's build an example using the FHIR API for a constrained search for diagnosis.
The relevant hierarchy is 404684003 |Clinical finding (finding)|. This includes all findings and disorders. The ECL query to select all clinical findings is < 404684003|Clinical finding (finding)|. Using the FHIR API we can fetch a value set of the concepts in this set using an implicit value set.
Example: GET /fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/<%20404684003|Clinical%20finding%20(finding)|

The first time this request is run after restarting Snowstorm it can take around 15 seconds to prime the ECL results cache. After that it will be fast. This set of clinical findings can be filtered using a text string that can come from the user.
Example: GET /fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/<%20404684003|Clinical%20finding%20(finding)|&filter=fever

These requests return each concept's prefered term as the display term. This is the description that is recommended to display to users, even if a different description on the concept caused it to appear in the search results.

Concept ID Mapping

Ideally the users of the system should never see or even need to know about the concept ids. They should search to find concepts using the descriptions. They should see a list of relevant concepts, each displayed using the preferred term and without showing the concept id. They should be able to select the concept they want and this should recorded in the healthcare application using the concept id, but displayed to the user using the preferred term. The user should not need to see the FSN and semantic tag because they should have the context of what type of field they are using to understand what type of concept it is. For example "Symptom: Fever" .. the symantic tag (finding) is not necessary here.
I hope I have understood your question here.

Integration with API

Do you have Elasticsearch running? It looks like when Snowstorm started up Elasticsearch was not online yet. The latest Snowstorm release at this time (version 9.2.0) see https://github.com/IHTSDO/snowstorm/blob/9.2.0/docs/getting-started.md.
I would be happy to jump on a call to go through some examples or take a look at your setup. Just drop me an email at [email protected].

from snowstorm.

Thank you so much for the reply. I am working on the solutions provided by you, if I encounter any issue during this I will revert back to you.

from snowstorm.