Mimic-code: Mapeo de conceptos / alias

Creado en 10 jul. 2016  ·  30Comentarios  ·  Fuente: MIT-LCP/mimic-code

Me preguntaba si la gente tenía opiniones sobre la contribución de los datos complementarios. Empecé a intentar analizar los eventos cartográficos y es un poco frustrante descubrir que PaO2 y PaCO2 tienen alrededor de 5 o 6 nombres de elementos diferentes cada uno. Sería particularmente útil si pudiéramos encontrar una forma de asignarles un alias.

Obviamente, preferiría no contaminar el esquema mimiciii y mantenerlo únicamente para los datos MIMIC originales, pero ¿quizás podríamos agregar un esquema contrib para datos como estos? (¿Quizás contribuiii para dejar en claro que va con mimiciii?)

contrib.aliases
alias_id
Apodo

contrib.d_items_aliases
row_id
alias_id (referencias contrib.aliases.alias_id)
itemid (referencias d_items.itemid)

Esto introduce una gran cantidad de problemas potenciales, nuevamente relacionados con el control de versiones de la base de datos: espero poder hacer un primer paso sensato de varias medidas (PaO2, PaCO2, pH, etc.), pero puede llegar un punto en el que otro intensivista pueda cambiar. y decir que en realidad "SpO2 XYZ" no es realmente lo mismo que "SpO2 ABC" y "SpO2".

¿Una posible solución en este caso sería agregar algún tipo de columna de versión a los alias? De modo que si alguien decide hacer su análisis con mis versiones increíblemente defectuosas de alias, todavía puede replicar sus datos o (con suerte) elegir la versión posterior.

Otro tema a considerar con este tipo de esquema es si debería haber un mapeo único de elementos a alias, es decir, ¿podría alguien crear teóricamente una vista que SELECCIONE * FROM chartevents y tachuelas en una columna que represente aliasname? Estoy tentado a argumentar en contra de esto, ya que potencialmente excluiría versiones / otras interpretaciones de alias, etc.

¿Pensamientos?

Comentario más útil

@rustyBilges @ Saqibm128 hemos tomado la iniciativa en esto, dando como resultado el conjunto de datos de referencia descrito en este manuscrito y cuyo código está alojado aquí y mantenido por el laboratorio de YerevaNN .

Estamos muy interesados ​​en que otras personas contribuyan ayudándonos a ampliar y enriquecer el punto de referencia. Si desea participar, diríjase al repositorio de referencia y comience un hilo o envíenos un PR. En particular, aquí hay áreas de necesidad:

  • expandir el mapeo para cubrir variables adicionales
  • agregar tratamientos, medicamentos, entradas al conjunto de datos
  • agregar nuevas tareas de predicción
  • agregar notas clínicas

Todos 30 comentarios

Gracias por iniciar esta conversación Jim.

La consolidación de conceptos es algo sobre lo que hemos hablado bastante, pero que aún no hemos abordado. De hecho, dejamos una columna 'conceptid' vacía en la tabla d_items para que actúe como marcador de posición para los ítems combinados.

@parisni buscará consolidar conceptos como parte de su doctorado y creo que @mghassem conoce a otros que también están trabajando en ello.

Si desea comenzar a fusionar los conceptos de inmediato, una opción sería crear una nueva carpeta en el Repositorio de código MIMIC llamada algo así como "mapas de conceptos", y luego agregar un script SQL para generar una tabla con los ítems asignados a un conjunto de identificadores consolidados.

El control de versiones es un problema que debemos abordar en todo el repositorio, pero creo que agregar una columna de "última actualización" al mapa conceptual sería un buen comienzo.

@jeblundell @tompollard según nuestro intercambio de correo electrónico, también comencé este esfuerzo con la ayuda de mi colaborador Zack Lipton de UCSD y algunas personas del Children's Hospital LA y Stanford. Un resumen de TL; DR de mis comentarios:

  • Zack y yo estamos creando y publicando algunos conjuntos de datos y tareas de series de tiempo multivariantes clínicas de referencia, por así decirlo, el "MNIST" clínico. El primero estará relacionado con la clasificación (es decir, fenotipado). Conozco a otras personas que quieren contribuir a este esfuerzo y utilizar los datos para otros fines.
  • Nuestra intención es NO compartir un conjunto de datos transformado real, o modificar los datos MIMIC3 en sí, sino publicar código (scripts de Python + configuraciones YAML) que cualquier persona con una descarga de MIMIC3 pueda usar para crear el conjunto de datos de referencia. De esta manera podemos realizar un seguimiento adecuado y las revisiones de la versión del punto de referencia.
  • Ya he mapeado ~ 250 ARTÍCULOS de laboratorio y gráfico a variables conceptuales. He compartido el mapa de Google Sheet con ustedes, pero si otros están interesados, hágamelo saber. El mapeo se realizó manualmente y sin mucha participación del médico, pero he manejado principalmente casos obvios, por lo que es probable que sea en su mayoría correcto.
  • Tengo una tubería de Python (escrita apresuradamente) que realiza el mapeo, maneja transformaciones de unidades, maneja casos extremos (por ejemplo, temperaturas que están claramente marcadas como F como C), etc.

Dave

@jeblundell @tompollard con respecto a la contaminación del esquema, el control de versiones, etc .: Me inclinaba por mantener mi esfuerzo SEPARADO de la tienda principal de MIMIC3. Me gustaría que una comunidad de investigadores pudiera ponerse de acuerdo y utilizar un punto de referencia sin imponerlo a todos los demás. Dicho esto, quizás haya una manera de tener nuestro pastel y comérselo también. Tal vez los esfuerzos "externos" para crear asignaciones de tareas específicas puedan seguir adelante como mejor les parezca, pero luego un esfuerzo "interno" sancionado (que podría incluir a algunas de las mismas personas) puede sintetizar la retroalimentación de esos esfuerzos y crear un mapeo canónico que vaya en la propia tienda MIMIC3.

Yo y @nickopotamus ciertamente podemos ayudar desde el punto de vista del médico y parte del trabajo duro de hacer algunas asignaciones.

Estaba planeando enviar una solicitud de extracción con un enfoque provisional y alguna información de @nickopotamus que el equipo podría

@jeblundell feliz de echar un vistazo a lo que tienes. Si tiene una rama o solicitud de extracción # o algo en github, envíelo a mi manera (solo puedo mirar, no hay poder real sobre los repositorios MIMIC).

Algunos pensamientos adicionales:

  • Nuestro marco de trabajo de mapeo colaborativo debe tener una sobrecarga baja y NO debe imponer una cadena de herramientas en particular (Python, SQL, etc.). En particular, el "mapeo" debe almacenarse (o exportarse) en algún formato de archivo simple legible por herramientas ubicuas, en lugar de, digamos, codificado en Python o SQL. A corto plazo, tal vez podamos comenzar con algo como la hoja de cálculo de Google que he creado.
  • Necesitamos asegurarnos de que la colaboración no cree bloqueos para proyectos individuales. Un ejemplo: mapear cosas con nomenclaturas y ontologías conocidas. Esto es increíblemente valioso a largo plazo, pero no es estrictamente necesario, por ejemplo, para crear conjuntos de datos de referencia para la comunidad de ML. Estaríamos satisfechos con el mejor esfuerzo de un experto clínico (o un estudiante graduado motivado armado con Wikipedia) en la identificación de variables y el mapeo de ITEM.

Gracias por la hoja de cálculo, parece que has realizado una gran cantidad de trabajo, ¡así que buen trabajo!

Estoy muy de acuerdo con sus pensamientos sobre: ​​formato simple y neutralidad de la cadena de herramientas. Parece que estamos gravitando hacia CSV tan sencillo como 2 columnas de nombre de concepto y itemid. ¿Qué tiene como esquema general en este momento para generar los datos detrás de esa hoja de cálculo?

Nuestro primer paso es con un alias_id, pero siempre puedo adaptar nuestros scripts SQL de tal manera que el CSV siga siendo útil, es decir, intentaremos que nuestros nombres de alias coincidan con los nombres que tenga en su hoja de cálculo. no tiene que hacer ningún trabajo innecesario (y le informará si necesitamos hacer cambios).

Algunas cosas de la medicina POV:

  • El pH de ABG y VBG podemos _probablemente_ agrupar de forma segura, ya que, aunque hay una diferencia sistemática entre ellos, es lo suficientemente pequeño como para no preocuparnos demasiado por nuestros propósitos. Aunque esa es solo mi opinión :)
  • Aunque todavía no ha hecho la pO2: definitivamente no puede agrupar el O2 arterial y venoso.
  • Agrupar la presión arterial invasiva y no invasiva será bastante problemático, ya que, aunque están correlacionados, la presión arterial no invasiva en particular está un tanto plagada de problemas (tamaño del manguito de presión arterial, posición, automatizado frente a manual, presencia de fibrilación auricular). Sí plantea otra cosa para agregar a la pila de problemas para los mapeos sensibles: en ausencia de una línea de arte, no invasivo es mejor que nada. Sin embargo, en presencia de una línea de arte (completamente funcional), probablemente sea mejor ignorar lo no invasivo. Entonces, realmente debe haber, en algún momento, una forma de decidir si la línea artística está dando lecturas razonables, en cuyo caso abandone el NIBP y simplemente use ABP, de lo contrario use NIBP ya que es una lectura de algún tipo. Por ahora, es mejor separarlos en ABP y NIBP.
  • De manera similar, si un paciente solo tiene un peso para los cálculos de medicamentos, entonces esa es una mejor estimación que nada, pero absolutamente quiero descartarlo si hay un peso real: la razón es que algunas dosis de medicamentos estarán en el peso corporal ideal, que generalmente será mucho más bajo para las personas con un IMC alto.
  • Básicamente, en algún momento (casi con certeza no en nuestro primer paso, ya que hay una gran cantidad de problemas) necesitamos una forma de que las cosas tengan una bandera de prioridad: algo que indique "si nada como esto hoy / este minuto / esta hora / lo que sea, entonces puedes usar esto si es necesario y es básicamente lo mismo "
  • Convenientemente, algunos de los que parece que faltan fueron algunos de los que comencé (FIO2, etCO2, pO2, pCO2, etc.), por lo que con suerte puedo completar los espacios en blanco. De manera similar, me encontré con un problema como el problema de Fahrenheit vs Celcius, donde FIO2 a veces es 0-100 y, a veces, 0-1.

Empezaré a trabajar con

Por cierto, ¿a qué corresponde la media / stdev? Definitivamente es muy sensato buscar valores atípicos locos (¡unidades con mal comportamiento!), ¡Aunque estoy un poco preocupado de que haya un solo paciente con un pH <1!

Gracias @jeblundell por incluirme en este hilo; Tal mapeo parecía una tarea gigantesca para mi propio trabajo usando MIMIC, pero como un novato relativo de SQL, probablemente pueda contribuir más al lado clínico aquí.

Personalmente, manejaría los valores arteriales y venosos de forma independiente; hay diferencias sutiles y no tan sutiles entre los gases venosos, capilares y arteriales centrales y mixtos. Una vez que se identifican como tales, sería sencillo para cualquier aplicación clínica que los trate como equivalentes para luego quitar un valor de pH de los gases disponibles.

Lo mismo se aplica a las mediciones de la presión arterial: marcar NIBP e IBP como variables independientes permite comparaciones entre las dos, lo que puede ser interesante por sí mismo, y sería trivial extraer "una presión arterial" si todos los alias potenciales de IBP y NIBP son conocido.

@turambar , @jeblundell

¡Hola a todos! Esto suena muy similar a algo en lo que he estado buscando comenzar. Y parece que ya ha hecho un buen trabajo. :) ¿Qué tipo de ayuda podría utilizar?

"Trabajo duro" suena como para lo que sería útil en esta etapa. Tengo acceso a Wikipedia, y quizás también a Google ...

Salud,

@aruberutou @nickopotamus si ha preferido cuentas de Google Drive,

@turambar ¡Gracias! Acabo de enviar un correo electrónico a su cuenta listada. Salud,

@turambar @nickopotamus @aruberutou Yo estaría firmemente a favor de que el primer mapeo sean búsquedas de variables simples, y estoy feliz de ser un revisor adicional en mapeos de variables / item_id. Nota al margen: hay una rica literatura sobre el mapeo de señales a ontologías existentes, y puedo pensar en varias personas que estarían muy interesadas en contribuir una vez que el proyecto avance en esa dirección.

Voy a intentar responder por correo electrónico. Procedamos a editar mi
hoja de cálculo. Me agregaron @nickopotamus y @aruberutou como editores. Alguien
cualquier otra persona que desee acceso de edición, hágamelo saber.

Si quieren "desagregar" las variables (presión arterial invasiva y no invasiva, pH,
O2 sat, etc.), hazlo en la columna "NIVEL1". Nosotros preservaremos
mi agrupación (y quizás agrupar otras variables) en la columna "NIVEL2". Si
necesita corregir las cosas que he hecho, adelante.

Intentaré agregar medicamentos, insumos, etc., a esto en el próximo día o dos.

¡Empiece a identificar nuevas variables! Espero que ustedes puedan ayudarme
identificar y priorizar variables de interés, cualquier cosa que agregue para su
El proyecto me interesará. Si necesita un lugar para comenzar, yo
sugerir CO2 espiratorio final y producción de orina, que no he podido
desenredar en MIMIC. Quizás también cualquier cosa relacionada con la ventilación.

Mi flujo de trabajo tiende a utilizar la búsqueda de texto (ya sea navegador o más
Hoja robusta "Buscar" que permite expresiones regulares) para encontrar probables
candidatos. Para una variable en particular ("HR"), busco todos los nombres ("corazón
frecuencia "), variantes (" frecuencia del pulso "), abreviaturas (" HR "), errores ortográficos (" calor
puntuar "), etc. Marco a todos los candidatos (pongo" RRHH "en la columna NIVEL1).
detenerse una vez, los recuentos caen por debajo de un umbral (decenas a cientos, según
cuenta total). Para aquellos candidatos en los que me siento seguro, pongo una "X" en
la columna "USAR". En ese punto, usualmente saco todos los valores para todos
ARTÍCULOS candidatos y observe las distribuciones (percentiles) para tratar de identificar
posibles problemas: valores atípicos, diferentes unidades, etc.
a menudo me armo con alguna información previa usando, por ejemplo, Wikipedia. :-PAGS

Otros dos pasos:

1) Definición de rangos y "normales" para cada variable mapeada. Tengo otro
hoja de cálculo para eso, que compartiré contigo. Lo que hago es definir:

  • dropBelow, dropAbove: un valor por debajo (por encima) del cual es una medida
    claramente inválido y debe desecharse
  • minValue, maxValue: valores mínimos (máximos) permitidos. Cosas
    debajo de minValue (pero no dropBelow) se reemplazan por minValue. Igual por
    maxValue y dropAbove.
  • normal: utilizado para algunos esquemas de imputación

Tenga en cuenta que para mi trabajo, también uso minValue y maxValue para cambiar la escala de todos
valores a [0, 1].

Para su información, crédito a quien corresponde el crédito: la terminología y la estructura de esa hoja de cálculo se debe a David Ledbetter y al equipo de VPICU del Children's Hospital LA.

2) Si encuentro una variable que requiere un manejo especial, como unidad
conversión (especialmente si las unidades son ambiguas o están marcadas erróneamente), yo
solo toma nota. Ahora mismo los manejo como algo único, pero tal vez podamos
sistematizar. Agregaré un documento de Google para esto y agregaré notas sobre el especial
casos que ya encontré, luego compártelo.

Dave

Saludos Dave. Acabo de comenzar a revisar el trabajo que ya ha realizado: ¡una empresa gigantesca!

Se me ocurrieron un par de problemas relacionados con la bilirrubina que valdría la pena aclarar por continuidad y facilidad de referencia:

  • Hay mediciones tanto de la bilirrubina total sérica como de las diversas fracciones (unidas a proteínas y no unidas, conjugadas / directas y no conjugadas / indirectas). Estos no pueden tratarse como equivalentes para el análisis de datos.
  • ¿Tenemos una nomenclatura estándar para diferenciarlos? Si no es así, ¿deberíamos acordar uno antes de procesar demasiado? Empecé a llamarlos, por ejemplo, bilirrubina total, sin embargo, eso no es muy elegante. Nos vendría bien definir un sistema para desglosar subtipos de medidas.
  • De manera similar, también hay mediciones continuas y categóricas (p. Ej., Inmersión en orina) de bilirrubina en otros líquidos (orina, LCR, líquido pleural) que necesitarán un estándar de nomenclatura para su manipulación.
  • Por último, hay muchos elementos de eventos que simplemente registran si se ha enviado una bilirrubina, principalmente desde la unidad neonatal. ¿Tendremos una bandera para estos para indicar que uno de nosotros los ha mirado y ha decidido que no son relevantes?

@nickopotamus gracias! Por cierto, me ha enseñado algo nuevo para Google Sheets (es decir, el uso de scripts y filtros).

re: bilirrubina, es bueno saberlo. Estoy bastante seguro de que cometí errores similares en otros laboratorios, por ejemplo, WBC. Me ENCANTARÍA comprender mejor los diferentes tipos y nuestras opciones para manejarlos (es decir, ¿podemos integrar las partes constituyentes en el total?). Creo que con suficientes datos, mi modelo de elección (redes neuronales) podría aprender funciones para combinarlas o, digamos, estimar la bilirrubina total incluso con algunos constituyentes faltantes. Lo mismo ocurre, por ejemplo, para estimar un "pH verdadero" latente a partir del pH venoso o arterial.

En una nota relacionada, me gustaría comprender los matices de los laboratorios de medición de los diferentes fluidos corporales. Por ejemplo, ¿cuál es la diferencia entre sangre, suero, pleural, ascitis, orina, líquido articular, otro líquido corporal, etc.?

re: nomenclatura, haz lo que creas que es mejor por ahora. Podemos iterar desde allí. Me equivocaría por ser descriptivo. Sé que usé algunas abreviaturas (una convención que adopté por el conjunto de datos Physionet Challenge 2012, que usé como una lista objetivo de variables), pero creo que las voy a cambiar a nombres completos.

re: marcar cosas como "no para ser usadas" sugiero poner una "n" en la columna USE. También cambié "x" por "y". Las entradas en blanco aún no están decididas.

También agregué una columna de NOTA al final para agregar explicaciones.

@turambar Estoy feliz de intercambiar información médica por código en cualquier momento;) Le enviaré un correo electrónico con un poco más sobre la bilirrubina durante el fin de semana ...

Comenzaré a revisar las cosas que ya ha mapeado en ernest la próxima semana antes de comenzar con nuevas variables. ¿Vale la pena que también completemos la bandera FLUID para los ITEMID donde aún no está poblada? Esto evitaría tener nombres como bilirubin-serum y bilirubin-CSF , o todos los distintos fluidos en los que se puede medir el sodio. Esto significaría que tendría que seleccionar "fluido biológico de interés" cuando desee extraer variables; personalmente, creo que eso lo hace más sencillo de manipular, pero me interesaría conocer sus pensamientos sobre cómo funcionaría esto con su código.

DEBE diferenciar bili-serum y bili-CSF. ¡No se pueden mezclar!
Marca R

Absolutamente @rgmark; Supongo que la pregunta que me hago es cuál es la mejor manera de hacer esto. ¿Le damos a cada alias un nombre descriptivo que incluya la medición y el líquido (por ejemplo, 'bilirrubina-suero total' y 'bilirrubina-csf') o proporcionamos un indicador de líquido para cada alias (por ejemplo, nombre = bilirrubina, líquido = sangre y nombre = bilirrubina, fluido = csf)?

utilizar códigos LOINC para todos los laboratorios

@rgmark ese es exactamente el tipo de esquema que estaba buscando, ¡gracias!
@turambar ¿ quizás podamos codificar los alias usando los códigos LOINC, luego usar su script (+/- aspectos de los paquetes LOINC descargables) para encontrar las variables correspondientes de las versiones legibles por humanos?

Hola a todos, perdón por llegar tarde a este juego, pero he estado reflexionando sobre el problema por un tiempo. Lo mejor que se me ocurrió es una estructura de árbol que ayudaría con el alias.

Los problemas descritos anteriormente con respecto a PaO2, NIBP / BP, Bilirrubina ... etc. deberían poder resolverse si anidamos los alias.

Por ejemplo, el nivel superior de PaO2 podría dividirse en PaO2 venosa, PaO2 arterial, PaO2 central, PaO2 pulmonar o, si el investigador desea ignorar por completo las diferencias, puede utilizar el código de nivel superior con los alias "aplanados".

¿Pensamientos sobre este enfoque?

Hola, @ngageorange suena sensato, pero usar un árbol genera cierta confusión en cuanto a en qué punto haces la ramificación (usando el ejemplo de la bilirrubina, ¿ramificas en total / directa / indirecta, o en qué fluido?). Creo que el mejor enfoque es usar códigos LOINC como sugirió @rgmark , lo que permitiría que esos árboles se generen como lo deseen los usuarios o usando los scripts de @turambar . Consulte https://search.loinc.org/ para ver ejemplos.

@rgmark @nickopotamus @ngageorange no hay objeciones al uso de códigos LOINC para laboratorios. No hay razón para reinventar una ontología donde ya existe una, suponiendo que sea fácil de usar. Por supuesto, aprender tal estructura a partir de los datos probablemente funcionaría aún mejor (consulte https://arxiv.org/abs/1602.05568), ¡pero eso es para trabajo futuro!

En serio, desde mi punto de vista, intento no dejar que lo perfecto sea enemigo de lo bueno aquí. Mis colaboradores quieren publicar un conjunto de datos de referencia de tareas lo antes posible, así que tomaré lo que tenemos hasta ahora y lo codificaré en una versión inicial. ¡Pero aceptaré cualquier actualización que puedan hacer en un futuro cercano!

Si alguien en este hilo quisiera una invitación a mi repositorio privado donde estoy desarrollando el código Python para construir conjuntos de datos de referencia, hágamelo saber.

¡Sí, por favor @turambar! Quería ponerme al día con esta conversación ...

Sí, por favor @turambar - ¡Estaría feliz de ayudarte también si todavía estás trabajando en esto!

¿Sigue siendo un área activa? ¿O el esfuerzo de mapeo de itemid ha muerto de alguna manera?

@rustyBilges @ Saqibm128 hemos tomado la iniciativa en esto, dando como resultado el conjunto de datos de referencia descrito en este manuscrito y cuyo código está alojado aquí y mantenido por el laboratorio de YerevaNN .

Estamos muy interesados ​​en que otras personas contribuyan ayudándonos a ampliar y enriquecer el punto de referencia. Si desea participar, diríjase al repositorio de referencia y comience un hilo o envíenos un PR. En particular, aquí hay áreas de necesidad:

  • expandir el mapeo para cubrir variables adicionales
  • agregar tratamientos, medicamentos, entradas al conjunto de datos
  • agregar nuevas tareas de predicción
  • agregar notas clínicas

@turambar ¡Hola! He examinado casi todos los códigos y el papel que mencionaste antes. Y me he estado centrando en la solución de la confusión de la tabla ID_ITEMS, que definitivamente es un trabajo tedioso e importante. ¡Parece que has hecho una gran cantidad de trabajo y un buen trabajo!
Tengo una pregunta sobre el archivo itemid_to_variable_map.csv en https://github.com/YerevaNN/mimic3benchmarks/tree/master/mimic3benchmark/resources , hay casi 370 ITEMID mapeados por lo que sé, así que si este trabajo aún está Continuando, me gustaría contribuir con mi poder.
¡Los mejores deseos!

¿Fue útil esta página
0 / 5 - 0 calificaciones