Contents of AllergyIntolerance .type and BeExtAllergyType

[bdc-ehealth]

Do we set the cardinality of AllergyIntolerance .type to 0..0 or do we fill it with an equivalent value if available?

Solution 1:

• advantage: no duplication of information
• disadvantage: if this resource is imported by a system outside of the Belgian context, this information will not be present, and thus lost.

Solution 2:

• disadvantage: both the field and extension should be kept in sync, and might contain contradictory information.
• advantage: if this resource is imported by a system outside of the Belgian context, this information will be there, and it will be correct if it is kept in sync with the extension.

In another context, but for a similar problem, we already wrote this down: https://docs.google.com/document/d/170Gc3L4kuWzwyxIF0zgy7XPvZqmdWmhKS88bsIIJ-AQ/edit?usp=sharing

[mlambot]

Hi,

We could publish an official mapping of the FHIR Type values and the SNOMED CT values we are using, based on the mapping published in the Allergy Implementation guide from SNOMED international Allergy CRG. This guide is not yet published on SNOMED international website but it is just a question of setting the layout. The guide content is finalized and I can supply you with its definitive version.

Basically FHIR definition of "ALLERGY" corresponds to the concept 609433001 |Hypersensitivity disposition (finding)|, thus this concept and its two children 609328004 |Allergic disposition (finding)| and 609396006 |Non-allergic hypersensitivity disposition (finding)| all can map to the FHIR Type code ALLERGY.

The concept 782197009 |Intolerance to substance (finding)| maps to FHIR INTOLERANCE code. But on the revrse, FHIR definiton of the INTOLERANCE code is a negative one, it is the following "A propensity for adverse reactions to a substance that is not judged to be allergic or "allergy-like". These reactions are typically (but not necessarily) non-immune. They are to some degree idiosyncratic and/or patient-specific (i.e. are not a reaction that is expected to occur with most or all patients given similar circumstances)."

Thus for them INTOLERANCE is all propensities to adverse reactions that are not included in their ALLERGY code. However SNOMED CT, being an ontology doesn't allow for defintions working by excluding appartenance to other concepts. INTOLERANCE can also be a misnamer, be it in English or in French. The word "intolerance" is used in clinic sometimes to mean something specific in cases like "intolerance to lactose" or "intolrance to fructose" where the mechanism of intolerance is known. It can also be used in an inadequate way in "intolerance to glucose" to mean a disease (pre-diabetes). Or is can be used to mean "does not tolerlate well" the substance, which actually corresponds in SNOMED CT to 420134006 |Propensity to adverse reaction (finding)|.

As a result, mapping SNOMED concept 420134006 |Propensity to adverse reaction (finding)| to a FHIR Type code is a bit controversial, because it could fall under the FHIR defintion of INTOLERANCE but it is also the parent of, 609433001 |Hypersensitivity disposition (finding)|, thus subsuming the concepts falling under FHIR type ALLERGY so it would not be right to map 420134006 |Propensity to adverse reaction (finding)| to INTOLERANCE since INTOLERANCE excludes the reaction Types falling under ALLERGY.

Hence the choice of the Allergy CRG to map FHIR INTOLERANCE only to 782197009 |Intolerance to substance (finding)| and to leave the FHIR Type empty if someone wanted to convey the meaning the type of reaction was equivalent to SNOMED CT concept 420134006 |Propensity to adverse reaction (finding)|. The reasoning here would be that if you register a substance in the AllergyIntolreance resource, it means the person had an abnormal reaction to this substance. If the mechanism isn't specified, in TYPE then it means the type of reaction is "he reacted pooly to this", which is in SNOMED CT 420134006 |Propensity to adverse reaction (finding)|. Saying nothing about the type is saying something because of the context of the data model.

It is useful however for us in Belgium when using SNOMED CT substance values to specify a default AllergyIntolerance Type other then blanco for readability inside our EHR when printing the current information in pdf in our transition phase from printed reports to the modular Care Sets. Having the substance coming out ouf AllergyIntolerance printed "alone" with no Type in a report could cause confusion in the reader. All it would take is no proper heading in a pdf and the reader would no know if one was talking about a medication line or an adverse reaction.

It is a small refet but a mediacally dangerous one and one of the first things we'll want to exchange internationaly from a clinical safety point of view. I'd take option 2 and keep a strict eye on the mapping between the FHIR codes and the SNOMED CT concepts used in the BE extension/future CodableConcept R5 element.

Solution 1 is loosing when exporting to other countires possibly specific info of allergies that were truly investigated and diagnosed as such. This could promt duplication of exams abroad to confirm what is already known and/or lead to underestimating the seriousness of the patient propensity.

At the very least one can and should safely map for Belgian data export 609328004 |Allergic disposition (finding)|, 609396006 |Non-allergic hypersensitivity disposition (finding)| and 609433001 |Hypersensitivity disposition (finding)| to FHIR ALLERGY code and 782197009 |Intolerance to substance (finding)| to FHIR INTOLERANCE code.

On the reverse, at import of FHIR AllergyIntolerance data for abroad, one could safely automatically map ALLERGY to 609433001 |Hypersensitivity disposition (finding)| in our BE-extension system but INTOLERANCE could only be mapped safely to 420134006 |Propensity to adverse reaction (finding)|. Both automatic "conversions" should come with a remark somewhere that if could mean a more specific BE-Type (609328004 |Allergic disposition (finding)| or 609396006 |Non-allergic hypersensitivity disposition (finding)| for ALLERGY and 782197009 |Intolerance to substance (finding)| for INTOLERANCE) but that some clinical decision/review of the individual data is needed to confirm this possible more precise mapping of this external medical information form abroad into the BE system.

[mlambot]

If as was said in the meeting today, any information that is exported from Belgium to another country is "processed" by a national center providing equivalences where needed, then the conversion of the Type would not be needed for internal Belgian data use, it could be done only for outbound data.

Let's not forget also that Type becomes a codableConcept in R5 and we can and will already adopt this so by the time our Belgian safes are truly able to exchange allergy data, there will only be a Type element, using whatever code system we want, meaning SNOMED CT codes in Belgium, and no need for a BE-extension anymore. We could however still want to provide both codes, SNOMED CT and the FHIR codes, in the Type CodableConcept element as support for interoperability toward countries that might still be using R4 level resources. Whether this is needed or not will depend partly on what sits in the EU x-eHealth standard regarding exchanging allergy data and partly on our wish to be worldwide (outside EU) compatible or not with our portable patient data.

[bdc-ehealth]

INAMI proposal on 12/01/2023 during meeting Réunion Care Sets: Coffres-forts - eHealth - INAMI . We set the cardinality of the international field to 0..0 . See meeting minutes of this meeting. Proposal created on branch issue_86.