Mimic-code: Отображение концепций / Псевдонимы

Спасибо, что начал этот разговор, Джим.

Консолидация концепций - это то, что мы довольно много обсуждали, но еще не затронули. На самом деле мы оставили пустой столбец «Conceptid» в таблице d_items, чтобы он служил заполнителем для объединенных идентификаторов элементов.

@parisni будет рассматривать консолидацию концепций в рамках своей докторской степени, и я думаю, что @mghassem знает и других, работающих над этим.

Если вы хотите немедленно приступить к объединению концепций, одним из вариантов было бы создать новую папку в репозитории кода MIMIC, названную чем-то вроде «концептуальные карты», а затем добавить сценарий SQL для создания таблицы с идентификаторами элементов, сопоставленными с набор консолидированных идентификаторов.

Управление версиями - это проблема, которую нам необходимо решить в репозитории, но я думаю, что добавление столбца «последнее обновление» в концептуальную карту было бы хорошим началом.

@jeblundell @tompollard, согласно нашему обмену электронной почтой, я также начал эту работу с помощью моего сотрудника Зака ​​Липтона из UCSD и некоторых людей из Детской больницы Лос-Анджелеса и Стэнфорда. Краткое изложение моих комментариев TL; DR:

• Мы с Заком создаем и публикуем несколько эталонных клинических задач и наборов данных многомерных временных рядов - так сказать, клинического «MNIST». Первый будет связан с классификацией (т.е. фенотипированием). Я знаю некоторых других людей, которые хотят внести свой вклад в эти усилия и использовать данные для других целей.
• Наше намерение состоит в том, чтобы НЕ делиться реальным преобразованным набором данных или изменять сами данные MIMIC3, а скорее публиковать код (скрипты python + конфигурации YAML), который любой, кто загрузил MIMIC3, может использовать для создания набора тестовых данных. Таким образом, мы можем правильно отслеживать и обновлять версии теста.
• Я уже сопоставил ~ 250 лабораторных и диаграммных ЭЛЕМЕНТОВ с концептуальными переменными. Я поделился картографической таблицей Google с вами, ребята, но если другие заинтересуются, дайте мне знать. Картирование было выполнено вручную и без особого участия врача, но я в основном имел дело с очевидными случаями, так что, скорее всего, это в основном правильное.
• У меня есть (наспех написанный) конвейер Python, который выполняет сопоставление, обрабатывает преобразования единиц, обрабатывает крайние случаи (например, температуры, которые четко обозначены F и помечены как C) и т. Д.

Дэйв

@jeblundell @tompollard относительно загрязнения схемы, управления версиями и т.д .: Я склонялся к тому, чтобы мои усилия были ОТДЕЛЬНЫ от основного хранилища MIMIC3. Я бы хотел, чтобы сообщество исследователей могло согласовать и использовать эталонный тест, не навязывая его всем остальным. Тем не менее, возможно, есть способ съесть и свой торт. Возможно, «внешние» усилия по созданию сопоставлений для конкретных задач могут просто продвигаться вперед по своему усмотрению, но тогда санкционированные «внутренние» усилия (которые могут включать некоторых из тех же людей) могут синтезировать обратную связь от этих усилий и создать каноническое сопоставление, которое идет в сам магазин MIMIC3.

Я и @nickopotamus, безусловно, могут помочь с точки зрения врача и некоторой

Я планировал отправить пул-реквест с предварительным подходом и некоторыми комментариями от

@jeblundell рад взглянуть на все, что у вас есть. Если у вас есть ветка или пул-реквест # или что-то еще на github, отправьте его мне (я могу только посмотреть - никакой реальной власти над репозиториями MIMIC).

Некоторые дополнительные мысли:

• Наша структура совместного сопоставления должна иметь низкие накладные расходы и НЕ должна навязывать конкретную цепочку инструментов (python, SQL и т. Д.). В частности, «отображение» следует хранить (или экспортировать) в каком-то простом формате файла, доступном для чтения повсеместными инструментами, а не, скажем, жестко запрограммированным на Python или SQL. В краткосрочной перспективе, возможно, мы сможем начать с чего-то вроде созданной мной таблицы Google (spread).
• Нам нужно убедиться, что совместная работа не создает препятствий для отдельных проектов. Пример: отображение вещей в известные номенклатуры и онтологии. Это невероятно ценно в долгосрочной перспективе, но не является строго необходимым, например, для создания наборов контрольных данных для сообщества машинного обучения. Мы были бы удовлетворены максимальными усилиями клинического эксперта (или мотивированного аспиранта, вооруженного Википедией) в выявлении переменных и отображении ЭЛЕМЕНТОВ.

Спасибо за таблицу - похоже, вы проделали грандиозный объем работы, так что хорошая работа!

Полностью согласен с вашими мыслями относительно простого формата и нейтральности инструментальной цепочки. Похоже, мы тяготеем к CSV так же просто, как 2 столбца с названием концепции и идентификатором элемента. Что у вас есть сейчас в качестве общей схемы для создания данных, лежащих в основе этой электронной таблицы?

Наш первый проход - с alias_id, но я всегда могу адаптировать наши сценарии SQL таким образом, чтобы CSV по-прежнему был полезен, т.е. мы попытаемся сопоставить имя нашего псевдонима с любыми именами, которые есть в вашей электронной таблице, поэтому вам не нужно выполнять ненужную работу (и мы сообщим вам, если нам потребуется внести изменения).

Немногое из медицины POV:

• pH от ABG и VBG мы можем _ вероятно_ безопасно связать вместе, поскольку, хотя между ними существует систематическая разница, она достаточно мала, чтобы не беспокоиться о ней для наших целей. Хотя это только мое мнение :)
• Хотя вы еще не сделали pO2: совершенно определенно нельзя связать артериальный и венозный O2 вместе.
• Объединение инвазивного и неинвазивного артериального давления вместе будет довольно проблематичным, поскольку, хотя они взаимосвязаны, неинвазивный, в частности, несколько чреват проблемами (размер манжеты для измерения артериального давления, положение, автоматическое или ручное, наличие фибрилляции предсердий). Поднимает еще одну вещь, чтобы добавить к куче проблем для разумного сопоставления: в отсутствие арт-линии неинвазивность лучше, чем ничего. Однако при наличии (полностью работающей) арт-линии, наверное, лучше не обращать внимания на неинвазивную. Так что действительно должен быть в какой-то момент способ решить, дает ли арт-линия разумные показания, и в этом случае откажитесь от НИАД и просто используйте АД, в противном случае используйте НИАД, поскольку это какое-то чтение. На данный момент лучше всего разделить на АД и НИАД.
• Точно так же, если у пациента есть вес только для расчета лекарств, то это лучшая оценка, чем ничего, но его абсолютно необходимо списать, если есть реальный вес: причина в том, что некоторые дозы лекарств будут соответствовать идеальной массе тела, которая обычно бывает равной. намного ниже для людей с высоким ИМТ.
• По сути, в какой-то момент (почти наверняка не в нашем первом проходе, поскольку это целый ряд проблем) нам нужен способ, чтобы у вещей был флаг приоритета: что-то, чтобы указать, «если ничего подобного сегодня / в эту минуту / в этот час / что угодно, тогда вы можете использовать это, если необходимо, и в основном это то же самое "
• Удобно, что некоторые из тех, которые вам, кажется, не хватает, были некоторыми из тех, с которых я начал (FIO2, etCO2, pO2, pCO2 и т. Д.), Так что, надеюсь, вы можете заполнить пробелы. Я так же столкнулся с проблемой, как с проблемой Фаренгейта против Цельсия, где FIO2 иногда составляет 0-100, а иногда 0-1.

Я начну работать с @nickopotamus над завершением нашего набора сопоставлений, и затем мы можем попытаться объединить их с вашим, чтобы получить окончательный список первой версии (а затем устранить различные несоответствия между нами). Довольно приятно, что мы эффективно применили стандартный подход> 1 человек к систематическому обзору, чтобы убедиться, что мы должным образом охватываем все основы!

Кстати, чему соответствует среднее значение / stdev? Определенно очень разумно проверять безумные выбросы (неправильно работающие единицы!), Хотя меня немного беспокоит то, что есть хотя бы один пациент с pH <1!

Спасибо @jeblundell за то, что ветку ; такое сопоставление выглядело гигантской задачей для моей собственной работы с использованием MIMIC, но как относительный новичок в SQL я, вероятно, могу внести здесь больший вклад в клиническую сторону.

Лично я бы обрабатывал венозные и артериальные показатели независимо; есть тонкие и не очень тонкие различия между центральными и смешанными венозными, капиллярными и артериальными газами. Как только они будут идентифицированы как таковые, будет легко для любого клинического применения, которое рассматривает их как эквивалент, а затем удалить значение pH из доступных газов.

То же самое относится и к измерениям артериального давления: отметка НИАД и ИДК как независимых переменных позволяет проводить сравнения между ними, что может быть интересно само по себе, и было бы тривиально извлечь «артериальное давление», если бы все потенциальные псевдонимы ИДД и НИАД были известен.

@turambar , @jeblundell

Всем привет! Это звучит очень похоже на то, что я хотел начать. И похоже, что вы уже проделали много хорошей работы. :) Какой помощью вы могли бы воспользоваться?

«Черновая работа» звучит как то, чем я был бы полезен на данном этапе. У меня есть доступ к Википедии и, возможно, также к Google ...

Ваше здоровье,

@aruberutou @nickopotamus, если вы предпочитаете учетные записи Google Диска, отправьте их мне, и я предоставлю вам доступ к своей электронной таблице.

@turambar Спасибо! Я только что отправил электронное письмо на указанный вами аккаунт. Ваше здоровье,

@turambar @nickopotamus @aruberutou Я бы решительно поддержал то, чтобы первое сопоставление было простым поиском переменных, и я счастлив быть дополнительным обозревателем сопоставлений переменных / item_id. Замечание: существует обширная литература по сопоставлению сигналов с существующими онтологиями, и я могу вспомнить нескольких человек, которые были бы очень заинтересованы внести свой вклад, когда проект пойдет в этом направлении.

Я попробую ответить по электронной почте. Приступим к редактированию моего
электронная таблица. Я добавлен в качестве редакторов @nickopotamus и @aruberutou . Кто-нибудь
если кто-то хочет получить доступ к редактированию, дайте мне знать.

Если вы, ребята, хотите разделить переменные (инвазивное и неинвазивное АД, pH,
О2 сел и т. Д.), Сделайте это в графе «УРОВЕНЬ1». Мы сохраним
моя комплектация (и, возможно, связка других переменных) в столбце «УРОВЕНЬ2». Если
вам нужно исправить то, что я сделал, вперед.

Я постараюсь добавить к этому лекарства, средства и т. Д. В ближайшие день или два.

Пожалуйста, начните определять новые переменные! Я надеюсь, что вы, ребята, сможете мне помочь
определять и расставлять приоритеты интересующих переменных - все, что вы добавляете для своего
проект будет мне интересен. Если вам нужно с чего начать, я бы
предложить CO2 в конце выдоха и диурез, что я не смог
распутать в MIMIC. Возможно также что-нибудь, связанное с вентиляцией.

Мой рабочий процесс, как правило, заключается в использовании текстового поиска (в браузере или тем более
надежный лист "Найти", который позволяет регулярным выражениям) находить вероятные
кандидаты. Для конкретной переменной («ЧСС») я ищу все имена («сердце»
скорость »), варианты (« частота пульса »), сокращения (« ЧСС »), орфографические ошибки (« тепло
рейтинг ") и т. д. Я отмечаю всех кандидатов (ставлю" HR "в столбец LEVEL1). Я стараюсь
остановить, когда счетчики упадут ниже порогового значения (от десятков до сотен, в зависимости от
общее количество). Для тех кандидатов, в которых я уверен, я ставлю крестик.
столбец «ИСПОЛЬЗОВАНИЕ». В этот момент я обычно вытаскиваю все значения для всех
кандидаты ЭЛЕМЕНТЫ и посмотрите на распределения (процентили), чтобы попытаться определить
возможные проблемы: выбросы, разные единицы измерения и т. д. Как не-MD, я
часто вооружаюсь некоторой предварительной информацией, используя, например, Википедию. :-П

Два других шага:

1) Определение диапазонов и «нормального» для каждой отображаемой переменной. у меня есть другой
таблица для этого, которой я поделюсь с вами. Что я делаю, так это определяю:

• dropBelow, dropAbove: значение ниже (выше), которое измеряется
  явно недействительный и должен быть выброшен
• minValue, maxValue: минимальные (максимальные) допустимые значения. Вещи
  ниже minValue (но не dropBelow) заменяются на minValue. То же самое для
  maxValue и dropAbove.
• нормальный: используется в некоторых схемах вменения

Обратите внимание, что в своей работе я также использую minValue и maxValue для масштабирования всех
значения к [0, 1].

К вашему сведению, кредит, если он причитается: терминология и структура этой таблицы принадлежат Дэвиду Ледбеттеру и его сотрудникам из отделения интенсивной терапии новорожденных Детской больницы Лос-Анджелеса.

2) Если я найду переменную, требующую особой обработки, например unit
преобразование (особенно, если единицы неоднозначны или ошибочно помечены), I
просто сделайте заметку. Прямо сейчас я обращаюсь с ними как с единичными, но, может быть, мы сможем
систематизировать. Я добавлю для этого Google Doc и добавлю заметки о специальных
кейсы я уже нашел, тогда поделитесь.

Дэйв

Ура, Дэйв. Я только начал просматривать уже проделанную вами работу - грандиозное предприятие!

При рассмотрении билирубина я столкнулся с несколькими проблемами, которые, возможно, стоит прояснить для непрерывности и простоты справки:

• Существуют измерения как общего билирубина в сыворотке, так и различных фракций (связанных и несвязанных с белками, конъюгированных / прямых и неконъюгированных / непрямых). Их нельзя рассматривать как эквивалент для анализа данных.
• Есть ли у нас стандартная номенклатура для их различения? Если нет, должны ли мы договориться об одном, прежде чем выполнять слишком большую обработку? Я начал называть их, например, билирубин-тотальный, но это не очень элегантно. Мы могли бы определить систему для разделения подтипов измерений.
• Точно так же существуют как непрерывные, так и категориальные (например, погружение в мочу) измерения билирубина в других жидкостях (моча, спинномозговая жидкость, плевральная жидкость), для которых потребуется стандарт наименования.
• И, наконец, есть множество элементов диаграммы событий, которые просто регистрируют, был ли отправлен билирубин, в основном из неонатального отделения. Должен ли мы иметь для них отметку, указывающую на то, что кто-то из нас посмотрел на них и решил, что они не имеют отношения к делу?

@nickopotamus спасибо! Кстати, вы научили меня чему-то новому для Google Таблиц (например, использованию скриптов и фильтров).

re: билирубин, полезно знать. Я почти уверен, что делал аналогичные ошибки в других лабораториях, например, в WBC. Будет ли LOVE лучше понимать различные типы и наши варианты обращения с ними (например, можем ли мы объединить составные части в единое целое?). Я думаю, что при наличии достаточного количества данных моя выбранная модель (нейронные сети) могла бы изучить функции для их комбинирования или, скажем, оценки общего билирубина даже при отсутствии некоторых составляющих. То же самое, скажем, для оценки скрытого «истинного pH» только на основе pH венозной или артериальной крови.

В связи с этим я хотел бы понять нюансы лабораторных измерений различных жидкостей организма. Например, в чем разница между кровью, сывороткой, плеврой, асцитом, мочой, суставной жидкостью, другой жидкостью организма и т. Д.

re: nomenclature, делайте то, что считаете лучшим на данный момент. Мы можем выполнять итерацию оттуда. Я бы ошибся в описании. Я знаю, что использовал некоторые сокращения (соглашение, которое я принял в наборе данных Physionet Challenge 2012, который я использовал в качестве целевого списка переменных), но я думаю, что я собираюсь заменить их на полные имена.

re: помечая вещи как «не предназначенные для использования», я предлагаю поставить «n» в столбце USE. Я также изменил «x» на «y». Пустые записи еще не решены.

Я также добавил столбец ПРИМЕЧАНИЕ в конце для добавления пояснений.

@turambar Я счастлив обменять медицинскую информацию на код в любое время;) Я пришлю вам электронное письмо с более подробной информацией о билирубине на выходных ...

На следующей неделе я начну рассматривать то, что вы уже нанесли на карту в ernest, прежде чем приступить к новым переменным. Стоит ли нам также заполнять флаг FLUID для ITEMID, где он еще не заполнен? Это предотвратит появление таких имен, как bilirubin-serum и bilirubin-CSF , или всех различных жидкостей, в которых можно измерить натрий? Это означало бы, что вам нужно было бы выбрать «интересующую биологическую жидкость», когда вы хотите извлечь переменные; лично я думаю, что это упрощает манипулирование, но мне было бы интересно узнать, как это будет работать с вашим кодом?

Вы ДОЛЖНЫ различать били-сыворотку и били-КСФ. Их нельзя перепутать!
R Марк

Совершенно верно @rgmark; Полагаю, я задаю вопрос, как лучше всего это сделать. Даем ли мы каждому псевдониму описательное имя, включая измерение и жидкость (например, «билирубин-общий-сыворотка» и «билирубин-CSF»), или мы предоставляем флаг жидкости для каждого псевдонима (например, имя = билирубин, жидкость = кровь и имя = билирубин, жидкость = CSF)?

используйте коды LOINC для всех лабораторий

@rgmark , это именно та схема, которую я искал - спасибо!
@turambar, возможно, мы сможем закодировать псевдонимы, используя коды LOINC, а затем использовать ваш сценарий (+/- аспекты загружаемых пакетов LOINC), чтобы найти соответствующие переменные из версий, удобочитаемых человеком?

Привет всем, извините, что опоздали в эту игру, но я уже давно обдумывал проблему. Лучшее, что я мог придумать, - это древовидная структура, которая поможет с псевдонимом.

Вышеуказанные проблемы в отношении PaO2, НИАД / АД, билирубина и т. Д. Должны быть решены, если мы вложим псевдонимы.

Например, верхний уровень для PaO2 может разделиться на венозный PaO2, артериальный PaO2, центральный PaO2, легочный PaO2 или, если исследователь хочет полностью игнорировать различия, он может просто использовать код верхнего уровня с псевдонимами «сглаженными».

Мысли об этом подходе?

Привет, @ngageorange звучит разумно, но использование дерева вызывает некоторую путаницу относительно того, в какой точке вы выполняете ветвление (используя пример билирубина, вы ветвитесь полностью / прямо / косвенно или с какой жидкостью?). Я думаю, что наилучшим подходом является использование кодов LOINC, предложенных @rgmark , которые затем позволяют создавать такие деревья по желанию пользователей или с использованием сценариев @turambar . См. Примеры на https://search.loinc.org/ .

@rgmark @nickopotamus @ngageorange не

Если серьезно, то с моей точки зрения, я стараюсь не позволять идеальному быть врагом хорошего. Мои сотрудники хотят как можно скорее выпустить набор данных для эталонных тестов, поэтому я собираюсь взять то, что у нас есть, и систематизировать его в начальной версии. Но я приму любые обновления, которые вы, ребята, можете сделать в ближайшем будущем!

Если кто-то в этой ветке захочет получить приглашение в мой частный репозиторий, где я разрабатываю код Python для создания наборов данных тестов, дайте мне знать.

Да, пожалуйста, @turambar! Я как раз хотел продолжить этот разговор ...

Да, пожалуйста, @turambar - я буду рад помочь, если вы все еще работаете над этим!

Это все еще активная область? Или работа по отображению идентификаторов элементов в какой-то мере умерла?

@rustyBilges @ Saqibm128 мы взяли на себя инициативу по этому поводу, в результате чего был этой рукописи , код которого размещен здесь и поддерживается лабораторией YerevaNN .

Мы очень заинтересованы в том, чтобы другие люди вносили свой вклад, помогая нам расширять и обогащать эталонный тест. Если вы хотите принять участие, зайдите в репозиторий тестов и начните обсуждение или отправьте нам PR. В частности, здесь есть потребности:

• развернуть отображение, чтобы охватить дополнительные переменные
• добавить лечение, лекарства, входные данные в набор данных
• добавить новые задачи прогнозирования
• добавить клинические заметки

@turambar Привет! Я просмотрел почти все коды и статьи, о которых вы упоминали ранее. И я сосредоточился на решении путаницы с таблицей ID_ITEMS, что, безусловно, является утомительной и важной работой. Так что, похоже, вы проделали большой объем работы и хорошо поработали!
У меня есть вопрос о файле itemid_to_variable_map.csv в https://github.com/YerevaNN/mimic3benchmarks/tree/master/mimic3benchmark/resources. Насколько я знаю, сопоставлено около 370 ITEMID, поэтому, если эта работа все еще продолжается, я хотел бы внести свою силу.
С наилучшими пожеланиями!