ES2784347T3 - Sistemas y métodos para detección y comunicación de eventos en tiempo real automatizados y centralizados - Google Patents

Sistemas y métodos para detección y comunicación de eventos en tiempo real automatizados y centralizados Download PDF

Info

Publication number
ES2784347T3
ES2784347T3 ES16200575T ES16200575T ES2784347T3 ES 2784347 T3 ES2784347 T3 ES 2784347T3 ES 16200575 T ES16200575 T ES 16200575T ES 16200575 T ES16200575 T ES 16200575T ES 2784347 T3 ES2784347 T3 ES 2784347T3
Authority
ES
Spain
Prior art keywords
location
critical
information
locations
individual
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16200575T
Other languages
English (en)
Inventor
Nathan Mancine
John Rovnan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Teletracking Technologies Inc
Original Assignee
Teletracking Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Teletracking Technologies Inc filed Critical Teletracking Technologies Inc
Application granted granted Critical
Publication of ES2784347T3 publication Critical patent/ES2784347T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Epidemiology (AREA)
  • Biomedical Technology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Un servidor de comunicación de hospital centralizado para monitorización y notificación de eventos, que comprende: una memoria que almacena instrucciones; y al menos un procesador configurado para ejecutar las instrucciones almacenadas para: recibir (502), desde un dispositivo en red, información del evento indicadora de un evento; recibir (504) entradas que pertenecen a la información del evento, las entradas que incluyen al menos un atributo personal de un individuo asociado con el evento y preferencias del individuo, al menos un atributo personal que incluye una o más características físicas y/o mentales del individuo; alterar al menos una de las entradas con base en al menos un atributo personal; determinar las prioridades de las entradas al determinar cada una de las entradas como críticas o no críticas para seleccionar una ubicación para el individuo y una prioridad relativa de cada entrada crítica y cada entrada no crítica que utiliza una jerarquía predeterminada de entradas; buscar (506) una base de datos de red para información de ubicación asociada con una pluralidad de ubicaciones dentro de un hospital, en la que, para cada una de la pluralidad de las ubicaciones, la información de ubicación incluye al menos un atributo de ubicación, al menos un atributo de ubicación que comprende un nivel de capacidad disponible en tiempo real de la ubicación; identificar, en base a la información del evento recibido, las entradas, y la información de ubicación, una ubicación seleccionada de la pluralidad de ubicaciones para el individuo asociado con el evento al: identificar una o más de la pluralidad de ubicaciones que tienen atributos de ubicación coincidentes todas entradas críticas; e iterar, hasta que se determine una sola ubicación o se hayan considerado todas las entradas no críticas: determinar cada una de la una o más ubicaciones que tiene un atributo de ubicación que coincide con la entrada no crítica que tiene la más alta prioridad, en la que si se determinan múltiples ubicaciones, la siguiente iteración es en base a las múltiples ubicaciones determinadas y la entrada no crítica que tiene la siguiente prioridad más alta, en la que si no se determina la ubicación, la siguiente iteración es en base a la entrada no crítica que tiene la siguiente prioridad más alta y las ubicaciones utilizadas durante la iteración actual, y en la que si se determina la ubicación única, la ubicación única es la ubicación seleccionada ; asignar (520) la ubicación seleccionada para el individuo y actualizar la base de datos de red para actualizar la información de ocupación en tiempo real de la ubicación seleccionada; y generar y transmitir automáticamente (522) al menos una comunicación electrónica relativa a la asignación a un dispositivo electrónico asociado con la ubicación seleccionada.

Description

DESCRIPCIÓN
Sistemas y métodos para detección y comunicación de eventos en tiempo real automatizados y centralizados Campo técnico
La presente divulgación se dirige al campo técnico de la detección y comunicaciones de eventos centralizados. Más particularmente, las realizaciones divulgadas se dirigen a sistemas de comunicación basados en servidor centralizados para generar mensajes electrónicos automatizados en una instalación basada en eventos detectados. Antecedentes
Los hospitales modernos tratan a cientos de pacientes todos los días. Cuando llega un paciente, se deben evaluar y abordar rápidamente su condición y necesidades, lo que a menudo requiere la coordinación y comunicación de múltiples departamentos en el hospital. En muchas situaciones, el paciente entrante se debe colocar en el área adecuada del hospital y, a veces, el paciente se debe reunir con múltiples médicos ubicados en diferentes unidades o instalaciones hospitalarias para citas programadas basadas en la condición del paciente y también cuando surgen emergencias, que requieren transporte de un área del hospital a otra o a otros hospitales/instalaciones. El cumplimiento de estas tareas requiere un intercambio frecuente y constante de datos e información en todo el hospital y entre varios hospitales.
Las técnicas de comunicación tradicionales para la detección y comunicación de eventos en dichos entornos se basan en tecnologías de comunicación obsoletas, lo que da como resultado sistemas sobrecargados que son lentos, propensos a errores y que no proporcionan comunicación en toda la instalación utilizando un sistema centralizado. De hecho, las técnicas tradicionales generalmente se basan en múltiples sistemas dispares, que no se pueden integrar e intercambiar información. Algunas técnicas tradicionales implican informes manuales de un evento y/o solicitudes manuales de transporte, generalmente a través de llamadas telefónicas entre personas en las instalaciones. A la escala de las operaciones hospitalarias modernas, los sistemas tradicionales generalmente resultan en líneas telefónicas sobrecargadas y solicitudes perdidas.
El documento EP 1914650 A2 se dirige a sistemas y métodos para gestionar asignaciones de camas en un centro sanitario. Los atributos de atención médica para un paciente se obtienen de un registro médico electrónico del paciente. Se genera una lista de camas en función de las capacidades de las camas y los atributos de atención médica, y el paciente se asigna a una cama seleccionada de la lista generada.
El documento US 2003/0074222 A1 se dirige a una red de prestación de servicios de salud integrada que maximiza los recursos de camas a través de la monitorización, automatización y comunicación en tiempo real.
En vista de las deficiencias técnicas de los sistemas actuales discutidos anteriormente, subsiste la necesidad de sistemas y métodos mejorados centralizados de detección y comunicación de eventos en tiempo real.
Resumen
La presente invención divulga un servidor de comunicación hospitalaria centralizado y un método para monitorización y notificación de eventos y un medio legible por ordenador no transitorio, como se establece en las reivindicaciones 1, 6 y 11, respectivamente.
El alcance de la invención solo se define por las reivindicaciones. Algunas realizaciones descritas a continuación comprenden características que no son parte de las reivindicaciones, por lo tanto, estas realizaciones no están cubiertas por las reivindicaciones. Las realizaciones divulgadas se refieren a sistemas y métodos para la detección y comunicación de eventos en tiempo real automatizados y centralizados. En algunas realizaciones, los eventos pueden incluir transferencias de pacientes, colocación y otras actividades realizadas por el sistema. Las realizaciones divulgadas pueden proporcionar la monitorización de una pluralidad de parámetros, horarios, etapas, eventos asociados con una visita del paciente, desde el proceso de admisión del paciente hasta dar de alta al paciente y más allá. En algunas realizaciones, la información del evento se recibe desde un dispositivo de red. La información del evento puede incluir, por ejemplo, el estado de una o más camas hospitalarias monitorizadas por ocupación, limpieza y mantenimiento. En algunas realizaciones, el sistema asigna automáticamente una cama de paciente en función de los atributos sobre el paciente, los atributos sobre la cama hospitalaria y la programación y disponibilidad. En algunas realizaciones, el sistema coordina automáticamente las solicitudes de admisión de otros hospitales en comunicación con el hospital, y genera solicitudes de admisión para enviar pacientes a otros hospitales según las necesidades del paciente. En algunas realizaciones, el sistema proporciona una interfaz de red bidireccional a una o más personas fuera de la red del hospital, como médicos que refieren a un paciente, especialistas y otras partes interesadas, para permitir el intercambio de información asociada con un paciente. Las realizaciones divulgadas abordan los problemas técnicos discutidos anteriormente mediante el uso de un servidor centralizado que genera de forma dinámica y automática solicitudes de información de fuentes informáticas y bases de datos en red ubicadas en toda la instalación para obtener datos tales como información de eventos e información de ubicación. Las realizaciones divulgadas también utilizan dispositivos sensores ubicados en toda la instalación y automatizan la generación de comunicaciones electrónicas a dispositivos electrónicos asociados con un evento detectado o acción requerida en función del evento detectado. Por lo tanto, las realizaciones divulgadas proporcionan una combinación y disposición de hardware informático junto con combinaciones ordenadas de etapas en una aplicación particular.
Las realizaciones divulgadas pueden proporcionar sistemas de comunicación mejorados entre departamentos en una instalación, y proporcionar comunicaciones automatizadas inteligentes asociadas con la detección de eventos tales como eventos activados o programados, transición del personal y tiempos de transferencia de pacientes.
Consistente con las presentes realizaciones, se divulga un servidor de comunicación hospitalaria centralizado para la monitorización y notificación de eventos. El servidor de comunicación hospitalaria centralizado puede incluir una memoria que almacena instrucciones y al menos un procesador configurado para ejecutar las instrucciones almacenadas para: recibir, desde un dispositivo en red, información de evento indicadora de un evento, la información de evento incluye al menos un atributo personal de un primer individuo asociado con el evento; buscar en una base de datos de red información asociada con al menos una ubicación dentro de un hospital, la primera información de ubicación incluye al menos un atributo de ubicación; identificar, en base a la información del evento recibido y la información de la primera ubicación recibida, una ubicación seleccionada para el primer individuo asociado con el evento; y generar y transmitir automáticamente al menos una comunicación electrónica a un primer dispositivo electrónico asociado con la ubicación seleccionada. Consistente con las presentes realizaciones, se divulga un método comunicación hospitalaria centralizado para la monitorización y notificación de eventos realizada por un servidor de comunicación centralizado. El método de comunicación hospitalaria centralizado puede incluir: recibir, desde un dispositivo en red, información de evento indicadora de un evento, la información del evento que incluye al menos un atributo personal de un primer individuo asociado con el evento; buscar en una base de datos de red información asociada con al menos una ubicación dentro de un hospital, la primera información de ubicación incluye al menos un atributo de ubicación; identificar, en base a la información del evento recibido y la información de la primera ubicación recibida, una ubicación seleccionada para el primer individuo asociado con el evento; y generar y transmitir automáticamente al menos una comunicación electrónica a un primer dispositivo electrónico asociado con la ubicación seleccionada.
Consistente con otras realizaciones divulgadas, un medio legible por ordenador no transitorio puede almacenar instrucciones de programa, que son ejecutadas por al menos un dispositivo procesador y hacen que un servidor de comunicación central realice operaciones para comunicaciones de monitorización y notificación de eventos centralizadas.
También se divulga en este documento un sistema informático, que comprende: al menos un procesador; y un medio de almacenamiento que comprende instrucciones que, cuando se ejecutan por al menos un procesador, asignan automáticamente un paciente a una cama hospitalaria al: recibir, al menos un procesador de una red, información del paciente para un paciente que está pendiente de asignación, la información del paciente que incluye al menos un atributo personal; recibir, desde una base de datos en red, la primera información de hospital asociada con camas hospitalarias disponibles, la primera información de hospital que incluye al menos un atributo de cama asociado con las camas hospitalarias disponibles; comparar la información del paciente y la primera información del hospital; determinar, en base a la comparación, una o más coincidencias entre el al menos un atributo personal y el al menos un atributo de cama; asignar el paciente a una de las camas hospitalarias disponibles en función de una o más coincidencias determinadas; y crear una entrada en la base de datos que refleje al paciente asignado.
Recibir la primera información del hospital puede incluir recibir al menos un atributo de cama asociado con una cama hospitalaria de un paciente en espera de ser dado de alta. La asignación del paciente puede incluir asignar al paciente a la cama del hospital del paciente en espera de ser dado de alta. La recepción de información del paciente puede incluir recibir una pluralidad de atributos del paciente y una prioridad de al menos uno de los atributos del paciente, y en el que la determinación de una o más coincidencias se basa en la prioridad de los atributos del paciente. La recepción de información del primer hospital puede incluir recibir primera información de unidad asociada con las camas hospitalarias disponibles de una primera unidad del primer hospital e información de segunda unidad asociada con camas hospitalarias disponibles de una segunda unidad del primer hospital. Las instrucciones pueden, cuando se ejecutan por al menos un procesador, asignar automáticamente el paciente al: recibir, de una base de datos en red, la segunda información del hospital asociada con las camas hospitalarias disponibles, la segunda información del hospital que incluye al menos un atributo de cama hospitalaria asociado con el disponible de camas hospitalarias; y/o consultar a los empleados disponibles para el transporte del paciente a la cama asignada. La asignación del paciente se puede basar en una cantidad de coincidencias determinadas.
En el presente documento también se divulga un método informático para asignar automáticamente un paciente a una cama hospitalaria, que comprende: recibir, al menos en un procesador de una red, información del paciente para un paciente que está pendiente de asignación, la información del paciente incluye al menos un atributo personal; recibir, desde una base de datos en red, la primera información de hospital asociada con camas hospitalarias disponibles, la primera información de hospital que incluye al menos un atributo de cama hospitalaria asociado con las camas hospitalarias disponibles; comparar la información del paciente y la primera información del hospital; determinar, en base a la comparación, una o más coincidencias entre el al menos un atributo personal y el al menos un atributo de cama hospitalaria; asignar el paciente a una de las camas hospitalarias disponibles en función de una o más coincidencias determinadas; y crear una entrada en la base de datos que refleje al paciente asignado.
El método puede incluir adicionalmente recibir al menos un atributo de cama hospitalaria asociado con una cama hospitalaria de un paciente en espera de ser dado de alta. La asignación del paciente a la cama del hospital puede incluir la asignación del paciente a la cama del hospital del paciente en espera de ser dado de alta. La recepción de información del paciente puede incluir recibir una pluralidad de atributos del paciente y una prioridad de al menos uno de los atributos del paciente, y en el que la determinación de una o más coincidencias se basa en la prioridad de los atributos del paciente. La recepción de información del primer hospital puede incluir recibir información de la primera unidad asociada con camas hospitalarias disponibles de una primera unidad del primer hospital e información de segunda unidad asociada con camas hospitalarias disponibles de una segunda unidad del primer hospital. El método puede incluir adicionalmente recibir la segunda información del hospital asociada con las camas hospitalarias disponibles, la segunda información del hospital incluye al menos un atributo de cama hospitalaria asociado con las camas hospitalarias disponibles. El método puede incluir adicionalmente consultar a los empleados disponibles para el transporte del paciente a la cama asignada. La asignación del paciente al hospital se puede basar en una cantidad de coincidencias determinadas.
También se divulga en este documento un medio legible por ordenador no transitorio que almacena instrucciones que, cuando se ejecutan, hacen que uno o más procesadores realicen un método para asignar automáticamente a un paciente a una cama hospitalaria, que comprende: recibir, al menos un procesador de una red, información del paciente para un paciente que está pendiente de asignación, la información del paciente incluye al menos un atributo personal; recibir, desde una base de datos en red, la primera información de hospital asociada con camas hospitalarias disponibles, la primera información de hospital que incluye al menos un atributo de cama hospitalaria asociado con las camas hospitalarias disponibles; comparar la información del paciente y la primera información del hospital; determinar, en base a la comparación, una o más coincidencias entre el al menos un atributo personal y al menos un atributo de cama hospitalaria; asignar el paciente a una de las camas hospitalarias disponibles con base en una o más coincidencias determinadas; y crear una entrada en la base de datos que refleje al paciente asignado.
Las instrucciones, cuando se ejecutan, adicionalmente pueden hacer que uno o más procesadores reciban al menos un atributo de cama hospitalaria asociado con una cama hospitalaria de un paciente en espera de ser dado de alta. La asignación del paciente al hospital incluye la asignación del paciente a la cama del hospital del paciente en espera de ser dado de alta. La recepción de información del paciente puede incluir recibir una pluralidad de atributos del paciente y una prioridad de al menos uno de los atributos del paciente, y determinar una o más coincidencias se pueden basar en la prioridad de los atributos del paciente.
Breve descripción de los dibujos
Los dibujos acompañantes, que se incorporan y constituyen una parte de esta especificación, ilustran varias realizaciones y, junto con la descripción, sirven para explicar los principios divulgados. En los dibujos:
La Figura 1 representa un ejemplo de un entorno de sistema para colocar pacientes dentro de un hospital, consistente con las realizaciones de la presente divulgación.
La Figura 2 representa un ejemplo de un terminal de ordenador, consistente con las realizaciones de la presente divulgación.
La Figura 3 representa un ejemplo de un dispositivo de usuario, consistente con las realizaciones de la presente divulgación.
La Figura 4 representa un ejemplo de un servidor de red, consistente con las realizaciones de la presente divulgación.
La Figura 5 es un diagrama de flujo de un ejemplo de un proceso para detectar eventos dentro de una instalación y comunicar información, consistente con las realizaciones de la presente divulgación.
La Figura 6 es un diagrama de flujo de un ejemplo de un proceso para determinar métricas del proceso de trabajo, consistente con las realizaciones de la presente divulgación.
La Figura 7 es una ilustración de un ejemplo de una interfaz de usuario del censo, consistente con las realizaciones de la presente divulgación;
La Figura 8 es una ilustración de un ejemplo de una interfaz de usuario de solicitud de cama, consistente con las realizaciones de la presente divulgación;
La Figura 9 es una ilustración de un ejemplo de una interfaz de usuario de atributo de cama, consistente con las realizaciones de la presente divulgación;
La Figura 10 es una ilustración de un ejemplo de una interfaz de usuario de solicitud de colocación, consistente con las realizaciones de la presente divulgación;
La Figura 11 es una ilustración de un ejemplo de una interfaz de usuario de asignación de cama, consistente con las realizaciones de la presente divulgación.
Descripción detallada de realizaciones ejemplares
Ahora se hará referencia en detalle a realizaciones ejemplares, ejemplos de las cuales se ilustran en los dibujos acompañantes y se divulgan en el presente documento. Siempre que sea conveniente, se utilizarán los mismos números de referencia en todos los dibujos para referirse a las mismas partes o partes similares.
La Figura 1 muestra un diagrama de un sistema 100 de gestión de flujo de trabajo y colocación de paciente que se puede configurar para realizar uno o más procesos de software que, cuando son ejecutados por uno o más procesadores, realizan métodos consistentes con las realizaciones divulgadas. Los componentes y disposiciones mostrados en la Figura 1 no pretenden limitar las realizaciones divulgadas, ya que pueden variar los componentes utilizados para implementar los procesos y características divulgados.
Como se muestra en la Figura 1, el sistema 100 de gestión de flujo de trabajo y colocación de pacientes puede incluir un servidor 130 de instalación, un terminal 140 de ordenador, un terminal 145 de administración, uno o más dispositivos 120 de usuario, servidor 160 de red, servidor 170 de terceros y base 180 de datos. Los componentes del sistema 100 se pueden comunicar directamente, a través de la red 150, a través de la red 110 local, o mediante una combinación de métodos de comunicación. En algunas realizaciones, la red 110 local, el servidor 130 de instalación, el terminal 140 de ordenador, el terminal 145 de administración y al menos un dispositivo 120 de usuario pueden estar dispuestos físicamente dentro de una instalación tal como un hospital o edificio de oficinas (es decir, como sistema 102 de instalación) mientras está en al menos un dispositivo 120 de usuario, la red 150, el servidor 160 de red, el servidor 170 de terceros y la base 180 de datos pueden ser externos al lugar de trabajo. Otros componentes conocidos por un experto en la técnica se pueden incluir en el sistema 100 para realizar tareas consistentes con las realizaciones divulgadas. Por ejemplo, en algunas realizaciones, el sistema 102 de instalación puede incluir uno o más dispositivos sensores ubicados en toda la instalación para monitorizar una o más condiciones tales como ocupación, temperatura, humedad, proximidad y otros parámetros indicativos de un estado o condición de una cama, habitación, área, equipo o suministros. Adicionalmente, en algunas realizaciones, el sistema 102 de instalación puede incluir uno o más receptores inalámbricos (no mostrados) configurados para detectar uno o más sensores inalámbricos o etiquetas de localización, para rastrear la ubicación de un artículo o persona etiquetados, o una condición sobre el artículo etiquetado y/o persona.
El terminal 140 de ordenador puede ser un dispositivo independiente dispuesto en una oficina, una habitación, una estación de empleados o una ubicación central alternativa en un lugar de trabajo. En algunas realizaciones, el terminal 140 de ordenador puede ser un ordenador de escritorio o portátil, una pantalla plana o pantalla proyectada, o cualquier otra pantalla. En algunas realizaciones, el terminal 140 de ordenador puede estar asociado con una habitación particular en una instalación, tal como una habitación de paciente particular, habitación de hotel, sala de conferencias o cualquier otro tipo de habitación. Por lo tanto, un mensaje recibido desde un terminal 140 de ordenador puede asociar automáticamente el mensaje con la habitación en la que está instalado el terminal 140 de ordenador.
El terminal 145 de administrador puede incluir un sistema de ordenador o dispositivo asociado con un usuario 125 que gestiona o supervisa una porción del sistema 102 de instalación. Por ejemplo, el terminal 145 de administrador puede comprender un sistema de ordenador ubicado en una estación de enfermería principal, una oficina del gerente de limpieza, o cualquier otra oficina o estación del gerente del departamento.
Los usuarios 125 pueden ser uno o más individuos, tales como empleados del hospital y cuidadores, asociados con el paciente. Los usuarios 125 pueden operar el terminal 140 de ordenador, los dispositivos 120 del usuario y/u otro ordenador (no mostrado) para interactuar con el sistema 100. Los usuarios 125 pueden ser individuos ubicados dentro y/o fuera del sistema 102 de instalación. Por ejemplo, los usuarios 125 pueden incluir médicos y enfermeras dentro del centro responsable de transferir a los pacientes a diferentes unidades. Los usuarios 125 también pueden incluir uno o más individuos responsables de responder a las solicitudes de tareas, tal como limpieza y transporte de los pacientes. Los usuarios 125 también pueden incluir individuos fuera del sistema 102 de instalación, tales como individuos con relaciones personales con los pacientes (por ejemplo, miembros de la familia) y personas de referencia (por ejemplo, médicos y doctores externos).
El sistema 100 puede ser personalizable y proporcionar acceso individualizado para cada uno de los usuarios 125. Por ejemplo, solo ciertos usuarios 125, tales como médicos y enfermeras, pueden generar solicitudes de transferencia. En algunas realizaciones, se puede requerir que uno o más usuarios 125, como el médico primario del paciente, autoricen todas las solicitudes. Los usuarios 125 exclusivamente responsables de tareas específicas pueden tener acceso limitado para realizar sus responsabilidades. También se contempla que algunos usuarios 125, tales como los miembros de la familia, puedan tener acceso de solo lectura.
Los dispositivos 120 de usuario pueden ser un dispositivo informático personal tal como, por ejemplo, un ordenador portátil o de propósito general, un dispositivo móvil con capacidad informática, un ordenador tipo tableta, teléfono inteligente, dispositivo portátil tal como Google Glass™ u relojes inteligentes, o cualquier combinación de estos ordenadores y/o componentes afiliados. En algunas realizaciones, un dispositivo 120 de usuario puede ser un sistema de ordenador o dispositivo de ordenador móvil que es operado por el usuario 125. En algunas realizaciones, un dispositivo 120 de usuario puede estar asociado con un individuo particular tal como el usuario 125, dichos mensajes y/o las asignaciones de tareas dirigidas hacia el usuario 125 se envían al dispositivo 120 de usuario. En algunas realizaciones, el dispositivo 120 de usuario se puede comunicar con el servidor 130 de instalación y/o el servidor 160 de red a través de enlaces de comunicación inalámbrica directa (no mostrados), o mediante una combinación de una o más de la red 110 local y/o la red 150.
El servidor 130 de instalación puede ser operado por una instalación tal como un hospital. El servidor 130 de instalación puede permitir la comunicación dentro de un sistema basado en ordenador que incluye componentes del sistema de ordenador tales como ordenadores de escritorio, estaciones de trabajo, ordenadores tipo tableta, dispositivos informáticos manuales, dispositivos de memoria y/o redes internas que conectan los componentes. Por lo tanto, en algunas realizaciones, el servidor 130 de instalación puede funcionar como un centro o estación centralizada para recibir y procesar datos asociados con los métodos y técnicas divulgados, y para generar y enviar transmisiones asociadas con los métodos y técnicas divulgados.
La red 150 puede comprender cualquier tipo de disposición de red informática utilizada para intercambiar datos. Por ejemplo, la red 150 puede ser Internet, una red de datos privada, una red privada virtual que utiliza una red pública y/u otras conexiones adecuadas que permiten que el sistema 100 envíe y reciba información entre los componentes del sistema 100. La red 150 también puede incluir una red telefónica pública conmutada (“PSTN”) y/o una red celular inalámbrica.
La red 110 local puede comprender cualquier tipo de disposición de red de ordenador utilizada para intercambiar datos en un área localizada, como WiFi, Bluetooth™, Ethernet y otras conexiones adecuadas de corto alcance que permiten que el terminal 140 de ordenador y el dispositivo 120 de usuario envíen y reciban información entre los componentes del sistema 100. En algunas realizaciones, la red 110 local se puede excluir, y el terminal 140 de ordenador y el dispositivo 120 de usuario se pueden comunicar con los componentes del sistema 100 a través de la red 150. En algunas realizaciones, el terminal 140 de ordenador y/o el dispositivo 120 de usuario se puede comunicar con uno o más componentes del sistema 100 a través de una conexión directa por cable o inalámbrica. El servidor 160 de red, el servidor 170 de terceros y la base 180 de datos pueden ser uno o más servidores o servicios de almacenamiento proporcionados por una entidad tal como un proveedor de servicios de red, en la nube o de respaldo. Por ejemplo, en algunas realizaciones, el servidor 160 de red puede estar asociado con un servicio informático en la nube tal como Microsoft Azure™ o Amazon Web Services™. En dichas realizaciones, el servidor 160 de red puede comprender una pluralidad de sistemas informáticos distribuidos geográficamente que ejecutan software para realizar una o más funciones de los métodos divulgados. Adicionalmente, en algunas realizaciones, el servidor 170 de terceros puede estar asociado con un servicio de mensajería, tal como, por ejemplo, Apple Push Notification Service, Azure Mobile Services, o Google Cloud Messaging. En dichas realizaciones, el servidor 170 de terceros puede manejar la entrega de mensajes y notificaciones relacionadas con las funciones de las realizaciones divulgadas, tales como creación de tareas, asignación de tareas, alertas de tareas y mensajes y notificaciones de finalización de tareas.
En algunas realizaciones, el sistema 100 puede incluir configuraciones que varían del ejemplo mostrado en la Figura 1, que ilustra un sistema 102 de instalación que funciona en conjunto con un sistema informático en la nube que incluye el servidor 160 de red, el servidor 170 de terceros y la base 180 de datos. Como primera variación, el sistema 100 puede incluir solo el sistema 102 de instalación, y por lo tanto puede excluir los componentes informáticos en la nube tales como el servidor 160 de red, el servidor 170 de terceros y la base 180 de datos. En tales realizaciones, el sistema 102 de instalación puede manejar sustancialmente todas las operaciones y funciones de las presentes realizaciones. Como segunda variación, el sistema 100 puede excluir componentes del sistema 102 de instalación, como el servidor 130 de instalación. En tales realizaciones, un sistema informático en la nube que incluye el servidor 160 de red, el servidor 170 de terceros y/o la base 180 de datos pueden manejar parte o todas las funciones informáticas y relacionadas con el mensaje de las realizaciones divulgadas.
La Figura 2 muestra un diagrama del terminal 140 de ordenador, consistente con las realizaciones divulgadas. Como se muestra, el terminal 140 de ordenador puede incluir una pantalla 210, uno o más procesadores 220, dispositivos 230 de entrada/salida (“E/S”), un transceptor 240 y memoria 250.
La pantalla 210 puede incluir una o más pantallas para mostrar información de gestión de tareas tales como, por ejemplo, pantalla de cristal líquido (LCD), plasma, tubo de rayos catódicos (CRT) o pantallas proyectadas
El procesador 220 puede ser uno o más dispositivos de procesamiento conocidos, tales como microprocesadores fabricados por Intel™ o AMD™ o con licencia de ARM. El procesador 220 puede constituir un procesador de núcleo único o de núcleo múltiple que ejecuta procesos paralelos simultáneamente. Por ejemplo, el procesador 220 puede ser un procesador de núcleo único configurado con tecnologías de procesamiento virtual. En ciertas realizaciones, el procesador 220 puede usar procesadores lógicos para ejecutar y controlar simultáneamente múltiples procesos. El procesador 220 puede implementar tecnologías de máquina virtual u otras tecnologías conocidas para proporcionar la capacidad de ejecutar, controlar, ejecutar, manipular, almacenar, etc. múltiples procesos de software, aplicaciones, programas, etc. En otra realización, el procesador 220 puede incluir una disposición de procesador central múltiple (por ejemplo, dual, quad core, etc.) configurada para proporcionar funcionalidades de procesamiento en paralelo para permitir que el terminal 140 de ordenador ejecute múltiples procesos simultáneamente. Un experto en la técnica entenderá que se podrían implementar otros tipos de arreglos de procesador que brinden las capacidades divulgadas en este documento.
Los dispositivos 230 E/S pueden incluir uno o más dispositivos que permiten que el terminal 140 de ordenador reciba la entrada de un usuario. Los dispositivos 230 E/S pueden incluir, por ejemplo, uno o más dispositivos señaladores, teclados, botones, interruptores, paneles táctiles, cámaras, escáneres de códigos de barras, lectores de etiquetas de identificación por radiofrecuencia (RFID) y/o micrófonos.
El transceptor 240 puede incluir uno o más módulos de comunicación para establecer la comunicación entre el terminal 140 de ordenador y otros dispositivos del sistema 100 a través, por ejemplo, de la red 110 local y/o la red 150. Por ejemplo, el transceptor 240 puede incluir circuitos y una o más antenas para comunicarse de forma inalámbrica con la red 110 local utilizando un protocolo de comunicación inalámbrica de corto alcance/campo cercano como Bluetooth™, Bluetooth™ LE, WiFi y Zigbee. Adicionalmente, el transceptor 240 se puede comunicar con la red 150 y/o la red 110 local utilizando cualquier protocolo de red conocido, incluida cualquier forma de acceso a Internet por cable o inalámbrico.
La memoria 250 puede incluir un dispositivo de almacenamiento volátil o no volátil, magnético, semiconductor, de cinta, óptico, extraíble, no extraíble u otro tipo de medio tangible (es decir, no transitorio) legible por ordenador que almacena uno o más programas 252, tales como aplicaciones 254, y datos 256. Los datos 256 pueden incluir, por ejemplo, información del paciente, información del usuario, información de tareas y configuraciones y preferencias de visualización. En algunas realizaciones, los datos 256 pueden incluir uno o más conjuntos de reglas para priorizar información y colocar pacientes individuales.
Los programas 252 pueden incluir sistemas operativos (no mostrados) que realizan funciones conocidas del sistema operativo cuando son ejecutados por uno o más procesadores. A modo de ejemplo, los sistemas operativos pueden incluir sistemas operativos Microsoft Windows™, Unix™, Linux™, Apple™, sistemas operativos de tipo Asistente Digital Personal (PDA), tal como Microsoft CE™ u otros tipos de sistemas operativos. En consecuencia, las realizaciones divulgadas pueden operar y funcionar con sistemas de ordenador que ejecutan cualquier tipo de sistema operativo. El terminal 140 de ordenador también puede incluir software de comunicación que, cuando es ejecutado por un procesador, proporciona comunicaciones con la red 150 y/o la red 110 local, tal como software de navegador web, ordenador tipo tableta o software de red de dispositivo de inteligente, o portátil etc.
Los programas 252 también pueden incluir aplicaciones 254, tales como una aplicación de gestión de flujo de trabajo y colocación de pacientes, que cuando se ejecuta hace que el terminal 140 de ordenador realice procesos relacionados con la gestión, priorización y programación de información y tareas del paciente. Por ejemplo, las aplicaciones 254 pueden configurar el terminal 140 de ordenador para realizar operaciones que incluyen recibir la entrada de solicitudes de transferencia de pacientes, mostrar información del paciente, monitorizar los estados de los pacientes, asignar tareas a los empleados, mostrar las asignaciones de los empleados y monitorizar los estados de las tareas.
La Figura 3 muestra un diagrama de un dispositivo de usuario ejemplar 120, consistente con las realizaciones divulgadas. Como se muestra, el dispositivo 120 de usuario puede incluir la pantalla 310, dispositivos 320 de E/S, procesador 330, memoria 340 que tiene almacenados datos 346 y uno o más programas 342, tales como aplicación(es) 344, sensor(es) 350 y antena 360.
La pantalla 310 puede incluir uno o más dispositivos para mostrar información, que incluye, pero no se limita a, pantallas de cristal líquido (LCD), pantallas de diodo emisor de luz (LED), pantallas de diodo emisor de luz orgánica (OLED) y otros dispositivos de visualización conocidos.
Los dispositivos 320 E/S pueden incluir uno o más dispositivos que permiten que el dispositivo 120 móvil envíe y reciba información. Los dispositivos 320 E/S pueden incluir, por ejemplo, un dispositivo señalador, teclado, botones, interruptores y/o un panel de pantalla táctil. Los dispositivos 320 E/S también pueden incluir uno o más módulos de comunicación (no mostrados) para enviar y recibir información a través de la antena 360 desde otros componentes en el sistema 100, por ejemplo, estableciendo conectividad por cable o inalámbrica entre el dispositivo móvil 120 a la red 110 local, red 150, o estableciendo conexiones directas por cable o inalámbricas entre el dispositivo 120 de usuario y otros componentes del sistema 100. Las conexiones directas pueden incluir, por ejemplo, Bluetooth™, Bluetooth LE™, WiFi, comunicaciones de campo cercano (NFC) u otra comunicación conocida métodos que proporcionan un medio para transmitir datos entre dispositivos separados.
Los procesadores 330 pueden ser uno o más dispositivos informáticos conocidos, tales como aquellos descritos con respecto al procesador 220 en la Figura 2.
La memoria 340 puede ser un dispositivo de almacenamiento volátil o no volátil, magnético, semiconductor, de cinta, óptico, extraíble, no extraíble u otro tipo de medio tangible (es decir, no transitorio) legible por ordenador, tal como aquellos descritos con respecto a la memoria 250 en la Figura 2.
En algunas realizaciones, el dispositivo 120 de usuario puede contener uno o más sensores 350 para recolectar datos ambientales, de movimiento y/o de seguridad. Los sensores 350 pueden incluir: uno o más sensores ambientales tales como, por ejemplo, sensores de luz ambiental, micrófonos, sensores de temperatura y sensores de humedad; detectores de movimiento tales como, por ejemplo, receptores GPS, receptores de datos basados en la ubicación, acelerómetros y giroscopios; y sensores de seguridad tales como, por ejemplo, lectores de huellas digitales, escáneres de retina y otros sensores biométricos capaces de usarse para seguridad e identificación individual. En algunas realizaciones, el procesador 330 puede utilizar datos recopilados por sensores 350 para controlar o modificar funciones de los programas 342.
La Figura 4 muestra un diagrama de un servidor 160 de red ejemplar, consistente con las realizaciones divulgadas. En algunas realizaciones, el servidor 160 de red puede soportar o proporcionar un servicio informático en la nube, tales como Microsoft Azure™ o Amazon Web Services. En dichas realizaciones, el servidor 160 de red puede incluir uno o más sistemas de ordenador distribuidos capaces de realizar funciones informáticas distribuidas y proporcionar servicios informáticos en la nube y funciones coherentes con las realizaciones divulgadas. En algunas realizaciones, el servidor 160 de red puede funcionar junto con el servidor 130 de instalación. En otras realizaciones, el servidor 160 de red puede funcionar solo, y el servidor 130 de instalación puede ser reemplazado por una conexión de red a la red 150 y/o red 110 local. En dichas realizaciones, el servidor 160 de red puede realizar todas las funciones asociadas con los métodos divulgados. En otras realizaciones, el servidor 130 de instalación puede funcionar solo, sin el servidor 160 de red. En dichas realizaciones, el sistema 102 de instalación puede funcionar como un sistema independiente, en el que el servidor 130 de instalación realiza todas las funciones asociadas con los métodos divulgados. Aquellos expertos en la técnica apreciarán que las disposiciones informáticas no se limitan a estos ejemplos, y que otras realizaciones pueden incluir una o más configuraciones alternativas de sistemas informáticos capaces de realizar funciones asociadas con las realizaciones divulgadas.
En algunas realizaciones, el servidor 160 de red se puede conectar a múltiples instalaciones ubicadas en diferentes ubicaciones geográficas. En dichas realizaciones, el servidor 160 de red puede gestionar tareas que abarcan múltiples instalaciones, tales como transferir pacientes entre instalaciones. Adicionalmente, el servidor 160 de red puede recolectar datos de múltiples unidades para evaluar los tiempos de rendimiento en diferentes unidades y mejorar la precisión de los tiempos de finalización esperados para diferentes tipos de tareas utilizando uno o más algoritmos de regresión de datos.
Como se muestra en la Figura 4, el servidor 160 de red puede incluir uno o más procesadores 420, dispositivos 430 de entrada/salida (“E/S”), memoria 440 que almacena programas 442 (que incluyen, por ejemplo, aplicaciones 444 de servidor y sistema 446 operativo) y datos 448, y una base 470 de datos. El servidor 160 de red puede ser un solo servidor o se puede configurar como un sistema de ordenador distribuido que incluye múltiples servidores u ordenadores que interoperan para realizar uno o más de los procesos y funcionalidades asociados con las realizaciones divulgadas.
Los procesadores 420 pueden ser uno o más dispositivos informáticos conocidos, tales como aquellos descritos con respecto al procesador 220 en la Figura 2)
En algunas realizaciones, el servidor 160 de red también puede incluir uno o más dispositivos 430 E/S que incluyen interfaces para recibir señales o entradas de dispositivos y proporcionar señales o salidas a uno o más dispositivos que permiten recibir y/o transmitir datos por el servidor 160 de red. Por ejemplo, el servidor 160 de red puede incluir componentes de interfaz, que pueden proporcionar interfaces a uno o más dispositivos de entrada, tales como uno o más teclados, dispositivos de ratón y similares, que permiten que el servidor 160 de red reciba entrada de uno o más usuarios 125 que están asociados con el sistema 102 de instalación.
En algunas realizaciones, el servidor 160 de red puede incluir uno o más dispositivos de almacenamiento configurados para almacenar información utilizada por el procesador 420 (u otros componentes) para realizar ciertas funciones relacionadas con las realizaciones divulgadas. En un ejemplo, el servidor 160 de red puede incluir una memoria 440 que incluye instrucciones para permitir que el procesador 420 ejecute una o más aplicaciones, como aplicaciones de servidor, una aplicación de transacción electrónica, una aplicación de estado de cuenta, procesos de comunicación de red y cualquier otro tipo de aplicación o software conocido por estar disponible en sistemas de ordenador. Alternativa o adicionalmente, las instrucciones, programas de aplicación, etc. se pueden almacenar en una base 470 de datos interna o en una base 180 de datos externa (mostrada en la Figura 1) en comunicación con el servidor 160 de red, tal como una o más bases de datos o memorias accesibles a través de la red 150 La base 470 de datos u otro almacenamiento externo puede ser un dispositivo de almacenamiento volátil o no volátil, magnético, semiconductor, de cinta, óptico, extraíble, no extraíble u otro tipo de medio tangible (es decir, no transitorio) legible por ordenador.
En una realización, el servidor 160 de red puede incluir una memoria 440 que incluye instrucciones que, cuando son ejecutadas por el procesador 420, realizan uno o más procesos consistentes con las funcionalidades divulgadas en este documento. Los métodos, sistemas y artículos de fabricación consistentes con las realizaciones divulgadas no se limitan a programas separados u ordenadores configurados para realizar tareas dedicadas. Por ejemplo, el servidor 160 de red puede incluir una memoria 440 que puede incluir uno o más programas 442 para realizar una o más funciones de las realizaciones divulgadas. Más aún, el procesador 420 puede ejecutar uno o más programas ubicados remotamente desde el sistema 100 de visualización de información de cuenta. Por ejemplo, el servidor 160 de red puede acceder a uno o más programas remotos que, cuando se ejecutan, realizan funciones relacionadas con las realizaciones divulgadas.
Los programas 450 almacenados en la memoria 440 y ejecutados por los procesadores 420 pueden incluir una o más aplicaciones 452 de servidor y el sistema 454 operativo. Las aplicaciones 452 de servidor pueden incorporar una o más aplicaciones configuradas para recibir entradas de información del paciente, solicitar transferencias de pacientes, supervisar transferencias de pacientes, asignar tareas a los usuarios 125 y mostrar asignaciones de tareas del usuario
En algunas realizaciones, la memoria 440 puede almacenar datos 448 que incluyen datos asociados con pacientes, unidades, empleados, tareas, activos, algoritmos de asignación y cualquier otro dato relacionado con las realizaciones divulgadas. Por ejemplo, los datos 448 pueden incluir una o más entradas que incluyen información relacionada con pacientes, incluyendo identificación, asignación de cama, rasgos personales, condiciones previas, prioridades y preferencias. Los datos 448 también pueden incluir una o más entradas pertenecientes a los usuarios 125, tales como ocupación, asociación con pacientes, responsabilidades y estados de solicitud. En algunas realizaciones, los datos 448 se almacenan en la base 470 de datos, la memoria 440, la memoria 250, la memoria 340, la base 180 de datos y cualquier combinación de las mismas.
En algunas realizaciones, la memoria 440 y la base 470 de datos pueden incluir uno o más dispositivos de memoria que almacenan datos e instrucciones utilizadas para realizar una o más características de las realizaciones divulgadas. La memoria 440 y la base 470 de datos también pueden incluir cualquier combinación de una o más bases de datos controladas por dispositivos controladores de memoria (por ejemplo, servidor(es), etc.) o software, como sistemas de gestión de documentos, bases de datos Microsoft SQL, bases de datos Share-Point, Oracle™ bases de datos, bases de datos Sybase™ u otras bases de datos relacionales.
El servidor 160 de red puede comunicarse con uno o más dispositivos de memoria remotos (por ejemplo, el servidor 170 de terceros y/o la base 180 de datos) a través de la red 150 o una red diferente (no mostrada). Los dispositivos de memoria remota se pueden configurar para almacenar información y el servidor 160 de red puede acceder y/o administrarlos. Solo a modo de ejemplo, los dispositivos de memoria remota pueden ser sistemas de gestión de documentos, bases de datos Microsoft SQL, bases de datos de SharePoint, bases de datos Oracle™, Sybase™ bases de datos u otras bases de datos relacionales. Sin embargo, los sistemas y métodos consistentes con las realizaciones divulgadas no se limitan a bases de datos separadas o incluso al uso de una base de datos.
La Figura 5 muestra un diagrama de flujo del proceso 500 ejemplar para detectar eventos dentro de una instalación y comunicar información. El proceso 500 puede proporcionar la ventaja de llevar a los pacientes al nivel y la ubicación de atención adecuados lo más rápido posible. El proceso 500 también puede distinguir ventajosamente los criterios críticos de los no críticos para colocar eficientemente al paciente en el entorno más cómodo posible. El proceso 500 se describe en este documento como realizado principalmente por el servidor 160 de red, sin embargo, en algunas realizaciones, el servidor 130 de instalación, el terminal 140 de ordenador, el terminal 145 de administración, el dispositivo 120 de usuario y/o el servidor 170 de terceros pueden realizar una o más etapas del proceso 500.
El proceso 500 puede comenzar en la etapa 502 cuando el servidor 160 de red detecta un evento dentro de la instalación. En algunas realizaciones, el servidor 160 de red puede detectar un evento en respuesta a la recepción de información de monitorización para uno o más dispositivos en red. En algunas realizaciones, la información de monitorización puede comprender datos del sensor recopilados por uno o más dispositivos sensores en red. En algunas realizaciones, la información de monitorización puede incluir una solicitud de tarea desde un terminal tal como el terminal 140 de ordenador, el terminal 145 de administración y/o el dispositivo 120 de usuario. En algunas realizaciones, las solicitudes pueden incluir un mensaje de texto, correo electrónico, comunicación desde la aplicación 254 o 344 u otra solicitud por escrito de cualquier dispositivo electrónico en comunicación con el servidor 160 de red. En algunas realizaciones, el servidor 160 de red puede recibir una o más solicitudes a través de otra interfaz, tal como un sistema de respuesta de voz interactiva (IVR) o sistema de entrada de teléfono por tonos. Las solicitudes pueden proporcionarse en una interfaz que tenga campos que sean críticos o no críticos para la colocación del paciente. El servidor 160 de red también puede proporcionarse con un software de reconocimiento de voz o caracteres configurado para extraer información para entradas de otros tipos de solicitudes.
En la etapa 504, el servidor 160 de red puede recibir entradas adicionales pertenecientes al paciente. Las entradas pueden incluir información para complementar la información recibida en la etapa 502, tal como atributos personales, preferencias del paciente e información de aislamiento. Los atributos personales pueden incluir, por ejemplo, datos fisiológicos, género, altura, peso, edad, salud mental, salud física, movilidad, personalidad, nivel de sedación y/o cualquier otra característica física o mental. Las preferencias de los pacientes pueden incluir, por ejemplo, el tamaño de la cama, la firmeza de la cama, la capacidad de ajuste de la cama, el nivel de atención, la interacción deseada con otros pacientes, la ubicación deseada en relación con la estación de enfermería o una ventana, y/o cualquier otro alojamiento especial. La información de aislamiento puede incluir información relacionada con cualquier enfermedad transmisible, tal como el tipo de transmisión (por ejemplo, en el aire, contacto, etc.) y el organismo (por ejemplo, MRSA). Algunas entradas pueden estar estrechamente relacionadas, de modo que el servidor 160 de red puede tener una característica de autocompletar que llena una primera entrada basada en una segunda entrada. Por ejemplo, en una realización, el servidor 160 de red puede alterar automáticamente el tamaño de cama solicitado en función de la altura y el peso del paciente. También se contempla que el servidor 160 de red pueda generar automáticamente una solicitud de cama más cerca de la estación de enfermería y aislada de la población general cuando el paciente experimenta problemas de salud mental asociados con mayores niveles de atención y/o privacidad.
El servidor 160 de red también puede recibir y/o determinar la prioridad de un nivel de prioridad de una o más de las entradas. La prioridad de las entradas puede determinarse automáticamente en función del carácter de las entradas, y/o puede ser ingresada manualmente por el usuario 125. La prioridad de las entradas se puede definir inicialmente si la entrada es crítica o no crítica para la colocación de paciente. En algunas realizaciones, la prioridad se puede definir adicionalmente de acuerdo con la importancia relativa de cada una de las entradas críticas y no críticas. En algunas realizaciones, el sistema 100 puede almacenar y utilizar una jerarquía de importancia predeterminada para cada entrada, para optimizar la colocación de la cama. Por ejemplo, con pacientes que tienen una altura y/o peso mayor que un umbral, el servidor 160 de red puede hacer automáticamente que el tamaño de la cama sea crítico para la colocación del paciente. Como otro ejemplo, el tamaño y firmeza de cama deseados de un paciente se pueden considerar no críticos y recibir menos peso en comparación con las entradas críticas. En este ejemplo, el servidor 160 de red puede considerar el tamaño de la cama y la firmeza de la cama al colocar al paciente, pero las características pueden no ser necesarias para una colocación adecuada.
En algunas realizaciones, el servidor 160 de red puede llenar una o más entradas al recuperar información del paciente de la base 180 de datos, o de cualquier otra memoria asociada con los componentes del sistema 100. Por ejemplo, el servidor 160 de red puede acceder a registros de pacientes o atributos personales., incluida la información relativa a las propiedades físicas (por ejemplo, altura y peso), afecciones médicas previas, salud mental, visitas previas al hospital, diagnósticos previos, prescripciones anteriores y actuales, domicilio y contactos personales. En base a las entradas del físico de referencia, el servidor 160 de red puede actualizar automáticamente los registros de pacientes. En algunas realizaciones, si el servidor 160 de red detecta una inconsistencia entre la entrada de la etapa 504 y los registros de pacientes recuperados, el servidor 160 de red puede proporcionar un aviso al médico que refiere a un paciente para garantizar la precisión de la información actualizada.
En algunas realizaciones, las etapas 502 y 504 se pueden realizar simultáneamente de modo que los campos de datos se puedan ingresar en la misma interfaz de usuario. En otras realizaciones, los campos de datos de las etapas 502 y 504 pueden estar separadas por pestañas y/o menús insertados. En algunas realizaciones, el servidor 160 de red puede no requerir entrada para cada campo presentado en la interfaz de usuario para procesar una solicitud de colocación. Por ejemplo, la firmeza de la cama puede ser una entrada no crítica, de modo que si el campo de datos se deja en blanco, el servidor 160 de red puede colocar al paciente sin considerar la firmeza de la cama. Al proporcionar campos de datos opcionales, el proceso de colocación de pacientes se simplifica para solicitudes que son urgentes o tienen poca información disponible, y el proceso de colocación de pacientes es altamente configurable para solicitudes con numerosas preferencias y parámetros disponibles.
En la etapa 506, el servidor 160 de red puede recuperar y procesar información perteneciente al hospital solicitado. La información puede incluir información detallada de cada unidad del hospital, que incluye, por ejemplo, el número y la ubicación de las camas ocupadas y no ocupadas de cada unidad, y el estado de los pacientes de cada cama ocupada. Específicamente, el servidor 160 de red puede recibir atributos personales de cada uno de los pacientes (por ejemplo, sexo, edad y personalidad) junto con el alta esperada de cada uno de los pacientes. En algunas realizaciones, las ubicaciones disponibles identificadas en una o más bases de datos pueden incluir ubicaciones de camas desocupadas, tales como un número y/o una letra de habitación para una cama que actualmente no está asociada con un paciente ingresado. Las camas ocupadas, así como las camas asignadas a pacientes pendientes de ser dados de alta, por lo tanto, se pueden almacenar como ubicaciones no disponibles. En algunas realizaciones, las ubicaciones no disponibles pueden incluir una indicación de que se espera que estén disponibles dentro de un período de tiempo predeterminado. El período de tiempo predeterminado, por ejemplo, se puede asociar con las métricas calculadas por el sistema asociado con la condición del paciente, almacenada, el progreso del paciente a través de un itinerario generado en asociación con la condición del paciente y las métricas almacenadas asociadas con un proceso predeterminado de dar de alta al paciente, y el estado actual del paciente en el proceso de darlo de alta. En algunas realizaciones, el período de tiempo predeterminado puede estar asociado con uno o más eventos programados para limpiar o mantener la ubicación no disponible, y un tiempo de finalización esperado para los eventos programados. El servidor 160 de red también puede recibir atributos de ubicación, por ejemplo, información detallada de cada una de las camas, que incluye la firmeza, el tamaño, la capacidad de ajuste, el tipo de cama, las capacidades y el equipo de monitorización y cuidado adjunto. En base a la información detallada sobre las camas hospitalarias y los pacientes actuales, el servidor 160 de red puede generar un gráfico para una o más unidades de hospital para proporcionar un estado en tiempo real del nivel de capacidad actual del hospital y su capacidad disponible. En algunas realizaciones, un atributo de ubicación incluye un nivel de capacidad disponible en tiempo real de una ubicación respectiva.
En algunas realizaciones, la etapa 506 se pueden realizar simultáneamente con las etapas 502 y 504. Por ejemplo, el servidor 160 de red puede generar y mostrar el gráfico al usuario 125 para permitir la asignación manual de una cama a un nuevo paciente sin ingresar ninguna información. En algunas realizaciones, después de recibir una selección de cama manual, el proceso 500 puede proceder directamente a la etapa 520, para asignar la cama seleccionada al paciente. En otras realizaciones, el servidor 160 de red puede tener en cuenta la solicitud de cama manual, pero aún así proceder a la etapa 508 para optimizar la colocación del paciente con base en otras entradas de datos recibidas con la selección de cama.
En la etapa 508, el servidor 160 de red puede determinar si hay una o más camas disponibles ubicadas en la unidad solicitada del hospital solicitado. La disponibilidad de la cama se puede determinar si la cama está desocupada u ocupada por un paciente con un alta pendiente o confirmada. El servidor 160 de red también puede determinar si al menos una de las camas proporciona todas las preferencias críticas de las etapas 502 y 504. Si dicha cama está disponible en la unidad solicitada (“sí” en la etapa 508), el proceso 500 puede continuar con la etapa 514, en la que el servidor 160 de red procesa adicionalmente la asignación de cama. Si no hay dicha cama disponible en la unidad asignada (“no” en la etapa 508), el proceso 500 puede proceder a la etapa 510, en la que el servidor 160 de red puede intentar reasignar al paciente a otra unidad y/u otro hospital. La etapa 510 puede ser similar a la etapa 508, en ese servidor 160 de red puede intentar reasignar al paciente basándose en preferencias críticas. Sin embargo, la etapa 510 puede expandir el proceso 500 a otras unidades relacionadas y/o no relacionadas del mismo u otros hospitales de la red. La consulta de la etapa 510 se puede determinar por una serie de determinaciones diferentes, tales como la relación o la proximidad física a la unidad solicitada. El orden de reasignación del paciente puede tener varias configuraciones diferentes. En algunas realizaciones, el servidor 160 de red se puede configurar para examinar primero otra unidad del mismo hospital, luego el servidor 160 de red se puede configurar para examinar unidades similares (por ejemplo, unidades que realizan los mismos procedimientos o procedimientos relacionados) de diferentes hospitales. En otras realizaciones, el servidor 160 de red se puede configurar para examinar primero unidades similares de diferentes hospitales, y luego examinar otra unidad del hospital solicitado. Esta configuración del servidor 160 de red puede depender del paciente individual. Por ejemplo, para los pacientes que requieren atención especializada que solo está disponible en el hospital solicitado, el servidor 160 de red se puede configurar para examinar primero las diferentes unidades del hospital solicitado. Esta configuración también puede ser favorable para los pacientes que prefieren la ubicación del hospital solicitado. Para otros pacientes que requieren una cama en una unidad particular, independientemente del hospital, el servidor 160 de red se puede configurar para examinar unidades de otros hospitales y puede que ni siquiera considere otras unidades del hospital solicitado.
Si el servidor 160 de red no puede reasignar al paciente (“no” en la etapa 510), el proceso 500 puede proceder a la etapa 512, en la que el servidor 160 de red puede enviar automáticamente una notificación al usuario 125 de que la asignación del paciente no está disponible. En algunas realizaciones, el servidor 160 de red puede acelerar la limpieza de la cama para tener una cama disponible. Por ejemplo, el servidor 160 de red puede notificar a los usuarios 125 seleccionados para indicar una asignación de limpieza de cama correspondiente a la solicitud. El servidor 160 de red puede, adicional o alternativamente, sugerir al usuario 125 solicitante cambios en las preferencias para obtener una colocación de cama en la unidad solicitada o en ubicaciones de otros hospitales.
Después de que se descubra que una o más camas tienen las preferencias críticas en las etapas 508-510, las etapas 514-518 pueden proporcionar un enfoque iterativo para optimizar la asignación de camas de acuerdo con lo anterior las entradas no críticas. En las etapas 514-518, el servidor 160 de red se puede configurar para asignar el paciente a una de las camas seleccionadas en las etapas 508-510 en función de las entradas no críticas, tales como preferencias, atributos personales y/o prioridades de la etapa 504. En una realización, el servidor 160 de red puede asignar al paciente a la cama que cumpla con las preferencias y/o atributos personales más introducidos. En esta realización, también se contempla que el servidor 160 de red pueda pesar cada una de las preferencias y/o atributos personales en función de la prioridad introducida. En otra realización, el servidor 160 de red también se puede configurar para considerar solo una o más de las preferencias y/o atributos personales en función de la prioridad. Por ejemplo, el servidor 160 de red se puede configurar para determinar si alguna cama seleccionada de las etapas 508-510 cumple con la entrada no crítica con la prioridad más alta. Si hay una cama individual que cumple con esa consulta de búsqueda, el paciente puede ser colocado en esa cama. Si hay más de una cama que cumple con la entrada no crítica con la prioridad más alta, el servidor 160 de red puede consultar esas camas para determinar si alguna cama también cumple con la entrada no crítica con la segunda prioridad más alta, y así sucesivamente. Si ninguna cama de pasos 508-510 cumple con la entrada no crítica con la prioridad más alta, el servidor 160 de red puede determinar si alguno de las camas cumple con la entrada no crítica con la segunda prioridad más alta, y así sucesivamente.
El servidor 160 de red puede hacer coincidir al paciente con la cama en función de las preferencias y/o atributos personales de muchas maneras. Por ejemplo, el servidor 160 de red puede tener en cuenta una entrada del tipo de cama deseado (por ejemplo, firmeza, tamaño, capacidad de ajuste) o ubicación física (por ejemplo, proximidad a una ventana o estación de enfermería). El servidor 160 de red también puede tener en cuenta los rasgos físicos y/o de personalidad de los pacientes en las camas ocupadas. Se contempla que el servidor 160 de red pueda configurarse para colocar al paciente cerca de otros pacientes con el mismo género y/o edad para optimizar la comodidad del paciente. El servidor 160 de red también se puede configurar para ubicar automáticamente a individuos próximos a otros pacientes con tipos de personalidad similares. Por ejemplo, el servidor 160 de red se puede configurar para colocar más proximidad de individuos salientes entre sí o en la misma habitación. Por otro lado, si el paciente solicita un entorno más silencioso, el servidor 160 puede colocar al paciente de acuerdo con lo anterior. En algunas realizaciones, el servidor 160 de red está configurado para seleccionar una ubicación no disponible cuando al menos un atributo de ubicación para la ubicación no disponible corresponde al atributo personal. En otras realizaciones más, el servidor 160 de red está configurado para determinar una prioridad de un individuo basándose en al menos un atributo personal, en el que la ubicación seleccionada se asocia con la prioridad determinada.
En algunas realizaciones, el servidor 160 de red puede emplear uno o más conjuntos de reglas o algoritmos para equilibrar cargas en diferentes unidades de una instalación, al optimizar la carga de trabajo de cada departamento y/u hospital. Por ejemplo, el servidor 160 de red se puede configurar para recibir datos de asignación y/o de alta de la base 180 de datos para cada departamento y/u hospital, y procesar los datos recibidos para asignar la cama del paciente con base en las cargas del departamento y/o del hospital en tiempo real, para asignar la unidad hospitalaria mejor posicionada para recibir y/o dar de alta al paciente en la fecha y/o hora correspondiente. El equilibrio de carga puede reducir el retraso que implica la recepción y/o el dar de alta al paciente.
Una vez que se optimiza una asignación de cama de acuerdo con las etapas 514-518, el servidor 160 de red puede asignar el paciente a la cama óptima en la etapa 520. Una vez que se completa la asignación, el servidor 160 de red puede enviar automáticamente una notificación al usuario 125 y la unidad receptora en la etapa 522. El servidor 160 de red también puede actualizar la base de datos de asignaciones de camas y organizar el transporte del paciente a la unidad asignada en la etapa 524.
Específicamente, en la etapa 524, el servidor 160 de red puede notificar a los usuarios 125 seleccionados de la tarea que debe realizarse. Los usuarios 125 seleccionados se pueden determinar con base en una determinada ocupación, tal como una enfermera. Los usuarios 125 seleccionados también se pueden determinar en base a la disponibilidad conocida de los usuarios 125. En este sentido, el servidor 160 de red puede consultar una base de datos para determinar cuáles de los usuarios 125 seleccionados están de servicio y cuáles de los usuarios seleccionados están de guardia. El servidor 160 de red también puede determinar el posicionamiento geográfico de cada uno de los usuarios 125 seleccionados para determinar qué usuario seleccionado 125 está en la mejor posición para completar la tarea. El servidor 160 de red puede notificar automáticamente a uno o más de los usuarios 125 seleccionados, a través del dispositivo 120 de usuario, con comentarios detallados o prioridad de la tarea. Esta notificación puede requerir reconocimiento o aceptación de la tarea. En algunas realizaciones, el servidor puede determinar que el usuario 125 ha reconocido la tarea si el dispositivo 120 de usuario asociado con el usuario 125 indica que el usuario 125 ha accedido o visto la notificación para la tarea. En algunas realizaciones, el servidor 160 de red puede determinar que un usuario 125 ha confirmado la tarea basándose en una entrada recibida del usuario 125 a través del dispositivo 120 de usuario. Si no hay confirmación afirmativa después de un cierto período de tiempo (por ejemplo, aproximadamente 5 minutos) pasa, el servidor 160 de red puede enviar una notificación de recordatorio a los usuarios 125 seleccionados para garantizar la recepción. Si no hay aceptación de los usuarios 125 seleccionados, el servidor 160 de red puede alterar la determinación de los usuarios 125 seleccionados y enviar notificaciones adicionales a otros usuarios 125 para garantizar que se complete la tarea.
La Figura 6 es un diagrama de flujo de un proceso de ejemplo para medir, registrar y generar métricas del estado de un trabajo. El proceso 600 se describe en este documento como realizado principalmente por el servidor 160 de red, sin embargo, en algunas realizaciones, el servidor 130 de instalación, el terminal 140 de ordenador, el terminal 145 de administración, el dispositivo 120 de usuario y/o el servidor 170 de terceros pueden realizar una o más etapas del proceso 600 Específicamente, en la etapa 602, los eventos del estado del trabajo pueden ser etiquetados, ingresados y grabados por el servidor 160 de red. Específicamente, el tiempo que cada evento del trabajo pueda ser etiquetado de acuerdo con el tipo de evento (por ejemplo, llamada, acuse de recibo, aceptación, finalización), día y hora, el empleado, la unidad y el hospital. En la etapa 604, el servidor 160 de red puede calcular el tiempo entre ciertos eventos que tienen lugar, como el tiempo desde localización hasta una devolución de llamada, el tiempo desde localización hasta la aceptación y el tiempo desde la aceptación hasta la finalización como se muestra en la Figura 6, y etiquetar y registrar los datos en consecuencia. De acuerdo con los datos etiquetados, el servidor 160 de red se puede configurar para filtrar y emitir los datos de acuerdo con cualquier número de variables en la etapa 606. Por ejemplo, el servidor 160 de red se puede configurar para filtrar y emitir para determinar el tiempo que tardan los empleados de un hospital para limpiar una cama El servidor 160 de red también se puede configurar para determinar cómo responde cada empleado de acuerdo con cada uno de los criterios. Se pueden hacer otras determinaciones, que incluyen la eficiencia de cada empleado, unidad y/u hospital. El servidor 160 de red es ventajoso porque proporciona retroalimentación instantánea de la eficiencia de la tarea y permite al hospital mejorar el rendimiento a nivel de empleado, a nivel de unidad, a nivel de hospital y a nivel de red. El servidor 160 de red también puede determinar la eficiencia del hospital en función de la hora del día, el día de la semana y la semana del año. El hospital puede contratar personal y operar en consecuencia para mejorar la eficiencia general.
Las Figuras 7-11 proporcionan ilustraciones de interfaces 700, 800, 950, 1000, 1100 ejemplares, consistentes con las realizaciones divulgadas. Las interfaces se pueden mostrar, por ejemplo, en el dispositivo 120 de usuario, el terminal 140 de ordenador o el terminal 145 de administrador con base en la comunicación a través de la red 110 local y/o la red 150. Las interfaces se describen en este documento como realizadas principalmente por el procesador 220, 330 de acuerdo con las instrucciones de programa almacenadas en la memoria 250, 340, sin embargo, en algunas realizaciones, el servidor 130 de instalación, el terminal 140 de ordenador, el terminal 145 de administración, el dispositivo 120 de usuario y/o el servidor 170 de terceros pueden realizar una o más etapas de las interfaces. Las instrucciones del programa almacenadas en la memoria 250, 340 se pueden personalizar agregando, restando, ampliando y/o reduciendo los campos de datos. Los datos mostrados en las interfaces pueden ser recibidos y actualizados en tiempo real por los procesadores 220, 330 del servidor 160 de red, la base 180 de datos, otros terminales 140 de ordenador y/u otros dispositivos 120 de usuario ubicados en diferentes hospitales. En algunas realizaciones, los datos recibidos pueden almacenarse en la memoria 250, 340 para acceder posteriormente. Las interfaces 700, 800, 900, 1000, 1100 se pueden organizar de diferentes maneras, que incluyen la navegación con pestañas como se muestra en las Figuras 7-11. Los datos obtenidos de las interfaces se pueden utilizar para procesar una solicitud de transferencia a través de un operador o realizar procesos automatizados, tal como se describe en los procesos 500, 600.
Adicionalmente, el procesador 220, 330 puede generar datos de usuario basados en la interacción con el usuario 125. El procesador 220, 330 puede actualizar los datos basados en la interacción con el usuario 125 y puede transmitir estos datos actualizados a través de la red 150 al servidor 160, base 180 de datos, otros terminales 140 de ordenador y/u otros dispositivos 120 de usuario. Por ejemplo, el procesador 220, 330 puede registrar la fecha y hora en que el usuario 125 interactúa con las interfaces, y puede registrar recibos y acuses de recibo de datos (por ejemplo, comunicaciones o tareas) basado en el usuario 125 viendo los datos. Los procesadores 220, 330 también pueden permitir que el usuario 125 transmita datos directamente al permitir que el usuario 125 genere comunicaciones o tareas. Estos datos se pueden transmitir directamente a otros terminales 140 de ordenador y/u otros dispositivos 120 de usuario para que otros usuarios 125 accedan a ellos, y/o se pueden transmitir al servidor 160 y/o la base 180 de datos para actualizar los datos almacenados.
La interfaz 700 de usuario, generada por el procesador 220, 330, puede permitir a los usuarios 125, tal como un administrador o médico responsable de dirigir la colocación del paciente, interactuar con el terminal 145 de administrador y operar la interfaz 700 de usuario. El procesador 220, 330 puede generar usuarios interfaz 700 para proporcionar una variedad de datos sin tener que buscar y comparar datos de diferentes fuentes. En la realización como se representa en la Figura 7, el procesador 220, 330 puede generar una interfaz 702 de censo que detalla los datos del censo de pacientes en una variedad de unidades y hospitales diferentes, una interfaz 704 de comunicación que permite la comunicación entre el usuario 125 correspondiente a posibles transferencias, y una interfaz 706 de tarea que detalla las tareas del usuario 125. En algunas realizaciones, los datos del censo, generados por el procesador, pueden mostrarse en al menos uno de los gráficos de barras, gráficos circulares, gráficos lineales y/o cuadros. Los procesadores 220, 330 pueden mostrar los datos del censo consistente con la cantidad de al menos una de las camas disponibles, camas ocupadas, camas sucias, camas bloqueadas y/o camas con el alta confirmada o pendiente.
La interfaz 704 de comunicación puede permitir la comunicación entre usuarios 125 ubicados en hospitales. En particular, los procesadores 220, 330 pueden permitir que se transmitan datos entre los dispositivos de usuario respectivos 120 y los terminales 140 de ordenador a través de la red 150. La red 150 puede proporcionar una red cerrada para las comunicaciones, por ejemplo, permitiendo que solo un número limitado de usuarios 125 envíen y reciban mensajes a través de la interfaz 704 de comunicación. Por ejemplo, los usuarios 125 limitados pueden estar basados en individuos que son responsables de supervisar la colocación del paciente y/o que tienen acceso a la interfaz 700 de usuario. Las comunicaciones de la interfaz 704 se pueden clasificar y filtrar por una serie de diferentes propiedades, como el estado de la comunicación, la naturaleza de la comunicación, la fecha/hora enviada o recibida y la fuente o destinatario de la comunicación.
La interfaz 706 de tareas puede permitir al usuario 125 ver la próxima tarea. Las tareas de la interfaz 706 pueden clasificarse y filtrarse de manera similar por una serie de propiedades, como el estado de la tarea, la naturaleza de la tarea, la fecha/hora enviada o recibida, y la fuente o el destinatario de la tarea. Las tareas pueden ser ingresadas y actualizadas por el procesador 220, 330 con datos recibidos en tiempo real desde el servidor 160 de red, la base 180 de datos, otros terminales 140 de ordenador y/u otros dispositivos 120 de usuario ubicados en diferentes hospitales.
La Figura 8 es una ilustración de un ejemplo de una interfaz 800 de colocación de pacientes, consistente con las realizaciones divulgadas. Los procesadores 220, 330 pueden mostrar la interfaz 800 de colocación de pacientes en respuesta a un comando del usuario 125 que busca transferir un paciente. Después de que el usuario 125 ingresa datos pertenecientes al paciente, el procesador 220, 330 puede generar un paquete de datos para la solicitud de cama y transmitirlo a través de la red 150 al servidor 160, la base 180 de datos, otros terminales 140 de ordenador y/u otros dispositivos 120 de usuario.
La interfaz 800 de colocación de pacientes puede incluir varios campos de datos diferentes para generar una solicitud de transferencia. Los campos de datos pueden incluir información 802 del paciente, información 804 de solicitud de cama, información 806 de la unidad e información 808 de asignación de cama. La información 802 del paciente puede incluir campos de datos para el nombre del paciente, el médico que lo acepta y la disposición. La información 804 de solicitud de cama puede incluir el tiempo de solicitud de cama, el solicitante, el estado de la solicitud, el origen y el nivel de atención. La información 806 de la unidad puede incluir la unidad de origen, el tiempo de la unidad objetivo y la unidad objetivo. La información 808 de asignación de cama puede incluir la cama asignada, el tiempo de asignación, asignado por y el tiempo de finalización. Los datos ingresados en la interfaz 800 de colocación de pacientes pueden ser utilizados por el servidor 160 de red en los procesos detallados en las Figuras 5-7.
El procesador 220, 330 también puede generar y mostrar datos en una interfaz 810 de guardia pasiva. Los datos pueden ser recuperados por el procesador 220, 330 a través de la red 150 desde el servidor 160, la base 180 de datos, otros terminales 140 de ordenador y/u otros dispositivos 120 de usuario. Específicamente, el procesador 220, 330 puede enviar una consulta al servidor 160, la base 180 de datos, otros terminales 140 de ordenador y/u otros dispositivos 120 de usuario para recuperar información perteneciente a los empleados. La información puede incluir nombres, títulos, equipo asociado (por ejemplo, cardíaco o trauma), especialidades, información de contacto (por ejemplo, Números de teléfono y direcciones de correo electrónico) y horarios. Los procesadores 220, 330 pueden mostrar entonces la información basada en los criterios introducidos por el usuario 125. El procesador 220, 300 puede generar la interfaz 810 de guardia pasiva de manera interactiva a medida que el usuario 125 ingresa datos. Por ejemplo, a medida que el usuario 125 ingresa datos para una solicitud de cama para una unidad (por ejemplo, pediátrica), el procesador 220, 330 puede recuperar y mostrar automáticamente los empleados que pueden estar de guardia pasiva durante un cierto período de tiempo en esa unidad. Los datos que se muestran en la interfaz 810 de guardia pasiva pueden incluir información relativa a los médicos de guardia pasiva en diferentes unidades y hospitales. La interfaz 810 de guardia pasiva puede permitir al usuario 125 personalizar la consulta del procesador 220, 330 filtrando los datos por una variedad de criterios diferentes, que incluyen unidad, campus y especialidad. La interfaz 810 de guardia pasiva también puede proporcionar enlaces rápidos para contactar a los médicos de guardia pasiva de cualquier manera, incluido el correo electrónico a través de la interfaz de comunicación 804.
La interfaz 800 de colocación de pacientes puede permitir al usuario 125 ingresar datos adicionales pertenecientes al paciente. La Figura 9 es una ilustración de un ejemplo de un menú 950, generado por el procesador 220, 330 consistente con las realizaciones divulgadas. El menú 950 se puede visualizar por el procesador 220, 330, cuando el usuario 125 accede a un hipervínculo o botón visualizado (por ejemplo, “Detalles” como en la Figura 8). El Menú 950 puede proporcionar campos adicionales, para proporcionar información relacionada con el paciente que puede utilizarse en los procesos de esta divulgación. Por ejemplo, el menú 950 puede tener campos 952 de datos para atributos de cama y campos 954 de datos para atributos de pacientes. Los campos 952 de datos pueden incluir el servicio hospitalario solicitado, el nivel de atención, la disciplina, las necesidades de alojamiento, el tamaño de cama necesario y los de datos atributos personalizados de la cama. Los campos 954 pueden incluir aislamiento y atributos personalizados del paciente. Los campos 952, 954 de datos se pueden incorporar en menús desplegables y/o campos de datos abiertos, como se representa en la Figura 9. En el caso de campos de datos abiertos, el procesador 220, 330 se puede configurar para ejecutar software de reconocimiento de datos (por ejemplo, reconocimiento de caracteres óptico) para extraer los datos. Los procesadores 220, 330 pueden solicitar datos adicionales relacionados con cada uno de los campos 952, 954 de datos, incluyendo si cada uno de los campos es crítico y un grado de criticidad de cada uno de los campos. Los datos ingresados en el menú 950 pueden ser utilizados por el servidor 160 de red en los procesos detallados en las Figuras 5 y 6.
La Figura 10 es una ilustración de un ejemplo de una interfaz 1000 de seguimiento de pacientes, consistente con las realizaciones divulgadas. En la interfaz 1000 de seguimiento de pacientes, el procesador 220, 330 puede recuperar y mostrar datos relacionados con los estados de las solicitudes de transferencia. Los estados de solicitud pueden formatearse en un gráfico 1002 como se representa en la Figura 10, que proporciona información como el nombre del paciente, la fecha en que se creó la solicitud, la fecha en que el paciente fue admitido, la instalación deseada y el estado de la solicitud. Un menú desplegable de la tabla 1002 puede proporcionar detalles adicionales, tales como diagnóstico, nombre del médico, nivel de atención, centro de referencia. Ciertos estados de transferencia se pueden fijar en la interfaz de seguimiento del paciente 1000 en una barra 1004 lateral. Las solicitudes de transferencia se pueden mostrar en la barra 1004 lateral cuando coinciden con cualquier número de criterios. Por ejemplo, la barra 1004 lateral puede mostrar todas las transferencias de pacientes solicitadas por el usuario 125. También se contempla que la barra 1004 lateral puede mostrar solo las transferencias de pacientes más recientes solicitadas por el usuario 125. También se contempla que la barra 1004 lateral pueda mostrar transferencias El usuario 125 solicitudes es responsable de recibir.
La Figura 11 es una ilustración de un ejemplo de una interfaz 1100 de seguimiento de cama, consistente con las realizaciones divulgadas. En la interfaz 1000 de seguimiento de pacientes, el procesador 220, 330 puede recuperar y mostrar datos relacionados con el estado de la cama. La interfaz de seguimiento de camas 1100 puede proporcionar el estado de las camas en cualquier número de maneras según la configuración del usuario. La interfaz 1100 de seguimiento de cama puede mostrar los estados de también se contempla que la interfaz 1100 de seguimiento de cama puede mostrar unidades similares de diferentes hospitales. Para cada cama mostrada, la interfaz 1100 de seguimiento de cama puede proporcionar información tal como la ubicación (por ejemplo, hospital, unidad), estado, ocupación del paciente y tamaño. El estado de la cama se puede seleccionar entre al menos uno de ocupado, desocupado, limpio, sucio, pendiente de alta y ocupante programado. Los procesadores 220, 330 pueden generar un código de color para cada uno de los estados de las camas para proporcionar al usuario 125 información inmediata y puede accederse a información adicional, por ejemplo, al hacer clic o tocar las camas mostradas.
La descripción anterior se ha presentado con fines ilustrativos. No es exhaustiva y no se limita a las formas o realizaciones precisas divulgadas. Las modificaciones y adaptaciones de las realizaciones serán evidentes a partir de la consideración de la especificación y la práctica de las realizaciones divulgadas. Por ejemplo, las implementaciones descritas incluyen hardware, firmware y software, pero los sistemas y métodos consistentes con la presente divulgación se pueden implementar solo como hardware.
Los programas de ordenador basados en la descripción escrita y los métodos de esta especificación están dentro de la habilidad de un desarrollador de software. Los diversos programas o módulos de programa se pueden crear utilizando una variedad de técnicas de programación. Por ejemplo, las secciones del programa o los módulos del programa se pueden diseñar en Java, C, C++, lenguaje ensamblador o cualquier otro lenguaje de programación. Una o más de dichas secciones o módulos de software pueden integrarse en un sistema de ordenador, medios legibles por ordenador no transitorios o software de comunicaciones existente.

Claims (11)

REIVINDICACIONES
1. Un servidor de comunicación de hospital centralizado para monitorización y notificación de eventos, que comprende:
una memoria que almacena instrucciones; y
al menos un procesador configurado para ejecutar las instrucciones almacenadas para:
recibir (502), desde un dispositivo en red, información del evento indicadora de un evento;
recibir (504) entradas que pertenecen a la información del evento, las entradas que incluyen al menos un atributo personal de un individuo asociado con el evento y preferencias del individuo, al menos un atributo personal que incluye una o más características físicas y/o mentales del individuo;
alterar al menos una de las entradas con base en al menos un atributo personal;
determinar las prioridades de las entradas al determinar cada una de las entradas como críticas o no críticas para seleccionar una ubicación para el individuo y una prioridad relativa de cada entrada crítica y cada entrada no crítica que utiliza una jerarquía predeterminada de entradas;
buscar (506) una base de datos de red para información de ubicación asociada con una pluralidad de ubicaciones dentro de un hospital, en la que, para cada una de la pluralidad de las ubicaciones, la información de ubicación incluye al menos un atributo de ubicación, al menos un atributo de ubicación que comprende un nivel de capacidad disponible en tiempo real de la ubicación;
identificar, en base a la información del evento recibido, las entradas, y la información de ubicación, una ubicación seleccionada de la pluralidad de ubicaciones para el individuo asociado con el evento al:
identificar una o más de la pluralidad de ubicaciones que tienen atributos de ubicación coincidentes todas entradas críticas; e
iterar, hasta que se determine una sola ubicación o se hayan considerado todas las entradas no críticas:
determinar cada una de la una o más ubicaciones que tiene un atributo de ubicación que coincide con la entrada no crítica que tiene la más alta prioridad, en la que si se determinan múltiples ubicaciones, la siguiente iteración es en base a las múltiples ubicaciones determinadas y la entrada no crítica que tiene la siguiente prioridad más alta, en la que si no se determina la ubicación, la siguiente iteración es en base a la entrada no crítica que tiene la siguiente prioridad más alta y las ubicaciones utilizadas durante la iteración actual, y
en la que si se determina la ubicación única, la ubicación única es la ubicación seleccionada;
asignar (520) la ubicación seleccionada para el individuo y actualizar la base de datos de red para actualizar la información de ocupación en tiempo real de la ubicación seleccionada; y
generar y transmitir automáticamente (522) al menos una comunicación electrónica relativa a la asignación a un dispositivo electrónico asociado con la ubicación seleccionada.
2. El servidor de comunicación de hospital centralizado de la reivindicación 1, en la que la ubicación seleccionada es una ubicación no disponible, se espera que la ubicación no disponible esté disponible dentro de un período de tiempo predeterminado.
3. El servidor de comunicación de hospital centralizado de la reivindicación 2, en el que al menos un procesador se configura adicionalmente para seleccionar la ubicación no disponible cuando al menos un atributo de ubicación para la ubicación no disponible corresponde al atributo personal.
4. El servidor de comunicación de hospital centralizado de una cualquiera de las reivindicaciones precedentes, en el que al menos un procesador se configura para determinar una prioridad del individuo en base a al menos un atributo personal, y en el que la ubicación seleccionada se asocia con la prioridad determinada.
5. El servidor de comunicación de hospital centralizado de la reivindicación 4, en el que el atributo personal incluye datos fisiológicos del individuo.
6. Un método de comunicación hospitalaria centralizado para monitorización y notificación de eventos, que se realiza por un servidor de comunicación centralizado, y que comprende:
recibir (502), desde un dispositivo en red, información del evento indicadora de un evento;
recibir (504) entradas que pertenecen a la información del evento, las entradas que incluyen al menos un atributo personal de un individuo asociado con el evento y preferencias del individuo, al menos un atributo personal que incluye una o más características físicas y/o mentales del individuo;
alterar al menos una de las entradas en base a al menos un atributo personal;
determinar las prioridades de las entradas al determinar cada una de las entradas como críticas o no críticas para seleccionar una ubicación para el individuo y una prioridad relativa de cada entrada crítica y cada entrada no crítica que utiliza una jerarquía de entradas predeterminada;
buscar (506) una base de datos de red para información de ubicación asociada con una pluralidad de ubicaciones dentro de un hospital, en la que para cada una de la pluralidad de las ubicaciones, la información de ubicación incluye al menos un atributo de ubicación, al menos un atributo de ubicación que comprende un nivel de capacidad disponible en tiempo real de la ubicación;
identificar, en base a la información del evento recibida, las entradas, y la información de ubicación, una ubicación seleccionada de la pluralidad de ubicaciones para el individuo asociado con el evento al:
identificar una o más de la pluralidad de ubicaciones que tienen atributos de ubicación coincidentes todas entradas críticas; e
iterar, hasta que se determine una sola ubicación o se hayan considerado todas las entradas no críticas:
determinar cada una de la una o más ubicaciones que tiene un atributo de ubicación que coincide con la entrada no crítica que tiene la más alta prioridad,
en el que si se determinan múltiples ubicaciones, la siguiente iteración es en base a las múltiples ubicaciones determinadas y la entrada no crítica que tiene la siguiente prioridad más alta,
en la que si no se determina la ubicación, la siguiente iteración es en base a la entrada no crítica que tiene la siguiente prioridad más alta y las ubicaciones utilizadas durante la iteración actual, y
en la que si se determina la ubicación única, la ubicación única es la ubicación seleccionada;
asignar (520) la ubicación seleccionada para el individuo y actualizar la base de datos de red para actualizar la información de ocupación en tiempo real de la ubicación seleccionada; y
generar y transmitir automáticamente al menos una comunicación electrónica a un dispositivo electrónico asociado con la ubicación seleccionada.
7. El método de comunicación hospitalaria centralizado de la reivindicación 6, en el que la ubicación seleccionada es una ubicación no disponible, se espera que la ubicación no disponible esté disponible dentro de un período de tiempo predeterminado.
8. El método de comunicación hospitalaria centralizado de la reivindicación 7, en el que al menos un procesador se configura adicionalmente para seleccionar la ubicación no disponible cuando al menos un atributo de ubicación para la ubicación no disponible corresponde al atributo personal.
9. El método de comunicación hospitalaria centralizado de cualquiera de las reivindicaciones 6 a 8, en el que al menos un procesador se configura para determinar una prioridad del individuo en base a al menos un atributo personal, y en el que la ubicación seleccionada se asocia con la prioridad determinada.
10. El método de comunicación hospitalaria centralizado de la reivindicación 9, en el que el atributo personal incluye datos fisiológicos del individuo.
11. Un medio legible por ordenador no transitorio que amacena instrucciones que cuando se ejecutan, provocan que un servidor de comunicación central realice el método de cualquiera de las reivindicaciones 6 a 10.
ES16200575T 2015-11-24 2016-11-24 Sistemas y métodos para detección y comunicación de eventos en tiempo real automatizados y centralizados Active ES2784347T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US201562259344P 2015-11-24 2015-11-24

Publications (1)

Publication Number Publication Date
ES2784347T3 true ES2784347T3 (es) 2020-09-24

Family

ID=57421665

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16200575T Active ES2784347T3 (es) 2015-11-24 2016-11-24 Sistemas y métodos para detección y comunicación de eventos en tiempo real automatizados y centralizados

Country Status (8)

Country Link
US (3) US10153994B2 (es)
EP (2) EP3690887B1 (es)
CA (1) CA2949316C (es)
DK (1) DK3173960T3 (es)
ES (1) ES2784347T3 (es)
HU (1) HUE049368T2 (es)
PL (1) PL3173960T3 (es)
PT (1) PT3173960T (es)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3006355A1 (en) * 2015-11-27 2017-06-01 Cadens Imagerie Medicale Inc. Method and system for executing a function for processing data using a server
CN107809517B (zh) * 2016-09-08 2020-07-10 阿里巴巴集团控股有限公司 事件展示方法及装置
WO2019115465A1 (en) * 2017-12-15 2019-06-20 Radiometer Medical Aps System of medical devices
US11705240B2 (en) * 2017-12-31 2023-07-18 Teletracking Technologies, Inc. Response to emergency department surge prediction
CN110365726B (zh) * 2018-04-09 2022-07-19 阿里巴巴集团控股有限公司 通信处理方法、装置、终端及服务器
US11288385B2 (en) 2018-04-13 2022-03-29 Sophos Limited Chain of custody for enterprise documents
WO2019217817A1 (en) * 2018-05-10 2019-11-14 Ccdr Group Llc Systems and methods for efficiently managing hospital operating rooms
US11278637B2 (en) * 2018-07-03 2022-03-22 Siemens Industry, Inc. Systems and methods for intelligent disinfection of disinfection environments through use of ultra-violet lights
CN109273075A (zh) * 2018-09-07 2019-01-25 上海京颐奂享物联网有限公司 一种医护人员交接班方法、装置及终端设备
CN109286555A (zh) * 2018-09-18 2019-01-29 南方科技大学 一种医院即时通讯系统及方法
US11721339B2 (en) 2020-09-27 2023-08-08 Stryker Corporation Message filtering based on dynamic voice-activated rules

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560580B1 (en) * 1999-05-10 2013-10-15 Teletracking Technologies, Inc. Visual display of room information
US8732573B2 (en) * 2000-05-10 2014-05-20 Teletracking Technologies, Inc. Visual display of room information
US7756723B2 (en) 2001-09-07 2010-07-13 Eclipsys Corporation System and method for managing patient bed assignments and bed occupancy in a health care facility
US8090590B2 (en) * 2003-03-10 2012-01-03 Intuit Inc. Electronic personal health record system
US20050080650A1 (en) * 2003-10-09 2005-04-14 Restaurant Computer Systems, Inc. System and method for meal distribution and dietary attention
CN100443045C (zh) * 2004-06-15 2008-12-17 皇家飞利浦电子股份有限公司 采集患者的生理信号的传感器
US20060004605A1 (en) * 2004-06-21 2006-01-05 Epic Systems Corporation System and method for a comprehensive interactive graphical representation of a health care facility for managing patient care and health care facility resources
CA2518293C (en) * 2004-09-07 2018-04-24 Gene E. Nacey Apparatus and method for the mobile visual display and modification of bed management information and patient placement information
US8296162B1 (en) * 2005-02-01 2012-10-23 Webmd Llc. Systems, devices, and methods for providing healthcare information
US20060247948A1 (en) 2005-04-29 2006-11-02 Ellis Linda S Graphical on-screen bed board with portable patient card
US7613620B2 (en) * 2005-06-07 2009-11-03 Angadbir Singh Salwan Physician to patient network system for real-time electronic communications and transfer of patient health information
US20070239484A1 (en) * 2006-03-20 2007-10-11 Arond Betty J System and method for managing patient bed assignments, bed occupancy, and staffing in a healthcare facility operation
US7813941B2 (en) * 2006-07-26 2010-10-12 Siemens Medical Solutions Usa, Inc. Patient bed search system
US8280748B2 (en) 2006-10-20 2012-10-02 Hill-Rom Services, Inc. Bed management
WO2008067147A2 (en) * 2006-11-13 2008-06-05 Infologix, Inc. Method, system and apparatus for dwell monitoring in a retail establishment
US8693659B2 (en) 2007-03-09 2014-04-08 Fonality, Inc. System and method for centralized presence management of local and remote users
US20090243833A1 (en) * 2008-03-31 2009-10-01 Ching Ching Huang Monitoring system and method for patient care
JP5401556B2 (ja) * 2008-12-08 2014-01-29 インフォノーツ インク． 疾病マッピングと感染制御のシステム及び方法
BR112012001304A2 (pt) * 2009-07-23 2018-04-03 Koninklijke Philips Electrnics N. V. sistema de monitoramento de quartos, unidade interna de quarto uso no sistema metodo de exibir a situação de um ou mais consultorios medicos
WO2011095365A2 (de) * 2010-02-05 2011-08-11 Cytolon Ag Automatisiertes system zur auswahl und vermittlung von gelagerten allogenen biologischen zellen für transplantation, therapie und forschung
US8799011B2 (en) * 2010-02-19 2014-08-05 Hill-Rom Services, Inc. Patient room and bed management apparatus and system
US20120116793A1 (en) * 2010-11-09 2012-05-10 International Business Machines Corporation Administering A Patient In A Hospital
US10149267B2 (en) * 2011-10-11 2018-12-04 Match Group, Llc System and method for matching using location information
US8930223B2 (en) * 2012-03-30 2015-01-06 International Business Machines Corporation Patient cohort matching
CN104272310B (zh) * 2012-05-02 2017-12-08 皇家飞利浦有限公司 用于将医学警告路由到选定的职员的设备和方法
US20130304485A1 (en) * 2012-05-11 2013-11-14 Mujtaba Ali Khan Method of referring patients to healthcare providers
US20140108035A1 (en) * 2012-10-11 2014-04-17 Kunter Seref Akbay System and method to automatically assign resources in a network of healthcare enterprises
US20150100333A1 (en) * 2013-10-08 2015-04-09 Clinical Lenz, Inc. Systems and methods for verifying protocol compliance
US20160132650A1 (en) * 2014-02-14 2016-05-12 Kamal Kejriwal Nursing Home Bed Reservation System
US10636104B2 (en) * 2014-04-16 2020-04-28 Vios Medical, Inc. Patient care and health information management systems and methods
US20160072681A1 (en) * 2014-09-04 2016-03-10 OpenBeds Inc. System and method for criteria-based optimized transfer of physical objects or people between different geographic locations including an exemplary embodiment for patients transfer between health care facilities
WO2016079552A1 (en) * 2014-11-17 2016-05-26 Umm Al-Qura University System, method, and apparatus for emergency response
US10665350B2 (en) * 2014-11-26 2020-05-26 Teletracking Technologies, Inc. Computerized data processing systems and methods for generating graphical user interfaces
US10235646B2 (en) * 2015-04-10 2019-03-19 Teletracking Technologies, Inc. Systems and methods for automated real-time task scheduling and management
US20170017758A1 (en) * 2015-04-15 2017-01-19 Infusystem Holdings, Inc. Integrated system for obtaining information from electronic medical records and method of use
EP3098739A1 (en) * 2015-05-26 2016-11-30 Hill-Rom Services, Inc. Healthcare communication system
US20160350499A1 (en) * 2015-05-29 2016-12-01 International Business Machines Corporation System and method for optimizing allocation of medical units for patient treatment
US10089441B2 (en) * 2015-06-22 2018-10-02 General Electric Company System-wide probabilistic alerting and activation

Also Published As

Publication number Publication date
US20200259769A1 (en) 2020-08-13
EP3690887A1 (en) 2020-08-05
CA2949316A1 (en) 2017-05-24
CA2949316C (en) 2024-04-16
US20170149701A1 (en) 2017-05-25
EP3173960A1 (en) 2017-05-31
US20190116139A1 (en) 2019-04-18
DK3173960T3 (da) 2020-04-14
HUE049368T2 (hu) 2020-09-28
EP3690887B1 (en) 2023-05-24
PT3173960T (pt) 2020-04-21
EP3173960B1 (en) 2020-01-08
US10652176B2 (en) 2020-05-12
US11240182B2 (en) 2022-02-01
US10153994B2 (en) 2018-12-11
PL3173960T3 (pl) 2020-07-27

Similar Documents

Publication Publication Date Title
ES2784347T3 (es) Sistemas y métodos para detección y comunicación de eventos en tiempo real automatizados y centralizados
US11799837B1 (en) Systems and methods for protecting displayed patient information
US10977590B2 (en) Computerized data processing systems and methods for generating graphical user interfaces
US11410096B2 (en) Systems and methods for automated task scheduling and management
US20220198402A1 (en) System and method for scheduling patient appointments
US11017337B2 (en) Computerized data processing systems and methods for generating interactive graphical user interfaces
US10679746B1 (en) Systems and methods for generating automated real-time graphical user interfaces
US11341442B2 (en) Systems and methods for processing real-time and historical data and generating predictive graphical user interfaces
US11914656B1 (en) Systems and methods for generating hypermedia-based graphical user interfaces for mobile devices
US20200251227A1 (en) Computerized data processing systems and methods for generating graphical user interfaces
US11250946B2 (en) Systems and methods for automated route calculation and dynamic route updating
US11838112B1 (en) Systems and methods for real-time transmission of digital data using a plurality of channels
EP3156951A1 (en) Systems and methods for automated route calculation and dynamic route updating
US11348679B1 (en) Systems and methods for processing real-time and historical data and generating nursing unit health scores
US10762989B1 (en) Systems and methods for generating automated graphical user interfaces for real-time facility capacity management
US11244756B1 (en) Integrated system and method for receiving and processing real-time digital data concerning transportation and service monitoring scheduling