hl7-be / allergy Goto Github PK

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

linked to #33

@HanneVuegen

• the asserter should come from valueset ‘Patientrelationship type’ for relatedperson and not refer to ‘related person’ as long as the Be profile for Related Person doesn’t exist.
• and like ‘recorder’ we should always reference the Belgian profiles BePatient, BePractitioner, BePractitionerRole

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

created because of #62

linked to #33

@HanneVuegen

• Should we also mention the TER-number?

linked to #33

technical issue for expansion of SNOMED refsets

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

https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/SNOMED.20.20refset.20as.20valueSet

Hi,

When connecting to the newest version of the Implementation Guide for AllergyIntolerance using the NPMValidationSupport feature of HAPI, we notice an inconsistency in the profile definition.
As the cardinality of the field asserter is 0..1 we can conclude this is an optional property.
However the invariant be-inv-asserter-person-rel-type (defined in the list of constraints) is returning an error in case asserter is empty.
Is this behavior expected or can the invariant be extended with the following statement: ‘or asserter.empty()’ or should the cardinality of asserter change to 1..1?

Link to AllergyIntolerance.asserter:
https://www.ehealth.fgov.be/standards/fhir/allergy/StructureDefinition-be-allergyintolerance-definitions.html#AllergyIntolerance.asserter
Link to constraints:
https://www.ehealth.fgov.be/standards/fhir/allergy/StructureDefinition-be-allergyintolerance.html#constraints

Kind regards,
Brecht Van Vooren
Vitalink-FHIR

@HanneVuegen

• Shouldn’t we specify CTI-extended > CNK > ATC
• Shouldn’t we refer to SAMv2?

collect info from hl7-be/core (branch v2)
collect info from hl7-be/riziv-inami : logical model

.. and PractitionerRole / BePractitionerRole.
We should remove the "core" resources if we only want to use the BE ones.

Some discussion here:
https://jira.hl7.org/browse/FHIR-35879

• info about export only in guidance

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.

This might be more useful for the medical record, but this concept gives a clear view on the problem. The attribute i'd like to discuss is AllergyIntolerance.reaction.exposureRoute

There exists a Kmehr table for drug administrations. This table is used in for example the current prescription and the vitalink concepts.
For the FHIR build we fully commit to the snomed CT standards, which I fully commit.
I do wonder if we need to explore the concept of mappings, for example between the kmehr drug administration routes and for example the Snomed CT Routes.

It's also fine if this development happens on a case-by-case basis, but it feels useful to explore this as an answer to questions that will inevitably arise on how to translate current kmehr - interfaces to fhir - interfaces in my opinion.

Example images:

In fhir this is called a concept map, and equivalence can be expressed with this value set.

@HanneVuegen

-        Can we add rules for:

Business Rules Allergy V1.2 NL.DOCX
Business Rules Allergy V1.2 FR.docx

release because of vaccination: hl7-be/vaccination#67

In een Belgische context kan een organisatie ook optreden als actor (zie COT kader): de referentie naar BeOrganization ontbreekt.

linked to #33

linked to #33

The recorder is a physical person who takes responsibility for the encoded information. It will therefore be identified by the NISS or NISS bis (mandatory)

But, it is possible to add other information such as the INAMI number, the name and first name, the role, or even the organization. Adding this additional information is optional but highly recommended.

@[email protected]
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

Decision:
Add to the AllergyIntolerance.recorder definition the following text:
...
Since the reference does not support BeOrganization, the BePractitionerRole resource/reference SHALL be used to refer to an organization when needed.

Approved with no abstention on 17-03

COW 18.05.2022.docx

after FHIR/ig-registry#95 and publication

Business Rules Allergy V1.3 FR.docx

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

use only the code 716186003 and not other. (delete the other code like 716220001 no known animal allergy or 409137002 no known drug allergy, ...)

from #9

J’ai aussi une petite remarque par rapport au modèle logique :

On peut avoir plusieurs manifestations  cardinality of reactions must be 0..*

https://docs.google.com/document/d/13qamEPfdQ2HgUiXmjwHQNchpEU3LsQHF5MN9jKufX2g/edit

@HanneVuegen

• Can we add a rule for ‘when no type is defined, VerificationStatus shall be ‘Unconfirmed’?

Business Rules Allergy V1.5 provisoire FR.docx
Business Rules Allergy V1.5 voorlopig NL.docx

Mail Anne Nerenhausen

no allergy: only the first (general) code #21
the other list in the email.

@HanneVuegen

• Cardinality should be 1 – 1

@HanneVuegen

• The definitions don’t match the definitions in the Business rule doc: resolved  pediatric allergies