Evolution ZAM^Z03 (accusé de lecture MSS)

[isa-ans]

• MSH-21=2.1
• OBX portant le statut de l'accusé: ajout OBX-1 (séquence), OBX-5.3 (remplacement HL70136 par expandedYes-NoIndicator)
• ajout du segment ERR qui rend compte de l'erreur retournée par le message MDN (Message Disposition Notification) reçu par la PFI expéditrice
• ERR-3.3 : remplacer HL70357 par MessageErrorCondition et vérification de la valeur ERR-3.3 par rapport aux valeurs de la table messageErrorCondition

[mlr-kereval]

Bonjour @isa-ans ,

1. Le nom « MessageErrorCondition » proposé pour l’élément « CWE.3/CE.3 - Name of coding system » dépasse la taille de 20 caractères recommandée dans le standard HL7v2. Le validateur de message remonte ainsi un warning. Souhaites-tu réduire la taille du nom ou devons-nous augmenter la taille du CE/CWE.3 au niveau du validateur afin de ne plus remonter de warning ?

2. Dans les spécifications, l’élément ERR-5 du message ZAM^Z03^ZAM_Z03 prend ces valeurs dans la table HL70357 étendu avec les codes 9XX (annexe 6).

Dans le standard HL7v2, la table HL70357 est utilisée pour l’élément ERR.3. L’élément ERR.5 utilise la table user defined HL70533. La table MessageErrorCondition est-elle à vérifier au niveau de l’élément ERR.3 ou ERR.5 ?

[isa-ans]

1- Augmentation de la taille du CE/CWE.3 au niveau du validateur. 2- Ajout du champ ERR-5 pour spécifier l'erreur fonctionnelle avec la table HL70533 dont le nom symbolique est applicationErrorCode. le champ ERR-3 prend la valeur 207 (application error)

[mlr-kereval]

Validateur ZAM^Z03^ZAM_Z01 mis à jour :

• OBX-5.3 = expandedYes-NoIndicator pour le segment portant le statut de l'accusé
• Ajout d'un segment ERR
• ERR-3.1 = 207
• ERR-3.3 = messageErrorCondition
• ERR-5.1 doit appartenir à la table applicationErrorCode
• ERR-5.3 = applicationErrorCode
• CE/CWE.3 -> length = 1..30

[isa-ans]

Vérifié --> OK