kaicode
commented
4 months ago 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 implementation@snomed.org.
Sonali129-dev
Issue: I am currently working on integrating SNOMED CT terminology services into our healthcare application to enhance its functionality and provide accurate diagnostic, procedure, medication, disease, and body system information to users. However, I have encountered several challenges and uncertainties regarding the implementation process and the construction of a relevant dataset.
Challenges:
Semantic Ambiguity: When searching for terms such as "fever" in the SNOMED CT Csno finder or Snomed CT browser, I'm presented with multiple concepts with different semantic tags. This ambiguity makes it difficult to accurately identify the relevant concept for integration into our application.
Concept ID Mapping: While SNOMED CT provides concept IDs for each term, it's not practical to assume that users will know these concept IDs in advance. Additionally, different terms may map to different concept IDs, complicating the process of constructing a dataset that aligns with our application's requirements.
Integration with API: Despite efforts to integrate SNOMED CT APIs into our application, we're facing challenges in connecting our healthcare application to the SNOMED CT server. I have gone through several documentations regarding the integration and implementation. I have also explored FHIR documentation and resources. I also explored the API collection in postman. But still I am not able to figure out the integration and implementation part.
Request for Assistance:
Guidance on Semantic Ambiguity: We would appreciate guidance on how to handle semantic ambiguity when querying SNOMED CT concepts, especially for terms with multiple semantic tags. Suggestions on best practices or strategies for disambiguation would be highly beneficial.
Approaches for Concept ID Mapping: We're seeking recommendations or approaches for mapping external terms or codes to SNOMED CT concept IDs within our application. Any tools, techniques, or resources that can simplify this process would be greatly appreciated.
Assistance with API Integration: We require assistance with connecting our server to the SNOMED CT server. Any insights, or support in configuring API integration and implementation would be valuable.
I tried to import zip file of snomed with snowstorm jar file but I am getting connection refused error.
Additional Context:
Our healthcare application aims to provide accurate and comprehensive diagnostic, procedural, and medication information to healthcare professionals and patients. We believe that integrating SNOMED CT terminology services will significantly enhance the functionality and utility of our application, but we're currently facing technical hurdles in achieving this integration effectively. Thank you for your attention to this matter. We look forward to your guidance and support in addressing these challenges and successfully integrating SNOMED CT into our healthcare application.