FR3073067A1 - Procede de pilotage d'une salle notamment operatoire d'un plateau medico-technique - Google Patents

Abstract

La présente invention concerne un procédé de pilotage d'une salle (1) d'un plateau médico-technique, un descripteur d'état courant de la salle (1) étant stocké dans des moyens de stockage de données (22) et présentant une première valeur, le procédé étant caractérisé en ce qu'il comprend la mise en œuvre d'étapes de : (a) Acquisition par des moyens d'acquisition sonore (20) d'un équipement (2) disposé dans la salle (1), d'une commande vocale ; (b) Analyse par des moyens de traitement de données (21) de ladite commande vocale acquise de sorte à identifier une commande de transition d'état parmi une liste de transitions d'état ; (c) Détermination par les moyens de traitement de données (21) d'une deuxième valeur du descripteur d'état courant en fonction de la première valeur et de la transition d'état identifiée ; (d) Notification à un serveur (3) de pilotage du plateau de la deuxième valeur du descripteur d'état courant.

Description

PROCEDE DE PILOTAGE D’UNE SALLE NOTAMMENT OPERATOIRE D’UN PLATEAU MEDICO-TECHNIQUE

DOMAINE TECHNIQUE GÉNÉRAL

La présente invention se rapporte au domaine hospitalier. Plus précisément, elle concerne un procédé de pilotage de salles opératoires, et par extension de l’environnement peropératoire incluant les salles d’attentes et les salles de réveil post-opératoires.

ETAT DE L’ART

Les blocs opératoires sont des structures où sont pratiqués les interventions chirurgicales et les gestes d’anesthésie-réanimation nécessaires au bon déroulement de l’intervention, ainsi formées d’un ensemble de salles opératoires (dans lesquelles les interventions sont à proprement parler effectuées), de vestiaires chirurgicaux, d’une salle de réveil (dite SSPI, pour Salle de Surveillance Post-Interventionnelle), et de bureaux.

Les blocs opératoires font partie de ce que l’on appelle le « plateau médico-technique » (ou simplement le plateau technique), c’est-à-dire l’ensemble des lieux d’un hôpital ou d’une clinique permettant de réaliser, des actes curatifs ou diagnostiques. Le plateau peut comprendre en outre des salles d'accouchement, des salles d'imagerie médicale, des salles d'exploration fonctionnelles, etc.

Les blocs opératoires et de façon générale les plateaux médicotechniques sont des ressources complexes et coûteuses à gérer au sein d’un hôpital ou d’une clinique.

Les grands hôpitaux ont plusieurs dizaines de salles opératoires avec chacune plusieurs opérations par jour, lesquelles sont souvent planifiées plusieurs semaines en avance.

On constate aujourd’hui en pratique qu’un bloc opératoire n’est en moyenne exploité qu’à deux tiers de ses capacités, ce qui pourrait largement être optimisé. Des économies substantielles pourraient être faites, avec à la clé une meilleure rentabilité des hôpitaux, une prise en charge des patients améliorée et des vies sauvées, ce d’autant plus que les moyens alloués à la santé tendent à baisser.

Les raisons de la sous-exploitation des blocs opératoires sont multiples, mais sont pour beaucoup liées à des retards imprévus qui conduisent à reprogrammer certaines interventions. Outre le fait qu’une procédure chirurgicale puisse durer plus longtemps que prévu (si elle est plus complexe que prévue ou si des complications surviennent), il arrive par exemple qu’un chirurgien se révèle être indisponible, qu’un patient ne soit pas prêt à temps, que des brancardiers soient occupés, qu’une urgence prioritaire survienne, ou encore que la salle de réveil soit congestionnée nécessitant l'immobilisation du patient dans la salle d’opération en attendant qu’une place dans la salle de réveil se libère.

Au lieu de re-programmer les interventions rendues impossibles pour des causes variées, il serait possible d’optimiser dynamiquement le planning avec des logiciels adaptés.

Le problème est qu’il y a très peu de visibilité en temps réel des activités ayant lieu au sein du bloc opératoire, un bloc formant un espace quasiment « hermétique » de l’hôpital. Le manque de mesure impacte considérablement la régulation des flux dans le bloc opératoire. Les outils actuels sont des tableaux et des listes sur papier ou au mieux des logiciels manuels, nécessitant l'apport constant et rigoureux du personnel médical d’indicateurs en temps réel sur l'état d’avancement opératoire. En pratique, le personnel hospitalier se concentre sur le soin du patient avant tout. Les erreurs de saisie et les oublis sont très fréquents, générant des historiques biaisés et très imprécis de durée des interventions. De surcroît on constate une redondance des saisies et des lourdeurs, d’où des pertes de temps.

Ont par conséquent été proposées des solutions afin de surveiller automatiquement et en temps réel l’état des salles opératoires grâce à des capteurs d’activité humaine, de sorte à permettre une gestion centralisée et optimisée. Cependant le problème est plus complexe qu’il n’y paraît : la salle peut être très agitée sans qu’une opération soit en cours (par exemple lors du nettoyage) et très calme alors qu’une opération est en cours (pendant une manipulation délicate où le chirurgien se concentre et procède lentement).

Par conséquent, la demande de brevet US2015/0374259 suggère d’introduire une pluralité de capteurs très divers au sein de la salle opératoire (sur les instruments chirurgicaux, la table d’opération, les équipements de ventilation, l’éclairage, etc.) et de mettre en œuvre des fusions de données.

Cette approche apporte satisfaction mais pose deux problèmes majeurs. Le premier est un problème d’encombrement et de praticité. En effet, le bloc opératoire est déjà saturé par la présence croissante d’équipements, de sorte que la mise en place de toute nouvelle technologie nécessite un coût incrémental croissant. Le deuxième est la nature intrusive de certains capteurs (par exemple sur les instruments chirurgicaux), qui pourrait gêner l’équipe chirurgicale, d’où un risque potentiel sur la santé des patients qui n’est pas acceptable.

La demande FR1753148 a présenté une solution astucieuse permettant de savoir automatiquement et à tout instant si une opération est en cours dans le bloc. Cette méthode apporte entière satisfaction, mais ne donne qu’un résultat binaire.

De sorte à anticiper encore mieux, il serait souhaitable de disposer d’un nouveau procédé permettant de suivre en temps réel l'état d’avancement opératoire de façon générale qui permette de piloter tout un plateau, qui soit très fiable, bien moins complexe et moins cher que les solutions existantes, et surtout qui ne cause pas la moindre gêne à l’équipe médicale.

PRÉSENTATION DE L’INVENTION

La présente invention se rapporte donc selon un premier aspect à un procédé de pilotage d’une salle d’un plateau médico-technique, un descripteur d’état courant de la salle étant stocké dans des moyens de stockage de données et présentant une première valeur, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre d’étapes de :

(a) Acquisition par des moyens d’acquisition sonore d’un équipement disposé dans la salle, d’une commande vocale ;

(b) Analyse par des moyens de traitement de données de ladite commande vocale acquise de sorte à identifier une commande de transition d’état parmi une liste de transitions d’état possibles ;

(c) Détermination par les moyens de traitement de données d’une deuxième valeur du descripteur d’état courant en fonction de la première valeur et de la transition d’état identifiée ;

(d) Notification à un serveur de pilotage du plateau de la deuxième valeur du descripteur d’état courant.

Selon d’autres caractéristiques avantageuses et non limitatives :

• l’étape (a) comprend l’acquisition préalable par les moyens d’acquisition sonore (20) d’une requête d’invocation de commande vocale ;

• l’étape (a) comprend l’analyse par les moyens de traitement de données de l’équipement de la requête d’invocation de commande vocale de sorte à détecter un mot-clé ;

• l’acquisition de la commande vocale est mise en œuvre soit pendant une durée prédéterminée soit jusqu’à détection d’un silence, suite à l’acquisition d’une requête d’invocation de commande vocale ;

• chaque transition d’état possible de ladite liste est associée à un poids, l’étape (b) étant également fonction desdits poids ;

• la transition d’état est identifiée à l’étape (b) seulement parmi les transitions d’état possibles présentant un poids supérieur à un premier seuil de référence ;

• les poids sont recalculés dynamiquement par les moyens de traitement de données ;

• les poids présentent une vitesse de variation fonction d’au moins la première valeur du descripteur d’état courant ;

• l’équipement comprend une interface de sortie, le procédé comprenant l’émission d’une notification d’alerte via l’interface de sortie si une transition d’état possible présente un poids supérieur à un deuxième seuil de référence ;

• l’étape (a) comprend le pré-traitement de la commande vocale par les moyens de traitement de données en fonction d’un contexte sonore de la salle ;

• l’équipement comprend une interface de sortie, l’étape (b) comprenant l’émission d’une confirmation via l’interface de sortie suite à l’identification d’une commande de transition d’état ;

• l’étape (c) comprend le remplacement de la première valeur du descripteur d’état courant par la deuxième valeur dans les moyens de stockage de données, et la répétition du procédé ;

• l’étape (b) comprend l’émission à destination d’un serveur distant d’un signal sonore de la commande vocale, et la réception en retour d’une transcription écrite de la commande vocale.

Selon un deuxième aspect est proposé un équipement de pilotage d’une salle d’un plateau médico-technique, le système étant caractérisé en ce qu’il comprend des moyens d’acquisition sonore et des moyens de traitement de données configurés pour la mise en œuvre du procédé selon le premier aspect de pilotage de la salle du plateau médico-technique.

Selon d’autres caractéristiques avantageuses et non limitatives, l’équipement comprend en outre les moyens de stockage de données stockant le descripteur d’état courant de la salle.

Selon un troisième aspect est proposé un système de pilotage d’un plateau médico-technique, comprenant, pour au moins une salle du plateau, un équipement selon le deuxième aspect, et un serveur de pilotage du plateau, connectés.

Selon un quatrième et un cinquième aspect sont également proposés un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de pilotage d’une salle d’un plateau médico-technique, lorsque ledit programme est exécuté sur un ordinateur ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de pilotage d’une salle d’un plateau médico-technique.

PRÉSENTATION DES FIGURES

D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels :

- la figure 1 est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ;

- la figure 2 représente une architecture d’un mode de réalisation préféré de ce système.

DESCRIPTION DÉTAILLÉE

Pilotage de salles d’un plateau médico-technique

La présente invention concerne un procédé de pilotage d’une salle d’un plateau médico-technique, et notamment d’une salle opératoire 1, en vue de gérer la disponibilité de la salle 1. Comme expliqué, la salle opératoire est une pièce du bloc opératoire dans laquelle les opérations sont effectuées. A ce titre une salle opératoire 1 comprend une table d’opération, généralement disposée en son centre de sorte à pouvoir circuler autour, sur laquelle le patient est allongé pour l’opération. Dans la suite de la présente description on prendra l’exemple préféré de la salle opératoire mais on comprendra que l’invention peut être mise en œuvre dans les autres salles du plateau médico-technique telle qu’une salle d’imagerie médicale ou une salle de cardiologie.

Par pilotage d’une salle 1, on entend la surveillance et la gestion, i.e. la détermination automatisée d’un état de la salle 1, en vue du contrôle et le cas échéant de la manipulation d’une base de données d’état de tout ou partie des salles du plateau, cette base de données étant généralement stockée sur un serveur 3 de l’hôpital, habituellement équipée d’une interface utilisateur 4. En effet, cette base de données est généralement gérée manuellement par le personnel hospitalier, qui renseigne pour chaque salle du plateau l’état, et le modifie en fonction des informations qui lui parviennent.

En ce qui concerne la notion d’état, a minima on fait la distinction entre un état « disponible » et un état « non disponible », préférentiellement on distingue au moins quatre états principaux :

- Salle libre ;

- patient dans la salle mais l’opération n’a pas encore commencé ;

- opération en cours ;

- opération terminée mais patient encore dans la salle.

Au sein de ces états principaux on peut distinguer des sous-états, notamment dans l’état opération en cours, par exemple, patient induit, patient insufflé, patient extubé, champ préparé, boîte chirurgicale préparée, etc.

Ici on comprendra que la notion d'opération est fonction du type de la salle. Par exemple, dans une salle d’imagerie médicale, au lieu d’« opération en cours » on aura un état de type « examen en cours », etc.

En référence à la figure 1, le procédé est mis en œuvre au sein d’un système comprenant au moins des moyens d’acquisition sonore 20 connectés à des moyens de traitement de données 21.

De façon préférée, les moyens d’acquisition sonore 20 et les moyens de traitement de données 21 sont ceux d’un équipement 2, disposé dans la salle opératoire 1. On comprendra qu’alternativement les moyens 21 peuvent être distants.

Ces moyens de traitement de données 21 (par exemple le processeur d’un microprocesseur de type Raspberry Pi) peuvent être également connectés au serveur 3 pour prise en compte des résultats.

Les moyens d’acquisition sonore 20 sont typiquement un microphone par exemple de type ReSpeaker Mic Array. Ces derniers peuvent être de types variés, il suffit qu'ils soient aptes à écouter le son ambiant de la salle 1.

L’équipement 2 comprend également avantageusement des moyens de stockage de données 22 tels qu’une carte SD (« Secure Digital »).

L’équipement 2 comprend également avantageusement une interface de sortie 23 qui peut comprendre un écran, des haut-parleurs, ou simplement une source lumineuse. Dans la suite de la description on prendra l’exemple de seuls haut-parleurs.

Les connexions des composants 20, 22, 23 aux moyens de traitement de données peuvent être de nombreux types et notamment permettre l’alimentation électrique des composants, par exemple en USB (« Universal Serial Bus »).

L’équipement 2 présente préférentiellement au moins un boîtier encapsulant tout ou partie des composants susmentionnés, préférentiellement en un matériau qui peut subir des stérilisations chimiques par application des solutions antiseptiques utilisées quotidiennement dans les salles opératoires.

On comprendra qu’alternativement l’équipement 2 pourra être être encastré dans le mur des salles opératoires 1.

Le présent procédé peut gérer simultanément plusieurs salles opératoires 1 chacune équipée d’un équipement 2, comme l’on voit sur la figure 2. Des configurations alternatives peuvent mettre en œuvre le positionnement d’équipements 2 additionnels dans le reste du bloc opératoire, en particulier la salle de réveil (SSPI) et/ou les couloirs.

La connexion entre les moyens de traitement de données 21 et le serveur 3 peut être filaire, en particulier Ethernet (et alors un équipement de routage 5 de type switch est préférentiellement utilisé s’il y a plusieurs équipements 2 de plusieurs salles 1 comme dans l’exemple de la figure 2), ou sans-fil (Wi-Fi). De façon préférée, l’équipement de routage 5 permet la connexion au réseau internet 51 pour la mise en œuvre d’un mode de réalisation préféré qui sera décrit plus loin. L’alimentation électrique du dispositif peut être séparée ou via PoE (Power over Ethernet).

Principe de l’invention

Le présent procédé propose une communication asynchrone entre le personnel opératoire et le serveur de l’hôpital 3 via de la reconnaissance vocale.

L’intérêt de la reconnaissance vocale est qu’elle ne nécessite pas d’utiliser ses mains, et donc qu’un chirurgien ou un autre membre du personnel peut tout à fait l’utiliser sans impact sur l’opération et sans risque d’hygiène.

Il est à noter que la notion de reconnaissance vocale a déjà été introduite dans les salles opératoires, en particulier pour le contrôle d’instruments chirurgicaux, voir par exemple le brevet US7921017.

De façon assez basique, il est proposé pour l’instrument, par exemple un endoscope, de comprendre des mots tels que « stop », « zoom », « rotate », « on », « off », de sorte à être contrôlé vocalement par le chirurgien tout en utilisant séparément ses mains.

Similairement, la demande US2009/0132276 propose l’utilisation de la reconnaissance vocale non pas dans les salles opératoires, mais aux urgences, pour dicter des notes d’informations sur les patients arrivant. Il n’y a à proprement parler pas de commandes vocales hormis pour le contrôle du logiciel de dictée.

Cette technologie peut être astucieusement transposée pour la gestion de disponibilité de salles en proposant de comprendre non pas des ordres adressés à un instrument chirurgical ou un terminal de dictée, mais des états de disponibilité de la salle opératoire 1.

L’idée est que qu’une intervention chirurgicale présente un nombre de déroulements possibles fini, et même assez réduit dans l’immense majorité des cas.

On peut donc considérer une intervention comme une succession d’états séparés par des transitions d’états (des événements), et modéliser l’ensemble des états « opératoires » par un graphe orienté.

Il suffit alors de savoir détecter les transitions d’état grâce aux mécanismes de reconnaissance vocale pour permettre de surveiller efficacement et sans risque l’état de toute salle opératoire 1 et de la piloter.

A ce titre, pour la mise en œuvre du présent procédé un paramètre, appelé descripteur d’état courant de la salle opératoire 1, est stocké dans des moyens de stockage de données 22 et présente une première valeur à l’initialisation du procédé. Plusieurs paramètres peuvent être stockés si plusieurs salles 1 du plateau sont pilotées simultanément.

On peut prévoir une valeur par défaut du descripteur qui est par exemple « salle libre ». Une itération du procédé permet de déterminer une deuxième valeur du descripteur suite à un événement, par exemple « patient dans la salle mais l’opération n’a pas encore commencé ».

De façon particulièrement avantageuse, les transitions d’état possibles peuvent être associés à des poids selon la nature de l’opération, le profil du patient et la disponibilité des ressources humaines et matérielles. Le poids d’une transition dans le graphe des états définit en pratique la probabilité d’occurrence de cette transition, et on peut choisir un poids à valeur dans [0 ; 1]·

Par exemple, on sait qu’une transition de l’état « induction » vers l’état « salle libre » est physiquement impossible, son poids est donc nul. De façon plus spécifique, on sait que les états « insufflation » ou « exsufflation » n’ont lieu que dans certaines opérations (coelioscopie), et donc le poids d’une transition « induction » vers « insufflation » est moyen pour ces opérations, et nul pour les autres. Dans tous les cas, le poids d’une transition « insufflation » vers « exsufflation » est élevé. A titre de dernier exemple, un patient allergique au latex sera préparé différemment d’un patient non-allergique avant l’incision (il ne sera pas intubé), la transition vers « intubation » présente donc un poids plus faible.

Le procédé peut être itéré au fur et à mesure des événements en prenant la deuxième valeur du descripteur comme une nouvelle première valeur et ainsi de suite, jusqu’à retourner dans l’état par défaut, i.e. d’avoir accompli un cycle complet c’est-à-dire d’une intervention du début à la fin. La salle 1 peut être alors réutilisée pour une nouvelle intervention.

Poids dynamiques

De façon préférée les poids évoluent dynamiquement au cours de l’opération, c’est-à-dire qu’ils sont recalculés par les moyens de traitement de données 21. Le recalcul peut être à chaque changement d’état, ou en temps réel, avantageusement les deux : à chaque changement d’état, on réaffecte des valeurs par défaut aux poids, et ceux-ci vont ensuite varier tant qu’aucune transition ne survient.

Selon un mode de réalisation préféré, les poids varient en fonction du temps, chacun présentant notamment une vitesse de variation.

De nombreuses transitions avec un poids nul peuvent présenter une vitesse de variation nulle (i.e. le poids reste nul), en particulier les transitions impossibles.

Certaines peuvent avoir une vitesse de variation positive, i.e. leur poids et donc la probabilité de survenir augmente au cours du temps (par exemple la transition de « insufflation » à « exsufflation »), et d’autres peuvent avoir une vitesse de variation négative, i.e. leur poids et donc la probabilité de survenir baisse au cours du temps (par exemple une transition « appel d’anesthésiste » après l’état « induction »).

Les vitesses de variation sont au moins fonction du premier état courant (l’état actuel). Plus précisément, à un état donné de nombreuses transitions ont une vitesse de variation nulle, et certaines liées à l’état en cours auront une vitesse de variation non nulle. Ainsi, à chaque changement effectif d’état on définit les nouvelles valeurs de variation des poids des transitions.

De façon préférée, les moyens 21 mettent en œuvre un algorithme d’apprentissage supervisé, par exemple un réseau de neurones, pour optimiser les valeurs de ces vitesses de variation au fur et à mesure des opérations réelles.

Comme l’on va voir, les poids dynamiques permettent à la fois de faciliter la mise en œuvre du procédé, et de détecter des erreurs telles que la détection manquée d’une transition.

On notera qu’il est possible de façon équivalente d’associer des poids non pas aux transitions mais aux états eux même (ce poids changeant à chaque transition naturellement), l’homme du métier saura transposer.

Procédé

Le présent procédé commence par une première étape (a) d’acquisition par les moyens d’acquisition sonore 20 d’une commande vocale. Comme l’on verra cette commande vocale désigne une transition d’état parmi une liste de transitions d’états potentielles.

Par acquisition de la commande vocale, on entend l’enregistrement d’un signal sonore (i.e. le signal électrique représentatif d’une vibration acoustique) obtenu lorsque ladite commande est prononcée par un praticien dans la salle opératoire 1, par exemple un signal sonore dans lequel on entend « début de l’opération ».

Selon un premier mode de réalisation, les moyens d’acquisition sonore 20 enregistrent en permanence le son. Une telle solution est possible mais très lourde en termes de traitements subséquent du signal (les moyens de traitement de données 21 doivent en permanence chercher à identifier une commande vocale dans le flux sonore).

Selon un deuxième mode de réalisation, l’étape (a) comprend l’acquisition préalable par les moyens d’acquisition sonore 20 d’une requête d’invocation de commande vocale.

Par « requête d’invocation de commande vocale » on entend une commande vocale spécifique d’initialisation du procédé, indiquant que la vraie commande vocale va suivre. Plus précisément, si une requête d’invocation de commande vocale est valablement acquise, alors (et seulement là) l’acquisition de la commande vocale est mise en œuvre.

Dans ce mode de réalisation, l’étape (a) comprend l’analyse par les moyens de traitement de données 21 de l’équipement 2 de la requête d’invocation de commande vocale de sorte à détecter un mot-clé. En d’autres termes, l’acquisition d’une commande vocale n’est pas mise en œuvre tant que le mot clé n’a pas été détecté. Si le mot clé n’est pas détecté, on considère que l’on n’a pas affaire à une requête d’invocation de commande vocale.

Le mot-clé de réveil, ou « wake word » ou encore « trigger word » en anglais, est un mot ou une phrase (et de façon générale une sonorité) prédéterminé facile à reconnaître, et dont la détection entraîne l’acquisition de la commande vocale, i.e. autorise la mise en œuvre de la suite du procédé.

Dans le contexte opératoire, le mot-clé est par exemple « Next ». On connaît par exemple les wake words « Ok Google » ou « Dis Siri » dans les systèmes de reconnaissance vocale Android et iOS.

Et dans la mesure où le wake word est unique et bref, il est plus facile de le détecter que de détecter l’une des commandes vocales.

Un module de détection de mot-clés de réveil est mis en œuvre par les moyens de traitement de données 21. Le module reçoit en permanence le signal sonore produit par les moyens d’acquisition sonore 20 (le son ambiant est donc écouté en permanence), et le traite en permanence en y cherchant le mot-clé.

En cas de détection du mot-clé (et donc lorsque l’acquisition de la commande vocale va être mise en œuvre), un signal de confirmation peut être émis à destination de l’interface de sortie 23 (par exemple un son sur les hautparleurs, ou une couleur verte de la ou les LEDs) de sorte à informer le praticien ayant prononcé la requête d’invocation qu’elle a bien été reçue et qu’il peut prononcer la commande vocale.

A ce titre, l’acquisition de la commande vocale peut avantageusement être mise en œuvre pendant une durée prédéterminée, par exemple cinq secondes, i.e. les moyens 20 génèrent un signal sonore « candidat » de cette durée prédéterminée. Alternativement, l’acquisition de la commande vocale peut être mise en œuvre jusqu’à la détection d’un silence, i.e. le son est enregistré tant que le praticien parle. Le signal sonore n’a alors plus une durée prédéterminée.

L’étape (a) peut ensuite comprendre le prétraitement de la commande vocale par les moyens de traitement de données 21 en fonction d’un contexte sonore de la salle 1. En effet, la prise de son n’est pas dans des conditions habituelles, dans la mesure où le personnel a généralement un masque qui déforme la parole, et de plus on a un bruit de fond résiduel dans la salle 1 (« bip » de certaines machines de surveillance corporelle, bruit des instruments métalliques, etc.).

Il est possible d'entraîner un réseau de neurones mis en œuvre par les moyens 21 pour tenir compte de ce contexte et « filtrer » le signal sonore acquis, pour faciliter la suite du procédé.

Dans une étape (b), le procédé comprend l’analyse par les moyens de traitement de données 21 de ladite commande vocale acquise de sorte à identifier une commande de transition d’état parmi une liste de transitions d’état possibles.

La liste de transition d’états peut à titre d’exemple comprendre les transitions potentielles suivantes :

a. le patient est arrivé ;

b. le patient a quitté la salle ;

c. intubation ;

d. incision ;

e. fin de la chirurgie ;

f. suture ;

g. tumeur extraite ;

h. appel du patient suivant ;

i. appel de brancardier ;

j. appel d’infirmière ;

k. appel d’anesthésiste ;

l. appel de chirurgien ;

m. insufflation ;

n. exsufflation;

etc.

A noter qu’on peut tout simplement prévoir que la liste de transitions d’états possibles contienne toutes les transitions théoriques, i.e. deux (dans un sens et dans l’autre) pour chaque paire d’états. Ainsi, s’il y a n valeurs du descripteur d’état courant, la liste contient n(n-1) transitions possibles, dont la grande majorité sera toutefois impossible et présentera un poids définitivement nul. Alternativement, le graphe n’est pas « complet » et seules les transitions effectivement possibles sont présentes dans la liste. On peut même prévoir une liste pour chaque valeur du descripteur d’état (i.e. les transitions d’état possibles à partir cet état).

Selon un mode de réalisation particulièrement préféré, une partie de cette étape est mise en œuvre par des moyens de traitement d’un serveur distant dédié 50, par exemple du réseau internet 51 (on comprend que ce serveur distant 50 pourrait être confondu avec le serveur de pilotage 3).

En effet, contrairement à la détection du mot-clé qui n’a pas besoin de reconnaissance vocale à proprement parler (on cherche juste à reconnaître une sonorité prédéterminée), l’analyse de la commande vocale de sorte à identifier la transition d’état implique une compréhension sémantique de cette commande.

Par exemple si le praticien dit « le patient est arrivé » ou « arrivée du patient dans la salle », on a deux sonorités différentes mais la commande est en fait identique.

Dans le mode de réalisation préféré où une partie du traitement est externalisé, les moyens de traitement 21 envoient le signal sonore acquis suite à l’étape (a) au serveur distant 50, et ce dernier réalise une transcription écrite de la commande vocale depuis le signal sonore.

Ensuite, les moyens de traitement 21 ou à nouveau le serveur distant 50 peuvent traduire cette transcription en utilisant un dictionnaire de mots (pour identifier le ou les mots fondamentaux de cette transcription, i.e. supprimer les articles ou « déconjuguer » les verbes), et n’ont plus qu’à comparer les mots fondamentaux identifiés dans cette transcription (par exemple « patient » et « arriver » dans l’exemple susmentionnés) avec un ou plusieurs libellés attendus des transitions d’état de la liste de sorte à identifier celle qui est visée par le praticien.

On comprendra que le présent procédé n’est pas limité à l’externalisation de la phase de transcription et/ou de la phase d’interprétation de la transcription, l’algorithme associé pouvant être embarqué par le module de traitement 21 de sorte que l’étape (a) est entièrement mise en œuvre au sein de l’équipement 2.

L’identification de la transition d’état signifiée par la commande vocale est avantageusement fonction des poids.

En particulier, on peut prévoir que la transition d’état est identifiée seulement parmi les transitions d’état possibles présentant un poids supérieur à un premier seuil de référence. En d’autres termes les moyens 21 définissent une « sous-liste » ne contenant que les transitions d’état possible avec un poids supérieur au premier seuil, i.e. on exclut les transitions en pratique impossibles. Ce premier seuil est par exemple égal à 5%.

Ensuite, le poids peut permettre de trancher en cas de doute, si deux transitions d’état sont possibles au vu de la commande vocale : les moyens 21 sélectionneront celle avec la probabilité la plus forte, i.e ; le poids le plus élevé, ou du moins présentant une avance de poids significative (par exemple un écart au-delà d’un seuil, par exemple au moins 10%). On peut en effet supposer que si l’on hésite entre deux transitions qui présentent des poids proches, on ne peut pas trancher.

Si la transition d’état est identifiée, à nouveau une confirmation peut être émise via l’interface de sortie 23 (par exemple en prononçant la transition d’état sur les haut-parleurs). Dans le cas contraire (si aucune transition d’état pouvant correspondre n’est identifiée, ce qui peut être le cas si le mot-clé a été prononcé par erreur et ainsi si la requête d’invocation de commande vocale a été émise par erreur, ou si deux transitions avec des poids proches sont possibles) un message peut être émis via l’interface de sortie 23 (par exemple une lumière rouge de la ou les LEDs).

Dans une étape (c), les moyens de traitement de données 21 déterminent une deuxième valeur du descripteur d’état courant en fonction de la première valeur et de la transition d’état identifiée. Comme expliqué, il suffit de disposer d’un graphe ou simplement d’une table de combinaisons (première valeur du descripteur d’état courant, transition d’état Θ deuxième valeur du descripteur d’état).

Par exemple si on est dans le premier état « salle libre » (état par défaut), et que la transition d’état [a. le patient est arrivé] est détectée, alors le deuxième état est « patient dans la salle mais l’opération n’a pas encore commencé ».

Dans une étape (d), la deuxième valeur du descripteur d’état courant est notifié au serveur 3 de pilotage de la plateforme en particulier pour modification de la base de données d’état des salles. En complément, des notifications peuvent être émise selon la valeur de l’état. Par exemple, si on atteint l’état « opération terminée mais patient encore dans la salle », l’équipe de la salle de réveil peut être informée du fait qu’elle peut venir chercher le patient.

Suggestions de transition

En parallèle, le procédé peut comprendre l’émission d’une notification d’alerte via l’interface de sortie 23 si une transition d’état possible présente un poids supérieur à un deuxième seuil de référence, par exemple 90%.

En effet, l’existence d’un tel poids est synonyme de problème : soit la détection d’une transition a été manquée (le personnel a mal prononcé la commande vocale ou a oublié de le faire), soit l’opération ne se déroule pas de façon nominale (un état prend trop de temps, on aurait déjà dû passer à l’état suivant).

Cette notification peut ainsi être une suggestion de transition (ladite transition présentant le poids au-dessus du deuxième seuil), émise par exemple par les haut-parleurs. Par exemple, si l’intubation a lieu, la probabilité est nulle de faire l’incision immédiatement après (poids proche de zéro). Or la vitesse de variation d’une telle transition est positive. Une fois le deuxième seuil atteint dans le temps, une proposition est suggérée vocalement, eg. “Avez vous procédé à l’incision ?”, les membres du personnel ayant oublié de le saisir répondent que “Oui” sinon “Non”. Ca garantit un enrichissement fiable, précis et temps-réel.

L’étape (d) peut également comprendre la notification au serveur 3 de chacune de ces notifications d’alerte, et de la réponse, de sorte par exemple à mobiliser automatiquement certains moyens (par exemple un deuxième chirurgien) s’il n’y a pas d’oubli mais bien une difficulté sur l’opération.

On notera que les valeurs des premier et deuxième seuils de référence des poids peuvent également être apprises par un réseau de neurones mis en œuvre par les moyens de traitement de données 21.

Système

Selon un deuxième aspect, l’invention concerne le système pour la mise en œuvre du procédé selon l’invention.

Ce système pour le pilotage d’un plateau médico-technique comprenant au moins une salle 1, notamment une salle opératoire 1, représenté par les figures 1 et 2, comprend donc, pour au moins une salle 1 (et préférentiellement pour chaque salle 1), des moyens d’acquisition sonore 20 et des moyens de traitement de données 21, en particulier ceux d’un équipement 2, configurés tel que décrit précédemment.

Le système peut également comprendre le serveur 3 de pilotage du plateau, et une interface 4 peut offrir une interface à un opérateur pour surveiller les salles 1 du plateau et être averti des changements de disponibilité, pour faire de l’optimisation.

Produit programme d’ordinateur

Selon un troisième et un quatrième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour 5 l’exécution (en particulier sur les moyens de traitement de données 21) d’un procédé selon le premier aspect de l’invention de pilotage d’une salle (1) d’un plateau médico-technique, ainsi que des moyens de stockage lisibles par un équipement informatique (des moyens de stockage de données 22 de l’équipement 2 comprenant les moyens de traitement de données 21) sur 10 lequel on trouve ce produit programme d’ordinateur.

Claims (18)

1. REVENDICATIONS

   1. Procédé de pilotage d’une salle (1) d’un plateau médicotechnique, un descripteur d’état courant de la salle (1) étant stocké dans des moyens de stockage de données (22) et présentant une première valeur, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre d’étapes de :

   (a) Acquisition par des moyens d’acquisition sonore (20) d’un équipement (2) disposé dans la salle (1), d’une commande vocale ;

   (b) Analyse par des moyens de traitement de données (21) de ladite commande vocale acquise de sorte à identifier une commande de transition d’état parmi une liste de transitions d’état possibles ;

   (c) Détermination par les moyens de traitement de données (21) d’une deuxième valeur du descripteur d’état courant en fonction de la première valeur et de la transition d’état identifiée ;

   (d) Notification à un serveur (3) de pilotage du plateau de la deuxième valeur du descripteur d’état courant.
2. 2. Procédé selon la revendication 1, dans lequel l’étape (a) comprend l’acquisition préalable par les moyens d’acquisition sonore (20) d’une requête d’invocation de commande vocale.
3. 3. Procédé selon la revendication 2, dans lequel l’étape (a) comprend l’analyse par les moyens de traitement de données (21) de l’équipement (2) de la requête d’invocation de commande vocale de sorte à détecter un mot-clé.
4. 4. Procédé selon l’une des revendications 2 et 3, dans lequel l’acquisition de la commande vocale est mise en œuvre soit pendant une durée prédéterminée soit jusqu’à détection d’un silence, suite à l’acquisition d’une requête d’invocation de commande vocale.
5. 5. Procédé selon l’une des revendications 1 à 4, dans lequel chaque transition d’état possible de ladite liste est associée à un poids, l’étape (b) étant également fonction desdits poids.
6. 6. Procédé selon la revendication 5, dans lequel la transition d’état est identifiée à l’étape (b) seulement parmi les transitions d’état possibles présentant un poids supérieur à un premier seuil de référence.
7. 7. Procédé selon l’une des revendications 5 et 6, dans lequel les poids sont recalculés dynamiquement par les moyens de traitement de données (21).
8. 8. Procédé selon la revendication 7, dans lequel les poids présentent une vitesse de variation fonction d’au moins la première valeur du descripteur d’état courant.
9. 9. Procédé selon l’une des revendications 7 et 8, dans lequel l’équipement (2) comprend une interface de sortie, le procédé comprenant l’émission d’une notification d’alerte via l’interface de sortie (23) si une transition d’état possible présente un poids supérieur à un deuxième seuil de référence.
10. 10. Procédé selon l’une des revendications 1 à 9, dans lequel l’étape (a) comprend le pré-traitement de la commande vocale par les moyens de traitement de données (21) en fonction d’un contexte sonore de la salle (1).
11. 11. Procédé selon l’une des revendications 1 à 10, dans lequel l’équipement (2) comprend une interface de sortie, l’étape (b) comprenant l’émission d’une confirmation via l’interface de sortie (23) suite à l’identification d’une commande de transition d’état.
12. 12. Procédé selon l’une des revendications 1 à 11, dans lequel l’étape (c) comprend le remplacement de la première valeur du descripteur d’état courant par la deuxième valeur dans les moyens de stockage de données (22), et la répétition du procédé.
13. 13. Procédé selon l’une des revendications 1 à 12, dans lequel l’étape (b) comprend l’émission à destination d’un serveur distant (50) d’un signal sonore de la commande vocale, et la réception en retour d’une transcription écrite de la commande vocale.
14. 14. Equipement (2) de pilotage d’une salle (1) d’un plateau médico-technique, le système étant caractérisé en ce qu’il comprend des moyens d’acquisition sonore (20) et des moyens de traitement de données (21) configurés pour la mise en œuvre du procédé selon l’une des revendications 1 à 13 de pilotage de la salle (1) du plateau médico-technique.
15. 15. Equipement selon la revendication 8, comprenant en outre les moyens de stockage de données (22) stockant le descripteur d’état courant de la salle (1).
16. 16. Système de pilotage d’un plateau médico-technique, comprenant, pour au moins une salle (1) du plateau, un équipement (2) selon l’une des revendication 14 et 15, et un serveur (3) de pilotage du plateau, connectés.
17. 17. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 13 de pilotage d’une salle (1) d’un plateau médicotechnique, lorsque ledit programme est exécuté sur un ordinateur.
18. 18. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 technique.