MXPA06011525A - Sistema y metodos para manejo del tratamiento y datos del paciente. - Google Patents

Sistema y metodos para manejo del tratamiento y datos del paciente.

Info

Publication number
MXPA06011525A
MXPA06011525A MXPA06011525A MXPA06011525A MXPA06011525A MX PA06011525 A MXPA06011525 A MX PA06011525A MX PA06011525 A MXPA06011525 A MX PA06011525A MX PA06011525 A MXPA06011525 A MX PA06011525A MX PA06011525 A MXPA06011525 A MX PA06011525A
Authority
MX
Mexico
Prior art keywords
data
database
metadata
patient
analysis
Prior art date
Application number
MXPA06011525A
Other languages
English (en)
Inventor
David B Agus
Original Assignee
Cedars Sinai Medical Center
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 Cedars Sinai Medical Center filed Critical Cedars Sinai Medical Center
Publication of MXPA06011525A publication Critical patent/MXPA06011525A/es

Links

Classifications

    • 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
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16B—BIOINFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR GENETIC OR PROTEIN-RELATED DATA PROCESSING IN COMPUTATIONAL MOLECULAR BIOLOGY
    • G16B40/00—ICT specially adapted for biostatistics; ICT specially adapted for bioinformatics-related machine learning or data mining, e.g. knowledge discovery or pattern finding
    • G16B40/10—Signal processing, e.g. from mass spectrometry [MS] or from PCR
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16B—BIOINFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR GENETIC OR PROTEIN-RELATED DATA PROCESSING IN COMPUTATIONAL MOLECULAR BIOLOGY
    • G16B20/00—ICT specially adapted for functional genomics or proteomics, e.g. genotype-phenotype associations
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16B—BIOINFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR GENETIC OR PROTEIN-RELATED DATA PROCESSING IN COMPUTATIONAL MOLECULAR BIOLOGY
    • G16B50/00—ICT programming tools or database systems specially adapted for bioinformatics
    • G16B50/30—Data warehousing; Computing architectures
    • 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/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
    • 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
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16B—BIOINFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR GENETIC OR PROTEIN-RELATED DATA PROCESSING IN COMPUTATIONAL MOLECULAR BIOLOGY
    • G16B40/00—ICT specially adapted for biostatistics; ICT specially adapted for bioinformatics-related machine learning or data mining, e.g. knowledge discovery or pattern finding
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16B—BIOINFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR GENETIC OR PROTEIN-RELATED DATA PROCESSING IN COMPUTATIONAL MOLECULAR BIOLOGY
    • G16B50/00—ICT programming tools or database systems specially adapted for bioinformatics

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Spectroscopy & Molecular Physics (AREA)
  • Public Health (AREA)
  • Biotechnology (AREA)
  • Databases & Information Systems (AREA)
  • Epidemiology (AREA)
  • Evolutionary Biology (AREA)
  • Biophysics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Data Mining & Analysis (AREA)
  • Molecular Biology (AREA)
  • Primary Health Care (AREA)
  • Bioethics (AREA)
  • Biomedical Technology (AREA)
  • Artificial Intelligence (AREA)
  • Software Systems (AREA)
  • Evolutionary Computation (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Pathology (AREA)
  • Signal Processing (AREA)
  • Chemical & Material Sciences (AREA)
  • Analytical Chemistry (AREA)
  • Genetics & Genomics (AREA)
  • Proteomics, Peptides & Aminoacids (AREA)
  • Automatic Analysis And Handling Materials Therefor (AREA)
  • Other Investigation Or Analysis Of Materials By Electrical Means (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)

Abstract

Se describen sistemas y metodos para el analisis de informacion, particularmente informacion obtenida del analisis espectroscopico (o proteomico) de masas de muestras biologicas e informacion asociada de pacientes y de tipo clinico. Los sistemas y metodos de la invencion se pueden usar para una variedad de propositos en el ambito medico, incluyendo identificar e implementar reglas clinicamente relevantes basadas en analisis proteomicos para dar seguimiento al tratamiento y manejo de datos del paciente.

Description

SISTEMA Y MÉTODOS PARA MANEJO DEL TRATAMIENTO Y DATOS DEL PACIENTE CAMPO DE LA INVENCIÓN Las modalidades de la presente invención se refieren a métodos y sistemas para el manejo del tratamiento y datos del paciente así como el análisis.
ANTECEDENTES DE LA. INVENCIÓN En cualquier campo de la medicina, existe un interés siempre presente en la obtención de un diagnóstico de la condición del paciente tan preciso como sea posible. Además existe un interés en establecer el pronóstico médico del paciente e implementar el tratamiento o tratamientos terapéuticos más eficaces, especialmente en aquellos casos en donde está disponible cierta variedad de opciones para el tratamiento (incluyendo la opción de no administrar ninguna terapia) . Con frecuencia, al inicio del tratamiento de una condición en particular, es difícil evaluar cuál es el régimen terapéutico que será más eficaz en un paciente. Los médicos simplemente tienen que intentar el tratamiento con una primera terapia y después implementar una segunda terapia si la primera terapia mencionada no produce la respuesta fisiológica deseada. Además, la condición de enfermedad de un paciente es de naturaleza dinámica; cambia con el tiempo en respuesta al tratamiento y a medida que progresa la patología. Este progreso generalmente se monitorea y en consecuencia se ajusta el tratamiento. Aún así, puede ser difícil determinar el tratamiento terapéutico más eficaz en varias etapas de intervención clínica. Las tendencias modernas en la investigación médica resaltan la importancia de entender las raíces genéticas u otras raíces fisiológicas que intervienen para crear o facilitar el desarrollo de las condiciones de la enfermedad. Los objetivos de esta invención consisten en descubrir por qué dos personas que tienen similitudes en las características intrínsecas (por ejemplo, edad, peso, sexo, estatura, tipo de cuerpo, historia familiar, otros factores genéticos, etc.) así como en las características extrínsecas (por ejemplo, entorno, dieta, nivel de tensión, etc.) pueden tener un grado muy diferente de propensión a desarrollar una condición de enfermedad en particular, o bien, descubrir por qué dos individuos con características similares, y que padecen la misma condición de enfermedad, pueden responder a dicha condición de una manera completamente diferente con el mismo tratamiento terapéutico. Probablemente existe un gran número de factores que influyen para establecer esas diferencias. Pero aun con el creciente entendimiento de algunos de estos factores, actualmente no hay alguna herramienta cuantitativa que pueda predecir la forma en que un paciente (o una condición) responderá al tratamiento. No obstante que están disponibles algunas herramientas de diagnóstico y pronóstico, no existe una lo suficientemente digna de tomarse en cuenta para las características tanto intrínsecas como extrínsecas descritas anteriormente, la amplia disposición de condiciones patológicas que puede confrontar un paciente o la forma en la cual probablemente dichas condiciones cambien tanto con el tiempo como con el tratamiento. Una notoria excepción es la descrita en la solicitud de patente de EE.UU. Serie No. 10/294,270, presentada el 14 de noviembre de 2002. Esta referencia describe sistemas y métodos para diagnosticar y tratar varias condiciones fisiológicas basadas en el análisis comparativo de proteínas encontradas, a manera de ejemplo, en un suero del individuo. Esto se logra realizando el análisis de reconocimiento de patrones y/o sus disciplinas secundarias (por ejemplo, análisis de discriminación, extracción de características, cálculo de error, análisis de grupos o reconocimiento de patrones "estadísticos", e interferencia gramatical y reconocimiento de patrones analizables o "sintácticos") del perfil proteínico del individuo con respecto a, por ejemplo, perfiles de pacientes con una condición de enfermedad similar. Esta referencia también describe el análisis comparativo para otra información del paciente con el fin de optimizar un régimen de tratamiento terapéutico. Esta es una aplicación de proteómicos, el análisis sistemático de las proteínas expresado en un sistema en particular en un punto dado en cierto tiempo para evaluar los cambios dinámicos en el proteoma, tal como aquellos asociados con perturbaciones del sistema interno o externo. El proteoma humano incluye todas las proteínas humanas codificadas por el genoma (en todos sus estados de modificación, por ejemplo, fosforilado, etc.). El proteoma cambia continuamente en respuesta a un vasto conjunto de factores (por ejemplo, eventos internos/externos, enfermedad, fármacos, estados de humor, etc.,), mientras que el genoma permanece relativamente estático y bien definido para un organismo. Un importante obstáculo para implementar la tecnología descrita en la solicitud mencionada anteriormente así como las tecnologías relacionadas que implican el almacenamiento y el análisis comparativo de información clínica del paciente son los requerimientos de un gran procesamiento y almacenamiento de datos para dicho sistema; particularmente cuando dicho sistema se implementa a gran escala. La implementación "a gran escala" puede implicar, por ejemplo, cierto número de instituciones médicas y otras similares, datos obtenidos directamente de múltiples poblaciones de pacientes y/u obtenidos de varios estudios clínicos publicados, y el uso rutinario de la tecnología presente en el consultorio del médico (por ejemplo, vía el Internet u otras formas de comunicación electrónica) . Estos factores sólo son algunos ejemplos de la forma en que la presente tecnología puede expandirse rápidamente más allá de la capacidad práctica de los sistemas de procesamiento de cómputo actualmente disponibles y configuraciones convencionales de la construcción de bases de datos. En resumen, la tecnología puede superar aquella que puede ser soportada y manejada de manera eficiente por los sistemas actuales de cómputo. Además, los sistemas para el manejo y cuidado de pacientes actualmente disponibles utilizan en su mayoría datos no alterados directamente de las pruebas del paciente para llenar las bases de datos subyacentes que contienen la información del paciente. Por lo tanto, uno de los inconvenientes del manejo de datos médicos convencionales es el gran número de formas en que se describen conceptos similares o idénticos; por ejemplo, dos médicos pueden referirse a la ubicación similar de una masa tumoral con descripciones diferentes (por ejemplo, "próximo a" o "cerca del" el hígado de un paciente, se puede hacer referencia una lesión en la pierna como "fracturada" o "rota") . Estas variaciones en los datos presentan un reto para manejar una serie de datos de tal manera que tengan consistencia entre los elementos de datos (es decir, descriptores de datos o metadatos) . La falta de consistencia puede hacer problemático o aun imposible el uso de estos datos para cualquier aplicación automática o computarizada. Actualmente, en la técnica existe el uso de elementos de datos comunes para resolver este problema. Estos elementos de datos comunes se usan como descriptores de metadatos, y en efecto crean un idioma común para describir ciertos metadatos. Sin embargo, el uso de elementos de datos comunes está limitado en su expansión e implementación. A medida que progresa la tecnología médica y se apoya crecientemente en sistemas computarizados y otros sistemas electrónicos para manejar datos de pacientes, con el fin de analizar información clínica y mejorar la precisión del tratamiento de la enfermedad, continuamente surgen oportunidades adicionales para entender mejor la enfermedad y manejar más completamente el cuidado de pacientes. En gran medida, aún se desaprovecha el potencial terapéutico y de diagnóstico asociado con una representación electrónica de un perfil de proteína de suero de un paciente o la capacidad de ofrecer un manejo de pacientes más eficiente mediante el uso de herramientas analíticas computarizadas y esquemas de bases de datos.
BREVE DESCRIPCIÓN DE LAS FIGURAS La Figura 1, ilustra un diseño lógico de la configuración de la base de datos de una modalidad de la presente invención. La Figura 2, ilustra un esquema de redes que ilustra una modalidad de la presente invención. La Figura 3, ilustra un diagrama de bloques de una modalidad de la presente invención, incluyendo un mantenimiento de elementos de datos comunes y sistema de captura de datos electrónico. La Figura 4, ilustra un diagrama de bloques del depósito de elementos de datos comunes de acuerdo con una modalidad de la presente invención. La Figura 5, ilustra un diagrama de bloques de un sistema que incluye el motor de formularios de red informática, de acuerdo con una modalidad de la presente invención. La Figura 6, ilustra un procedimiento que utiliza el motor de formularios de red informática con el fin recopilar datos de pacientes vía la Internet, de acuerdo con una modalidad de la presente invención. La Figura 7, ilustra un diagrama de bloques de un programador de visitas, de acuerdo con una modalidad de la presente invención.
La Figura 8, ilustra un proceso que puede utilizarse para programar las visitas de pacientes en un ensayo clínico y para definir nuevos elementos de datos de acuerdo con una modalidad de la presente invención. La Figura 9, ilustra un fraccionamiento de muestras de suero en relación con el análisis de reconocimiento de patrones, de acuerdo con una modalidad de la presente invención. La Figura 10, ilustra una variación en puntos de lectura m/z a través de un espectro entre espectrómetros de masa, de acuerdo con una modalidad de la invención. La Figura 11, ilustra una configuración de base de datos de una tecnología de análisis de reconocimiento de patrones de acuerdo con una modalidad de la presente invención.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La presente invención se refiere a un sistema y a un método para el manejo de datos y tratamiento de pacientes. Integra una variedad de métodos científicos, dispositivos y protocolos. También admite nuevos medios a través de los cuales se plantean el tratamiento médico, el descubrimiento de fármacos y el análisis de laboratorio a partir de los datos del paciente. En general, la invención puede incluir un sistema de cómputo configurado para almacenar, manipular y analizar datos médicos. Como se apreciará fácilmente por los expertos en la técnica, es vasta la disposición de sistemas de cómputo, herramientas de investigación, bases de datos y otras fuentes de información que se pueden utilizar en relación con los sistemas y métodos de la presente invención para lograr sus objetivos. Casi cada uno del hardware, firmware, software, sistema operativo, plataforma de base de datos, técnica de configuración de redes y otra herramienta de cómputo convencional, puede configurarse para operar en relación con el sistema y los métodos de la presente invención, tal como será apreciado también por los expertos en la técnica. Además, es casi ilimitada la variedad de dispositivos que pueden emplearse en relación con el sistema y métodos. Dichos dispositivos pueden incluir aquellos que se encuentran normalmente en las técnicas tradicionales de cómputo (por ejemplo, sistemas de cómputo, herramientas de red, etc.), en diagnósticos médicos (por ejemplo, formación de imágenes por resonancia magnética, o ?X RI" por sus siglas en inglés, tomografía axial computarizada, o "barrido CAT" por sus siglas en inglés, análisis de suero sanguíneo, etc.), en intervenciones terapéuticas o quirúrgicas, en ambientes de investigación (por ejemplo, salida de espectrometría de masas, secuenciadores de ADN, etc.), entre otros. Por lo tanto, la presente invención se ilustra mediante la consecuente descripción de sus componentes y aspectos particulares que pueden utilizarse en relación con la misma, pero de ninguna manera se pretende que se limite por los dispositivos o sistemas específicos descritos en la presente. En la presente invención, los datos del paciente y/o clínicos pueden mantenerse en una o más bases de datos o depósitos. Estas bases de datos pueden seleccionarse a partir de cualquier tipo de bases de datos conocidos actualmente en la técnica o desarrollados más adelante. A manera de ejemplo, la o las bases de datos pueden seleccionarse a partir de bases de datos de idioma de marcación extendida, o XML por sus siglas en inglés, bases de datos Oracle, bases de datos de Microsoft MySQL o cualquier otra base de datos adecuada. Se pueden configurar bases de datos utilizando un idioma tal como XML o alternativamente pueden configurarse mediante la entrada directa de datos. También es posible el uso de bases de datos orientadas a objeto, y se considera dentro del ámbito de la presente invención. Más adelante se describe una modalidad de una configuración de bases de datos adecuada para usarse en relación con la presente invención y se describe a detalle en la Figura 1. Además, las bases de datos y depósitos de la presente invención pueden almacenarse en sí mismas u otras bases de datos físicas. Si se almacenan las bases de datos y depósitos en la(s) misma (s) base(s) de datos físicas, puede ser posible reducir los costos de administración, aunque hay beneficios para separar las bases de datos y depósitos en diferentes bases de datos físicas. Cualquiera de las bases de datos o depósitos puede dividirse a partir de una sola base de datos física en cualquier momento. El sistema de la presente invención se puede adaptar para su configuración en una red, tal como una Intranet (por ejemplo, red de área local) . Esto puede permitir el acceso a cualesquiera o todas las bases de datos de la invención, por ejemplo, dentro de un hospital o sistema de hospitales. Adicional o alternativamente, puede adaptarse para su configuración en el Internet (por ejemplo, para proporcionar acceso a la base de datos mediante usuarios remotos que pudieran no estar asociados con el propietario de la base de datos) , las terminales remotas pueden tener acceso por este medio a la base de datos. En varias modalidades, los usuarios remotos pueden subscribirse o pagar de alguna manera, para tener dicho acceso a la base de datos o a varios aspectos de la invención.
Depósito de metadatos Como se ilustra en la Figura 1, en una modalidad de la presente invención, el sistema incluye un depósito de metadatos (101) . El depósito de metadatos (101) puede almacenar una gran cantidad de metadatos que pueden interpretarse o analizarse mediante otros componentes en el sistema. Los metadatos almacenados en el depósito de metadatos (101) pueden incluir cualquier tipo de información deseable acerca de un paciente, tratamiento, condición o cualquier otra información que pudiera ser útil en el transcurso del manejo, diagnóstico o tratamiento de pacientes. El depósito de metadatos (101) puede basarse en cualquier tipo de depósito conocido en la técnica. Por ejemplo, pero sin limitación, puede ser un depósito con base en las normas de depósitos ISO/TEC 11179. Además, los metadatos pueden almacenarse en su totalidad en un idioma común o en una combinación de idiomas, dependiendo de la particular configuración del sistema. Por ejemplo, para varias aplicaciones médicas, los metadatos pueden almacenarse en el idioma normal de Nivel de Salud 7 ("HL7", por sus siglas en inglés) o cualquier otro idioma que pudiera ser conveniente para describir el tipo de elementos médicos y clínicos que pudieran ocupar el depósito de metadatos (101) . El uso de un idioma preexistente que pudiera permitir a los usuarios almacenar una gran cantidad de metadatos sin tener que definir cada elemento de datos.
Sin embargo, se puede utilizar un idioma completamente nuevo o diferente para almacenar metadatos en modalidades alternativas de la presente invención. En una modalidad de la presente invención, se pueden definir nuevos elementos para los cuales actualmente no hay un elemento correspondiente definido en el idioma que se está utilizando en el depósito de metadatos (101) para que se trabajen dentro del idioma. Si se adicionan nuevos elementos a un idioma existente, la capacidad del depósito de metadatos (101) para almacenar información importante puede extenderse a una amplia serie de aplicaciones adicionales, como, por ejemplo, en aquellos casos en donde HL7 es el idioma usado en el sistema, los elementos ya están disponibles para un gran número de tipos de datos definidos; por ejemplo, los tipos de datos utilizados comúnmente en el cuidado de pacientes, referencias de pacientes y administración de hospitales . Sin embargo, si un elemento no está disponible para un tipo en particular de datos (por ejemplo, la masa isotópica de una proteína encontrada en el suero de un paciente) , dentro del alcance de la presente invención se crea un nuevo elemento para dichos datos que operan con el idioma HL7. De esta forma, la presente invención no está limitada por algún tipo de información en particular que se pudiera almacenar en su depósito de metadatos (101) .
Más particularmente, los metadatos en el depósito de metadatos (101) pueden incluir cualquier tipo de elemento de datos. Por ejemplo, pueden incluir elementos de datos existentes de otros depósitos, como el depósito del Centro de Bioinformática del Instituto Nacional del Cáncer. El depósito de metadatos (101) también permite el almacenamiento de datos básicos de pacientes y clínicos, tales como, por ejemplo, edad, sexo, tipo de sangre, peso, clasificación de antígeno prostático específico ("PSA", por sus siglas en inglés) , etapa del cáncer, tipo de régimen de tratamiento, hallazgos clínicos encontrados en una visita al consultorio u otro tipo de datos de pacientes o clínicos. En el depósito de metadatos (101), también se puede incluir otro tipo de información, tal como el perfil de proteínas de suero encontrado en una muestra de suero del paciente en un momento en particular y/o los resultados de los análisis comparativos de dicho perfil con otros en el curso de un proceso analítico. Los datos almacenados en el depósito de metadatos (101) pueden organizarse por paciente, fecha de visita al consultorio o de alguna otra manera que pudiera ser adecuada para lograr las metas particulares de una modalidad del sistema de la invención. Los datos pueden incluir resultados de ensayos clínicos u otras pruebas con amplias bases. También pueden incluir datos recopilados de un sistema de registros electrónicos del hospital así como datos obtenidos de ensayos clínicos publicados o bien de cualquier otra fuente. Esencialmente no hay límites para los tipos de datos que pueden incluirse en el depósito de metadatos (101) . La capacidad de almacenamiento del depósito de metadatos (101) puede incrementarse o suplementarse de tal manera que se tomen en cuenta para el desarrollo. El depósito de metadatos (101) además se puede vincular o integrar con cualquier instrumento médico o de investigación de manera que la salida de dicho instrumento se introduce directamente (es decir, vía comunicación electrónica instantánea) o indirectamente (por ejemplo, al descargarse o de alguna manera obtenerse del instrumento o su medio de almacenamiento asociado al depósito de metadatos después de que el instrumento se utiliza en relación con un procedimiento médico o de investigación) en el depósito de metadatos (101) . A manera de ejemplo, los instrumentos médicos que pueden ser particularmente adecuados para usarse en relación con el sistema y métodos de la presente invención, pueden incluir, pero de ninguna manera se está limitado a, espectrómetros de masa, cromatógrafos de gases, instrumentos de electroforesis capilar, equipo de formación de imágenes MRI o CT por sus siglas en inglés, secuenciadores de ADN, herramientas de expresión de genes de disposición microscópica, etc. En una modalidad, los datos no procesados que implican a un paciente en particular se recopilan durante un ensayo clínico, en el curso de un examen físico de rutina con un médico tratante o en cualquier otro momento o de cualquier otra manera y por lo tanto se introducen o capturan en el depósito de metadatos (101) de otra forma (por ejemplo, automáticamente, cuando los datos se generan de un instrumento de investigación) . Los datos se pueden convertir en formato XML. Una vez que se han introducido estos datos no procesados del paciente, puede almacenarse en una base de datos central. Además de la discusión anterior acerca de fuentes de información y dispositivos que se pueden utilizar en relación con el sistema y métodos de la presente invención, también hay métodos para introducir, manipular y editar inicialmente datos que están dentro del campo de acción de la invención. Por ejemplo, se puede utilizar una herramienta de edición para editar el depósito de metadatos. La herramienta de edición puede ser una herramienta de curación de metadatos que se utiliza para buscar y mantener los metadatos. Por ejemplo, la herramienta de curación de metadatos puede usarse para editar o suprimir las entradas incompletas de metadatos. Alternativamente, la herramienta de edición puede ser una herramienta de autoría de formularios que busca los elementos de datos almacenados en el depósito y permite que los autores configuren formularios de elementos de datos comunes. Los formularios entonces pueden reproducirse en papel usando un agente reproductor, tal como el Sistema de Captura de Datos Electrónico INFORM (disponible de Phase Forward, Inc.; Waltham, MA) o cualquier motor de formularios de red informática adecuado. Además, se puede utilizar una herramienta de autoría de formularios para fines de control de calidad. Dicha herramienta puede validar datos o ayuda a definir preguntas para obtener una base de datos precisa. También se pueden introducir datos vía la captura (110) mediante el procesamiento de textos y/o lenguajes. Por ejemplo, se pueden capturar datos directamente en el depósito de metadatos (101) como texto o, inicialmente, un procesador puede convertir el texto o lenguaje en elementos de datos. Se puede utilizar cualquier interfaz de registros médicos electrónicos para capturar datos en relación con una modalidad alternativa de la presente invención. En una modalidad de la presente invención, un motor de formularios de red informática que lee definiciones de formularios generadas por la herramienta de autoría de formularios, se usa para conducir una aplicación de red para la recopilación de datos electrónicos. Esta modalidad se ilustra en mayor detalle en la siguiente sección de Ejemplos, junto con modalidades adicionales de la invención que pueden emplearse para crear y usar formularios .
Base de datos de hechos En otra modalidad, como se describe en la Figura 1, la presente invención puede incluir una base de datos de hechos (102) . La base de datos de hechos (102) puede ser una base de datos aislada, separada, o bien, puede estar integrada con cualquiera de las otras bases de datos de la invención, como se apreciará fácilmente por los expertos en la técnica. La forma específica en la cual se configura la base de datos de hechos (102) con otras bases de datos del sistema así como otros componentes del sistema puede seleccionarse con base en una variedad de factores, tales como, por ejemplo, eficiencia del sistema, capacidad de almacenamiento electrónico, seguridad de la base de datos, costo, facilidad de uso y similares. En general, la base de datos de hechos (102) se incluye en el sistema para promover su eficiencia operativa (por ejemplo, ayudando en la estandarización de datos no procesados contenidos en el depósito de metadatos (101) o impartiendo un esquema organizacional a estos datos no procesados que lo vuelve más fácilmente accesible por otros componentes del sistema y/o programas de software) . La eficiencia operativa puede facilitar significativamente los diferentes procesos analíticos y se pueden llevar a cabo protocolos de aprendizaje de la máquina con respecto a la información almacenada por todo el sistema (es decir, en el depósito de metadatos, la base de datos de hechos, etc.). Esto puede ser particularmente importante en el contexto de la presente invención cuando se aplican sus enseñanzas al campo médico, dado que, como se observó previamente, el sistema tiende a contener una gran cantidad de información y la eficiencia del sistema puede comprometerse, por lo menos parcialmente, sin procedimientos y/o componentes en lugar de dirigirse a este aspecto. Además, hay bastantes medios para hacerlo, pero la base de datos de hechos (102) es una útil herramienta a este respecto. Más específicamente, los hechos incluidos en la base de datos de hechos (102) pueden derivarse de los datos no procesados almacenados en el depósito de metadatos (101) . Como se describió antes con respecto al tipo de información que puede estar contenida en el depósito de metadatos (101) , correspondientemente, los hechos incluidos en la base de datos de hechos (102) pueden representar similarmente un huésped de diferentes tipos de información acerca de un paciente (o una población de pacientes) . Hablando en general, la diferencia más significativa entre los datos no procesados en el depósito de metadatos (101) y los hechos incluidos en la base de datos de hechos (102) es que los hechos pueden interpretarse, compararse y analizarse más fácilmente mediante varios aspectos del sistema de la invención o mediante varias aplicaciones de software externas y programas analíticos que pueden utilizarse en relación con el mismo. Como se apreciará fácilmente por los expertos en la técnica, es amplia la disposición de modificaciones y/o reorganizaciones que pueden implementarse para traducir los datos no procesados en el depósito de metadatos (101) en hechos en la base de datos de hechos (102) . Como tal, se puede implementar cualquier traducción, modificación, reorganización, filtro de información adecuados, u otra operación realizada con respecto a los datos primaros para crear, actualizar o de alguna manera importar información en esta base de datos de hechos (102), ya sea en forma independiente o simultáneamente, en serie o en paralelo, como un evento que se presenta una sola vez o en forma recurrente y/o en cualquier combinación conveniente, en relación con las modalidades alternativas de la presente invención. Por ejemplo, puede existir una necesidad de estandarizar inicialmente los datos no procesados que se recopilan de varios estudios clínicos publicados, los datos que se generan mediante herramientas de investigación (por ejemplo, con sensibilidades variables o unidades de medición) o cualquier otra forma de datos no procesados que pudieran beneficiarse de alguna forma inicial de estandarización antes de los análisis de sistemas más sustantivos . Como se entenderá fácilmente por los expertos en la técnica, prácticamente son ilimitadas las diferentes formas en las cuales los datos no procesados en el depósito de metadatos (101) pueden estandarizarse o manipularse de alguna manera en este contexto para importarlos a la base de datos de hechos (102) . Por lo tanto, cualquier estandarización inicial o procedimiento similar puede ser útil en relación con varias modalidades, puede considerarse dentro del alcance de la presente invención y puede implementarse por los expertos en la técnica sin experimentación inapropiada. En otro ejemplo, puede existir la necesidad de filtrar datos no procesados que se almacenan en el depósito de metadatos (101); por ejemplo, cuando se recopilan continuamente a partir de una herramienta de investigación que se integra al sistema. En una modalidad de la presente invención, el sistema se utiliza en relación con el equipo que obtiene información con respecto a las características de proteínas en una muestra de suero individual. Esto se ilustra más adelante en la sección de Ejemplos. En este aspecto de la invención, el equipo puede integrarse con el sistema de la invención de manera que los datos no procesados recopilados en el transcurso del examen de proteínas se telecargan al depósito de metadatos (101) . Puede haber artículos de información especiales contenidos en los datos no procesados que son importantes para lograr las metas específicas de la modalidad del sistema (por ejemplo, para estudiar una enfermedad en particular que se correlaciona con la presencia de un número finito de proteínas encontradas en el suero) . Como tal, únicamente puede necesitarse una porción de los datos no procesados para el análisis ulterior por el sistema y, por lo tanto, la base de datos de hechos (102), puede configurarse para incluir únicamente aquella información para análisis ulterior. El resto de la información puede permanecer almacenada en el depósito de metadatos (101) como datos no procesados . En otro ejemplo, y de conformidad con aún otra modalidad de la presente invención, los datos no procesados contenidos en el depósito de metadatos (101) se pueden "reorganizar" e importar a la base de datos de hechos (102) ; independientemente de que se lleve a cabo cualquier otra operación (por ejemplo, una operación de estandarización) con respecto a estos datos no procesados.
Por ejemplo, entre los datos no procesados contenidos en el depósito de metadatos (101) , pude haber información del paciente obtenida durante una visita por el paciente al consultorio (por ejemplo, temperatura corporal, presión sanguínea, peso, etc.). Sin que sea relevante alguna diferencia en unidades comunes de medición empleadas en varias partes del mundo (que fácilmente pueden explicarse mediante una operación de estandarización) , por lo menos en los Estados Unidos, la temperatura corporal generalmente se mide en grados Fahrenheit ("°F"), la presión sanguínea se mide en milímetros de mercurio ("mmHg") (es decir, con respecto a la presión sanguínea arterial tanto sistólica como diastólica) y el peso se mide en libras ("lbs") . La reorganización de datos no procesados del depósito de metadatos (101) , simplemente puede implicar la importación de esta información en la base de datos de hechos (102) de tal manera que los datos no procesados se asocian con otro campo de datos, tal como nombre del paciente o un identificador alfanumérico asignado al paciente en el curso de un estudio clínico (por ejemplo, para mantener la confidencialidad del paciente) . Mientras que esta información de alguna manera puede estar asociada al depósito de metadatos (101) , pueden perfilarse en la base de datos de hechos (102) separándola de otra información asociada con este paciente que no pudiera tener uso particular para los procesos analíticos usados por el sistema en una modalidad en particular. Si es conveniente, la información puede volver a asociarse en un punto ulterior obteniendo la misma del depósito de metadatos (101) . Sin embargo, eso podría reducir significativamente el volumen de información en la base de datos de hechos (102) comparado con el depósito de metadatos (101) ; mejorando así la eficiencia del sistema cuando un programa analítico consulta la base de datos de hechos (102) . Como se entenderá fácilmente por los expertos en la técnica, prácticamente son ilimitadas las diferentes formas en las cuales los datos no procesados en el depósito de metadatos (101) se pueden reorganizar, canalizar o, de alguna manera, manipular al importarlos a la base de datos de hechos (102) . Por lo tanto, cualquier reorganización que puede ser útil en relación con varias modalidades, se contempla por estar dentro del alcance de la presente invención y se pueden implementar fácilmente por los expertos en la técnica sin experimentación inapropiada. Como se observó antes, se puede implementar un huésped de operaciones trasladando información del depósito de metadatos (101) a la base de datos de hechos (102) . En otras modalidades de la presente invención, la información puede importarse directamente en la base de datos de hechos (102) sin haber sido introducido primero al depósito de metadatos (101) o puede importarse la información de manera idéntica y directamente tanto al depósito de metadatos (101) como a la base de datos de hechos (102) . Los medios más convenientes y/o apropiados para importar información en el depósito de metadatos (101) y/o la base de datos de hechos (102), puede seleccionarse e implementarse por alguien experto en la técnica para lograr las metas de una modalidad en particular de la presente invención sin experimentación inapropiada. Además, el sistema y métodos de la invención pueden ser completamente operacionales sin la inclusión de bases de datos de hechos; sin embargo, una base de datos de hechos puede hacer posible almacenar datos de pacientes en una base de datos que con frecuencia es más pequeña que el propio depósito de metadatos (101) . Esto puede proporcionar el acceso más fácil y eficiente a los datos sin procesar y a la sustancia real de información alojada en el sistema. En modalidades alternativas de la presente invención, se puede obtener y analizar información (por ejemplo, información del paciente) : (1) directamente como datos no procesados del depósito de metadatos (101) , (2 ) directamente como hechos de la base de datos de hechos (102); o (3) en cualquier combinación como datos no procesados y hechos del depósito de metadatos (101) y la base de datos de hechos (102), respectivamente.
Base de datos de reglas En otra modalidad, como se ilustra en la Figura 1, la presente invención además puede incluir una base de datos de reglas (103) . De manera general, la base de datos de reglas (103) puede "interpretar" información contenida en la base de datos de hechos (102) y/o contenida en el depósito de metadatos (101) . Las reglas incluidas en la base de datos de reglas (103) pueden seleccionarse de una escala de diferentes tipos. Por ejemplo, en el contexto médico, las reglas pueden incluir principios aceptados generalmente con respecto al diagnóstico y tratamiento (por ejemplo, que una clasificación de PSA dentro de la escala numérica particular se correlaciona con cierta probabilidad de un paciente que tiene cáncer de próstata) . En otra modalidad, las reglas en la base de datos de reglas (103) también pueden tomarse en cuenta para la variación entre los datos no procesados contenidos en el depósito de metadatos (101) y/o los hechos contenidos en la base de datos de hechos (102) realizando una operación de estandarización. Por ejemplo, en una modalidad, el depósito de metadatos (101) y/o la base de datos de hechos (102) pueden incluir entrada de información mediante un médico con respecto a su descripción de diagnóstico de una masa tumoral del paciente. Específicamente, un médico puede introducir que el tumor de su paciente está localizado "cerca" de la próstata. Otro médico que diagnostica una condición similar en un paciente diferente puede introducir que el tumor de su paciente está localizado "en seguida" de la próstata. Un tercer médico que diagnostica aún a otro paciente similar puede introducir que el tumor de su paciente se localiza "adyacente a" la próstata. Como se apreciará fácilmente por alguien experto en la técnica de oncología, cada uno de los tres pacientes mencionados antes tiene una condición similar; una masa tumoral en proximidad estrecha con la próstata. Sin embargo, un análisis computarizado de esta información puede que no capte las formas alternativas en las cuales puede describirse esta condición idéntica mediante practicantes médicos. Además, si se evaluara un programa analítico con la rutina de identificar y toma en cuenta primero estas descripciones divergentes antes de cualquier análisis adicional, podría comprometerse la eficiencia de dicho programa analítico. Por lo tanto, en esta modalidad, es un objetivo de la base de datos de las reglas (103) tomar en cuenta la variación sustantiva entre las descripciones de diagnóstico en la información contenida en el depósito de metadatos (101) y/o la base de datos de hechos (102) . Utilizando el ejemplo de los tres pacientes y tres médicos anterior (cada uno de los cuales diagnosticó la misma condición, pero la ha descrito de diferente manera) , una regla en la base de datos de reglas (103) consecuentemente puede reconocer las diferentes descripciones de este diagnóstico y "traducir" la información (es decir, en la que un paciente tiene un tumor localizado "cerca" de su próstata, un segundo paciente tiene un tumor localizado "en seguida" de su próstata y un tercer paciente tiene un tumor localizado "adyacente a" su próstata) . Por ejemplo, para cada uno de estos pacientes, la base de datos de reglas (103) puede indicar que cada uno de los tres pacientes tiene un tumor localizado "adyacente a" su próstata. Con esta descripción idéntica aplicada a cada uno de los tres pacientes, puede ser notoriamente más eficiente para implementar ahora una herramienta analítica que pueda estudiar la información acerca de estos pacientes, dado que se ha estandarizado sustancialmente la discrepancia que resulta de las descripciones particulares de varios médicos de la condición fisiológica idéntica. El tipo de operación de estandarización "inicial" descrita antes con respecto a la base de datos de hechos (102) difiere del tipo de operación de estandarización "sustantiva" que puede implementarse mediante una regla en la base de datos de reglas (103) . Aunque no necesariamente es una distinción brillante entre estos tipos de operaciones, en general, se puede implementar una operación de estandarización "inicial" que pueda implementarse en la base de datos de hechos (102), se podría contabilizar para la variación matemática o numérica entre los datos sin procesar; por ejemplo, la variación en unidades de medición, variación en la sensibilidad de herramientas de investigación o equipo de diagnóstico, variación en el descriptor utilizado para describir el sexo de un paciente (por ejemplo, siendo lo mismo "M" o "masculino") , o similares. Por otro lado, una operación de estandarización "sustantiva" realizada mediante una regla en la base de datos de reglas (103) puede imponer una variación en la información de un paciente de manera que no se "convierta" fácilmente (es decir, se requiere un análisis más crítico para que se estandarice la información) . La base de datos de reglas (103) , puede incluir también "reglas no obligatorias". Las reglas no obligatorias pueden variar conforme a un análisis que se esté llevando a cabo de la información incluida en el sistema (por ejemplo, datos no procesados) , tal como mediante la implementación de "aprendizaje automático", descrito en mayor detalle más adelante. Esto toma lugar más probablemente con el tiempo, a medida que se introduce información adicional al sistema y se lleva a cabo el análisis continuo. Las reglas no obligatorias, adicional o alternativamente, pueden incluir reglas basadas en los resultados de estudios clínicos o aquellos recopilados de los informes en publicaciones escolares. Las reglas no obligatorias también pueden incluir información derivada de investigación llevada a cabo dentro de una organización del usuario del sistema (por ejemplo, un hospital de investigación o compañía farmacéutica) , y/o pueden incluir información de fuentes externas. Las reglas no obligatorias se pueden incluir en la base de datos de reglas (103) o se pueden alojar en una base de datos de reglas no obligatorias separada (no mostrada) . Como se entenderá fácilmente por los expertos en la técnica, "aprendizaje automático" se refiere generalmente a una amplia clase de métodos de probabilidad y estadística para estimar dependencias entre datos y utilizando las dependencias estimadas para hacer predicciones. Puede lograrse mediante algoritmos sencillos que miran a una distribución bidimensional de puntos de datos y crean una regla para definir la distribución. También es posible empezar con una regla, puntos de datos en una gráfica extraídos de la regla y luego buscar los grupos de datos . Si hay un grupo de puntos de datos que existe en un gran margen lejos de otros puntos de datos, probablemente la regla es una buena regla (es decir, una que describe precisamente una característica de los datos) . Si hay un margen pequeño, es menos probable que la regla sea buena. Las mejores reglas dependen generalmente de unos cuantos puntos de muestreo críticos, denominados como "vectores de soporte". Las máquinas de aprendizaje automático que se basan en dichos puntos, comúnmente son denominadas como máquinas de vectores de soporte, pueden cambiar y ajustar el espacio antes de separar los puntos de datos para mejorar más el análisis de reglas. Los algoritmos de aprendizaje automático complejos pueden implicar graficar distribuciones tridimensionales de puntos de datos. Por ejemplo, en el análisis de componentes principales ("PCA", por sus silgas en inglés) , la máquina encuentra las direcciones que explican la mayor parte de las variaciones en los datos. Proyecta todos los datos en estas direcciones "importantes". Luego, esta proyección más pequeña de datos se usa para operar la máquina vectorial sencilla. También es posible cambiar y juntar los datos antes del PCA. Se puede utilizar cualquier forma de algoritmo de aprendizaje automático (por ejemplo, PCA de núcleo, incluyendo, por ejemplo, núcleos polinomiales, función de base gaussiana o radial, redes sigmoides, neurales) , en relación con varias modalidades de la presente invención, como se apreciará e implementará fácilmente por los expertos en la técnica sin experimentación inapropiada. En otra modalidad de la presente invención, los usuarios del sistema de la invención pueden actualizar o registrar sus propias reglas no obligatorias para crear un sistema personalizado. Por ejemplo, un médico en particular puede tratar a sus pacientes de acuerdo con criterios de diagnóstico que no son tomados en cuenta de alguna manera en una modalidad en particular del sistema. Por ejemplo, el sistema puede proveer cierta información basada en correlaciones aceptadas específicamente entre las escalas de clasificación PSA y la probabilidad de tener cáncer de próstata, como se describió antes, mientras un usuario en particular del sistema puede tener una visualización más restrictiva que aquella que generalmente se acepta con base en su experiencia u opinión. Como tal, una regla no obligatoria puede utilizarse con el fin de que se tome en cuenta para el criterio de diagnóstico personal del médico. Además, en varias modalidades de la presente invención, las reglas no obligatorias que se implementan pueden estar limitadas a aquellas seleccionadas por un usuario del sistema. Por ejemplo, el usuario puede elegir aplicar únicamente sus reglas no obligatorias, todas las reglas no obligatorias disponibles o cualquier combinación o permutación de las mismas. Adicionalmente, el sistema puede permitir que otros individuos que no sen usuarios del sistema registren reglas. Este aspecto también dependerá de la preferencia del usuario.
La base de datos de reglas (103) , puede cambiarse y/o actualizarse con el tiempo para tomar en cuenta nuevos desarrollos en conocimientos de enfermedades y tratamientos y similares. Estos cambios se pueden ingresar manualmente vía la entrada (110) o se pueden derivar del aprendizaje automático construido en el sistema. Las reglas, incluyendo las reglas no obligatorias, se pueden asociar con las capacidades y procesos de aprendizaje automático del sistema. La salida de varias bases de datos de reglas (103) puede usarse para cualquier número de propósitos, como se apreciará fácilmente por los expertos en la técnica e implementarse sin experimentación indebida. Como tal, la salida del sistema de la base de datos de reglas (103) puede exportarse a un huésped de componentes o sistemas diferentes, ya sea que estos componentes o sistemas se integren directamente con el sistema de la invención (por ejemplo, con un software integrado adecuado, a través de una conexión de redes, vía Internet) o existe de manera separada del sistema (por ejemplo, requiriendo una exportación de información del sistema y la importación/carga simultánea o subsiguiente al sistema separado) . Por ejemplo, la salida se puede enviar a un motor de formularios para preparar varios formularios, lo cual es una práctica de rutina en el campo médico. La salida se puede usar para aprendizaje automático interno (es decir, por el sistema) para ayudar a generar nuevas reglas y/o para mejorar aquellas que ya están presentes en el sistema (por ejemplo, para definir nuevas normas de cuidados de pacientes o actualizar aquellas que ya están en uso) . La salida también se puede usar para programar citas y/o regímenes de tratamientos para pacientes. Por ejemplo, una regla puede proveer que un paciente con cáncer que se somete a un transcurso en particular del tratamiento deberá recibir dicho tratamiento una vez cada dos semanas durante tres meses (por ejemplo, quimioterapia), y/o puede requerir visitas al consultorio mientras dure el tratamiento. La salida también se puede utilizar por las reglas en la base de datos de procesos (104), descrita más adelante. Además, el sistema puede indicar una "preferencia" para una opción de diagnóstico o tratamiento en particular con base en el aprendizaje automático y otras reglas y análisis usadas de acuerdo con varias modalidades de la presente invención en la base de datos de reglas (103) . A manera de ejemplo, como se describe en la solicitud de patente de EE.UU. serie No. 10/294,270, el sistema puede implementar una técnica de reconocimiento de patrones con respecto a un patrón de proteínas en el suero sanguíneo de un paciente, comparado con los patrones de proteínas identificados en sueros sanguíneos de otros pacientes. Esto puede ser particularmente ventajoso en casos en donde están disponibles cierto número de opciones de tratamiento para un paciente en particular (por ejemplo, la variedad de "cócteles" farmacéuticos prescritos convencionalmente para el tratamiento de VIH/SIDA) . Si el patrón de proteínas en el suero sanguíneo del paciente está correlacionado más estrechamente con pacientes que respondieron satisfactoriamente con un régimen de fármacos normal opuesto a aquellos que respondieron exitosamente a un régimen de fármacos alterno, entonces el sistema puede sugerir que se trate al paciente con el primero en lugar con el último. Otras aplicaciones para esta técnica de reconocimiento de patrones se describen con mayor detalle en la solicitud de patente de EE.UU. serie No. 10/294,270, y el uso de la misma en el contexto de la presente invención se apreciará e implementará fácilmente por los expertos en la técnica sin experimentación inadecuada. La base de datos de reglas (103) es una herramienta flexible y dinámica, la cual puede actualizarse, alterarse y/o suplementarse según sea conveniente para lograr una amplia disposición de tareas . Se apreciará fácilmente por los expertos en la técnica la forma en que puede utilizar más este aspecto de la invención para facilitar el tratamiento y/o diagnóstico de enfermedad o, más generalmente, para mejorar el cuidado y manejo del paciente.
Base de datos de procesos Todavía, en una modalidad adicional, como se ilustra en la Figura 1, la presente invención puede incluir una base de datos de procesos (104) que contiene una disposición de procesos. En varias modalidades de la invención, los procesos pueden describir aspectos particulares derivados de normas para el cuidado del paciente (es decir, protocolos de tratamientos ampliamente aceptados que se utilizan comúnmente por médicos en un campo en particular para tratar/diagnosticar enfermedades en sus pacientes) . Por ejemplo, los procesos específicos pueden indicar que se deberá realizar una prueba en particular a un paciente, o bien, que se deberá prescribir un medicamento en una cantidad/dosis/frecuencia específica. Las metodologías de reconocimiento de patrones descritas en la solicitud de patente de EE.UU. serie No. 10/294,270, también puede ser particularmente útil a este respecto y puede implementarse fácilmente en relación con la base de datos de procesos (104) de la presente invención. La selección de un proceso (o procesos) particular (es) puede depender del resultado de un análisis realizado por el sistema con base en una regla (o reglas) que examina varios hechos y/o datos no procesados. Por ejemplo, los datos no procesados en el depósito de metadatos (101) pueden indicar que un paciente es hombre, de 64 años de edad y tiene un nivel de PSA de 19 ng/ml. Una serie de hechos en la base de datos de hechos (102) puede indicar que el paciente tiene un tumor localizado "adyacente a" su próstata pero no se detectan otras masas tumorales en su cuerpo (por ejemplo, con base en los resultados de un barrido CAT, MRI y/o ultrasonido) . Una regla en la base de datos de reglas (103) , mediante el análisis de estos datos no procesados y hechos, puede indicar que el paciente tiene una alta probabilidad de tener cáncer de próstata en etapa temprana. Con base en los datos no procesados en el depósito de metadatos (101) , los hechos en la base de datos de hechos (102) y la salida de las reglas en la base de datos de reglas (103) , un proceso en la base de datos de procesos (104) puede indicar que el paciente debería iniciar un régimen de tratamiento particular (por ejemplo, terapia de radiación externa, cinco veces por semana durante cuatro semanas) . Como con otros componentes de bases de datos de la presente invención, la base de datos de procesos (104) puede ser una base de datos separada, aislada, o bien, puede integrarse con una o más de las otras bases de datos usadas en relación con varias modalidades de la presente invención con base en los mismos criterios mostrados con respecto a las otras bases de datos del sistema.
EJEMPLOS Los siguientes ejemplos describen una escala de aplicaciones del sistema y métodos de la presente invención, así como un número de componentes que se pueden integrar fácilmente y/o utilizar de alguna manera en relación con la misma. Estos Ejemplos demuestran algunas de las varias configuraciones del sistema de la invención y el impacto potencial que puede tener sobre la práctica convencional de medicina.
EJEMPLO 1 Implementación de análisis de reconocimiento de patrones La presente invención se integra con equipo de diagnóstico que permite la implementación de análisis de reconocimiento de patrones de un perfil de proteínas, tal como un perfil de proteínas de suero, como se describió en la solicitud de patente de EE.UU. serie No. 10/294,270. Se puede obtener una amplia disposición de muestras y utilizarse junto con modalidades alternativas del sistema (por ejemplo, un fluido corporal, tal como sangre, plasma, suero, LCR (fluido espinal) , orina, sudor, saliva, lágrimas, extracción mamaria, fluido de próstata, fluido seminal, defecación, fragmentos cervicales, células, fluido amniótico, fluido intraocular, mucosa, humedad del aliento, tejido animal, lisados celulares, tejido tumoral, cabello, piel, raspados bucales, uñas, médula ósea, cartílago, priones, polvo de hueso, cerilla, etc.). Para obtener muestras para su análisis con el sistema, se deberá someter a un paciente a una prueba de tensión antes de obtener una muestra (por ejemplo, inhalar humo y obtener una muestra de la exhalación, alimentar a un paciente con una dieta en particular antes del cultivo de la muestra) , o bien, las muestras pueden obtenerse del paciente antes y después de la prueba de tensión, de manera que se pueda evaluar el efecto de tensión en el paciente. Además, se puede alterar de alguna manera una muestra después de ser extraída de un paciente (por ejemplo, calentando una muestra, exponiendo una muestra a luz UV, ajustando el pH de una muestra, permitiendo que pase tiempo con la muestra ex vivo antes del análisis) . Un suero de control normal para aplicaciones particulares del sistema es útil en el análisis de datos, aunque no se requiere (por ejemplo, un suero de control puede contener tripsina, una proteasa, una glicosilasa u otro manipulador enzimático para separar las proteínas en una forma predecible antes de su análisis ulterior) . Alternativamente o en adición, se puede usar un láser (por ejemplo, un láser de 25W) para "romper" las proteínas incluidas en la muestra. Una vez que se obtiene la muestra, se prepara para su análisis ulterior. En un protocolo de preparación, las proteínas en la muestra se reducen químicamente (por ejemplo, con ditiotreitol ("dTT")), se desnaturalizan (por ejemplo, con guanadina HCl pH6 o urea), se alquilan (por ejemplo, con yodoacetamida o "IAA") y se separan (por ejemplo, con tripsina) . Una vez digeridas, se puede aplicar un esquema de marcación isotópica; por ejemplo, se puede marcar una muestra de control con una molécula hidrogenada, mientras que una muestra de prueba puede marcarse con una molécula deuterada isotópicamente. Estas muestras isotópicamente marcadas pueden mezclarse antes de su análisis. Si no se incluye control, puede que no sea necesario el marcado: aunque las intensidades resultantes pueden ser menos confiables sin un control para la cuantificación o comparación relativa. Después de la preparación de la muestra, el sistema incluye una fase de cromatografía de líquidos ("LC", por sus siglas en inglés) seguido por espectrometría de masa (es decir, "LC/MS", por sus siglas en inglés) . La fase de espectrometría de masa se realiza usando un Espectrómetro de Masa de Resonancia Ciclotrónica de Iones de Transformación Fourier ("FTICR-MS", por sus siglas en inglés) . La fase de LC puede ser una fase de avance o inversa, y puede tener una o varias dimensiones (por ejemplo, ID, 2D, 3D, etc.) incluyendo técnicas cromatografías de exclusión de tamaños e intercambio iónico. También puede ser LC estándar, LC de alto rendimiento ("HPLC", por sus siglas en inglés) o LC de rápido rendimiento ("FPLC", por sus siglas en inglés); dependiendo de los parámetros del sistema, el carácter de la muestra y el formato deseado de la salida del sistema. En este caso se emplea HPLC de fase inversa. Además, se utiliza ionización de electro-rociado ("ESI", por sus siglas en inglés) en línea con una HPLC en el sistema. Para obtener una mejor resolución del sistema, después de pasar a través de una fuente de ionización ZSPRAY (disponible de Micromass Ltd.; Manchester, RU) , las partículas pasan a través de cuatro polos triples seguido por seis polos antes de entrar al capilar de un FTICR. También se pueden utilizar microfluidos después de la fase de LC y antes de la MS para facilitar la ampliación del sistema, dado que se pueden realizar simultáneamente un mayor número de análisis. Con el fin de superar el cuello de botella del sistema creado por correr muestras a través de un solo imán, en serie, en una versión modificada del sistema, se emplea un aparato de LC/MS bidireccional. Dos células ICR se insertan en un solo imán (es decir, cada una configurada a 180° de la otra, mirando a los extremos opuestos de un imán cilindrico) , y las muestras se introducen independientemente, con respecto a cada célula. Esto duplica la eficiencia del sistema, dado que los datos de dos muestras pueden obtenerse en un imán con dos detectores. Esto puede ser particularmente ventajoso en términos de ampliación del sistema. Alternativamente, se puede utilizar un rociador de ionización de "metralla" para disparar rápidamente diferentes rociados en un solo imán. Todavía, en otro diseño alternativo, las porciones de una muestra son disparadas sobre regiones del centro absoluto del imán o en otras regiones del imán. De esta forma, se pueden analizar simultáneamente varias porciones de una muestra. Por ejemplo, la escala dinámica molecular de escala de radio m/z puede dividirse en unidades arbitrarias, y cada rango unitario puede dispararse en una región diferente del imán (por ejemplo, Rango #1 disparado en la Región #1, Rango #2 disparado en la Región #2, etc.). Mientras que se distorsionan los datos no procesados obtenidos de dicho procedimiento, es predecible dicha distorsión, dado que cada porción de muestra de una escala en particular siempre se dispara en la misma región en el imán. Por lo tanto, la distorsión se contabiliza con una corrección matemática apropiada. A manera de ejemplo, en donde las órbitas son perfectamente elípticas, los datos de señal ciclotrónica se transforman en espectro de masa aplicando funciones elípticas en lugar de las funciones esféricas de la transformación de Fourier básica avanzada. Entre las fases de LC y FTICR, se puede integrar un paso de fraccionamiento en el sistema (denominado como "LC/MS Plus" o "LC/MS+") . En esta versión, y como se describe ilustrativamente en la Figura 9, se incluye un separador de flujos 903 entre las fases de LC 902 y FTICR 904 para recopilar fracciones mediante un colector de fracciones 905 del flujo de muestra fuera de la LC. Debido a que las fracciones obtenidas se correlacionan con el tiempo de retención (por ejemplo, un espectro de masas de interés producido en 34 minutos se correlaciona con la fracción obtenida en 34 minutos), se puede identificar fácilmente una fracción de relevancia considerable. Por lo tanto, esta fracción puede someterse después a análisis adicional. Por ejemplo, las proteínas en una fracción de relevancia puede identificarse por secuenciación de proteínas, un factor (por ejemplo, una etiqueta específica para metales tales como átomos de plata) se puede unir a los azúcares en la fracción de relevancia como un medio para examinar modificaciones después del traslado; se pueden examinar las interacciones de proteína-proteína; o, se puede emplear la espectroscopia Raman para indicar cualquier química en la fracción, tal como la presencia de silicón o moléculas de oro. Un análisis de la muestra fraccionada puede automatizarse, tal como ocurre en paralelo con el análisis de FTICR. Por lo tanto, un pico de interés que se identifica por reconocimiento de patrones puede acoplarse inmediatamente con información adicional acerca de las proteínas específicas y otras moléculas asociadas con dicho pico. Un frasco vial que incluye la muestra fraccionada puede usarse entonces en otras aplicaciones. Por ejemplo, el frasco vial que contiene dicha muestra puede enviarse a una entidad de investigación externa para usarse en el desarrollo de métodos de diagnóstico o terapéuticos (por ejemplo, se identifica cierto número de factores como importantes para cáncer de ovarios, y los frascos de dichos factores obtenidos de un separador de flujos se proporcionan a una compañía farmacéutica para probar y desarrollar fármacos) . En lugar de enviar el frasco vial físico, la información obtenida sometiendo la muestra fraccionada para su prueba adicional, puede acoplarse con los datos de espectrometría de masas y almacenarse en la base de datos del sistema o puede transmitirse a una parte interesada vía, por ejemplo, el Internet. Automatizando el paso de fraccionamiento, se pueden incluir aspectos adicionales en el sistema. Por ejemplo, después de generar datos de FTMS, por sus siglas en inglés, en toda la muestra, el sistema puede realizar análisis adicionales en las proteínas identificadas como, por ejemplo, las cinco más abundantes en la muestra. Otro ejemplo incluye un sistema que elige automáticamente - los péptidos de masas particulares en donde se obtiene cierto espectro (por ejemplo, cuando se obtiene el espectro 122, se analizan los péptidos con masa 100, 250 y 322) . FTMS es un componente primario de este sistema de separación; sin embargo, se puede usar en combinación con una disposición de otras técnicas y sistemas para identificar picos de relevancia para análisis. Como se observó previamente, se puede utilizar HPLC en el sistema. En modalidades alternativas, el sistema puede emplear una doble interacción de espectrometría de masas (es decir, MS/MS) ; puede combinar espectrometría de masas con espectroscopia Raman (es decir, MS-Raman) ; puede incorporar tanto cromatografía de líquidos como espectroscopia Raman con espectrometría de masas (es decir, LC-Raman-MS) ; o puede incluir una doble interacción de cromatografía de líquidos con espectrometría de masas (es decir, LC/LC/MS) . De hecho, se puede utilizar cualquier combinación aleatoria de LC y CM. Se pueden utilizar otras variantes del sistema, dependiendo de la aplicación en particular, la forma de la muestra siendo analizada y los aspectos particulares de análisis de datos que se desean. Por ejemplo, alternativas para FTMS pueden incluir Ionización por Desorción de Láser Asistida por Matriz con Tiempo de Vuelo ("MALDI-TOF", pos sus siglas en inglés) , el Sistema API 3000 de LC/MS/MS (disponible de Applied Biosystems; Foster City, CA) , el Sistema Híbrido QSTAR XL de LC/MS/MS (también disponible de Applied Biosystems) o Q-TOF (disponible de Micromass) . Como una alternativa para LC/MS, se puede implementar una técnica de Ionización por Desorción de Láser con Superficie Mejorada ("SELDI", por sus siglas en inglés) . SELDI es un procedimiento de formación de imágenes moleculares basada en microcircuitos, en el cual se dispersan anticuerpos (es decir, entrelazan) sobre la superficie de placas de acero inoxidable provistas por el fabricante (disponible de Ciphergen Biosystems, Inc.; Fremont, CA) . Las placas de acero inoxidable pueden modificarse de manera que no incluyan anticuerpos sobre su superficie. Esta modificación provee resolución superior más allá de la cual se puede lograr con placas SELDI convencionales. Puede ser particularmente conveniente utilizar placas de acero inoxidable con alguna molécula o combinación de varias moléculas dispersas sobre otras diferentes a los anticuerpos usados en relación con las placas SELDI comercialmente disponibles. En general, los algoritmos de reconocimiento de patrones pueden procesar datos que se introducen en forma de vectores (es decir, una lista de números que siempre tiene la misma longitud) . La lectura de LC/MS estándar conduce por sí misma a la representación de vectores adecuada para el análisis con un algoritmo de reconocimiento de patrones. Sin embargo, se puede usar la propia lectura de LC así como cualquier dato adicional que sea conveniente para una modalidad particular del programa. Los datos clínicos de salida y otra información pueden vincularse con el vector. Un idioma de anotación estandarizado para esta información (por ejemplo, HL7) facilita el análisis de base de datos. Las resoluciones de diferencias entre las lecturas obtenidas de LC/MS (es decir, diferentes números de tramas ya sea del mismo equipo o uno diferente) puede producir "listas" de números que no tienen la misma longitud. Sin embargo, esto no presenta un obstáculo para la representación de vectores y reconocimiento de patrones, dado que los valores de m/z pueden mapearse de trama a trama para que se tome en cuenta cualquier discrepancia con base en la resolución. Además, como se describe ilustrativamente en la Figura 10, los puntos de lectura de m/z reales a través de un espectro pueden diferir entre espectrómetros de masa. Para obtener datos en un conjunto de puntos de lectura estándar, y permitir así la comparación óptima de patrones, los datos que se leen desde puntos de lectura no estándar pueden interpolarse a puntos de lectura estándar (por ejemplo, por estandarización "inicial" de datos no procesados en el sistema) . Esto puede ser particularmente útil cuando los conjuntos de datos de cierto número de recursos usando diferente equipo se introducen en el sistema. La interpolación lineal puede ser suficiente con base en los perfiles de datos intermitentes producidos por LC/MS de proteínas de suero, aunque en otros casos pueden ser eficaces las formas más complejas de interpolación (por ejemplo, interpolación uniforme, interpolación cuadrática, interpolación flexible, pequeñas ondulaciones) . Adicionalmente, se deberá proveer el archivo de calibración del equipo remoto para ayudar a importar datos al sistema. A medida que se conectan datos en la fase de FTMS, se aplica un transformador Fourier y los datos resultantes después se exportan a través de un digitalizador en forma binaria al componente de análisis de datos del sistema (es decir, computadora) . En una versión modificada del sistema, los datos se exportan en forma de ASCII, en lugar de la forma binaria. Los datos exportados en forma binaria son más pequeños de tamaño que los datos de ASCII, y ya están en el formato que generalmente requieren los programas de análisis de datos convencionales. Sin embargo, al grado de que varias aplicaciones de cómputo pueden requerir la entrada de ASCII, el sistema es lo suficientemente versátil para cumplir también con dicho requerimiento. Además, el sistema puede ser modernizado adicionalmente automatizando la exportación de datos a la computadora y usando un digitalizador más rápido (por ejemplo, puede ser suficiente un digitalizador de 14 bits para aplicaciones particulares, pero puede ser ventajoso un digitalizador de 32 bits, 64 bits o más rápido en modalidades alternativas) . Además, la computadora puede reemplazarse con un componente que actúa como cliente a la base de datos del sistema. Realizando esto, se procesan las muestras con FTMS y los datos resultantes se transfieren automáticamente al componente de análisis de datos del sistema, en donde se analiza y almacena, como se trata más adelante en mayor detalle. Adicionalmente se puede incluir una impresora en el sistema, de manera que se puede generar una copia dura de los datos producidos por FTMS antes del análisis y se almacenan en fases subsecuentes del sistema. Esto permite la validación de la fase de FTMS. Como se ilustra en la Figura 11, los datos no procesados (1101) se introducen en el sistema, en cuyo punto se utiliza una forma de filtro rápido en tiempo lineal (1102) para proveer una visualización más útil de los datos. Se pueden incluir operaciones adicionales, tales como extracción pico, asignación de péptidos y proyecciones aleatorias (es decir, un método para comprimir significativamente vectores en una forma tal que conserva la salida de los algoritmos de aprendizaje automático usados en el sistema) (no mostrado) . Estas operaciones proveen diferentes vistas de los vectores y su salida se canaliza a una base de datos que puede ser pública, semipública o privada (por ejemplo, la base de datos de hechos (102) del sistema) . También se pueden crear muestras virtuales en esta etapa para dirigir aspectos tales como error de calibración, variación de errores de intensidad, error de graduación y similares . Esto puede disminuir la confianza en la graduación específica. Los datos no procesados también pueden almacenarse en la base de datos (1103) (por ejemplo, el depósito de metadatos (101) del sistema) . Además del reconocimiento de patrones, o bien, como un substituto del mismo, se puede utilizar cualquier registro de imágenes u objetos (es decir, una forma de reconocimiento de imágenes) para analizar perfiles obtenidos de espectrometría de masa. La desconvolución es un método convencional usado en muchas herramientas comercialmente disponibles para realizar este tipo de análisis, pero en lugar de usar una serie de algoritmos de reconocimiento de imágenes, se puede evitar la desconvolución. Los datos no procesados introducidos al sistema pueden almacenarse en un CD, DVD o biblioteca de cintas magnéticas. Probablemente, los discos no sean un medio de almacenamiento eficiente para un sistema con casi 20 GB de datos para cada muestra. Además, los algoritmos que analizan datos "de manera estrecha" (por ejemplo, un algoritmo de colocación de cintas) , pueden implementarse para dirigir datos no procesados a una ubicación óptima de almacenamiento, de manera que los valores de datos correlacionados entre sí aparecen en el mismo bloque de datos . El almacenamiento automático de datos con base en el conocimiento del dominio puede mejorar significativamente el acceso a los datos y a la eficiencia del sistema. También se puede utilizar un código de corrección de error para dirigirse a lo que se refiere a confiabilidad. También se incluye un sistema de refuerzo para almacenar una segunda copia de los datos no procesados. Después del procesamiento y refuerzo inicial, se implementan algoritmos de aprendizaje automático para identificar grupos de características en los datos que vienen juntos, y que explican variaciones en los datos. Estas características tienen relevancia clínica al grado en que se pueden usar como reglas en la base de datos de reglas (103) del sistema. Las máquinas de vectores de soporte pueden lograr la tarea de identificar grupos de características en los datos que vienen juntos aplicando métodos tales como PCA de núcleo (1107) . Los vectores de soporte pueden formular afirmaciones estadísticas acerca de cualquier vector entrante; no están limitados a proteínas o cualquier otra molécula específica. Para operar vectores de soporte, una matriz de covarianza centralizada (1104) se incluye en el sistema para mantener información acerca de la relación estrecha entre las muestras en la base de datos. La configuración de base de datos incluye por lo tanto, una matriz de covarianza centralizada (1104) con un PCA de núcleo (1106), (1107), adecuada, que opera en la parte superior de la misma, así como una base de datos de covarianza (1105) . Las matrices de covarianza múltiple pueden incluirse en versiones alternativas del sistema (por ejemplo, matrices de covarianza en forma logarítmica, forma semilogarítmica, filtradas, no filtradas) . Una vez que la matriz de covarianza es operacional (sin importar el hecho de que puede actualizarse periódicamente a medida que se generan nuevos datos) , se han identificado las características importantes de los datos (por ejemplo, las reglas) . A medida que se introducen nuevos datos, las características (por ejemplo, las reglas) se extraen en la misma base o en otra base de datos (1108) (por ejemplo, la base de datos de reglas (103) del sistema) , en donde se presenta una visualización de las características de los datos. Por lo tanto, existe una visualización no procesada de los datos (1103) (es decir, el depósito de metadatos (101) ) que se procesa inmediatamente y se obtiene una visualización de las características de los datos (1108) (es decir, que contiene información biológicamente importante) (por ejemplo, en la base de datos de reglas (103) del sistema) . Los datos clínicos suplementales y otra información del paciente pueden incluirse en la base de datos (1103) que incluye los datos no procesados. Los algoritmos de aprendizaje automático operan principalmente desde la visualización de características (por ejemplo, en la base de datos de reglas (103) ) , aunque también puede tener acceso a la visualización no procesada (es decir, el depósito de metadatos (101) ) u otra visualización (por ejemplo, en la base de datos de hechos (102) ) . Los datos pueden reprocesarse periódicamente para extraer nuevas características (por ejemplo, reglas) y producir una nueva característica (o regla) . Las características (por ejemplo, reglas) anteriores, pueden mantenerse de manera que no se alteran los programas que corren sobre las mismas, y para soportar los estudios que han identificado buena información en ellos. Este reprocesamiento puede tener lugar periódicamente como una identificación y extracción de características en lotes estáticos, lo cual crea una versión nueva de la característica. Alternativamente, el reprocesamiento puede ser dinámico. El sistema puede vincularse fácilmente a bases de datos externas incluyendo información pertinente (por ejemplo, Banco de genes, otras bases de datos que contienen información biológica) . Además, las bases de datos que se vuelven públicas o semipúblicas (por ejemplo, para consultar con fines de investigación, para su publicación) , se pueden mantener sobre una plataforma estándar. Como se describió antes, existe una amplia variedad de aplicaciones para esta tecnología. Por ejemplo, puede usarse para predecir el desarrollo de una condición de enfermedad en particular (por ejemplo, la probabilidad de tener un ataque al corazón, desarrollar la enfermedad de Alzheimer o cáncer) ; predecir una respuesta a una alteración del sistema (por ejemplo, cómo responderá un individuo a fumar cigarrillos) ; identificar blancos terapéuticos para el tratamiento de enfermedad (por ejemplo, identificando picos de proteínas relevantes y dirigiendo el tratamiento a los mismos) ; predecir si un individuo responderá a una intervención terapéutica en particular (por ejemplo, seleccionando participantes para un estudio clínico) ; identificar la firma de una salida y preparar un tratamiento, consecuentemente (por ejemplo, un efecto lateral en un estudio clínico) ; identificar individuos para quienes puede ser tóxico un agente terapéutico (por ejemplo, un fármaco para diabetes el cual ocasiona fallas en el hígado en un pequeño porcentaje de pacientes) , seleccionar el estilo más apropiado de dispositivo implantable (por ejemplo, configuración de una cadera o rodilla artificial en particular) ; detectar bacterias (por ejemplo, detección de H. pylori basado en productos encontrados en la humedad del ambiente) ; determinar la actividad enzimática (por ejemplo, comparando con una firma asociada con metaloproteinasa de membrana superior y actividad de calicreína-2 humana) ; probar la presencia de una mutación de genes (por ejemplo, presencia de mutación de BRCAl para predecir cáncer de mama) ; determinar diferencias fisiológicas entre razas y otros grupos (por ejemplo, diferente reacción de individuos japoneses al alcohol comparado con individuos caucásicos); determinar si un individuo tiene una alergia (es decir, sin tener que exponer al individuo al alérgeno) ; en pruebas prenatales (por ejemplo, tamizar para características genéticas) ; en pruebas de inteligencia (por ejemplo, si las proteínas exclusivamente producidas por el cerebro están asociadas con el Cl) ; y optimizar la dosificación con un fármaco en particular. Otra aplicación implica administrar un fármaco a un animal y después definir el patrón proteómico en el animal. Se pueden investigar los picos identificados en dicho análisis en un paciente humano y se puede implementar el análisis de paso alto para determinar si las proteínas blanco están presentes en el ser humano. Esto puede simplificar la identificación de un blanco terapéutico.
EJEMPLO 2 Mantenimiento de elementos de datos comunes y captura electrónica de datos El sistema de la invención puede incluir una característica de mantenimiento de elementos de datos comunes y de captura electrónica de datos. La característica de mantenimiento de elementos de datos comunes y captura electrónica de datos provee un mecanismo para el mantenimiento sencillo, conveniente, y la explotación de un conjunto de datos robusto, tal como, por ejemplo, metadatos. Esto puede ser particularmente ventajoso para instituciones de investigación, incluyendo hospitales, clínicas, universidades y otros para mantener grandes depósitos de datos. La Figura 3 ilustra una modalidad del sistema de mantenimiento de elementos de datos comunes (300) y la captura electrónica de datos de acuerdo con una modalidad de la presente invención. Como se mostrará en la presente, el sistema de mantenimiento de elementos de datos comunes (300) y de captura electrónica de datos incluye una herramienta de autoría de formularios (304), el cual se puede usar para crear nuevos formularios, un agente de conversión (308) para convertir los formularios en varios formatos, procesadores (312) y (314) para ejecutar las instrucciones de la herramienta de autoría de formularios (304) y el agente de conversión (308), una base de datos de procesos (104) para almacenar los formularios creados, y un depósito de elementos de datos comunes ("CDER", por sus siglas en inglés) (310) para almacenar los datos. El CDER (310) puede usarse para recopilar y almacenar datos. El CDER (310) puede proveer un conjunto de preguntas estándar y representaciones de datos que pueden usarse para construir formularios de reportes de casos y se pueden ampliar para incorporar nuevos elementos de datos según sea necesario. Esta característica de capacidad de expansión permite la definición de más elementos de datos estándar y evita tener elementos de datos en el sistema con mismos significados. La Figura 4 ilustra un diagrama de bloques del CDER (310) , de acuerdo con una modalidad de la presente invención. Como se muestra en esta figura, el CDER (310) también puede comprender un depósito de metadatos (101) para almacenar los datos y diversos mecanismos de protección de datos . También se pueden utilizar diversos mecanismos de protección de datos en el CDER (310) para salvaguardar la privacidad del paciente protegiendo los datos del paciente, protegiendo la integridad de los datos y proveer un medio de expedientes para la recuperación de los datos en caso de que ocurriera algún desastre. Como se muestra en la Figura 4, la modalidad ilustrada del CDER (310) incluye mecanismos de protección de datos tales como un sistema de seguridad del depósito (404) para restringir el acceso a la información, un sistema de integridad de datos (408), un sistema de archivo de datos (410), un sistema de respaldo y recuperación (412) y un sistema que contabiliza los depósitos (414) . Se pueden usar otros mecanismos de protección de datos junto con o, en vista de aquellos mostrados en esta modalidad, incluyendo cualesquiera otros mecanismos de protección de datos que se conocen comúnmente en la técnica, tales como, pero de ninguna manera limitado a, barridos de antivirus, espejos de datos, sistemas a prueba de fallas que protegen el acceso a los datos en el caso de que el servidor conectado no pueda comunicarse, aplicaciones de detección independientes o en combinación con una mota para monitorear condiciones externas o internas como la temperatura ambiental, humedad o vibración, y sistemas de energía de emergencia tales como un suministro de energía sin interrupción. El sistema de seguridad del depósito (404) puede incluirse para permitir la restricción de acceso a los datos y los elementos de datos en múltiples niveles. El sistema de seguridad del depósito puede incluir un proceso de autenticación para asegurarse de que el acceso o alteración de los elementos de datos por el usuario sea una fuente confiable. El proceso de autenticación puede incluir cualquier proceso conocido comúnmente en la técnica, incluyendo, pero no limitado a, protección de contraseña, el uso de tarjetas con contraseña, firmas digitales o autenticación biométrica. Un sistema de integridad de datos (408) puede usarse para asegurase más de que se mantenga la confiabilidad de los datos. El sistema de integridad de los datos (408) protege a los datos a los que se puede tener acceso por dos o más usuarios o un solo usuario con múltiples sesiones. El sistema de integridad de datos (408) puede ser cualquier sistema conocido en la técnica, incluyendo, pero no limitado a, bloqueo optimista, bloqueo pesimista, bloqueo en una columna y bloqueo de nivel de aplicación; todos los cuales aseguran la segura edición de datos distribuidos. Por ejemplo, el sistema de integridad de datos (408), puede funcionar de manera que si un usuario actualiza datos mientras otro está trabajando en el mismo, ningún usuario podrá guardar cualesquiera cambios hechos sin revisar y reconocer primero los cambios que realizó el otro usuario. Se puede utilizar el sistema de archivos de datos (410) para asegurarse de que se mantienen todos los datos y que nunca serán borrados. Esta característica permite que un usuario designado (por ejemplo, un administrador del sistema) , "reinicie" los cambios hechos pro los usuarios revirtiendo una versión anterior o que vea el estado de la base de datos en cualquier punto anterior. El sistema de archivos de datos (410) puede implementarse, por ejemplo, haciendo una copia de cualquier archivo que haya sido editado, incrementando la versión asociada con el archivo de datos y guardando la copia en un archivo de datos o recurso de almacenamiento. El sistema de archivo de datos se puede utilizar entonces para almacenar todas las versiones anteriores de los datos. En modalidades alternativas, el sistema de archivo de datos puede implementarse por cualquier otra metodología conocida comúnmente en la técnica. También se puede configurar completamente externa al CDER (310) . El CDER puede incluir además un sistema de contabilidad del depósito (414) . El sistema de contabilización del depósito se puede usar para permitir que los usuarios designados (por ejemplo, un administrador del sistema) , monitoreen el acceso a los datos y rastreen todos los cambios hechos a los mismos. Además, el sistema de contabilidad del depósito (414) puede recopilar y almacenar los datos monitoreados, los cuales se pueden usar entonces para producir un rastreo de auditoria de cualesquiera modificaciones. El sistema de contabilidad del depósito (414) además se puede configurar para limitar o extender la cantidad de información producida en el rastreo de auditoria. El rastreo de auditoria puede incluir, por ejemplo, tal información como el nombre del usuario que hace los cambios, la fecha y hora en que se hicieron dichos cambios y otra información relacionada con la sesión, así como una gráfica de comparación que resume la forma en que se cambiaron los datos. El sistema de contabilización (414) puede implementarse en cualquier manera conocida en la técnica incluyendo, pero no limitado a, el uso de una aplicación de red basada en XQuery. El sistema de respaldo y recuperación (412) también se puede emplear para proveer una medida de seguridad adicional para los datos almacenados en el CDER (310) . Un sistema de respaldo y recuperación permite alta disponibilidad de los datos y provee medios para el expediente y restauración eficaz en costos de los datos en el depósito en el caso de cierto número de eventos catastróficos, incluyendo la falla de hardware o software e infección del sistema con un virus. Además, el CDER (310) puede incluir además un sistema de transferencia de datos (406) , el cual se puede usar para facilitar la transferencia de datos por medio de la importación y exportación. La capacidad de transferencia de datos provee un mecanismo para compartir grandes conjuntos de datos entre, por ejemplo, instituciones de investigación, que puede permitir una explotación más consciente del valioso conjunto de datos y acelera así la investigación para protocolos de tratamiento mejorados. Por ejemplo, una construcción de CDER que usa una base de datos de XML (por ejemplo, Cerisent XQE) puede importar y exportar elementos de datos existentes desde y hacia depósitos de datos, tal como al Centro de Bioinformática del Instituto Nacional de Cáncer.
EJEMPLO 3 Herramienta de formularios Como se ilustra en la Figura 3, se puede usar una herramienta de autoría de formularios (304) en relación con el sistema de la presente invención. Los formularios se usan en la comunidad de salud con una variedad de propósitos, como se apreciará fácilmente por los expertos en la técnica. A manera de ejemplo, se usan formularios para recopilar información del paciente en el curso de un estudio clínico. La herramienta de autoría de formularios (304) provee al diseño del expediente nuevos formularios que pudieran necesitarse, por ejemplo, un ensayo clínico. Además, la herramienta de autoría de formularios (304) puede usarse para buscar elementos de datos almacenados en el CDER (310) que entonces se pudiera seleccionar para usarse en un formulario. Como tal, la herramienta de autoría de formularios (304) provee un diseñador con un medio para construir y editar formularios con los elementos de datos comunes almacenados en CDER (310) . Durante el proceso de edición o diseño, la herramienta de autoría de formularios (304) protege la integridad de los datos y permite que las definiciones de formularios se cambien independientemente del almacenamiento de datos. Como tales, los elementos de formularios se pueden agregar o remover mientras que la aplicación está en uso sin comprometer la integridad de los datos. Una vez que se ha diseñado y/o se ha completado la edición, se genera una definición de formularios que corresponden a la representación gráfica del formulario y entonces puede guardarse en la base de datos de procesos (104) . Desde luego, la definición de formularios puede guardarse alternativamente en una base de datos separada tal como una base de datos de formularios (no mostrada) . El formulario entonces puede convertirse a varios formatos usando un agente de conversión (308) . La Figura 3 también ilustra un agente de conversión (308) incluido en el mantenimiento de elementos de datos comunes y sistema de captura de datos electrónica (300) . El agente de conversión (308) puede usarse por la herramienta de autoría de formularios (304) para facilitar el diseño de nuevos formularios y editar los formularios existentes que se pueden usar para recopilar subgrupos variables de datos de pacientes para múltiples ensayos clínicos. Cuando se diseña un formulario, el agente de conversión (308) lee datos del CDER (310). Entonces se puede usar la herramienta de autoría de formularios (304) para diseñar un formulario. Una vez que se completa el diseño de formularios, el agente de conversión (308) puede usarse para guardar la definición resultante de los formularios en la base de datos de procesos (104) y exhibir el formulario en varios formatos. Por lo tanto, el agente de conversión (308) puede incluir cualquier número de sistemas de captura electrónica de datos, tal como un sistema de Captura Electrónica de Datos PhaseForward INFORM, el motor de formularios de red informática descrito más adelante para la captura electrónica de datos vía el Internet y/o una impresora para convertir a papel el formulario.
Las modalidades alternativas de la presente invención pueden incluir un motor de formularios de red informática. El motor de formularios de red informática se puede usar para recopilar electrónicamente la información del paciente (por ejemplo, historia médica del paciente, actualizaciones de los síntomas que experimenta el paciente, actualizaciones de medicamentos adicionales que pueda estar tomando el paciente, actualizaciones de información de contactos personales, etc.). Como resultado, el motor de formularios de red informática puede reducir el costo y tiempo asociados normalmente con recopilación y entrada de datos manual. Por ejemplo, en una modalidad, cuando un paciente visita el sitio de red, la aplicación genera un idioma de marcación de hipertexto ("HTML", por sus siglas en inglés) con base en una definición abstracta de formulario. Una vez que el paciente ha completado el formulario, se recopilan los datos en el formulario y se almacenan en un formato XML. La Figura 5 describe un diagrama de bloques de un sistema que incluye el motor de formularios de red informática de acuerdo con una modalidad de la presente invención. El motor de formularios de red informática (500) puede usarse para diseñar nuevos formularios útiles en, por ejemplo, la recopilación de subgrupos variables de datos de pacientes para múltiples ensayos clínicos. Cuando se diseña un formulario, el motor de formularios de red informática (500) lee los datos desde el depósito de metadatos (101) . Esto, por ejemplo, permite que el diseñador seleccione entre una variedad de categorías de elementos de datos que pueden usarse en el formulario recién diseñado, tal como la presión sanguínea, ritmo cardíaco, conteo de leucocitos en la sangre, nivel de hemoglobina, etc., del paciente, dependiendo de la naturaleza del ensayo clínico. Una vez que se completa, el motor de formularios de red informática (500) puede usarse para guardar la definición resultante del formulario en la base de datos de procesos (104) . Desde luego, la definición de formularios puede guardarse alternativamente en una base de datos separada tal como una base de datos de formularios (no mostrada) . Además, el motor de formularios de red informática (500) puede usarse para leer definiciones abstractas de formularios y facilitar la recopilación electrónica de datos. Una vez que se ha diseñado un formulario, puede usarse para recopilar datos de pacientes. El motor de formularios (500) recupera la definición de los formularios de la base de datos de procesos (510) . El motor de formularios de red informática (500) entonces puede construir una representación de HTML del formulario con base en su definición de formulario, de manera que el formulario puede publicarse por el servidor de red (506) y se exhibe para una salida vía un usuario (112), que puede ser una computadora, un auxiliar digital personal ("PDA", por sus siglas en inglés) , un teléfono móvil u otro dispositivo similar conectado a la Internet o una Intranet (202) . Sin embargo, alguien experto en la técnica apreciará fácilmente que la forma también puede construirse y representarse usando otros lenguajes, incluyendo XML, SGML, VRML y similares. Para construir el formulario, el motor de formularios de red informática (500) puede usar todo tipo de datos de los elementos de datos comunes para determinar cuáles mecanismos de control serán usados para exhibir los artículos de datos . Dichos mecanismos de control incluyen, pero de ninguna manera están limitados a, botones de radio, menús o listas descendentes y campos de textos. Una vez que se ha exhibido el formulario, un usuario puede introducir los datos solicitados en los campos apropiados usando la entrada (110) (por ejemplo, una computadora, PDA, teléfono móvil, otro dispositivo conectado a la Internet o Intranet (202)) y presenta el formulario cuando se completa. El motor de formularios de red informática (500) recopila los datos de entrada y los almacena en la base de datos de hechos (102) . Las modalidades alternativas del motor de formularios de red informática (500) pueden incluir un sistema de archivo en donde el motor de formularios de red informática (500) asigna un número de versión a cada formulario almacenado en la base de datos de hechos (102) . Cada vez que se almacena un formulario que tiene la misma definición de un formulario existente en la base de datos de hechos (102) , el formulario existente en la base de datos puede cambiarse a un archivo de datos (no mostrado) y la versión más nueva se coloca en su lugar en la base de datos de hechos (102) . Para hacerlo, los investigadores pueden realizar investigación adicional y rastrear varias tendencias en pacientes individuales de un ensayo clínico, que puede dar como resultado el desarrollo de protocolos de tratamiento mejorados. En otras modalidades, el motor de formularios de red informática (500) puede incluir además varias características de seguridad (no mostradas) para proveer protección para los datos personales que el usuario puede proporcionar o exhibirse en un formulario generado por el motor de formularios de red informática. Dichas características de seguridad pueden incluir cualquier proceso de autenticación conocido comúnmente en la técnica, incluyendo, pero de ninguna manera limitado a, protección de contraseñas, el uso de tarjetas con claves, firmas digitales o autenticación biométrica. Además, el motor de formularios de red informática puede incluir cualquier esquema de cifrado de datos comúnmente conocido en la técnica, incluyendo, pero no limitado a, sistemas de cifrado de claves simétricos o sistemas de cifrado de claves públicos tal como firmas digitales, fase de conexión segura ("SSL", por sus siglas en inglés), seguridad de fase de transporte ("TLS", por sus siglas en inglés) o cualquier combinación de los mismos, dependiendo del nivel de seguridad considerado necesario y otras consideraciones fácilmente conocidas por los expertos en la técnica. La Figura 6 ilustra un proceso en el cual una modalidad del motor de formularios de red informática puede usarse para recopilar datos de pacientes vía el Internet. Primero, un usuario puede registrarse en el sitio de red (602) desde una computadora remota y solicitar un formulario (604). Dicho acceso al sitio de red puede lograrse también mediante una computadora local dentro de una clínica o una computadora localizada dentro del Intranet de una clínica. Una vez que se ha solicitado el formulario, el motor de formularios de red informática recupera las definiciones de formularios (608) del depósito y los datos reales correspondientes de la base de datos de hechos y reglas de la base de datos de reglas, permitiendo así respuestas conocidas a los interrogatorios (por ejemplo, nombre, dirección, historia médica previa, estado dentro del protocolo del tratamiento del paciente, etc.) para que sean ocupadas previamente para conveniencia del paciente. El generador de formularios de red informática genera entonces el formulario (610) solicitado, que se exhibe en el formato HTML en la computadora del usuario. El usuario puede completar el formulario (612) introduciendo los datos solicitados en los campos correspondientes. Cuando el usuario ha completado el formulario, los datos se cifran (614) para proveer los datos privados del paciente y se transmiten a un servidor de red dentro de la clínica. Los datos se descifran mediante el servidor de red, el marcador se retira y los datos restantes se almacenan en un archivo de estructura lineal, el cual facilita el almacenamiento de datos en una base de datos de XML. El servidor de red avanza los datos (616) al motor de formularios de red informática, el cual archiva (618) versiones previas de los hechos y almacena la nueva versión en la base de datos de hechos.
EJEMPLO 4 Programador automático de visitas de ensayos clinicos Una modalidad de la presente invención incluye un programador de visitas. El programador de visitas facilita la tarea de programar visitas y procedimientos para realizarse durante las visitas del paciente, por ejemplo, como parte de un ensayo clínico. Normalmente, este proceso se realiza manualmente por miembros del personal en una clínica u hospital, dando como resultado tiempo y gasto considerables. El personal de la clínica debe adecuar a cada paciente en el programa clínico en vista por lo cual con frecuencia pueden presentarse incomodidades por el tiempo tan corto durante la visita de un paciente y la lista de pruebas que deberán aplicarse y los datos reunidos de cuerdo con el protocolo de tratamiento prescrito para cada paciente. La Figura 7 ilustra un diagrama de bloques de una modalidad de la presente invención. Como se ilustra en la presente, un programador de visitas (700) puede tener acceso a la base de datos de procesos (104) para obtener información de programación y reglas para un régimen o protocolo de tratamiento en particular. El programador de visitas (700) tiene acceso a la base de datos de hechos (102) y la base de datos de reglas (103) para determinar el tipo de paciente, el régimen de tratamiento actual del paciente, el estado del paciente dentro del régimen de tratamiento y cualquier otra información apropiada. Esta información entonces se puede usar para decidir cuando se citará de nuevo al paciente. Además, la información puede usarse junto con la base de datos de procesos (104) , la cual puede contener todos los datos que pertenecen a las tareas que serán realizadas durante una visita del paciente. La base de datos de procesos (104) puede identificar además al personal apropiado que deberá notificarse de dichas tareas durante cada visita del paciente dentro de un régimen de tratamiento en particular. El programador de visitas (700) además puede incluir la herramienta de autorización de programas (708), que permite la creación de nuevas definiciones del proceso por la clínica u hospital mientras que se determinan nuevos protocolos de tratamiento. Cuando se define un nuevo proceso, el programador de visitas (700) inicia la herramienta de autoría de programas (708) , el cual puede tener acceso al depósito de metadatos (101) y la base de datos de reglas (103) para definir nuevos metadatos y reglas para clasificar y programar pacientes. La herramienta de autoría de programación (708) almacena entonces las reglas recién definidas en la base de datos de reglas (103) y los metadatos recién definidos en el depósito de metadatos (101) . Sin embargo, la herramienta de autoría de programación (708) también puede elegir reglas existentes para clasificar pacientes. En esta modalidad de la invención, la herramienta de autoría de programación (708) solo escribe datos para la base de datos de procesos (104) . El programador de visitas (700) puede configurarse como una aplicación independiente o puede incluirse dentro de un correo electrónico comercialmente disponible, paquete de software de calendarización o productividad conocido comúnmente en la técnica (por ejemplo, Microsoft OUTLOOK) . El programador de visitas (700) puede construirse también usando cualquiera de entre varios idiomas de programación o una combinación de éstos, como se sabe comúnmente en la técnica (por ejemplo, Visual Basic, Visual C++) . La Figura 8 ilustra un proceso que se puede usar para programar visitas de paciente en un ensayo clínico y para definir nuevos elementos de datos de acuerdo con una modalidad de la presente invención. Primero, un usuario puede iniciar una aplicación de productividad (802) . El usuario puede elegir entonces iniciar el programador de visitas (804) . Una vez que se inició el programador de visitas, el usuario puede definir un nuevo elemento de datos o programar una visita clínica (806) . Sin embargo, se deberá observar que también se pueden lograr otras tareas por el programador de visitas en modalidades alternas de la presente invención, incluyendo, pero no de manera limitada a, la modificación y/o cancelación de programas de visitas. Cuando el usuario elige definir un nuevo elemento de datos (808), el usuario puede definir nuevos metadatos, reglas o procesos. Si el usuario elige introducir nuevos metadatos (810) , todos los datos serán almacenados en el depósito de metadatos (816) ; si el usuario elige introducir nuevas reglas (812), las nuevas reglas serán almacenadas en la base de datos de reglas; y si el usuario opta por introducir un nuevo proceso (814), el nuevo proceso se almacenará en la base de datos de procesos (820) . Alternativamente, cuando el usuario elige programar una visita clínica (822) , los datos del proceso se recuperan (824) de la base de datos de procesos. El usuario introduce entonces los datos del paciente (si el paciente es un paciente nuevo) o recupera datos del paciente (826) (si no es la primera visita del paciente) . Una vez que se han introducido o recuperado los datos del paciente, se recuperan hechos y datos de reglas (828) de los hechos y bases de datos de reglas, respectivamente. Todos los espacios de citas disponibles se determinan (830) de acuerdo con el régimen de tratamiento del paciente y se presentan al usuario. El usuario entonces puede seleccionar uno de los espacios disponibles para crear una cita (832) y calendarizarla . Si el usuario intenta seleccionar una cita que está fuera de la escala aceptable definida por el protocolo de tratamiento del usuario, el programador de visitas alerta al usuario y le pide seleccionar otra cita. Una vez que el usuario realiza una selección, se introducirá la cita en múltiples calendarios, incluyendo, pero de ninguna manera limitado a, el calendario del paciente y el (los) calendario (s) del personal de la clínica apropiado (s) (es decir, aquellos que tendrán que realizar tareas asociadas con la visita del paciente y/o técnicos de laboratorio que necesitarán procesar y analizar especimenes provistos por el paciente) . Además, se pueden distribuir notificaciones (834) a cada una de las partes mencionadas antes. Las notificaciones pueden suministrarse en una miríada de formas incluyendo, pero no limitado a, correo electrónico, fax, páginas de texto o numéricas y mensajes de voz. EJEMPLO 5 Traductor de registros médicos electrónicos Una modalidad de la presente invención incluye un traductor de registros médicos electrónicos. El traductor de registros médicos electrónicos facilita la rápida transformación de registros médicos electrónicos existentes en un "hecho" descrito anteriormente en detalle. El traductor de registros médicos electrónicos puede, por ejemplo, leer los metadatos en el depósito de metadatos (101) junto con las reglas en la base de datos de reglas (103) para determinar la forma en que se traduzcan apropiadamente los metadatos en un hecho. Una vez que se completa la traducción, el hecho resultante puede almacenarse entonces en la base de datos de hechos (102) . Sin embargo, si el registro médico electrónico incluye datos para los cuales no hay regla con la cual se pueden traducir los datos, los datos nunca podrán almacenarse en el depósito de metadatos (101) y marcarse y después revisarse usando una herramienta de edición (por ejemplo, la herramienta de curación de metadatos descrita antes) . Mientras la descripción anterior se refiere a modalidades particulares de la presente invención, se entenderá que se pueden hacer varias modificaciones y variaciones alternativas sin alejarse del espíritu de la misma. Se pretende que las reivindicaciones anexas abarquen dichas modificaciones y variaciones alternativas consideradas dentro del alcance y espíritu real de la presente invención. Por lo tanto, las modalidades descritas en la presente, se consideran en todos los aspectos como ilustrativas y no restrictivas, el alcance de la invención siendo indicado por las reivindicaciones anexas en lugar de la descripción anterior, y por lo tanto, se pretende que todos los cambios dentro del significado y escala de equivalencia de las reivindicaciones sean abarcados en las mismas.

Claims (22)

  1. REIVINDICACIONES : 1. Un sistema, caracterizado porque comprende: una entrada del sistema para recibir una cantidad de datos proteómicos obtenidos del análisis espectrométrico de masa de una muestra biológica; un depósito de metadatos para almacenar una cantidad de metadatos que incluye la cantidad de datos proteómicos; una base de datos de reglas para almacenar por lo menos una regla derivada de un análisis de la cantidad de datos proteómicos; y un procesador para realizar por lo menos una operación o algoritmo para efectuar el análisis de la cantidad de datos proteómicos y derivar así por lo menos una regla.
  2. 2. El sistema según la reivindicación 1, que comprende además una base de datos de hechos para almacenar una cantidad de datos no procesados, almacenar una cantidad de datos importados del depósito de metadatos, o ambos.
  3. 3. El sistema según la reivindicación 2, en donde el procesador se configura para realizar una operación de traducción, modificación, reorganización o filtrado en por lo menos una porción de la cantidad de datos que se importa desde el depósito de metadatos a la base de datos de hechos.
  4. 4. El sistema según la reivindicación 1, que comprende además una base de datos de procesos para almacenar una cantidad de procesos.
  5. 5. El sistema según la reivindicación 4, en donde por lo menos un proceso que se incluye en la cantidad de procesos depende de la salida de un análisis de por lo menos una regla almacenada en la base de datos de las reglas.
  6. 6. El sistema según la reivindicación 2, en donde el procesador se configura para implementar por lo menos un algoritmo de aprendizaje automático para generar por lo menos una regla no obligatoria que se almacena en la base de datos de reglas basada en un análisis de por lo menos una porción de la cantidad de datos proteómicos, por lo menos una porción de la cantidad de metadatos, por lo menos una porción de datos no procesados, por lo menos una regla, o combinaciones de los mismos.
  7. 7. El sistema según la reivindicación 6, en donde por lo menos una regla no obligatoria explica una variación clínicamente relevante en por lo menos una porción de los datos proteómicos.
  8. 8. El sistema según la reivindicación 1, que comprende además una máquina de vectores de soporte que comprende : una matriz de covarianza para mantener información acerca de qué tan estrechas son las relaciones en aspectos de datos proteómicos de las muestras biológicas almacenadas en el depósito de metadatos; y una base de datos de covarianza, en donde el sistema se configura para operar una secuencia de análisis de componentes principales de núcleo en la matriz de covarianza para operar la máquina de vector de soporte.
  9. 9. El sistema según la reivindicación 1, que comprende además una entrada secundaria de sistema para recibir una cantidad de datos de entrada desde una fuente seleccionada del grupo que consiste de un instrumento médico o de investigación, un usuario de sistema, una base de datos externa y combinaciones de los mismos.
  10. 10. El sistema según la reivindicación 1, que comprende además una salida del sistema.
  11. 11. El sistema según la reivindicación 2, en donde la cantidad de metadatos, los datos no procesados, o ambos, incluyen información de pacientes, información clínica, o ambas.
  12. 12. El sistema según la reivindicación 1, que comprende además una herramienta de curación de metadatos para buscar y mantener los metadatos.
  13. 13. El sistema según la reivindicación 4, que comprende además una característica de mantenimiento de elementos de datos comunes y captura de datos electrónicos.
  14. 14. El sistema según la reivindicación 13, en donde la característica de mantenimiento de elementos de datos comunes y captura de datos electrónicos comprende además : una herramienta de autoría de formularios para crear por lo menos un formulario; y un agente de conversión para convertir por lo menos un formulario en varios formatos, en donde el procesador se configura para ejecutar instrucciones de la herramienta de autoría de formularios y el agente de conversión, y por lo menos se almacena un formulario en la base de datos de procesos.
  15. 15. El sistema según la reivindicación 14, en donde la característica de elementos de datos comunes y captura de datos electrónicos comprende además un componente adicional seleccionado del grupo que consiste de un sistema de seguridad de depósito para permitir la restricción de acceso a los metadatos, un recurso de archivo de datos para mantener los metadatos, un sistema de respaldo y recuperación para permitir la restauración de los metadatos en el caso de un evento catastrófico, un sistema de contabilización del depósito para monitorear el acceso y cambios a los metadatos, un sistema de transferencia de datos para facilitar el transporte de datos y combinaciones de los mismos.
  16. 16. El sistema según la reivindicación 10, que comprende además un programador automático de visitas de ensayo clínico para programar visitas y procedimientos que serán llevados a cabo durante una visita del paciente.
  17. 17. El sistema de acuerdo con la reivindicación 2, que comprende además un traductor de registros médicos electrónicos para traducir por lo menos un artículo de metadatos en por lo menos un hecho.
  18. 18. El sistema según la reivindicación 1, en donde dicha muestra biológica se selecciona del grupo que consiste de un fluido corporal, sangre, suero, fluido espinal, orina, sudor, saliva, lágrimas, extracción mamaria, fluido de próstata, fluido seminal, defecación, fragmentos cervicales, células, fluido amniótico, fluido intraocular, mucosa, humedad del aliento, tejido animal, lisados celulares, tejido tumoral, cabello, piel, raspados bucales, uñas, médula ósea, cartílago, priones, polvo de hueso y cerilla.
  19. 19. El sistema según la reivindicación 1, en donde el análisis espectrométrico de masa comprende un análisis espectrométrico de masa de transformación de Fourier.
  20. 20. Un método para identificar una regla que explique una variación clínicamente relevante en datos proteómicos obtenidos de múltiples fuentes, caracterizado porque comprende : proveer un sistema que comprende: una entrada del sistema para recibir una cantidad de datos proteómicos obtenidos de análisis espectrométricos de masa de múltiples muestras biológicas, un depósito de metadatos para almacenar una cantidad de metadatos que incluye la cantidad de datos proteómicos, una base de datos de reglas para almacenar por lo menos una regla derivada de un análisis de la cantidad de datos proteómicos, y un procesador para realizar por lo menos una operación o algoritmo para que se derive por lo menos una regla; realizar por lo menos una operación o algoritmo para analizar por lo menos una porción de la cantidad de datos proteómicos, por lo menos una porción de la cantidad de metadatos, por lo menos una regla, o combinaciones de los mismos; y derivar una regla que explica una variación clínicamente relevante de por lo menos una operación o algoritmo.
  21. 21. El método según la reivindicación 20, en donde por lo menos una operación o algoritmo incluye por lo menos un algoritmo de aprendizaje automático.
  22. 22. El método según la reivindicación 21, en donde el sistema además comprende una máquina de vector de soporte, caracterizado porque comprende: una matriz de covarianza para mantener información acerca de qué tan estrechas son las relaciones en aspectos de por lo menos una porción de la cantidad de datos proteómicos de múltiples muestras biológicas; y una base de datos de covarianza, en donde el método comprende además operar una secuencia de análisis de componentes principales de núcleo en la matriz de covarianza para operar la máquina de vector de soporte.
MXPA06011525A 2004-06-23 2005-06-22 Sistema y metodos para manejo del tratamiento y datos del paciente. MXPA06011525A (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US58221704P 2004-06-23 2004-06-23
PCT/US2005/022736 WO2006002415A1 (en) 2004-06-23 2005-06-22 System and methods for patient data and treatment management

Publications (1)

Publication Number Publication Date
MXPA06011525A true MXPA06011525A (es) 2007-03-21

Family

ID=35782144

Family Applications (1)

Application Number Title Priority Date Filing Date
MXPA06011525A MXPA06011525A (es) 2004-06-23 2005-06-22 Sistema y metodos para manejo del tratamiento y datos del paciente.

Country Status (4)

Country Link
EP (1) EP1763837A1 (es)
AU (1) AU2005258314A1 (es)
MX (1) MXPA06011525A (es)
WO (1) WO2006002415A1 (es)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008011046A2 (en) 2006-07-17 2008-01-24 The H.Lee Moffitt Cancer And Research Institute, Inc. Computer systems and methods for selecting subjects for clinical trials
US8589178B2 (en) * 2008-09-10 2013-11-19 Roche Diagnostics Operations, Inc. Extensible therapy delivery system and method thereof
US10319574B2 (en) 2016-08-22 2019-06-11 Highland Innovations Inc. Categorization data manipulation using a matrix-assisted laser desorption/ionization time-of-flight mass spectrometer
US11862298B1 (en) 2017-09-13 2024-01-02 Verily Life Sciences Llc Artificial neural network model for prediction of mass spectrometry data of peptides or proteins
US10902593B2 (en) * 2018-08-31 2021-01-26 Life Technologies Corporation Methods and apparatus for extended dynamic range from single exposures in capillary electrophoresis
KR102292715B1 (ko) * 2019-03-28 2021-08-23 경상국립대학교산학협력단 인공관절 통합관리 장치 및 어플리케이션

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2837815B2 (ja) * 1994-02-03 1998-12-16 インターナショナル・ビジネス・マシーンズ・コーポレイション 対話型ルール・ベース・コンピュータ・システム
US6277071B1 (en) * 1999-06-25 2001-08-21 Delphi Health Systems, Inc. Chronic disease monitor
US20010037340A1 (en) * 2000-02-07 2001-11-01 Daniel Hawkins System and method for providing medical services and administering medical protocols to individuals based upon biological testing

Also Published As

Publication number Publication date
WO2006002415A1 (en) 2006-01-05
AU2005258314A1 (en) 2006-01-05
EP1763837A1 (en) 2007-03-21

Similar Documents

Publication Publication Date Title
US7187790B2 (en) Data processing and feedback method and system
Hornbrook et al. Building a virtual cancer research organization
US20040122702A1 (en) Medical data processing system and method
US20040122708A1 (en) Medical data analysis method and apparatus incorporating in vitro test data
US20040122787A1 (en) Enhanced computer-assisted medical data processing system and method
US20040122790A1 (en) Computer-assisted data processing system and method incorporating automated learning
US8949079B2 (en) Patient data mining
US20040122703A1 (en) Medical data operating model development system and method
US20040122707A1 (en) Patient-driven medical data processing system and method
US20040122704A1 (en) Integrated medical knowledge base interface system and method
US20030149597A1 (en) System for supporting clinical decision-making
CN110148440A (zh) 一种医疗信息查询方法
WO2007084502A1 (en) Platform for interoperable healthcare data exchange
US7505867B2 (en) System and method for predicting medical condition
CA2459003A1 (en) Method and system for data evaluation, corresponding computer program product, and corresponding computer-readable storage medium
JP2005110944A (ja) 診療支援装置、診療支援方法及び診療支援プログラム
MXPA06011525A (es) Sistema y metodos para manejo del tratamiento y datos del paciente.
KR101295785B1 (ko) 유전변이 데이터 베이스 구축 장치 및 방법
WO2014121128A1 (en) Methods, systems, and computer readable media for exchanging genomic and/or patient information
WO2022244829A1 (ja) 生体情報管理システム、生体情報管理方法、及び生体情報管理プログラム
JP2004348749A (ja) 診療情報システム、診療情報提供システム、診療情報提供方法、診療情報システム、遺伝子解析システム
Yu et al. Data Analysis on Health Management Systems for Improving Doctor's Advice on Patients
McMurry et al. Using routinely collected patient data to support clinical trials research in accountable care organizations
Shraideh et al. Requirements for Transferring Value from proteomics Research to Personalized Medicine: Insights from the current Tool Landscape.
Carus Transforming cancer registry data into an ontology-driven common data model: evaluation of the implementation and integrability of the Observational Medical Outcomes Partnership Model in Clinical Cancer Registry