Этим летом у нас в Курае был отличный класс стажеров. Мы принимаем стажеров в разные команды круглый год. Фактически, у нас сейчас есть несколько стажеров на осень и зиму. Этот пост посвящен работе, проделанной замечательными стажерами-инженерами, которые у нас были за лето. Мы будем обновлять этот блог с информацией о будущей работе стажеров, и вы должны с нетерпением ждать публикаций других стажеров в ближайшие месяцы.

В этот пост мы включаем работу, проделанную Марки и Андреа, которые учатся в Стэнфорде, Диланом и Меси из MIT, Кайлом из CMU и Джозефом, студентом MD и CS в UPenn. Конечно, вся эта работа была бы невозможна без большой работы их наставников в команде инженеров, других коллег из других команд (например, медицинской команды), которые объединились с ними в проектах, и тех, кто вызвался помочь отредактировать это Почта. Далее следует отредактированная короткая версия их работы, написанная их собственными словами (среди прочего, наши стажеры были так гордились нашей миссией Обеспечить лучшее в мире здравоохранение для всех, что все они упомянули об этом, когда описывая свою работу). Приятного чтения об их работе. Отправьте нам свое резюме по адресу [email protected], если вы заинтересованы в том, чтобы помочь нам в выполнении нашей миссии, пройдя стажировку или заняв любую из наших других должностей.

1. Преобразование речи в текст доктора

Дилан Доблар (Массачусетский технологический институт)

Этим летом я имел удовольствие поработать инженером-интерном в Curai. Под руководством своего наставника Эрика Ана я создал микросервис преобразования речи в текст для поддержки врачей при общении с пациентами на нашей платформе чата Curai Health. Эта функция направлена ​​на повышение эффективности работы врачей, обеспечивая функцию преобразования речи в текст в реальном времени, которая позволяет врачам диктовать сообщения пациентам. Для достижения этой цели мы решили, что Doctor Speech-to-Text должен быть:

  1. Точно, особенно с медицинскими терминами
  2. Проста в использовании и легко интегрируется в продукт
  3. Высокая масштабируемость и возможность вычислений
  4. Быстро, с обратной связью почти в реальном времени
  5. Безопасный, гарантирующий сохранение конфиденциальности пациента

Мы рассматривали возможность использования предварительно обученных моделей (от IBM, nVoq, Microsoft и Google), а также возможность обучения нашей собственной модели. Мы остановились на движке преобразования речи в текст Google Cloud, потому что он продемонстрировал, что он может достаточно хорошо распознавать медицинские термины во время наших экспериментов, обеспечивать двунаправленную потоковую передачу с прерывистыми результатами и может масштабироваться для поддержки всех врачей в нашей глобальной сети врачей.

Для включения транскрипции в реальном времени потребуется двунаправленная потоковая передача между браузером врача и серверами Google. Для потоковой передачи аудиосигнала на серверы Google и получения ответов нам нужно было отправлять фрагменты звука через gRPC. Поскольку современные браузеры не поддерживают gRPC, мы настроили наш собственный сервер в качестве промежуточного программного обеспечения, соединяющего браузер врача с серверами Google. Поскольку конфиденциальность является основной проблемой для этой функции, мы позаботились о том, чтобы звук записывался только по указанию врачей. Кроме того, потоковая передача звука из браузера на наш сервер и с нашего сервера на серверы Google осуществляется в соответствии с требованиями HIPAA, и никакие аудиофайлы никогда не сохраняются.

В целях масштабируемости мы решили сделать Doctor STT микросервисом вместо того, чтобы вкладывать его функции в наш основной сервер API. Это позволяет ресурсам, выделенным для этой функции, расти независимо от остальной платформы. Хотя изначально мы создали наш промежуточный сервер, используя настройку Flask для всех других наших микросервисов, мы поняли, что сервер Express лучше подходит для этой задачи из-за асинхронного, событийного характера Node.js и изящной обработки нескольких одновременных запросов. Одна из сложностей этого потока информации связана с кодированием звука. Браузеры записывают звук в формате, который не интерпретируется механизмом STT Google, поэтому мы разработали схему для мгновенного перекодирования фрагментов звука в браузере.

Благодаря этой настройке мы смогли достичь всех желаемых характеристик функций. Механизм STT Google достаточно хорошо справляется с медицинской терминологией, возможность записи встроена непосредственно в веб-приложение и доступна одним нажатием кнопки, микросервисная архитектура обеспечивает эффективное масштабирование, а наша схема двунаправленной потоковой передачи делает эту функцию быстрой и почти реальной. своевременная обратная связь безопасным способом с сохранением конфиденциальности. Я хотел бы поблагодарить своего наставника Эрика Ана, а также всех остальных членов команды инженеров за всю помощь и советы, которые способствовали успеху этого проекта.

2. Медицинские вложения

Андреа Даль (Стэнфорд)

Я Андреа, начинающая студентка младшего курса компьютерных наук в Стэнфорде. Этим летом я работал над очень интересным проектом НЛП в Curai. В некотором смысле, этот пост описывает многие усилия по НЛП, над которыми мы работаем в Curai. Многие из наших задач моделирования НЛП зависят от качества встроенных слов, которые в них включены. Первоначально мы экономили время, используя высококачественные предварительно обученные вложения, такие как вложения BERT. Такие вложения проходят обучение на общих английских корпусах, таких как база данных Википедия или набор данных Google News (около 100 миллиардов слов), и отлично подходят для представления использования слов на языке, похожем на эти тексты. Однако для моделирования разговоров между пациентами и врачами такие вложения не идеальны. Таким образом, мы решили обучить пользовательскому встраиванию слов в разговоры Curai Health, чтобы повысить производительность существующих и будущих моделей разговора.

Curai Health - это платформа для общения пациентов с врачами. Я обучал встраиванию сообщений, отправленных от пациентов, сообщений, отправленных от врачей, и целых разговоров, включая обе стороны. Сообщения, отправленные от врачей, интересны, потому что, хотя врачи обладают знаниями в предметной области, чтобы использовать определенную медицинскую терминологию, в Curai Health они общаются с пользователями и должны писать так, чтобы они были понятны неспециалистам, не имеющим медицинского образования.

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

Токенизация - это метод разделения входных данных предложения на более мелкие строки. Поскольку многие медицинские термины на самом деле являются фразами, например, головная боль или боль в животе, мы предположили, что обучение встраиванию многословных токенов приведет к более эффективным вложениям, чем однословные токены. Можно представить себе, что если написать предложение о городах, вложения для new и york будут недостаточным представлением по сравнению с вложением new_york. Этот метод похож на триграммы или биграммы, но имеет меньший и более управляемый словарный запас, поскольку он сохраняет только наиболее часто встречающиеся фразы. Например, для предложения У меня насморк традиционный метод токенизации биграмм добавил бы [i_have, have_a, a_runny, runny_nose] в словарь, но этот метод может токенизировать только для [ "У меня насморк"]. Я использовал специальный пакет токенизации Gensim Model Phrases, который хранит все триграммы и биграммы, превышающие определенный порог вероятности, а также все униграммы в каждом предложении.

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

«Stsrt», «circler», «oncall», «poofy», «tep», «круглые скобки», «caked», «sprry», «playdoh», «swallowinh»,

Интересно, что вложения все еще могут правильно понимать слова с ошибками. Ближайшие соседи слов с ошибками отражают понимание того, что это слово должно быть.

Мы также можем наблюдать, как вложения выглядят в 2D-пространстве. Очевидно, что модель FO Word2Vec для данных пациентов здесь улавливает правильное значение этих слов и понимает контекст, в котором они существуют. Здесь нанесены слова, наиболее похожие на слова в ключе (ближайшие соседи).

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

«разложившийся», «розацеа», «цеана», «преципитаты», «гамартома», «номер службы экстренной помощи», «противогрибковые_пылевые_порошки», «эссенциальные минералы», «силла», «мобилизация», «эмоциональные состояния», «контр-тинелол-адвил», «кислота» ',' Connective_tissues_attachments ',' premenstrual_syndrome_includes ',' neti_pot_plain ',' article_php '

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

'я', 'адрес электронной почты', 'предоставить_временное_рельеф', 'применение_содержащих_паков', 'триптаны', 'cool_wet_cloth', 'еда_smaller_portions', 'различные_ причины', 'лицензия', 'ношение_loose_clothes', 'конечно', 'bodily_fluid', 'scope ',' support_network ',' relievers ',' real ',' character_limit ',' fiber_foods ',' killer ',' Sound_familiar ',

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

После обучения встраиванию речи пациента и речи врача мы поняли, что можно получить ценную информацию о том, насколько эти языки отличаются друг от друга. Поскольку вложения были обучены с использованием того же метода Word2Vec и поскольку словари имеют высокую степень перекрытия, теоретически их формы должны быть очень похожими, и линейное преобразование одной формы могло бы выровнять ее с другой. Я использовал код контролируемой модели MUSE, чтобы выровнять пространства для встраивания по-разному, чтобы в дальнейшем изучить различия в том, как пишут пациенты и врачи. В частности, метод MUSE включает итерационный метод Procrustes, который определяет линейное преобразование, применяемое к исходной матрице. Существует также неконтролируемый метод GAN, который был менее эффективным и не использовался для наших данных.

Выравнивание итальянского и английского вложения из бумаги MUSE

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

Работа по встраиванию и переводу текста, которую я завершила этим летом в Curai, внесет вклад в продвижение НЛП команды ML в Curai. Никогда не посещая уроки НЛП в школе, этим летом я многому научился, работая над этими отдельными проектами, а также внося свой вклад в большую команду и кодовую базу. Приятно видеть, что эта работа помогла мне расти как инженеру, а также принесет пользу команде машинного обучения Curai.

3. Интерпретация ответов на естественном языке в беседах врача с пациентом.

Марки Вагнер (Стэнфорд)

Мой проект «Следующий вопрос на естественном языке» был направлен на понимание разговоров врача и пациента и извлечение структурированных данных из неструктурированного текста произвольной формы.

Фон

Когда пациент впервые входит в чат, он должен указать свою основную жалобу. Затем наш механизм Next Question генерирует серию последующих вопросов для пациента, которые спрашивают пациента, есть ли у него симптом. Например, если пациент приходит и жалуется на жар, механизм следующего вопроса может спросить: «У вас болит голова?» В настоящее время пациент может ответить, только нажав кнопку «Да», «Нет» или «Не уверен». Это упущенная возможность получить дополнительную информацию от пользователей, которые часто хотят предоставить дополнительную информацию, например о серьезности или продолжительности симптома. Это также далеко не идеальный пользовательский опыт, поскольку система диалогового диалога дает пациенту больше свободы, в отличие от того, чтобы его заставляли выбирать между тремя вариантами.

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

Использование BERT для обнаружения подтверждения симптома

Наша система следующего вопроса генерирует вопросы в формате «Есть ли у вас [симптом]?». Чтобы заменить функциональные возможности переключателей, я создал модель, которая могла извлекать из ответа пациента, говорят ли они «да», «нет» или «неуверен» в своем текстовом ответе. Это оказывается сложной проблемой, поскольку более 40% пользователей не используют в своих ответах фразы «да / нет / не уверен» (например, «да», «нет», «нет» или «не уверен»). В большинстве случаев необходимо определить, говорит ли пользователь «да» или «нет».

Чтобы понять, подтверждал ли пациент наличие симптома или отрицал его, я экспериментировал с несколькими своими собственными стратегиями инженерии признаков и популярными моделями НЛП. В своих первоначальных попытках я пытался использовать общедоступные данные для ответов на вопросы, такие как Набор данных ответов на вопросы Amazon, но эти модели не справлялись с такой специфической для предметной области задачей. Я закончил тем, что использовал комбинацию слабого надзора и помеченных данных Mechanical Turk для создания своего набора данных.

Проведя эксперименты с несколькими моделями классификации последовательностей, я нашел наибольший успех с использованием языковых моделей BERT и XLNet, выпущенных Google. В итоге я использовал реализацию Huggingface этих моделей трансформаторов в Pytorch. Эти модели особенно хорошо работали с небольшими наборами данных, поскольку в них используется трансферное обучение. BERT и XLNet сначала обучаются на крупномасштабном наборе данных, а затем настраиваются на меньшем наборе данных для более конкретной целевой задачи. В моем случае я отображал последовательность (вопрос врача, ответ пациента) на двоичную классификацию (подтверждение пациента, отрицание пациента).

Использование условных случайных полей для извлечения серьезности, частоты и продолжительности

Для сбора данных о степени тяжести я решил использовать комбинацию набора данных hNLP (аннотированные обезличенные клинические заметки из нескольких учреждений) и слабо контролируемых меток из наших собственных журналов чата пациентов. Слабо контролируемые метки были сгенерированы с использованием иерархии функций маркировки, которая состояла из жестко запрограммированных эвристик, синтаксиса (в частности, деревьев зависимостей Spacys) и многого другого. Я также закончил загрузку большего количества данных из наших журналов чата, используя шумные ручные ярлыки от Mechanical Turk.

Для временного набора данных я не стал использовать данные из журналов чата нашего собственного приложения, поскольку у меня был доступ к небольшому, но высококачественному набору данных с аннотированными временными объектами. Чтобы еще больше повысить производительность, я решил выполнить повторную выборку из конкретных категорий, с которыми мой набор проверки постоянно боролся.

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

Результаты

В конце концов, я смог создать модели, которые могли последовательно и точно собирать данные следующего вопроса на естественном языке.

Интеграция

В конце стажировки мне пришлось переключиться с исследований на разработку продукта и интегрировать вызовы API для каждой модели в бэкэнд. Curai использует Kubernetes, Prometheus и недавно перешел на Helm, поэтому мне пришлось научиться использовать эти технологии, чтобы успешно интегрировать, тестировать и производить свои модели.

Заключение

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

4. Опыт летней стажировки от доктора, ставшего инженером-программистом

Джозеф Лю (UPenn)

Привет. Я Джозеф, студент первого курса магистратуры CS Пенсильванского университета. Раньше я несколько лет проработал врачом в Великобритании, прежде чем сменить профессию. Этим летом я имел удовольствие использовать оба опыта в стажировке по разработке программного обеспечения в Curai. Во время стажировки я работал над двумя проектами: (1) Объяснение результатов диагностики с помощью LIME, NS (2) Группирование результатов на основе сходства. Я даже некоторое время совмещал оба проекта. Однако в этом посте я сосредоточусь на использовании LIME для медицинских объяснений, проекте, который требовал объединения моего понимания программного обеспечения, машинного обучения и медицины.

Объяснение результатов диагностики с помощью LIME

Curai работает над разработкой самых современных алгоритмов диагностики (подробнее см. Этот пост в техническом блоге Curai). То, как это работает, похоже на волшебство: пациент вводит набор симптомов, отвечает на несколько вопросов и пуф, вот так двигатель выдает дифференциальный диагноз.

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

LIME расшифровывается как Local Interpretable Model-Agnostic Explanations. Проще говоря, это означает, что он может объяснить любой классификатор черного ящика. Неважно, имеем ли мы дело с моделью диагностики, классификатором спама или моделью, которая классифицирует изображение как хот-дог или нет - LIME может это сделать!

В следующем примере я смоделировал пациента, у которого аллергическая реакция на укус пчелы. После ввода наших симптомов наша диагностическая модель вывела следующие диагнозы:

  1. Анафилаксия (причудливый способ сказать «опасная для жизни аллергическая реакция»)
  2. Жало пчелы
  3. Укус насекомого
  4. Аллергическая вазоспастическая стенокардия

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

Что касается анафилаксии, мы видим, что из трех симптомов укус пчелы и отек верхней губы были очень важными для этого диагноза, в то время как плач - нет. Это обнадеживает, потому что плач не является причиной анафилаксии (если только у вас нет аллергии на плач!)

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

Мы использовали модуль классификатора текста LIME; мы преобразовали входные данные (список объектов симптомов) в одну строку с разделителями-запятыми (например, «upper_lip_swelling, bee_sting, crying») и создали функцию-оболочку, которая анализирует строку и вызывает внутреннюю функцию нашего собственного классификатора.

Выходные данные функции-оболочки должны возвращать вероятности для каждой метки или болезни. Однако наш классификатор выводит вероятности только для тех заболеваний, вероятность которых больше нуля. Поэтому, чтобы уместить его в LIME, мы должны были включить вероятности, даже когда они были равны нулю. Это означало включение вероятности каждого заболевания в нашу базу знаний.

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

Эта установка идеально подходит тем, кто является «мастером на все руки», как и я, и в этой стажировке было все: мне нужно было немного заняться серверной частью, интерфейсом, машинным обучением, клинической информатикой и даже алгоритмами (как оказывается, вся эта подготовка к техническому собеседованию была в конце концов полезна!)

Но что лучше всего? Ваша работа будет видна в конечном продукте. После моей последней презентации выяснилось, что способ сгруппировать результаты - это функция, о которой пользователи недавно просили. И действительно, нет ничего более приятного, чем знать, что ваша работа окажет влияние.

5. Интернационализация и инженерные усовершенствования.

Кайл Чин, CMU

Привет, меня зовут Кайл, и я пишу о своем опыте работы стажером по разработке программного обеспечения в Curai этим летом. На ранней стадии стартапа не было (и есть) недостатка в задачах, которые нужно выполнять еженедельно, и в результате я работал над множеством различных проектов в течение своей 11-недельной стажировки. Наслаждаться!

Интернационализация и перевод чата в реальном времени

Моим первым проектом в Curai было начало работы по интернационализации (i18n). Это означает поддержку приложения Curai Health на разных языках в зависимости от языковых предпочтений пользователя. Например, кнопка с надписью «Привет» по умолчанию должна произносить «Hola», если язык пользователя установлен на испанский. Поддержка неанглийских языков имеет важное значение для глобального предложения приложения Curai Health.

Первая часть этого - это выбор и внедрение фреймворка i18n. Мы определили три основных требования к любой библиотеке i18n: она должна быть масштабируемой, гибкой и поддерживаемой. Изучив различные библиотеки, мы решили продолжить работу с i18next, популярной библиотекой javascript для i18n. Пара преимуществ, которые выделялись, заключалась в том, что он был хорошо документирован и поддерживался, а его реализация в коде Curai Health была простой и чистой.

Поскольку приложение Curai Health представляет собой приложение для чата, в долгосрочной перспективе i18n также означает облегчение беседы между врачом и пользователем, который может плохо говорить на одном языке. В идеале пользователей можно было бы сопоставить с врачами, говорящими на их родном языке, но с учетом экономии спроса и предложения (особенно в отношении времени ответа врача) это не всегда возможно или оптимально. Итак, вторая часть этого проекта заключалась в создании прототипа многоязычного чата, чтобы пользователь, не говорящий по-английски, мог общаться с англоговорящим врачом.

Это было довольно просто реализовать. Во-первых, в профиль пациента необходимо добавить столбец «Предпочитаемый язык чата». Затем неанглоязычные сообщения, поступающие от пациента, необходимо перевести на английский, а сообщения от врача - на язык чата пациента. В любом случае для языкового моделирования и других функций NLP, которые использует FirstOpinion, требуется доступ к английскому тексту, поэтому и английский текст, и необработанный текст хранятся вместе с сообщениями.

Интерфейсный рефакторинг контекста

В любой быстрорастущей компании, а тем более в такой, как Curai, которая приобрела очередной стартап, накапливается хлам. Пара неудобств, существовавших в кодовой базе внешнего интерфейса (React), заключалась в следующем:

  1. Router.js, файл, который должен был просто выбрать правильный компонент для отображения на основе URL-адреса, растянулся на более чем 750 строк кода, потому что он также обрабатывал подключение веб-сокета к чату в дополнение к множеству других более мелких задач.
  2. Prop Drilling: все функции API для взаимодействия с серверной частью были созданы в Router и переданы компонентам. Для компонентов, находящихся в самом низу дерева, это означало передачу функций через восемь (!!) других компонентов, чтобы передать функцию одному компоненту, который в ней нуждался.

В старой архитектуре у маршрутизатора была логика для подключения к веб-сокету, даже если отображаемый компонент не использовал веб-сокет. Кроме того, все вызовы API и информационные реквизиты исходили от маршрутизатора. Это означало, что если компонент B должен был выполнить вызов api, функцию необходимо будет передать через компонент A и Chat, даже если эти компоненты не нуждаются в этом. Чтобы решить эти проблемы, я:

  1. Обработка веб-сокетов чата перенесена в отдельный компонент из Router.js.
  2. Созданы контексты React для таких сервисов, как вызовы API, чтобы компоненты, которые в них нуждались, могли подписаться на контекст напрямую, а не получать их через проп-бурение.
  3. Полученные и сохраненные данные, относящиеся к глобальному состоянию (например, данные пациента), в легком настраиваемом диспетчере состояний, получившем название Weedux.
  4. Подключил некоторые существующие компоненты, чтобы они могли использовать (2) и (3).
  5. Обновлены и добавлены тесты (неожиданный бонус!), А также задокументирован новый способ взаимодействия с этими сервисами.

В новой архитектуре новый компонент оболочки для чата под названием ChatTooBig (раздражающее название, которое побуждает нас разбивать чат на более мелкие части) обрабатывает соединение через веб-сокет независимо от маршрутизатора, что означает, что маршрутизатор может быть просто маршрутизатором. Кроме того, такие компоненты, как A и B, могут «подключаться» к API или данным, которые им нужны, непосредственно к контекстам.

Рефакторинг должен облегчить разработку приложения. Маршрутизатор и чат теперь разделены, что означает, что их можно тестировать по отдельности, а новые компоненты можно легко добавлять в маршрутизатор. Компоненты теперь могут выборочно подписываться на данные, и ненужное бурение опор скоро исчезнет. Наконец, это закладывает основу для постоянного перехода от Weedux к Redux для удовлетворения всех потребностей Curai Health в управлении глобальным состоянием.

Изучение семантического сходства причин встреч пациентов

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

В целом, лето получилось насыщенным, насыщенным и познавательным! Я не знал, чего ожидать от работы в технологическом стартапе, особенно учитывая различные стереотипы, витающие вокруг, но я был чрезвычайно впечатлен культурой и ценностями Курая. Мои товарищи по команде были посвящены не только миссии и продукту, но и подчеркивали этический рост, сплоченность команды и жизнь вне работы. Я обнаружил, что это инклюзивная и разнообразная среда, в которой ценится мнение всех (даже стажеров!), И я рад, что есть хотя бы один стартап, нарушающий типичные шаблоны стартапов. Спасибо за прочтение!

6. Улучшение рабочего процесса дерматологии в Интернете

Мезерт Кебеде (Массачусетский технологический институт)

Я Меси, сейчас учусь в магистратуре Массачусетского технологического института. Этим летом я стажировался в группе разработчиков продукта в Curai.

Curai управляет службой Curai Health, где пользователи могут общаться с медицинским работником и загружать изображения. Эти изображения особенно полезны для диагностики дерматологических заболеваний. Моим основным проектом было улучшение нашего рабочего процесса по сбору и обработке изображений для нашего приложения Curai Health. Эта работа соответствовала нашим усилиям по улучшению опыта Curai Health в решении конкретных проблем дерматологии, поскольку 30% всех случаев первичной медико-санитарной помощи связаны с дерматологией [сайт]. Я работал вместе с многофункциональной командой, чтобы определить основные аспекты этого проекта: 1) упростить сбор данных и хранение изображений 2) улучшить взаимодействие с пользователем, чтобы облегчить загрузку фотографий высокого качества.

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

Чтобы улучшить качество фотографий, сделанных пользователями, мы решили предоставить пользователям рекомендации по созданию фотографий высокого качества. Эти рекомендации служат напоминанием о важных элементах фотографии, которые часто игнорируются в чатах. Например, лучше делать снимок с однотонным фоном, чтобы акцент был сделан на фотографируемом состоянии. Ниже описан процесс сбора изображений перед этим проектом [Рисунок 1] и последний поток после завершения моей стажировки [Рисунок 2].

Рисунок 1: Процесс сбора исходных изображений.

Рисунок 2: Конечный поток сбора изображений, из разговора пользователь инициирует поток, нажав кнопку камеры. Затем пользователя спрашивают, относится ли фотография к дерматологии, и предоставляют рекомендации.

После того, как пользователь загрузит фотографию, ему будет предложено заполнить анкету, было ли это изображение связано с кожей.