Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce value set to either findings or substances CHAllergyIntoleranceValueSet (Annatina Foppa, eHealth Suisse) #65

Open
ig-feedback opened this issue Mar 1, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@ig-feedback
Copy link
Collaborator

ch.fhir.ig.ch-allergyintolerance#1.0.0 /ValueSet-CHAllergyIntoleranceValueSet.html

Currently, the value set used for AllergyIntolerance.code uses codes of the hierarchy (findings) as well as of the (substance) hierarchy as “386961008 Aprotinin”. This solution is not satisfying because it lessens the potential for further usa as with CDS or inclusion in the problem list.
Discussions with representants from SNOMED led to the following conclusion: ". SNOMED CT implementation in FHIR guidance can be found here: http://build.fhir.org/ig/IHTSDO/snomed-ig/ while proposals of SNOMED CT adapted FHIR resources can be found here: http://build.fhir.org/ig/IHTSDO/snomed-ig/profiles.html .
You will note that there are two separated FHIR profiles proposed on this page, based on the general HL7 FHIR AllergyIntolerance resource. One is substance focused, meaning that the record centers for the AllergyIntolerance.code value on the substance the patient reacts to and captures separately the type of reaction in the AllergyIntolerance.type field. One can say this model captures the allergy/intolerance to X in a postcooordinated way. The second profile is finding focused, meaning it captures the allergy/intolerance in the AllergyIntolerance.code field using precoordinated "allergy/intolerance to X" SNOMED CT concepts and makes no use of the AllergyIntolerance.type field."
=>> Substance and finding based content should not be used simultaneously.
I propose a change to one of the hierarchies, whereby I am more in favor of the finding hierarchy.

Annatina Foppa, eHealth Suisse

@pjolo pjolo added the enhancement New feature or request label May 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants