ПО для симулятора родов

Эйдос разрабатывал робот-симулятор — манекен «Роженица» — на котором врачи-акушеры могли бы отрабатывать навыки при родовспоможении. Нам же нужно было разработать софт, с которым бы взаимодействовали методологи и курсанты.

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

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

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

Над тем, как сделать конструктор сценариев родов, пришлось поломать голову.

Конструктор родов как кубики Lego

У нас было несколько вариантов, как создавать сценарии симуляции родов и управлять ей родами.

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

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

Мы стали смотреть вокруг. Вообще насмотренность — это ключевой навык не только для дизайнеров, но и для разработчиков, потому что именно она помогает решать подобные задачи. Наличие в нужный момент правильной идеи экономит гигантское количество усилий в будущем. Такой идеей стал для нас Lego Mindstorms и его графический язык программирования LabView.

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

Источник: официальный канал Lego на YouTube

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

В команде — аналитики, разработчики и акушер-гинеколог

«Роженица» стала одним из наших первых проектов, на котором мы вывели аналитику в отдельный процесс, описывали все в формальных нотациях и расписывали сценарии использования.

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

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

Юлия Козлова
SmartHead, руководитель проекта

Акушер-гинеколог отвечал на вопросы аналитиков и сам искал дополнительные материалы. Ему тоже приходилось непросто из-за запросов, с которыми он еще никогда не сталкивался.

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

В процессе разработки техзадания мы описывали все требования и процессы в виде моделей и схем по нотации UML2 — информации было много, и в тексте ее бы никто не прочитал. Полностью техзадание было сформировано за полтора месяца.

Все требования мы описывали в Visual Paradigm

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

«SmartHead является для нас образцом подрядной организации, нас всегда устраивали методы работы и взаимодействие. Любая работа начинается с проработки целей и задач, понимания этапов и объемов работы. Мы приходим с абстрактными хотелками и в ответ получаем метод работы, наиболее подходящий к конкретной задаче. SmartHead всегда открыт для взаимодействия, при изменении целей/сроков/объемов идут на встречу и корректируют свою работу, что выгодно отличает их от остальных компаний. Хотя практически всегда предварительно озвученные сроки и бюджет не превышаются».

Рамиль Зайнуллин
Эйдос-Медицина, соучредитель

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

2 432 000 000 000 000 000 сценариев

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

Рабочее поле методолога

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

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

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

Все было написано на ActionScript 3 в среде Adobe Air, над проектом работала команда из восьми сотрудников SmartHead, трех специалистов Эйдоса и консультанта.

В итоге у нас получился конструктор, который не ограничивает пользователей в том, как составлять сценарии родов — у прямых конкурентов настолько гибкой системы не было. Софт был разработан так, что тестирование можно было проходить и без аппаратной части: мы написали симулятор, который показывал продвижение плода, параметры жизнедеятельности — в общем все, что происходило бы с манекеном, только без него.