Les itinéraires cliniques organisent et coordonnent la prise en charge, le traitement et le suivi de patients souffrant de maladie chronique. Le projet PIPAS a pour but de développer un support informatique à ce type de workflow. Cet article détaille l’approche retenue pour répondre aux multiples défis posés par la limitation des ressources disponibles (médecins, équipements) et par le grand nombre d’itinéraires simultanés à gérer, chacun assorti de deadlines afin de garantir la qualité des soins.
Un des objectifs du projet PIPAS consiste à piloter les itinéraires cliniques des patients, qui font l’objet de nombreuses contraintes. Le personnel et les ressources disponibles sont tout d’abord limités. Il y a également un grand nombre d’itinéraires cliniques à piloter en même temps et qui doivent partager l’accès à ces ressources. Par ailleurs, chaque itinéraire est assorti de deadlines qui doivent être respectées pour assurer une bonne qualité des soins, tant au niveau médical qu’au niveau du confort du patient.
Afin de piloter des itinéraires cliniques, le CETIC développe un moteur permettant de dispatcher les patients aux différents endroits et de les prioriser de manière à ce que chaque patient puissent être traité selon son itinéraire clinique, et endéans les délais imposés.
Techniquement parlant, ce problème de dispatching et de priorisation est connu sous le nom technique de « scheduling ». Celui-ci nécessite l’utilisation d’un outillage informatique spécifique.
Cet outillage devra aussi respecter deux exigences supplémentaires, à savoir, l’efficacité et la généricité :
Résoudre le problème de scheduling sur des itinéraires cliniques est difficile parce que ces itinéraires incluent des points de décision, dont on ne connaît pas à l’avance la décision qui sera prise, et donc la suite du traitement. Les choix de priorisation doivent justement considérer les événements futurs pour prendre une décision. Considérons l’exemple type d’un patient qui, suivant une décision à venir, devra suivre soit une thérapie longue, soit une thérapie courte, les deux étant assorties d’une deadline identique. Selon la durée de la thérapie, le patient peut devenir plus ou moins prioritaire. Le degré de priorité n’est donc pas directement connu avant que la décision ne soit prise.
Une approche de résolution de ce problème a donc été proposée. Elle consiste à traduire le problème de scheduling sur des itinéraires cliniques avec un degré d’inconnue sous la forme d’une série de problèmes de « job shop scheduling » au moyen d’un algorithme dit du « regret ». Les problèmes de « job shop scheduling » ne contiennent pas d’inconnue, et peuvent donc être résolus directement.
Ces problèmes de job shop peuvent être résolus efficacement par une approche de type recherche locale basée sur des contraintes. Un moteur générique de recherche locale basée sur des contraintes a donc été développé, dans le but de résoudre des problèmes de « job shop scheduling ». L’architecture globale du système est illustrée à la Figure 1.
La couche générique du moteur nommée Astéroid est par ailleurs disponible sur la forge du projet Cellavi. Une seconde release (V0.2) en améliore notablement les performances. N’hésitez pas à la tester et nous contacter pour en savoir plus sur les possibilités de mise en oeuvre de tels outils dans votre domaine.