Il faut absolument, que les méthodes suivantes, de l'objet ISearch, permettent de filtrer les services sur la base de l'objet "ITarmedInput" passé par la propriété "DignityFilter".

La prise en compte de l'objet "ITarmedInput" devrait être générique et éritée par toutes les fonctions de rechercher.

ISearch.SearchCode
ISearch.SearchServiceBlock
ISearch.SearchServiceGroup
etc...

ISearch.SearchName255 ne peut pas suffir; s'il on veut développer un navigateur permettant à l'utilisteur de voir l'ensemble du tarif ou seulement la partie filtrer en fonction de sa dignité. Les applications des clients regroupent plusieurs "Physician"s de dignités différentes. Le passage de l'un à l'autre doit refiltrer les objets ouverts dans l'application en fonction du "Physician" courant de l'application. Il est également très ennuyeux de montrer un arbre de chapitres à moitié ou presque totalement vide. Le catalogue des chapitres devrait également permettre de filtrer avec un objet "ITarmedInput", c'est logique.
Nous pouvons également vous assurer que nos utilisateurs passeront normalement par une recherche par "code" et rarement une recherche par "nom". Le "code" est la seule partir d'un
service qui ne varie pas avec la langue de l'application. C'est également le "code" qui sera conservé dans la base de données du client. Si l'utilisateur veut se créer des raccourcis de
saisie, il mettra un "code" officiel en regard d'un code de saisie. Si l'utlisateur veut se créer un groupe de services liés et prêt à l'emploi, c'est également une série de "code"s
officiels qui seront mis en regard d'un seul code de saisie.

Les manoeuvres de contournement que le programmeur doit appliquer, pour pallier à se genre de manquement, sont trop pénalisantes pour l'application. Par exemple, pour chaque entrée de service d'un "ServiceBlock", il faut repasser un SearchName255 pour savoir s'il on a le droit de montrer le service.