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

Remark by Marie-Alexandra Lambot #62

Closed
bdc-ehealth opened this issue Aug 17, 2022 · 3 comments
Closed

Remark by Marie-Alexandra Lambot #62

bdc-ehealth opened this issue Aug 17, 2022 · 3 comments

Comments

@bdc-ehealth
Copy link
Contributor

bdc-ehealth commented Aug 17, 2022

@marie-alexandra.lambot@stpierre-bru.be
Based on document #63
Bonjour,

Et donc si je lis bien les modifications, comme ça, sur base de la CoW qui sont des fournisseurs de logiciel, sans réunion de ceux qui ont écrit les business rules de départ, on supprime l'hypersensibilité non allergique, un paramètre clinique qu'on s'est battu à SNOMED international pour faire reconnaître dans le modèle HL7 FHIR international jusqu'au Patient Care Group et pour lequel SNOMED on FHIR a crée spécialement une extension?

Franchement, je n'ai pas de mots.
Bien à vous

Dr LAMBOT Marie-Alexandra
Adjointe à la direction médicale
+32 2 535 49 80

@costateixeira
Copy link
Contributor

costateixeira commented Aug 17, 2022 via email

@mlambot
Copy link
Collaborator

mlambot commented Aug 17, 2022

Jose is exactly hitting the point. HL7 is considering to include more values in the Type field of AllergyIntolerance resource and make it a codable concept so SNOMED CT concepts can be used to represent the clinically relevant types of hypersensitivity reactions. BUT Patient care group has decided first to make this as an extension and see if it gets used and what feedback from the Belgian use-case they get before changing their standard resource. So if we scrape those values here and now, awaiting further HL7 developments, there is no test use-case anymore and the standard will not evolve. It's a snake biting its own tail and we're the head of the snake. Dropping those values now is throwing away one year and a half of efforts from the SNOMED international Allergy CRG and the Belgian CSCT community, and impoverishing clinical expression because there ARE patients with non allergic hypersensitivities. And calling that allergies or forcing a null value on type for that is not only putting them in danger of not receiving adequate care but also negating a very difficult condition they often had to fight hard to get diagnosed. In the light of the patient readable EHRs, this is thus also a morally damaging choice.

As for the fouth value, "hypersensitivity", is should be retained also and be the default because we are talking about postcoodination here, of having split the type of reaction and the substance causing the reaction on two fields. If you have no default, in some EHRs and in data retrieval, you'll only get the substance displayed, making the info impossible to understand. This is not a theoretical issue, it is a problem we face in an EHR I will not cite but that equips a lot of people here. We need a default type, it can't be empty at clinical display of pdf letter output level. It just won't do for clinicians in hospitals. If you don't have hypersensitivity as default then all will be tagged by default as allergies, abusively, so there is no blanc in the pdf. That is the reality of of good bunch of hospital EHRs today. Now there is a workaround. We'll use (keep using as it is already in prod since April in a number of places) four values in the EHR and share only two at care Set level but that's dirty.
It would improve clinical data if, as we said in the v1.1 of the business rules and in CSCT FAQs, "allergy" is to be used only for proven allergies, by IgE testing, patch, or allergologist expert advice and keep "hypersensitivity" for all the reactions that we still don't really know if they really are allergies. By keeping only two values, we ensure the persistence of abusive use of the term allergy for everything and anything, keeping our allergy box full of crap, denying patients with a lot of goods meds on one side with unproven "allergies" and casting doubt on the true allergy to drugs diagnosis on the other.

I find it utterly unacceptable if standardization comes down to impoverishing clinical expression and encouraging medical langue abuse just because it would take a bit of effort like using an extension and giving proof to the standard body there is a need to evolve. One must also bear in mind that the Allergy FHIR resource is an old one. It doesn't mean necessarily that it is perfect and should not be challenged. It may be that everyone gave up fighting to update it like we're about to do.

@bdc-ehealth
Copy link
Contributor Author

Business Rules Allergy V1.6 NL.docx
Business Rules Allergy V1.6 FR.docx

Mail by Sarah Francois (05/10/2022)

Chers tous,

L’INAMI souhaite vous informer du résultat de la discussion au sujet du « Type » dans le Care Set Allergie.

La problématique des différents types de classifications d’allergie a été exposée lors du congrès HL7 International le 21 septembre à Baltimore, la décision du groupe a été de changer le type vers un CodeableConcept, et laisser le binding strength « preferred ». Cela nous permet finalement d’utiliser un value set avec les types « Allergy », « Non-allergic hypersensitivity » et « Intolerance ».

Techniquement, ce changement sera dans la nouvelle version FHIR R5 (Mid-2023), mais il peut être adopté immédiatement via une extension puisque FHIR permet/préconise d’importer des éléments de la R5 comme extensions, en évitant une extension belge.

Vous trouverez, ci-joint, la dernière version du document Business rules avec cette adaptation.

Cordialement,

Sarah & Anne

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants