Comme beaucoup d'autres se retrouvent probablement, nous étions obligés de faire un mappage de données en direct dans notre moteur d'interface, ce que nous ne voulions vraiment pas faire, mais nous n'avions pas de bon choix alternatif. Nous voulons uniquement conserver les mappages aussi longtemps que nécessaire, puis purger les lignes expirées en fonction d'une valeur TTL. Nous avions en fait 4 cas d'utilisation pour cela nous-mêmes avant de créer cela. Cas d'utilisation :

1. Le premier résultat ORU avec OBR-21 unique est converti en événement MDM^T02, tout ORU ultérieur avec la même valeur OBR-21 dans les 30 jours (flux de travail maximal possible) est envoyé en tant que MDM^T08 pour remplacer le lien de document existant.
2. L'ORM CPOE est généré à partir d'un résultat ORU. Le fournisseur résultant n'accepte pas les numéros de commande de remplissage et le moteur d'interface doit effacer le champ. L'interface CPOE doit avoir le numéro de commande de remplissage. Impossible de remplacer le numéro de commande de placement par le numéro de commande de remplissage car les techniciens cliniciens doivent référencer le numéro de commande de placement à l'intérieur des appareils du fournisseur. Le moteur d'interface doit ensuite mapper les numéros de commande de placement aux numéros de commande de remplissage pour ajouter les valeurs manquantes requises pour CPOE
3. Le fournisseur résultant ne peut pas modifier la procédure après le début de l'examen, et le dépôt des résultats doit être celui de la procédure la plus récente. Pour éviter de les traiter manuellement à chaque fois qu'ils se produisent, le moteur d'interface doit créer une carte pour toutes les nouvelles procédures après la notification de début d'examen et mapper les résultats à la nouvelle procédure. Le temps maximum pour conserver ces mappages de procédures est de 72 heures.
4. Le fournisseur ne peut pas gérer la mise à jour de la commande XO pour le message ORM de modification de procédure. Au lieu de cela, il attend une annulation (CA) pour l'ancienne procédure et une nouvelle (NW) ou une mise à jour (XO) pour la nouvelle procédure. Pour créer le message d'annulation, le moteur d'interface doit conserver une carte du numéro de commande à la procédure. Lorsqu'un message de mise à jour de procédure arrive, le moteur recherche la procédure précédente, envoie la commande d'annulation, puis met à jour le mappage persistant et envoie la mise à jour de la commande avec la nouvelle procédure. Il y aura un temps maximum qui devrait généralement être possible entre la nouvelle commande et une procédure de modification ultérieure.

Étant donné que ces scénarios conserveront des clés et des valeurs dynamiques en direct, nous souhaitons conserver les mappages uniquement aussi longtemps que nécessaire, puis purger les lignes expirées. J'ai examiné la classe LookupTable, mais elle ne fournit aucune fonctionnalité TTL. Nous avons donc écrit notre propre classe appelée LookupData.

https://codefile.io/f/vEgnWzafOx

Il s'agit de ma première classe que j'ai développée à partir d'une feuille blanche. Je suis ouvert aux critiques constructives sur la manière dont cela peut être amélioré. Je suis sûr qu'il existe de meilleures façons d'exécuter certaines méthodes, donc j'apprécie vos commentaires.