ES2295753T3 - Sistema de comunicacion y procedimiento para la manipulacion de datos medicos. - Google Patents
Sistema de comunicacion y procedimiento para la manipulacion de datos medicos. Download PDFInfo
- Publication number
- ES2295753T3 ES2295753T3 ES04023327T ES04023327T ES2295753T3 ES 2295753 T3 ES2295753 T3 ES 2295753T3 ES 04023327 T ES04023327 T ES 04023327T ES 04023327 T ES04023327 T ES 04023327T ES 2295753 T3 ES2295753 T3 ES 2295753T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- server
- communication
- medical
- client
- 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
Links
Classifications
-
- 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/2866—Architectures; Arrangements
- H04L67/2895—Intermediate processing functionally located close to the data provider application, e.g. reverse proxies
-
- 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/56—Provisioning of proxy services
-
- 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
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- 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
-
- 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/60—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 operation of medical equipment or devices
- G16H40/67—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 operation of medical equipment or devices for remote operation
-
- 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
- G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
-
- 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/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- 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/56—Provisioning of proxy services
- H04L67/564—Enhancement of application control based on intercepted application data
-
- 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/56—Provisioning of proxy services
- H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
-
- 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/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
Landscapes
- Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Epidemiology (AREA)
- Biomedical Technology (AREA)
- Public Health (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Business, Economics & Management (AREA)
- Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Pathology (AREA)
- Electrotherapy Devices (AREA)
- Measuring And Recording Apparatus For Diagnosis (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
Sistema de comunicación para la manipulación de datos médicos, el sistema de comunicación comprende un equipo médico, que presenta un medio de detección para detectar datos médicos, una unidad de memoria para el almacenamiento de datos de modo que éstos puedan ser llamados, así como un interface de comunicación para el intercambio de datos, un server (20), que presenta una unidad de memoria, en la cual están almacenados los datos registrados por el equipo médico de modo que pueden ser llamados, así como un interface de comunicación, mediante el cual el server (20) está en comunicación con uno o múltiples clientes (30) al menos temporalmente, así como múltiples clientes (30), que presentan una unidad de evaluación así como un interface de comunicación, caracterizado porque los clientes también (30) presentan una unidad de memoria en la cual están almacenados los datos registrados por el equipo médico, asimismo la unidad de evaluación incluye una aplicación de evaluación para la lectura, el tratamiento, la modificación o el complemento de los datos almacenados en la unidad de memoria de los clientes (30), asimismo, mediante el interface de comunicación se transmiten los datos tratados, modificados o completados en los clientes (30) desde los clientes (30) al server (20), asimismo estos datos son almacenables en la unidad de memoria del server (20), porque están previstos medios para la sincronización de los datos del server (20) y de los clientes (30), mediante los cuales se pueden transmitir al server (20) los datos tratados, modificados o completados exclusivamente en un cliente (30) y porque están previstos medios mediante los cuales se transmiten los tratamientos, las modificaciones o los complementos de datos realizados por otros clientes (30) y almacenados en el server (20), del server (20) a los clientes (30), de modo que en todos los clientes (30) y en el server (20) se hallen los mismos juegos de datos.
Description
Sistema de comunicación y procedimiento para la
manipulación de datos médicos.
La presente invención comprende un sistema de
comunicación así como un procedimiento para la manipulación de
datos médicos, acordes al término genérico de las reivindicaciones 1
y 24. Especialmente en el primer tratamiento y en el tratamiento
posterior de pacientes de emergencia es de suma importancia que los
datos recogidos en el marco del tratamiento sean registrados de
modo confiable, y que puedan ser vistos al mismo tiempo o en corto
tiempo y, en caso de ser necesario, ser completados por el médico
tratante. Para poner a disposición los datos registrados por el
equipo médico a un mayor círculo de usuarios para su lectura, se
propuso almacenar los datos en un server web. Un sistema semejante
se conoce por la memoria WO 02/17593 A2. El sistema publicado allí
posibilita la visualización de datos del tratamiento que son
transmitidos, por ejemplo, de un marcapasos de modo inalámbrico a
un dispositivo de comunicación, y de él a un server web. De este
modo es posible la observación del paciente sin la necesidad de la
visita del médico. Los datos almacenados en el server web pueden
ser vistos por parte de usuarios autorizados mediante un explorador
de Internet.
El sistema conocido por la memoria WO 02/17593
A2 presenta la desventaja de que los datos del tratamiento y los
programas de aplicación se hallan en el server web central, desde
donde, en caso de necesidad, se deben cargar los archivos
necesarios a un ordenador local y aquí pueden ser visualizados
mediante el explorador. En este tipo de aplicaciones de exploración
en cada acceso se cargan todos los datos o aplicaciones del server
web central al ordenador local, por lo cual se obtienen cantidades
relativamente grandes de datos a transmitir y tiempos de
transmisión correspondientemente prolongados. Otra desventaja
resulta porque los usuarios sin conexión a Internet en este tipo de
sistemas naturalmente no tienen la posibilidad de visualizar los
datos del tratamiento que se encuentran en el server web. En el
sistema conocido por la memoria WO 02/17593 A2 es finalmente
desventajoso que, a causa de la transmisión de juegos de datos
completos existe en principio también la posibilidad de acceder a
ellos o interceptarlos sin autorización, lo cual es naturalmente
indeseado en caso de datos sensibles de pacientes y de
tratamientos.
Por el artículo "SQL server for Windows CE - A
data base engine for mobile and embedded platforms; Seshadri, P.
et. al, Data Engineering, 2000, Proceedings, 16th
International Conference on San Diego, CA, USA, 29 FEB - 3 MAR
2000, Los Alamitos, CA, USA, IEEE Compute SOC, US, 29 de febrero de
2000 (2000-02-29)", páginas 642
a 644, XP 010378761, se conoce un banco de datos para plataformas
móviles en las cuales se realiza el intercambio de datos entre
server y cliente de modo que las modificaciones que se llevan a cabo
en el cliente se transmiten al server a los fines de la
sincronización.
La memoria US 2002/0049684 A1 comprende un
sistema de comunicación entre cliente y server en el cual las
modificaciones llevadas a cabo en el cliente son almacenadas en un
server. Estos datos son transmitidos luego a un equipo médico para
poner a disposición datos médicos actuales o un plan de
tratamiento.
La presente invención se origina por ello con el
objetivo de poner a disposición un sistema de comunicación así como
un procedimiento para la manipulación de datos médicos que trabaje
con cortos tiempos de transmisión de datos, que también sea
accesible para usuarios sin acceso a Internet y en el cual sea
posible, con un volumen menor de datos a transmitir, la generación
de juegos de datos idénticos en el cliente y en el server.
Este objetivo se logra a través de un sistema de
comunicación con las características de la reivindicación 1 así
como a través de un procedimiento con las características de la
reivindicación 24. Los condicionamientos ventajosos de la invención
son objeto de las subreivindicaciones. El presente sistema de
comunicación comprende una arquitectura de
cliente-server en la cual se puede acceder
localmente a una aplicación de evaluación almacenada localmente en
el cliente. Mediante la aplicación de evaluación es posible
visualizar y procesar datos almacenados localmente. El trabajo con
datos almacenados localmente reduce el riesgo de que datos sensibles
sean interceptados, llamados o vistos sin autorización. Los datos
tratados, modificados o completados en el cliente se pueden
transmitir al server y almacenar allí, y están luego a disposición
para otros usuarios. El cliente obtiene los datos médicos por
ejemplo o bien inmediatamente del equipo médico o bien del server,
en caso de que estos ya se encuentren disponibles en el server.
Bajo la denominación "datos médicos" se
entienden todos los datos relevantes en el marco de una atención o
un tratamiento de un paciente, como por ejemplo datos del
tratamiento que se recogen durante un tratamiento médico, o también
datos sin intervención de un médico, por ejemplo, los datos de un
marcapasos, sensor de presión sanguínea etc. registrados
continuamente.
La presencia de una aplicación local en el
cliente trae consigo la ventaja de que también el usuario sin
conexión a Internet puede ser atendido, y porque se suprime la
carga de una aplicación desde un server central, por lo cual se
pueden reducir las cantidades de datos a transmitirse. En un
intercambio de datos entre server y cliente se puede prever además,
en un acondicionamiento ventajoso de la invención, a los fines de la
sincronización, que no se transmita todo el juego de datos, sino
sólo la diferencia en forma de datos nuevos o modificados, por lo
que se pueden reducir aún más los tiempos de transmisión. A causa de
la posibilidad de transmitir datos del o de los clientes al server,
se puede asegurar que el juego de datos que se encuentra en el
server esté siempre actualizado.
La transmisión de datos entre el equipo médico,
el o los clientes y el server puede realizarse respectivamente
inmediatamente o mediatamente por interconexión de otros componentes
del sistema.
Los datos almacenados en el equipo médico pueden
ser transmitidos inmediatamente a través de su interface de
comunicación al o a los clientes o al server.
En el caso del equipo médico puede tratarse por
ejemplo de un desfibrilador externo. En principio el sistema de
comunicación y el procedimiento acordes a la invención también se
adecuan a cualquier otro equipo médico, preferentemente a equipos
médicos transportables, que se utilizan por ejemplo en
intervenciones de emergencia.
Como es descrito anteriormente, acorde a la
invención están previstos medios para la sincronización de los
datos del server y del cliente, mediante los cuales se pueden
transmitir al server los datos tratados, modificados o completados
exclusivamente en el cliente. De este modo no se vuelven a
transmitir todos los datos de un objeto de datos en cada
comunicación entre server y cliente, sino solamente la diferencia de
datos. Lo correspondiente vale para las modificaciones realizadas
por otros clientes que se encuentran almacenadas en el server.
También para tales modificaciones vale que, mediante la unidad de
sincronización sólo se transmiten las modificaciones o los
complementos realizados por otros clientes al cliente sincronizado.
De este modo se asegura que en todos los clientes, así como en el
server, estén presentes juegos de datos idénticos, asimismo se deben
transmitir relativamente pocas cantidades de datos.
En otros acondicionamientos de la invención está
previsto que en el caso de la aplicación de evaluación que se
encuentra en el cliente se trate de una aplicación Java WebStart.
Una ventaja de esta tecnología es que las actualizaciones para los
usuarios del Software se pueden obtener automáticamente por
Internet. Asimismo, los componentes más nuevos pueden ser
instalados al iniciar la aplicación, siempre y cuando exista una
conexión a Internet. Otra ventaja de la aplicación Java WebStart se
desprende del hecho que ésta es independiente de la plataforma que
se utiliza, y puede ser aplicada correspondientemente de manera
independiente al sistema operativo del usuario.
En otros acondicionamientos de la invención está
previsto que al menos un interface de comunicación del equipo
médico, así como al menos de un cliente, es un interface para la
transmisión de datos directa. La técnica de transmisión de datos
puede ser seleccionada libremente. Se puede pensar por ejemplo en
infrarrojos o Bluetooth. También puede estar prevista la aplicación
de una técnica que usualmente sólo sirve para la transmisión de
datos a distancia, como por ejemplo, la técnica de radiotelefonía
móvil. En cuanto a la técnica de transmisión de datos entre el
equipo médico y el cliente no hay ningún tipo de limitaciones. Para
el paso de los datos del equipo médico, éste se puede comunicar con
el cliente mediante un interface infrarrojo o también por ejemplo
por Bluetooth. Los datos pueden ser transmitidos luego, tras un
eventual tratamiento en el cliente, desde éste al server. El
interface del equipo médico puede, además, servir para tomar datos
del cliente, como por ejemplo, datos de configuración locales o
datos de ajuste del equipo. En principio es igualmente posible
enviar este tipo de datos inmediatamente desde el server al equipo
médico.
En un acondicionamiento preferido de la
invención está previsto que el interface de comunicación del equipo
médico esté constituido como interface radiotelefónico móvil. El
server o un server de comunicación cuentan, en este
acondicionamiento de la invención, con un interface radiotelefónico
móvil, mediante el cual se pueden transmitir los datos del equipo
médico al server o al server de comunicación y desde allí al server.
De este modo se pueden transmitir los datos de la intervención o
del tratamiento directamente del equipo médico al server. La
transmisión puede realizarse mediante tecnología de radiotelefonía
móvil o también mediante otras técnicas de transmisión de datos
adecuadas. Si se utiliza la tecnología de radiotelefonía móvil, se
aplica por ejemplo estándar GSM, GPRS o UMTS.
El server de comunicación puede ser un
componente integral del server.
Si el equipo médico así como el server o un
server de comunicación presentan un interface radiotelefónico
móvil, se puede prever que los datos se puedan transmitir del server
al equipo médico o del server al server de comunicación y desde
allí al equipo médico. De este modo es posible proveer al equipo
médico rápidamente de datos importantes, por ejemplo con datos de
pacientes, requeridos y útiles para continuar con el tratamiento.
Además es posible proveer al equipo médico de una conexión de datos
de ese tipo con datos locales o datos de configuración sin que éste
deba comunicarse para ello con el cliente.
En la unidad de memoria del server o del cliente
se pueden hallar, entre otros, los datos locales específicos del
equipo médico, actualizaciones de firmware, datos correspondientes
al ajuste del equipo médico o de los datos de pacientes,
especialmente datos correspondientes a enfermedades previas,
tratamientos actuales o pasados. Estos datos o actualizaciones
pueden transmitirse mediante interfaces de comunicación del server,
del cliente y del equipo médico, desde el server o el cliente
inmediatamente al equipo médico, o del server al cliente, y
mediante el interface de comunicación del cliente y del equipo
médico, del cliente al equipo médico. De este modo el equipo médico
es configurable mediante el cliente o el server y es posible proveer
al equipo médico de datos relevantes, por ejemplo de datos
importantes y necesarios inmediatamente de pacientes.
En otro acondicionamiento de la invención está
previsto que el equipo médico cuente con medios para recoger
valores de medición obtenidos en el marco de un tratamiento. Los
medios para recoger valores de medición pueden incluir detectores
mediante los cuales pueden ser recogidos por sensores los datos
transmitidos por técnica de transmisión directa, por ejemplo,
mediante transmisión de datos por infrarrojos o Bluetooth. Es
especialmente ventajoso si el equipo médico reconoce por sí mismo
sensores a su alcance que emitan datos relevantes. Los datos de
estos sensores se almacenan, por ejemplo, adicionalmente a los del
ECG (electrocardiograma) en la memoria del equipo médico o del
desfibrilador, y están a disposición en la lectura de datos. Si en
el caso del equipo médico se trata de un desfibrilador, los medios
para recoger valores de medición pueden incluir los electrodos del
desfibrilador. La manipulación de datos en el desfibrilador puede
referirse a la visualización de datos, especialmente a la
representación del ECG en tiempo real. Paralelo a ello en el monitor
se puede indicar también de modo numérico la frecuencia de pulso y
eventualmente la saturación de oxígeno. Además puede integrar un
sensor spO_{2} externo por Bluetooth en el registro de datos. El
procesamiento de datos del desfibrilador además puede incluir la
protocolización en lo que respecta a las partes del protocolo que
pueden registrarse prontamente. El registro de datos puede ser
completado luego mediante el cliente 30.
Además se puede prever que el equipo médico
presente medios para recoger datos de pacientes. Puede tratarse, en
este caso, por ejemplo de medios de lectura para cualquier medio de
almacenamiento en el cual se hallan datos de pacientes. Una
posibilidad es el dispositivo de lectura de la tarjeta chip para
leer una tarjeta del seguro del paciente. También se puede pensar
en que los medios presenten medios de entrada y/o salida mediante
los cuales se ingresan datos o un código, que presentan una
asignación a un paciente y posibilitan la carga de los
correspondientes datos del paciente en el equipo médico y su salida.
En conexión con la entrada de datos o del código se puede prever
que el equipo médico acceda a los datos de los pacientes de
cualquier memoria. Puede estar previsto que los medios para
descargar los datos de los pacientes de un acta de un paciente
electrónica sean brindados por Internet. En este caso los medios
están conformados como dispositivos para bajas los datos
correspondientes desde Internet o también desde cualquier otro
server no basado en la web. Por los medios para recoger los datos
de los pacientes se puede asegurar que las informaciones básicas
correspondientes al paciente se hallen en el equipo médico. Toda
otra información puede ser ingresada en el equipo médico o mediante
el cliente.
El equipo médico en otro acondicionamiento de la
invención, presenta medios para ingresar y/o seleccionar datos. De
este modo se abre la posibilidad de ingresar datos ya durante la
intervención o el tratamiento, que luego pueden ser completados
para conformar un protocolo de la intervención. Si en el equipo
médico sólo hay posibilidades limitadas de ingresar datos, es
ventajoso si se realiza una selección de datos predeterminados. Las
listas correspondientes que contienen las respuestas seleccionables,
pueden estar almacenadas en el acta local del server y ser cargadas
desde allí o a través del cliente al equipo médico.
Si el equipo médico es difícil de cargar durante
el tratamiento, es ventajoso si el equipo médico cuenta con un
interface de comunicación, mediante el cual pueden ser transmitidos,
en tiempo real, los valores de medición obtenidos en el marco de un
tratamiento a un monitor. Se puede pensar, por ejemplo, en la
representación de un ECG. La transmisión de los valores de medición
puede realizarse por ejemplo por Bluetooth. En principio también
son pensables otras técnicas de transmisión. De modo alternativo o
adicional el equipo médico puede presentar un monitor integrado
para la visualización de los datos del tratamiento recogidos, lo
cual es especialmente ventajoso si no hay un monitor externo o una
posibilidad de transmisión a un monitor externo.
En otro acondicionamiento de la invención está
previsto que el sistema de comunicación presente una unidad de
recepción con un interface de comunicación para la recepción
mediante infrarrojo o Bluetooth de los datos almacenados en el
equipo médico de modo que pueden ser llamados. La unidad de
recepción puede hallarse, por ejemplo, en el servicio de emergencia
de una clínica y sirve para llamar rápidamente a los datos de
tratamiento que se encuentran en el equipo médico. Los datos
transmitidos de este modo pueden ser luego por ejemplo procesados
y/o cargados en la Intranet de una clínica. Además se puede prever
que la unidad de recepción cuente con un interface para el
intercambio de datos con el server, de modo que los datos del
tratamiento pueden ser accedidos desde el server, lo cual, sin
embargo, tiene como consecuencia tiempos de transmisión más
prolongados.
En otro acondicionamiento de la invención está
previsto que el server cuente con múltiples juegos de datos, de los
cuales al menos un primer juego de datos incluya datos de los
pacientes y al menos un segundo juego de datos incluya datos
correspondientes al equipo médico, asimismo los datos recogidos en
el segundo juego de datos no presentan una asignación a un paciente
determinado. En el segundo juego de datos se almacenan
exclusivamente datos de un equipo correspondiente. Estos datos no
presentan, por motivos de protección de datos, relación alguna con
un paciente determinado.
Además, puede preverse que el server incluya al
menos un tercer juego de datos con datos específicos para un médico
y al menos un cuarto juego de datos con datos específicos para el
lugar del equipo médico. En el caso de los datos específicos del
médico se puede tratar de datos personales del médico, de datos de
sus intervenciones, ajustes personales del equipo médico, etc. En
el caso de datos específicos locales del cuarto juego de datos, se
puede tratar, por ejemplo, de datos relativos al posible operador en
el lugar, una lista de los equipos médicos del lugar, clínicas,
vehículos o medicamentos, del lugar, así como de intervenciones
realizadas con los equipos médicos del lugar.
Es especialmente ventajoso si el server cuenta
con un interface de comunicación, mediante el cual se pueden
almacenar datos de documentos transmitidos mediante Telefax en el
server. Por ejemplo, cada archivo del server puede estar provisto
de una identificación de fax, que identifica los telefaxes que
ingresan al server y luego los archiva como documento nuevo en el
archivo correspondiente. Además es posible que el server cuente con
un interface de comunicación, mediante el cual se pueden transmitir
mediante Telefax datos de documentos almacenados en el server A su
vez puede pensarse que el emisor le indique al server que envíe un
fax con datos relevantes a un receptor definido. También es posible
pensar en proveer de datos automáticos, por ejemplo, de protocolos
de intervención a todas las clínicas del lugar. Es posible,
asimismo, que se asignen identificaciones de solicitud de fax que
permitan una llamada directa de datos por parte del server, por
ejemplo, de los datos de la última intervención, por llamadas por
polling de fax.
En otro acondicionamiento de la invención en la
unidad de memoria del server se encuentran las condiciones o los
valores límite relacionados con los datos allí almacenados, y porque
están previstos medios mediante los cuales se pueden generar
indicaciones o comunicaciones al presentarse las condiciones o al
alcanzarse el valor límite. Se puede pensar, por ejemplo, en que al
superar un valor límite de un valor de azúcar en sangre sea
notificado un médico por SMS o por correo electrónico. También se
puede pensar en que en el server sean almacenados mensajes sobre el
estado del equipo médico, que generan el envío de un telefax al
responsable del mantenimiento correspondiente.
La presente invención comprende además un
procedimiento acorde a la reivindicación 24, para la manipulación
de datos médicos, en el cual un equipo médico recoge datos médicos,
que se almacenan de modo que se puedan llamar y se transmiten a un
receptor, en el cual en un server se almacenan de modo que puedan
ser llamados, en el cual en al menos un cliente, que está al menos
temporalmente en comunicación con el server, se almacenan los datos
recogidos por el equipo médico y mediante una aplicación de
evaluación que se encuentra en el cliente, se almacenan, tratan,
modifican o complementan, porque estos datos tratados, modificados o
completados se trasmiten del cliente al server y se almacenan en el
server. Los condicionamientos ventajosos del procedimiento son
objeto de las subreivindicaciones.
Otros detalles y ventajas de la invención se
detallan a partir de un ejemplo de ejecución representado en los
dibujos. Se muestra:
Figura 1: Un diagrama de flujo de datos del
sistema de comunicación
Figura 2: Una cuadro esquemática de posibles
interlocutores de comunicación de un desfibrilador,
Figura 3: Una representación esquemática de la
integración de los datos del desfibrilador en un sistema de
información de una clínica,
Figura 4: Una representación esquemática de
archivos del server y sus relaciones entre sí,
Figura 5: Una representación esquemática del
reenvío de los datos del server y
Figura 6: Una representación esquemática de la
técnica de sincronización del sistema de comunicación.
Para el sistema de comunicación y el
procedimiento acordes a la invención es fundamental el principio de
que los datos del equipo médico, por ejemplo, de un desfibrilador,
no deben ser enviados directamente a una estación de manipulación,
por ejemplo, en la clínica, sino que deben ser almacenados en un
server central, desde el cual se puede llevar a cabo una
distribución rápida a diferentes receptores de diferentes formas.
Desde el server los datos pueden ser consultados mediante el
cliente. Esta comunicación se realiza preferentemente a través de
una conexión HTTPS cifrada. Pero en principio también puede pensarse
que los datos del server, por ejemplo, los datos de la
intervención, sean solicitados al server por fax. También es posible
pensar en la solicitud o la retransmisión de los datos del server a
una unidad terminal móvil, por ejemplo, un teléfono móvil o un
PDA.
La figura 1 muestra el desfibrilador externo 10,
que recibe datos desde sus electrodos 90, de los sensores externos
80 cercanos preferentemente mediante análisis sensorial inalámbrico,
así como de una unidad de registro 95 del desfibrilador 10, por
entrada local del usuario. De un cliente local 30 el desfibrilador
10 también puede ser provisto de datos de configuración locales,
actualizaciones de firmware y ajustes del equipo, preferentemente
por infrarrojos.
Los datos de configuración locales son cargados
por el server 20, eventualmente manipulados en el cliente 30 y
luego enviados al desfibrilador 10. En principio es igualmente
posible enviar estos datos del server 20 al desfibrilador 10
inmediatamente, por ejemplo, por GSM, GPRS, UMTS etc.
Lo mismo vale para los ajustes del equipo del
desfibrilador 10, que son transmitidos a desfibrilador 10 a través
del cliente 30 o bien inmediatamente desde el server 20. En una
transmisión de datos del cliente 30 existe la posibilidad de que el
cliente 30 consulte los datos del server 20 o los complete mediante
sincronización con el server 20.
Como se puede ver en la figura 1, la
comunicación con el server 20 se lleva a cabo a través del server de
comunicación 22.
Como se desprende asimismo de la figura 1, las
informaciones básicas del paciente pueden ser ingresadas por la
tarjeta del seguro del paciente 97. Todas las demás informaciones
pueden ser recogidas en el desfibrilador 10 o posteriormente a
través del cliente 30 durante una manipulación posterior, como por
ejemplo, entradas de texto libres. En principio también es pensable
y ventajoso si los datos de los pacientes, por ejemplo,
tratamientos previos, datos de enfermedades previas y semejantes
sean enviados inmediatamente del server 20 al desfibrilador 10,
para que estos estén a disposición ya antes o a más tardar durante
el tratamiento.
La protocolización local acorde a la figura 1
sirve a la posibilidad de ingresar datos ya durante la intervención
o el tratamiento, que luego pueden ser completados para conformar un
protocolo de la intervención. Esto se refiere sobre todo a
indicaciones críticas temporalmente, como el registro de la emisión
de descargas por el desfibrilador, el suministro de medicamentos o
la introducción de medidas terapéuticas. Preferentemente gran parte
de estas medidas y entradas se consignan localmente en el acta local
160 del server 20, de modo que las correspondientes entradas
posibles sólo deben ser elegidas de listas. Los datos registrados
por los sensores 80 o por los electrodos 90 son ingresados
inmediatamente en el desfibrilador 10. A diferente de otros datos
registrados, todos los valores de medición tienen una frecuencia de
lectura constante y por ello pueden ser almacenados en forma de un
array, ahorrando espacio. Se lleva a cabo un almacenamiento
intermedio de los canales individuales en la memoria del
desfibrilador 10. En la lectura de los datos por el cliente 30 o en
la retransmisión de datos al server 20 se puede acceder a los
canales individuales por separado. De este modo también se puede
llevar a cabo un online streaming de datos en una PC o en un monitor
externo.
Los valores de medición continuos son empacados
en formato EDF antes de la transmisión y luego enviados en forma de
bloque. Con ello, todos los canales registrados se encuentran en una
unidad de transmisión. La transmisión debe realizarse en tiempo
real, de modo que un monitor conectado pueda mostrar los datos en
vivo. En la lectura posterior de los datos la transmisión en tiempo
real no juega ningún papel. Por ello, la señal aquí puede ser
enviada en toda la calidad representada. Los datos de pacientes son
transmitidos, en cuanto se registran en la intervención, en el
juego de datos de la intervención. Una asignación de datos de
pacientes a un acta de paciente 130 no se realiza en el
desfibrilador 10, sino sólo posteriormente en el cliente 30 durante
la reelaboración. Por motivos de protección de datos, los datos de
pacientes son recibidos en el acta del médico 150 del server 20,
pero no en el acta local
160.
160.
Para almacenar los datos el desfibrilador 10 se
comunica con el server 20 o con el server de comunicación 22 o
indirectamente a través del cliente 30, que eventualmente almacena
los datos en el server 20 tras reelaborar o completarlos. Allí los
contenidos son separados y asignados a las actas que podemos
observar en la figura 1, el acta del paciente 130, el acta del
equipo 140, el acta del médico 150 y el acta local 160.
En principio es igualmente posible llevar a cabo
la comunicación por streaming de datos, en el cual todas las
señales presentes, incluso señales externas recibidas por Bluetooth,
son emitidas como streaming EDF a través de una conexión
serial.
Cada médico que trabaja con el sistema de
comunicación, obtiene un acta de médico 150 propia, en la cual se
pueden registrar sus datos personales. Ese tipo de datos médicos
específicos comprenden: datos personales del médico, datos
administrativos del médico (lugar, especialidad etc.), datos de sus
intervenciones, comentarios personales sobre sus intervenciones,
datos personales de facturación de las intervenciones, ajustes
personales del desfibrilador.
Cada desfibrilador 10 asignado a un lugar,
obtiene, a través del acta local 160, acceso a los datos comunes de
todos los desfibriladores del lugar de una intervención. Con ello se
puede garantizar que todos los desfibriladores de un lugar accedan
a especificaciones comunes. Además los datos de intervenciones son
registrados en el acta local 160, lo cual trae consigo la ventaja
de que se posibilita una búsqueda de intervenciones a nivel regional
sin tener que conocer qué desfibrilador fue utilizado. Los datos
específicos registrados en el acta local 160 son los siguientes:
operadores posibles, para poder establecer rápidamente una selección
de la lista en la protocolización, lista de desfibriladores en el
lugar, clínicas en el lugar con información de contacto, repertorio
de medicamentos estandarizado del lugar o de la ambulancia,
intervenciones llevadas a cabo con los desfibriladores del
lugar.
En el acta del equipo 140 que contiene los datos
específicos del equipo se documentan los siguientes datos: modelo,
número de serie, localización, propietario, persona de contacto,
técnico responsable, versión de Software de todos los componentes,
cantidad de intervenciones, cantidad de las descargas suministradas,
próxima fecha de mantenimiento, protocolos de mantenimiento, Link
al acta local 160.
Los datos del paciente que se registran en actas
durante la intervención se registran provisoriamente en el acta del
médico 150. Desde allí el médico puede trasladar los datos al acta
del paciente 130. Se registran: Datos de origen de la tarjeta del
seguro, fecha de la emergencia, protocolo de emergencia de la
intervención, médico tratante.
Los datos de la intervención son registrados,
como se ha mencionado anteriormente, en el acta local 160.
Adicionalmente se realiza un protocolo de intervención que
corresponde a los estándares requeridos. Este protocolo es
registrado parcialmente durante la intervención, pero también puede
ser completado por el médico mediante el cliente 30, tras la
intervención. Los datos de la intervención registrados le sirven al
medico para elaborar una factura. Los contenidos del juego de datos
de la intervención son los siguientes: Fecha de la emergencia, lugar
de la emergencia, emisión de la llamada de emergencia, llegada del
desfibrilador 10, medidas tomadas (medicamentos, respiración
artificial, reanimación, suministro de descargas) con sello de
tiempo, valores registrados (ECG, otros sensores), datos del
paciente registrados (de la tarjeta del paciente), operadores del
desfibrilador, clínica en que se realiza el tratamiento posterior,
fecha de hospitalización, otras indicaciones acordes al protocolo
de emergencia.
La figura 4 muestra la relación entre sí de las
actas mencionadas, es decir, áreas de la memoria
130-160 así como sus contenidos preferidos. Al acta
del paciente 130 no existen relaciones directas, dado que no estaría
permitido por motivos de protección de datos.
Existe la posibilidad de firmar digitalmente
partes de los datos en las diferentes actas. Esto puede realizarse
mediante una firma de árboles parciales del documento XML almacenado
en el server 20. De este modo, personas o unidades diferentes
también pueden firmar por separado subconjuntos de los datos. Esto
es especialmente relevante en el acta local 160, en la cual
diferentes médicos realizan entradas que deben ser asignadas sin
duda a una persona. La firma garantiza con ello la integridad y la
imposibilidad de desmentir los datos. La firma se basa en una firma
de claves criptográficas pública y privada basada en GnuPG. Quien
desee firmar datos en el sistema debe generar primero una clave, de
la cual la clave pública es almacenada en un keyserver público. La
clave privada (secreta) es propiedad del propietario y es asegurada
adicionalmente con un PIN. Para firmar los datos se genera un valor
hash del fragmento XML a firmar, que se firma con la clave secreta.
El valor hash firmado es anexado al documento XML con la ID de la
clave. La univocidad de la firma garantiza que la firma calculada
sólo se puede generar con una sola clave determinada del valor hash
de los datos. Con cualquier otra clave se habría generado otra
firma. Para verificar la firma, se accede desde el keyserver a la
clave pública con la ID de la clave y se aplica el algoritmo inverso
de la firma a los datos. Se debe generar para ello el mismo valor
que en la firma. Si estos valores no son idénticos los datos fueron
cambiados y la firma no es válida.
En un perfeccionamiento preferido de la
invención se realiza un cifrado de los datos. A su vez está previsto
que el cifrado se realice en dos lugares: En el recorrido de la
comunicación, para impedir una intercepción de los datos, así como
en el almacenamiento en el server 20. El cifrado en el recorrido de
la comunicación, es asumido por el protocolo HTTPS, que configura
un cifrado SSL asimétrico. El cifrado para el almacenamiento en el
banco de datos es uno simétrico, que sólo representa un seguro
adicional de la infraestructura del server. Un cifrado de datos
para receptores especiales, como se realizaría en una comunicación
de correo electrónico cifrada, no se lleva a cabo. Éste no es
necesario, dado que ya se realiza una verificación de los derechos
de acceso en el server. Un cifrado de los datos para un receptor
determinado puede ser relevante si los datos de la intervención se
deben enviar a un receptor por correo electrónico.
Mediante el cliente 30 es posible el mando del
desfibrilador 10, así como la administración de múltiples equipos
médicos, así como la manipulación médica de los datos. El cliente 30
presenta una aplicación en forma de una aplicación JavaWebStart, lo
cual hace a la aplicación independiente del sistema operativo del
usuario.
La mayoría de los datos médicos resultantes son
empacados en forma de un documento XML. De esta forma los datos
pueden ser elaborados y visualizados tanto por el Software del
cliente como también por el server 20. Sin embargo, para la serie
de mediciones registradas se adecua mejor el formato EDF, dado que
en su aplicación se generan menos costos generales que en caso de
la aplicación de XML. La conexión entre datos XML y EDF se logra
linkeando el documento EDF desde el documento XML.
El server de comunicación 22 acorde a la figura
1 sirve para posibilitar la transmisión de datos del desfibrilador
10 al server 20 o en dirección contraria. El server 22 recibe los
mismos paquetes de datos que el cliente 30 recibe por infrarrojos.
Desde aquí se genera el protocolo de intervención en formato XML,
así como, por separado, el archivo EDF con los valores de medición.
Ambos se transmiten directamente al server 20. El server 22 puede
realizarse directamente en el server 20. La transmisión de los datos
se lleva a cabo por ejemplo por interfaces V. 110, a través de la
red GSM y con ello, digitalmente.
La figura 2 muestra en otra representación
esquemática del interlocutor de comunicación del desfibrilador 10.
Junto con al interlocutor de comunicación ya representado en la
figura 1 están previstos en la figura 2 el o los monitores externos
120, que obtienen los valores de medición en tiempo real por
Bluetooth.
Además en la figura 2 está representada
esquemáticamente una estación de recepción en una clínica. Esta
presenta una unidad de recepción 122, que dispone de un interface
de comunicación para la recepción de los datos almacenados en el
desfibrilador 10 mediante Bluetooth.
La figura 3 muestra esquemáticamente cómo los
datos de la intervención de la clínica pueden ponerse a disposición
para un tratamiento posterior. Junto a la recepción inmediata de
datos del desfibrilador 10 existe la posibilidad de acceder a
través de una conexión a Internet a los datos de intervención del
acta local 160 del server 20. De modo alternativo, los datos de
intervención pueden ser tomados inmediatamente por la unidad de
recepción 122 desde el acta local 160, como se desprende de la
figura 3. Esto presupone, sin embargo, que los datos del
desfibrilador 10 sean transmitidos a tiempo al server 20 y a su acta
local 160.
Además existe la posibilidad, como se puede ve
en la figura 3, de enviar al server 20 los juegos de datos de la
unidad de recepción 122 con las modificaciones efectuadas en la
clínica. Otra posibilidad consiste en procesar el juego de datos en
la clínica a través del cliente 30. Los datos del server pueden ser
transmitidos de modo inalámbrico al servicio de emergencia, lo cual
es ventajoso especialmente en lo que respecta a intervenciones
anteriores. En principio también es posible replicar los datos en el
cliente 30 antes de iniciar la marcha y evaluarlos en el viaje
hasta el lugar de la emergencia.
Las siguientes funcionalidades están
implementadas en la unidad de recepción 122: Recepción de datos de
intervención, inclusive informaciones del paciente del
desfibrilador 10 mediante Bluetooth; recepción de datos del acta
local 160; impresión inmediata del protocolo de intervención,
administración basada en browser de las intervenciones anteriores
obtenidas y de las intervenciones actuales. a su vez se deberían
implementar las siguientes funcionalidades: Ingresar los datos de
intervención en la documentación interna del sistema de información
de la clínica (KIS); asignar los datos de la intervención a un acta
de pacientes existente; crear una nueva acta de paciente a partir
del incidente, ingresar la documentación del sistema de información
de la clínica en el acta del paciente.
Se lleva a cabo una manipulación de datos en el
desfibrilador 10, en el cliente 30, en el server 20 así como
también en la unidad de recepción 122. En el cliente 30 se verifican
nuevamente los datos registrados en el desfibrilador 10 y se
completan en el protocolo de emergencia completo. En el cliente 30
los datos del ECG pueden ser evaluados y clasificados nuevamente a
través de algoritmos correspondientes, si es que esto no ha
ocurrido ya en el desfibrilador 10. La clasificación calculada puede
ser consignada luego directamente en el ECG. La representación del
ECG en el cliente 30 permite un rápido resultado dentro del juego de
datos. Puntos llamativos pueden ser seleccionados, ampliados y
medidos con movimientos del ratón. A través de un simple doble clic
en el ECG, se puede agregar un comentario en el punto
correspondiente en el desarrollo de los datos, que luego es
almacenado en los datos de la intervención.
El ECG también puede ser reproducido, en esta
representación, en tiempo real, sincronizado con los datos de audio
registrados. La tarea principal del cliente 30 en la versión del
médico será completar el protocolo de intervención. Los datos
registrados por la protocolización en actas local son manipulados y
completados posteriormente. Ergonómicamente son posibles las
entradas de texto.
Además el cliente 30 posibilita el ajuste de una
facturación por la intervención en forma de factura.
Si las informaciones del paciente no pudieron
ser ingresadas ya durante la intervención desde la tarjeta del
paciente, éstas pueden ser ingresadas posteriormente mediante el
cliente 30. Debe tenerse en cuenta especialmente que debería
existir una posibilidad de asignar los datos de la intervención en
un acta de paciente 130 existente, o de generar una nueva acta de
paciente 130, que luego es completada con los datos de la
intervención.
La figura 5 muestra el reenvío de los datos
almacenados en el server 20. El reenvío posibilita un paso rápido
de los datos de la intervención registrados a un determinado. Están
disponibles los siguientes mecanismos:
- Correo electrónico con link El emisor libera el juego de datos en el acta local 160 y le envía al receptor un link, que indica directamente el juego de datos en el browser.
- Envío de Fax: El emisor le ordena al server 20 enviar un fax con el protocolo de la intervención a un receptor definido. También pueden enviarse automáticamente protocolos de la intervención a todas las clínicas en el lugar.
- Solicitud de fax: Se pueden asignar identificaciones de solicitud de fax a un acta local 160, que permitan una solicitud directa de datos por parte del server, por polling de fax.
- Sincronización: Si un receptor también cuenta con un cliente 30, se puede llevar a cabo un acceso a nuevas intervenciones a través de una sincronización simple, como se detallará mas adelante.
Además es posible proveer al cliente 30 de
fuentes de datos externas. También es posible, llevar a cabo
evaluaciones estadísticas en el cliente 30 sobre las intervenciones
realizadas, lo cual es especialmente significativo para la gestión
de calidad.
Los posibles receptores de los datos almacenados
en el server 20 son la clínica, el servicio de emergencia, el
médico de cabecera y una institución de rehabilitación, el servicio
de emergencias a los fines de la gestión de calidad, así como el
paciente.
Una solución simple en lo que respecta a la
comunicación con la clínica consiste en transmitir los datos por
telefax del server 20 a la clínica. Para ello el desfibrilador 10
debe ser leído y los datos de la intervención deben ser
transmitidos al server 20, lo cual trae consigo una demora. En
relación con la velocidad es más ventajosa la recepción de datos en
la clínica mediante la unidad de recepción 122, por ejemplo, por
Bluetooth, acorde a la figura 3. La unidad de recepción 122 recepta
el juego de datos de la intervención como fue protocolizado durante
la intervención. Desde la unidad de recepción 122 se pueden
visualizar o imprimir los datos. Los datos pueden ser
posteriormente representados en la pantalla, o en determinadas
circunstancias, ser importados directamente al sistema de
información de la clínica.
En lo que respecta al médico de cabecera y la
institución de rehabilitación un tiempo latente entre la
intervención en el accidente y la disponibilidad de los datos juega
un papel secundario. El acceso a los datos puede llevarse a cabo
por un lado a través del cliente 30 o también a través de una vista
por Internet, o también ser solicitada por fax desde el server.
Para el paciente, al igual que para el médico de
cabecera o la institución de rehabilitación no es requerido un
acceso en tiempo real a los datos. Aquí es suficiente si el
paciente, que recibe una copia de los datos del médico de cabecera,
de la clínica o del servicio de emergencia en su acta del
paciente130, tiene acceso a sus datos tras el tratamiento. Este
acceso puede realizarse por browser web, dado que no es requerida
ninguna funcionalidad de manipulación.
La figura 6 muestra el desarrollo de la
sincronización de los datos del server y del cliente. Como se
desprende de la figura 6, son replicadas partes del objeto de datos
XML del server 20 (Replicación 1, 2) y almacenados localmente en el
cliente 30 (cliente A, cliente B). Las modificaciones en el cliente
(\Delta1, \Delta2) son protocolizados y corroborados en el
procedimiento de sincronización (sincronización 1, 2C) en el server
20. Las modificaciones que entretanto fueron sincronizadas en el
server por otros clientes son a su vez transmitidas al cliente en
proceso de sincronización (sincronización 2S, 3S), tras una
evaluación correspondiente (sincronización 2C, 3C). Individualmente
la sincronización incluye los siguientes pasos: Protocolización de
las modificaciones acorde a Xpath, fecha y tipo de modificación en
el cliente; transmisión de la modificación al server; verificación
de las modificaciones protocolizadas en el server desde la última
sincronización del cliente, solución de conflictos de la
sincronización; almacenamiento de las modificaciones en una tabla en
el server; transmisión de las modificaciones restantes al cliente;
si se modifican o agregan elemento binarios al cliente estos objetos
modificados son solicitados por el cliente; almacenamiento de los
objetos binarios en el banco de datos.
Objetos nuevos almacenados en el cliente que
pueden aparecer varias veces en un conjunto, son provistos con IDs
temporarias (negativas) en el cliente. Durante la sincronización se
controla en el server qué IDs ya fueron asignadas para esta ruta.
El server modifica las IDs negativas a las siguientes mayores aún no
asignadas. Esta modificación es luego comunicada también al
cliente, para que éste pueda actualizar su copia local. De este
modo diferentes clientes pueden agregar al mismo tiempo elementos
nuevos sin influenciarse entre sí.
Puede ser significativo que al alcanzar o
superar valores límite de datos se desencadenen determinadas
acciones. Para ello se colocan preferentemente los denominados
watchpoints, que al superar un valor límite envían un mensaje, por
ejemplo, por SMS. Para ello deben realizarse los siguiente pasos:
Definir el elemento de dato a observar; definir los criterios a
tener en cuenta; definir la acción a desencadenar (envío de un
mensaje, etc.); almacenar los watchpoints en el banco de datos;
procesar todos los watchpoints de un acta en cada sincronización;
procesar sincronizados temporalmente todos los watchpoints de todas
las actas.
Para garantizar una administración de datos
segura puede ser ventajoso liberar a diferentes usuarios diferentes
partes de juegos de datos del server 20. En este caso se puede
determinar qué usuario puede acceder a qué árbol parcial del objeto
de datos XML para lectura y escritura. Además un usuario puede pasar
los derechos de administración de su juego de datos propio a otros
usuarios, que entonces asumen el derecho de administración del
propietario casi como representantes. Para el usuario las rutas en
el árbol XML están ocultas tras descripciones textuales. Se deben
llevar a cabo los siguientes pasos: Selección o determinación de un
co-usuario del juegos de datos propio;
determinación de los derechos de escritura/lectura en el juego de
datos; eventualmente definición del co-usuario como
administrador del juego de datos propio, que a su vez puede
determinar otros co-usuarios (y también
co-administradores).
A su vez existe la posibilidad de no poder
otorgar derechos sólo sobre elementos individuales de los datos,
sino sobre complejos de temas completos, que se pueden hallar en
diferentes lugares del objeto de datos del server.
Claims (34)
1. Sistema de comunicación para la manipulación
de datos médicos, el sistema de comunicación comprende un equipo
médico, que presenta un medio de detección para detectar datos
médicos, una unidad de memoria para el almacenamiento de datos de
modo que éstos puedan ser llamados, así como un interface de
comunicación para el intercambio de datos, un server (20), que
presenta una unidad de memoria, en la cual están almacenados los
datos registrados por el equipo médico de modo que pueden ser
llamados, así como un interface de comunicación, mediante el cual
el server (20) está en comunicación con uno o múltiples clientes
(30) al menos temporalmente, así como múltiples clientes (30), que
presentan una unidad de evaluación así como un interface de
comunicación, caracterizado porque los clientes también (30)
presentan una unidad de memoria en la cual están almacenados los
datos registrados por el equipo médico, asimismo la unidad de
evaluación incluye una aplicación de evaluación para la lectura, el
tratamiento, la modificación o el complemento de los datos
almacenados en la unidad de memoria de los clientes (30), asimismo,
mediante el interface de comunicación se transmiten los datos
tratados, modificados o completados en los clientes (30) desde los
clientes (30) al server (20), asimismo estos datos son almacenables
en la unidad de memoria del server (20), porque están previstos
medios para la sincronización de los datos del server (20) y de los
clientes (30), mediante los cuales se pueden transmitir al server
(20) los datos tratados, modificados o completados exclusivamente
en un cliente (30) y porque están previstos medios mediante los
cuales se transmiten los tratamientos, las modificaciones o los
complementos de datos realizados por otros clientes (30) y
almacenados en el server (20), del server (20) a los clientes (30),
de modo que en todos los clientes (30) y en el server (20) se
hallen los mismos juegos de datos.
2. sistema de comunicación acorde a la
reivindicación 1, caracterizado porque los datos almacenados
en el equipo médico son transmitidos inmediatamente a través de su
interface de comunicación al o a los clientes (30) o al server
(20).
3. Sistema de comunicación acorde a la
reivindicación 1 o 2, caracterizado porque en el caso del
equipo médico se trata de un desfibrilador externo (10).
4. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque los
tratamientos, los cambios o los complementos de datos realizados
por otros clientes y almacenados en el server (20) se pueden
transmitir del server (20) al cliente (30).
5. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque en el caso
de la aplicación de evaluación que se encuentra en el cliente (30),
se trata de una aplicación Java WebStart.
6. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque un
interface de comunicación del equipo médico está constituido como
interface radiotelefónico móvil, y porque el server (20) o un
server de comunicación (22) que se encuentra en comunicación con él
también cuenta con un interface radiotelefónico móvil, mediante el
cual se pueden transmitir los datos del equipo médico al server (20)
o al server de comunicación (22) y desde allí al server (20).
7. Sistema de comunicación acorde a la
reivindicación 6, caracterizado porque el server de
comunicación (22) es un componente integral del server (20).
8. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque un
interface de comunicación del equipo médico está constituido como
interface radiotelefónico móvil, y porque el server (20) o un
server de comunicación (22) que se encuentra en comunicación con él,
también cuenta con un interface radiotelefónico móvil, mediante el
cual se pueden transmitir los datos del server (20) al equipo médico
o del server (20) al server de comunicación (22) y desde allí al
equipo médico.
9. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque en la
unidad de memoria del server (20) o del cliente (30) se encuentran
los datos locales específicos del equipo médico, actualizaciones de
firmware, datos correspondientes al ajuste del equipo médico o de
los datos de pacientes, especialmente datos correspondientes a
enfermedades previas, tratamientos actuales o pasados, y porque
estos datos o actualizaciones se pueden transmitir inmediatamente
mediante los interfaces de comunicación del server (20), del
cliente (30) y del equipo médico, del server (20) o del cliente (30)
al equipo médico, o del server (20) al cliente (30), y mediante los
interfaces de comunicación del cliente (30) y del equipo médico, del
cliente (30) al equipo
médico.
médico.
10. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque el equipo
médico cuenta con medios para recoger valores de medición obtenidos
en el marco de un tratamiento, asimismo los medios para recoger
valores de medición incluyen detectores mediante los cuales pueden
ser recogidos por sensores (80) los datos transmitidos por
infrarrojos o Bluetooth.
11. Sistema de comunicación acorde a las
reivindicaciones 3 y 10, caracterizado porque los medios para
recoger valores de medición incluyen a los electrodos (90) del
desfibrilador (10).
12. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque el equipo
médico presenta medios para recoger datos de pacientes.
13. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque el equipo
médico presenta medios (95) para ingresar y/o seleccionar datos.
14. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque el equipo
médico cuenta con un interface de comunicación, mediante el cual
pueden ser transmitidos, en tiempo real, los valores de medición
obtenidos en el marco de un tratamiento a un monitor (120).
15. Sistema de comunicación acorde a la
reivindicación 14, caracterizado porque los valores de
medición se pueden transmitir a través de un interface de
comunicación del equipo médico mediante Bluetooth.
16. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque el
interface de comunicación presenta una unidad de recepción (122)
con un interface de comunicación para la recepción mediante
infrarrojos o Bluetooth de los datos almacenados en el equipo
médico de modo que pueden ser llamados.
17. Sistema de comunicación acorde a la
reivindicación 16, caracterizado porque la unidad de
recepción (122) también presenta un interface para el intercambio
de datos con el server (20).
18. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque el equipo
médico presenta un monitor integrado para la visualización de los
datos del tratamiento recogidos.
19. Sistema de comunicación acorde a una de las
reivindicaciones anteriores caracterizado porque el server
(20) cuenta con múltiples juegos de datos, de los cuales al menos un
primer juego de datos (130) incluye datos de los pacientes y al
menos un segundo juego de datos (140) incluye datos correspondientes
al equipo médico, asimismo los datos recogidos en el segundo juego
de datos (140) no presentan una asignación a un paciente
determi-
nado.
nado.
20. Sistema de comunicación acorde a la
reivindicación 19, caracterizado porque el server (20)
incluye al menos un tercer juego de datos (150) con datos
específicos para un médico y al menos un cuarto juego de datos
(160) con datos locales específicos del equipo médico.
21. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque el server
(20) cuenta con un interface de comunicación, mediante el cual se
pueden almacenar datos de documentos transmitidos mediante Telefax
en el server (20).
22. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque el server
(20) cuenta con un interface de comunicación, mediante el cual se
pueden transmitir mediante Telefax datos de documentos almacenados
en el server (20).
23. Sistema de comunicación acorde a una de las
reivindicaciones anteriores, caracterizado porque en la
unidad de memoria del server (10) se encuentran las condiciones o
los valores límite relacionados con los datos allí almacenados, y
porque están previstos medios mediante los cuales se pueden generar
indicaciones o comunicaciones al presentarse la condición o al
alcanzarse el valor límite.
24. Procedimiento para la manipulación de datos
médicos, en el cual, en un equipo médico, los datos médicos se
recogen, se almacenan de modo que puedan ser llamados y se
transmiten a un receptor, y en el cual se almacenan, en un server
(20) los datos médicos recogidos por el equipo médico, de modo que
puedan ser llamados, caracterizado porque en clientes (30)
que están al menos temporalmente en comunicación con el server (20)
los datos recogidos por el equipo médico se almacenan y mediante
una aplicación de evaluación que se encuentra en el cliente (30),
se almacenan, tratan, modifican o complementan, porque estos datos
tratados, modificados o completados se trasmiten del cliente (30)
al server (20) y se almacenan en el server (20), porque a los fines
de la sincronización de datos se transmiten al server (20) los
datos tratados, modificados o completados exclusivamente en un
cliente (30) y porque los tratamientos, las modificaciones o los
complementos llevados a cabo por otros clientes (30) son
transmitidas del server (20) a los clientes (30), de modo que en
todos los clientes (30) y en el server (20) se encuentren los
mismos juegos de datos.
25. Procedimiento acorde a la reivindicación 24,
caracterizado porque los datos almacenados en el equipo
médico son transmitidos inmediatamente al server (20) o al cliente
(30).
26. Procedimiento acorde a la reivindicación 24
o 25, caracterizado porque en el caso del equipo médico se
trata de un desfibrilador externo (10).
27. Procedimiento acorde a una de las
reivindicaciones anteriores caracterizado porque la
transmisión de datos entre el equipo médico y el cliente (30) se
lleva a cabo por transmisión de datos por infrarrojos.
\newpage
28. Procedimiento acorde a una de las
reivindicaciones anteriores, caracterizado porque los datos
se transmiten mediante tecnología de radiotelefonía móvil del
equipo médico al server (20) o a un server de comunicación (22) en
comunicación con él, o del server (20) o del server de comunicación
(22) al equipo médico.
29. Procedimiento acorde a una de las
reivindicaciones anteriores caracterizado porque los valores
de medición obtenidos en el marco del tratamiento de son recogidos
y registrados por el equipo médico.
30. Procedimiento acorde a las reivindicaciones
26 y 29, caracterizado porque la recolección de datos se
realiza mediante los electrodos (90) del desfibrilador (10) o
mediante detectores que obtienen los datos por transmisión de datos
por infrarrojos o Bluetooth.
31. Procedimiento acorde a una de las
reivindicaciones anteriores caracterizado porque está
prevista una unidad de recepción (122), y porque los datos
almacenados en el equipo médico se transmiten a la unidad de
recepción (122) por infrarrojos o Bluetooth.
32. Procedimiento acorde a la reivindicación 31,
caracterizado porque los datos se transmiten del server (20)
a la unidad de recepción (122) y/o de la unidad de recepción (122)
al server (20).
33. Procedimiento acorde a una de las
reivindicaciones anteriores, caracterizado porque el server
(20) puede ser direccionado por un número de telefax y porque el
contenido de datos del Telefax es almacenado en el server (20).
34. Procedimiento acorde a una de las
reivindicaciones anteriores, caracterizado porque a pedido
del receptor o de un tercero, se envían por Telefax los datos
almacenados en el server (20).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10350538 | 2003-10-29 | ||
| DE10350538A DE10350538A1 (de) | 2003-10-29 | 2003-10-29 | Kommunikationssystem und Verfahren zur Bearbeitung medizinischer Daten |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2295753T3 true ES2295753T3 (es) | 2008-04-16 |
Family
ID=34399601
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04023327T Active ES2295753T3 (es) | 2003-10-29 | 2004-09-30 | Sistema de comunicacion y procedimiento para la manipulacion de datos medicos. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US20050216311A1 (es) |
| EP (1) | EP1528752B1 (es) |
| AT (1) | ATE380430T1 (es) |
| DE (2) | DE10350538A1 (es) |
| DK (1) | DK1528752T3 (es) |
| ES (1) | ES2295753T3 (es) |
| PL (1) | PL1528752T3 (es) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130231960A1 (en) * | 2005-09-12 | 2013-09-05 | Mymedicalrecords, Inc. | Personal health record with genomics |
| US8121855B2 (en) * | 2005-09-12 | 2012-02-21 | Mymedicalrecords.Com, Inc. | Method and system for providing online medical records |
| NO325438B1 (no) * | 2005-12-22 | 2008-05-05 | World Medical Ct Holding Sa | Fremgangsmate for sikker overforing av medisinsk data til en mobil enhet/terminal |
| JP4855172B2 (ja) * | 2006-07-31 | 2012-01-18 | シャープ株式会社 | 生体情報測定装置、管理装置、および生体情報通信システム |
| US20080056152A1 (en) * | 2006-09-05 | 2008-03-06 | Sharp Kabushiki Kaisha | Measurement data communication device, health information communication device, information acquisition device, measurement data communication system, method of controlling measurement data communication device, method of controlling information acquisition device, program for controlling measurement data communication device, and recording medium |
| US20080215360A1 (en) * | 2006-10-24 | 2008-09-04 | Kent Dicks | Systems and methods for medical data interchange interface |
| DE102007033992A1 (de) * | 2007-07-19 | 2009-01-22 | Biotronik Crm Patent Ag | Anordnung und Verfahren zum Management von Daten einer Mehrzahl von programmierbaren persönlichen medizinischen Geräten |
| DE102007043090A1 (de) | 2007-09-10 | 2009-03-12 | Biotronik Crm Patent Ag | Fernprogrammierbares persönliches Gerät sowie Anordnung und Verfahren zum Fernprogrammieren eines persönlichen Gerätes |
| DE102008000895B4 (de) | 2008-03-31 | 2013-04-11 | CompuGroup Medical AG | Verwendung eines mobilen Telekommunikationsgeräts als elektronische Gesundheitskarte |
| US20110029592A1 (en) * | 2009-07-28 | 2011-02-03 | Galen Heathcare Solutions Inc. | Computerized method of organizing and distributing electronic healthcare record data |
| WO2013056194A1 (en) | 2011-10-14 | 2013-04-18 | Zoll Medical Corporation | Automated delivery of medical device support software |
| CN105190631A (zh) | 2013-03-15 | 2015-12-23 | 卓尔医学产品公司 | 病人监护屏幕聚合 |
| US10340035B2 (en) | 2013-11-13 | 2019-07-02 | Fenwal, Inc. | Medical record storage with electronic signature |
| WO2016080997A1 (en) * | 2014-11-20 | 2016-05-26 | Draeger Medical Systems, Inc. | Transferring device settings |
| US10269454B2 (en) * | 2015-01-06 | 2019-04-23 | Stryker Corporation | Method of configuring devices in an operating theater |
| US11329683B1 (en) | 2015-06-05 | 2022-05-10 | Life365, Inc. | Device configured for functional diagnosis and updates |
| US10560135B1 (en) | 2015-06-05 | 2020-02-11 | Life365, Inc. | Health, wellness and activity monitor |
| US10185513B1 (en) | 2015-06-05 | 2019-01-22 | Life365, Inc. | Device configured for dynamic software change |
| US9974492B1 (en) | 2015-06-05 | 2018-05-22 | Life365, Inc. | Health monitoring and communications device |
| US10388411B1 (en) | 2015-09-02 | 2019-08-20 | Life365, Inc. | Device configured for functional diagnosis and updates |
| CN114036092A (zh) * | 2021-11-16 | 2022-02-11 | 深圳市联影高端医疗装备创新研究院 | 一种医学设备的操作管理系统、方法及存储介质 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5724985A (en) * | 1995-08-02 | 1998-03-10 | Pacesetter, Inc. | User interface for an implantable medical device using an integrated digitizer display screen |
| DE19707026B4 (de) * | 1997-02-21 | 2004-10-28 | Siemens Ag | Medizinische Therapie- und/oder Diagnoseanlage |
| US6272545B1 (en) * | 1997-10-24 | 2001-08-07 | Microsoft Corporation | System and method for interaction between one or more desktop computers and one or more mobile devices |
| DE19758393B4 (de) * | 1997-12-23 | 2006-04-20 | Biotronik Meß- und Therapiegeräte GmbH & Co. Ingenieurbüro Berlin | Anordnung zur Patientenüberwachung |
| US6263245B1 (en) * | 1999-08-12 | 2001-07-17 | Pacesetter, Inc. | System and method for portable implantable device interogation |
| US6497655B1 (en) * | 1999-12-17 | 2002-12-24 | Medtronic, Inc. | Virtual remote monitor, alert, diagnostics and programming for implantable medical device systems |
| GB0001026D0 (en) * | 2000-01-18 | 2000-03-08 | Hewlett Packard Co | Configurable connectivity unit and method and system for configuring such a unit |
| TW587929B (en) * | 2000-05-31 | 2004-05-21 | Matsushita Electric Ind Co Ltd | Medical checkup network system |
| US7349947B1 (en) * | 2000-08-04 | 2008-03-25 | Firelogic, Inc. | System and method for managing, manipulating, and analyzing data and devices over a distributed network |
| DE10131911A1 (de) * | 2001-07-02 | 2003-01-16 | Ghc Global Health Care Gmbh | Portables telemedizinisches Multidiagnostikgerät |
-
2003
- 2003-10-29 DE DE10350538A patent/DE10350538A1/de not_active Withdrawn
-
2004
- 2004-09-30 DK DK04023327T patent/DK1528752T3/da active
- 2004-09-30 EP EP04023327A patent/EP1528752B1/de active Active
- 2004-09-30 DE DE502004005640T patent/DE502004005640D1/de active Active
- 2004-09-30 AT AT04023327T patent/ATE380430T1/de active
- 2004-09-30 PL PL04023327T patent/PL1528752T3/pl unknown
- 2004-09-30 ES ES04023327T patent/ES2295753T3/es active Active
- 2004-10-29 US US10/977,964 patent/US20050216311A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| ATE380430T1 (de) | 2007-12-15 |
| DE502004005640D1 (de) | 2008-01-17 |
| DE10350538A1 (de) | 2005-06-16 |
| DK1528752T3 (da) | 2008-01-02 |
| EP1528752A2 (de) | 2005-05-04 |
| PL1528752T3 (pl) | 2008-05-30 |
| US20050216311A1 (en) | 2005-09-29 |
| EP1528752B1 (de) | 2007-12-05 |
| EP1528752A3 (de) | 2005-09-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2295753T3 (es) | Sistema de comunicacion y procedimiento para la manipulacion de datos medicos. | |
| US11907397B2 (en) | Records access and management | |
| CN110462654B (zh) | 记录存取和管理 | |
| US20190208354A1 (en) | Records access and management | |
| US9801036B2 (en) | Initial rescue information collection device, operation method thereof, recording medium, and system | |
| ES2780850T3 (es) | Intercambio seguro de registros de salud en tiempo real | |
| US8126735B2 (en) | Systems and methods for remote patient monitoring and user interface | |
| US20090234672A1 (en) | Systems and methods for remote patient monitoring and storage and forwarding of patient information | |
| US20090112769A1 (en) | Systems and methods for remote patient monitoring | |
| US20230317233A1 (en) | Systems, devices and methods for securing and tracking drug dispensing devices | |
| JP2009125133A (ja) | 歯科医療支援システム及び歯科医療支援用ｘ線センサ | |
| JP6570691B1 (ja) | 個人医療情報集約システム | |
| US11328048B2 (en) | Method for logging in to system | |
| CN107004048B (zh) | 记录访问和管理 | |
| US9492088B2 (en) | Medical device for the measurement and processing of a health parameter of a patient | |
| JP2020064435A (ja) | 疾病診断・治療・予防システム | |
| CN112927775B (zh) | 基于区块链的诊疗信息处理方法及装置 | |
| ES2690354T3 (es) | Sistema de seguridad con gestor de cuentas para un dispositivo médico portátil | |
| JP2022000819A (ja) | 情報処理システム、情報処理装置及びプログラム | |
| KR100945819B1 (ko) | 휴대 단말기를 이용한 개인건강기록 서비스 방법 및 그에따른 시스템 | |
| JP2010067237A (ja) | 医用情報サービス提供端末及びモバイル情報端末並びにそれらを用いてなる医用情報サービス提供システム | |
| KR102313308B1 (ko) | 챌린지 지원 시스템 | |
| JP2003337861A (ja) | 医療情報提供システム | |
| KR20090036341A (ko) | 유비쿼터스 기반의 사용자 의료정보 공유 시스템 및 그구축방법 | |
| Iwaya | A security framework for mobile health data collection. |