Случалось ли вам проснуться однажды утром с идеей инновационного прибора, который принципиально изменит мир здравоохранения? Или вы работаете в многомиллионной корпорации, поставляющей на рынок сотни различных медицинских устройств? На самом деле это не имеет значения, ведь независимо от размеров компании и типа устройств разработка программного обеспечения — это основная часть повседневного бизнеса медицинских производителей. Нравится нам это или нет, но оборудование, которое не зависит от программного обеспечения, давно стало пережитком прошлого.
Большинство сложностей, встающих перед игроками медицинского рынка в процессе разработки ПО, довольно стандартны: с ними сталкиваются все компании, нуждающиеся в информационных решениях, независимо от индустрии. Никому не обойтись без налаженных процессов, хороших разработчиков, опытных архитекторов, умелых тестировщиков и квалифицированных менеджеров. В своей статье я пропущу общие вопросы, связанные с разработкой программного обеспечения в целом, и сразу перейду к специфике медицинских решений. Все нижеизложенное — это, если можно так сказать, взгляд с высоты птичьего полета на некоторые интересные выводы, к которым пришли инженеры Ауриги га основании собственного опыта.
Чтобы определиться с понятиями, давайте с самого начала оговорим, какими компаниями и с какой целью создается новое медицинское ПО. Большинство известных производителей медицинских устройств уже зарекомендовали себя в качестве надежных поставщиков (а барьеры для входа на этот рынок весьма высоки!). Однако рано или поздно любая медицинская компания сталкивается с ситуацией, когда жизненный цикл их продуктов подходит к концу. Например, прекращается производство аппаратных компонентов продукта или проницательный конкурент выпускает новый прибор с более привлекательным набором функций. В любом случае, наступает момент, когда откладывать разработку нового поколения продукта уже нельзя. Специфика медицинской отрасли в том, что цикл выпуска продукта очень длинный (часто
Итак, раз мы определились, кому максимально полезен будет наш более чем
1. Чем раньше вы привлечете команду разработчиков, тем лучше
Убедитесь, что выбранная команда имеет достаточно опыта работы с оборудованием, встроенным ПО и операционными системами, и вовлекайте ее как можно раньше, желательно уже на этапе проектирования нового устройства. Это позволит вам значительно сэкономить время и деньги. Как правило, инженеры создают дизайн устройства, а разработчики решают, какое аппаратное обеспечение оптимально подойдет для конкретной операционной системы. Вооружившись этими знаниями на раннем этапе, ваша команда поможет вам определить, сколько требуется процессоров, нужна ли операционная система реального времени, что делать с пакетом поддержки платформы (BSP) и уровнем абстракции оборудования (HAL), какие аппаратные драйверы доступны и что нужно будет писать с нуля. Не пренебрегайте этим советом, ведь ошибки в дизайне могут стать роковыми. Над каким бы решением вы ни трудились, не забудьте задействовать разработчиков на раннем этапе!
2. Ваша команда должна работать в соответствии с принятыми стандартами
Обучите ваших специалистов стандартам IEC 62304 и ISO 13485, а также стандартам управления рисками. В последние годы эти стандарты де-факто стали основным сводом требований к разработке медицинского оборудования и ПО. Очевидно, процесс разработки ПО является лишь частью системы управления качеством медицинского продукта, однако это абсолютно необходимая часть, поэтому очень важно хорошо интегрировать команду разработчиков в общую систему качества.
Если и есть что-то важнее знания этих стандартов, то это тщательное им следование. Зрелые команды обязательно работают в соответствии со стандартами. Как правило, это эксперты с многолетним опытом разработки критически важного ПО для авиации, медицины, оборонной промышленности. Медицинские компании часто обращают на это внимание, ведь такой уровень опыта не наработать за один день.
3. Защищайте ваши алгоритмы — работайте с надежными партнерами
Когда вы производите устройство, что вы считаете вашей интеллектуальной собственностью? Зачастую это не самый навороченный процессор, не восхитительный сенсорный экран и не крутые маркетинговые находки. Чаще всего это математические алгоритмы и их реализация. Опытные продуктовые команды знают, что алгоритмы — их главная ценность. У нас были проекты, для которых мы получали алгоритмы в виде зашифрованных блоков (и не воспринимали это как недостаток доверия). И были проекты, когда нашу команду нанимали специально и только для разработки этих алгоритмов с нуля. Между этими двумя полюсами есть множество промежуточных ситуаций, но в какой бы из них вы ни оказались, внимательно относитесь к своим алгоритмам и принимайте меры по защите своей интеллектуальной собственности.
4. Создайте простой и надежный пользовательский интерфейс
Удобство использования — одно из наиболее важных качеств нового продукта. Даже самое надежное устройство не будет хорошо продаваться, если оно выглядит как приборы, которые использовали наши прабабушки, не дает врачу информации, которая должна быть у него под рукой, или не оповещает медсестру о критическом состоянии больного наглядно и оперативно. Однако не переусердствуйте! Имейте в виду, что ваш прибор должен быть простым, интуитивно понятным и безотказным. Новая прикольная функция, на днях появившаяся в вашем iPhone, не обязательно необходима в вашем медицинском устройстве. В разработке хорошего медицинского ПО решающее значение имеют потребности конечных пользователей и технологов-проектировщиков. Чем бы вы ни занимались, ваши пользователи выполняют самую сложную работу на свете — спасают жизни! Им и так приходится нелегко, поэтому вы, как поставщик ПО, должны сделать все возможное, чтобы упростить их задачу.
5. Модернизация не всегда равна полной переработке
Как уже было упомянуто выше, многие медицинские компании уже выпускают готовое устройство (или десятки устройств), но хотят сделать его более удобным и продвинутым. Не так давно мы работали над подобным проектом: устройство заказчика функционировало отлично, но вызывало у пользователей ощущение «чего-то устаревшего». В качестве решения этой проблемы наша команда предложила разделить продукт на две взаимодействующие части. Оригинальное устройство класса 3 практически не изменилось, сохранив все основные показатели и элементы управления. Дополнительным устройством стал сенсорный экран, оснащенный новым ПО. Медицинский персонал получил удобный и современно выглядящий инструмент для отчетности, с которым приятно работать. Второе устройство не относится к третьему классу медицинских устройств, оно лишь «общается» с оригинальным устройством. Так что реализованный подход позволил заказчику сэкономить время и деньги в процессе прохождения сертификации нового устройства.
6. Планируйте функциональную совместимость с самого начала
Дни, когда медицинский прибор можно было собрать «на коленке» и установить в местной больнице, давно канули в лету. Конечно, для каждого правила найдутся исключения, однако подавляющее большинство современных медицинских устройств — это сложные аппараты с несколькими слоями работающего ПО. Более того, они должны обмениваться данными с другим оборудованием и информационными системами больницы, которые совсем необязательно будут изготовлены одним производителем. Устройства разных фирм должны «разговаривать друг с другом» с помощью различных протоколов: от специализированных прямых последовательных соединений, Wi-Fi или Bluetooth, и до тех, еще неизвестных, способов связи, которые изобретут в следующем году. Функциональная совместимость медицинских приборов становится крайне важна, и ваша команда разработчиков должна уметь ее обеспечить. Знакомство со стандартом HL7 может стать отличной отправной точкой!
Понятно, что все это — лишь верхушка айсберга, но если данная статья заставила вас задуматься о том, как лучше организовать ваши медицинские проекты, значит, она достигла своей цели. Независимо от того, решите ли вы использовать на проекте свою собственную команду или привлечь внешних разработчиков, не забывайте о наших рекомендациях. Помните, что от ваших медицинских решений зависит чья-то жизнь!
Автор статьи — исполнительный вице-президент компании Аурига.
