-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
Hi.
The discussion at HL7 is still ongoing - which is why I think we should
keep this visible, and NOT omit "non-allergic hypersensitivity".
https://jira.hl7.org/browse/FHIR-35879
*Proposal: add non-allergic hypersensitivity in Belgium by *
* making allergyintolerance.type 0..0
* adding an extension with the 3 values
* report this to HL7 international as feedback that the current valueset is
limiting.
…On Wed, Aug 17, 2022 at 9:08 AM Bart Decuypere (eHealth) < ***@***.***> wrote:
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
—
Reply to this email directly, view it on GitHub
<#62>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD3HUUD4EY3HNIKPC7LPO7LVZSFWVANCNFSM56YME4ZA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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. 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. |
Business Rules Allergy V1.6 NL.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 |
@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
The text was updated successfully, but these errors were encountered: