Может ли Agile применяться в ИТ-отделах здравоохранения?

Можно ли использовать Agile в таких областях, как ИТ-отдел здравоохранения, где большая часть ухода за пациентами зависит от качества и своевременности поставки систем?

Да, гибкая разработка, безусловно, играет определенную роль в развитии информационных технологий здравоохранения. Никто, ни конечный пользователь, ни пациент, и, конечно, не команда разработчиков, хорошо обслуживаются плохо выполненным процессом разработки. Рассматривая некоторые принципы, лежащие в основе Agile манифеста (список беззастенчиво вырван из Википедии с моим комментарием):

• Удовлетворенность клиентов быстрой доставкой полезного программного обеспечения . Когда это не цель?
• Добро пожаловать в меняющиеся требования, даже на поздних стадиях разработки . Медицинские информационные технологии интегрируются в область, которая, хотя и абсолютно завалена технологиями, не особенно сфокусирована на ИТ. Потенциал для системы, спроектированной так, чтобы «сделать все правильно» с нуля, довольно низок.
• Рабочее программное обеспечение поставляется часто (недели, а не месяцы) . Как конечный пользователь некоторых из этих вещей, боже, я бы любил это. Быстрые, рабочие изменения неоценимы, и что превращает ИТ-отдел здравоохранения из «того, что нам нужно делать», в «то, что меняет мою работу».
• Рабочее программное обеспечение является основной мерой прогресса . Имеет смысл в большинстве приложений, так что на самом деле нет никаких причин, по которым он не охватил бы HIT.
• Устойчивое развитие, способное поддерживать постоянный темп . Вы видите это по всему здравоохранению, от эпиднадзора за инфекциями до HIT и учреждений. Здравоохранение - это не цикл бума или спада, а постоянный удар барабана.
• Тесное ежедневное сотрудничество деловых людей и разработчиков . Большинство ХИТ не инструмент разработчика. Это инструмент, созданный разработчиками. Контакт с клиентом является и должен быть ключевым. Кроме того, гораздо проще внедрить систему, если она работает и интегрируется в рабочий процесс клиента, а не требует ее установки, исправления и т. Д.
• Личная беседа - лучшая форма общения (совместного размещения) . Из моего взаимодействия с врачами, это способ легче получить вещи сделано лично, желательно с подушечками бумаги, чем любым другим способом.
• Проекты построены вокруг мотивированных людей, которым следует доверять . Это то, что сделает вашу жизнь лучше - так что да, это следует принять;)
• Постоянное внимание к техническому совершенству и хорошему дизайну . Это опять-таки одна из тех вещей, которые «каждый должен делать, поэтому, конечно, вы должны». Но рассмотрим сложность систем HIT и их бесчисленное множество применений изо дня в день. Разрушенная система не собирается сокращать это.
• Простота . Это должно работать из коробки. Это должно работать хорошо все время и так, как должно. Люди идиоты. Работники здравоохранения - это люди. Поэтому ... ты знаешь остальное. Простота помогает.
• Самоорганизующиеся команды . Это может быть немного больше для HIT. Честно говоря, я не достаточно уверен, чтобы так или иначе сказать, хороша ли самоорганизация в этой обстановке или нет.
• Регулярная адаптация к меняющимся обстоятельствам . HIT является активной, растущей отраслью со сложным, меняющимся регуляторным бременем. Способность адаптироваться кажется хорошей идеей.

Обсуждения, связанные с использованием Agile Medical Software Software Development в регулируемых FDA условиях, ведутся уже давно и имеют отношение к этому вопросу. Вот несколько причин, почему:

1. Плюсы и минусы «Водопад против итеративной разработки», по сути, одинаковы, и их необходимо учитывать для любого ИТ-проекта в сфере здравоохранения.
2. Используемые FDA системы качества (см. Общие принципы валидации программного обеспечения; Окончательное руководство для промышленности и персонала FDA ) для разработки программного обеспечения для медицинских устройств являются золотым отраслевым стандартом. Следует отметить, что эти правила не диктуют какую-либо конкретную методологию развития. В любом случае качество программного обеспечения Health IT значительно улучшилось бы, если бы все эти передовые методы были соблюдены.
3. Большинство разработок программного обеспечения Heath IT в настоящее время не работают в соответствии с этими нормативными стандартами FDA. Поскольку барьеры для совместимости медицинских устройств продолжают падать, в частности для мобильных платформ, это, вероятно, изменится - см. FDA Addresses Mobile Medical Apps .
4. Кроме того, если вы разрабатываете коммерческое программное обеспечение Health IT, вы должны спросить себя, создаете ли вы систему данных медицинского устройства (MDDS): Является ли мой продукт MDDS?

Краткий ответ - да". Более длинный, но более точный ответ: «Если вы принимаете это всерьез».

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

Что касается безопасности и качества, имейте в виду, что создание безопасного программного обеспечения является трудным делом. Несколько хороших программистов со знанием предметной области могут запустить невероятно полезное программное обеспечение, которое довольно безопасно. Если они являются частью развертывания в локальных клинических условиях и могут продолжать реагировать и приспосабливаться к событиям во время развертывания и использования программного обеспечения, программное обеспечение может обеспечить ценность, спасая или улучшая жизни только с несколькими травмами или смертельными случаями, связанными с ошибками использования. или программные ошибки. Но программное обеспечение будет требовать, чтобы программисты постоянно были там, отвечали, совместно развивали программное обеспечение по мере развития программного обеспечения. Это не масштабируемый процесс, и когда программисты умирают или скучают, система может очень быстро стать очень опасной. Чтобы улучшить эти результаты и сделать безопасное программное обеспечение, Существуют важные шаги процесса разработки, которые необходимо предпринять во время разработки программного обеспечения. Хорошее «готовое» введение к ним можно найти в международном стандарте разработки программного обеспечения для медицинских устройств ISO / IEC 62304. Основная концепция - управление рисками безопасности на всех этапах - во время анализа сценариев использования и разработки истории, требования Выяснение, системное и архитектурное проектирование, внедрение, юнит и интеграционное тестирование. Благодаря гибкости не удастся ни выполнить эту работу, ни сделать ее менее трудной, но, сосредоточившись на создании ценности и устранении работы (такой как ненужные функции или чрезмерные циклы проверки / исправления проверки), которая не создает ценности, гибкая разработка может Позволить команде интегрировать эту работу в разработку, в результате чего будет разработано более безопасное программное обеспечение. Практики итеративной разработки, обычно используемые гибкими командами, очень хорошо подходят для выполнения работы по управлению рисками безопасности, развиваясь на протяжении всей жизни проекта, а не запоздалая мысль. И после того, как программное обеспечение будет в рабочем состоянии, необходимо учитывать обратную связь от пользователей и любые события, которые могут даже привести к травме, индивидуально и в совокупности, чтобы обеспечить безопасность использования программного обеспечения. Agile может помочь в этом, если он обеспечивает быстрый и безопасный процесс для внесения изменений, не нарушая другие части системы, что, в свою очередь, требует хорошей архитектуры и хорошо понятных взаимодействий проектирования, которые были созданы при разработке программного обеспечения. развиваться на протяжении всей жизни проекта, а не запоздалая мысль. И после того, как программное обеспечение будет в рабочем состоянии, необходимо учитывать обратную связь от пользователей и любые события, которые могут даже привести к травме, индивидуально и в совокупности, чтобы обеспечить безопасность использования программного обеспечения. Agile может помочь в этом, если он обеспечивает быстрый и безопасный процесс для внесения изменений, не нарушая другие части системы, что, в свою очередь, требует хорошей архитектуры и хорошо понятных взаимодействий проектирования, которые были созданы при разработке программного обеспечения. развиваться на протяжении всей жизни проекта, а не запоздалая мысль. И после того, как программное обеспечение будет в рабочем состоянии, необходимо учитывать обратную связь от пользователей и любые события, которые могут даже привести к травме, индивидуально и в совокупности, чтобы обеспечить безопасность использования программного обеспечения. Agile может помочь в этом, если он обеспечивает быстрый и безопасный процесс для внесения изменений, не нарушая другие части системы, что, в свою очередь, требует хорошей архитектуры и хорошо понятных взаимодействий проектирования, которые были созданы при разработке программного обеспечения.

Вторая проблема - нормативная. В идеальном мире правила безопасности будут применяться ко всем продуктам, которые могут быть достаточно опасными, и поставщик сможет выполнить их, выполнив несколько простых действий, когда они начнут пересекать черту. На практике глобальные правила являются сложными и быстро меняющимися в этой отрасли. Это означает, что в один прекрасный день вы можете разработать небольшое приложение для iPhone, которое отображает некоторые медицинские данные, а в следующий раз вы должны будете соответствовать стандартам ISO и FDA для «управления качеством». система ", или СМК. Это может быть страшно для компаний, которые в прошлом не имели формальной СМК. А гибкость может усугубить это, потому что вы можете начать с концепции продукта и через эволюционное развитие невольно вступить в регулируемое целевое использование (например, отображение данных клинической диагностики для пользователя). Это октябрь 2011 года; Мой совет любой компании, которая рассматривает возможность маркетинга продукта, в названии которого есть «здоровье», «медицина», «здравоохранение», заключается в том, что у них должен быть план, когда продукт, который они производят, регулируется одним или несколькими регуляторами медицинского оборудования во всем мире. И здесь Agile может помочь, потому что Agile-практики обычно производят (или легко могут производить) совместимые результаты, чтобы удовлетворить клиентов со стороны регулирующих органов как для предварительных проверок (например, FDA 510k), так и для сертификации (например, ISO 13485) и после-рыночных операций. Разработка Test-First вписывается прямо в медицинское программное обеспечение. Непрерывная интеграция, автоматизированное модульное тестирование и метаданные SCRUM sprint могут предоставить полное объективное свидетельство того, что управление рисками и надлежащая проверка выполняются не просто как запоздалое размышление, а в процессе разработки. В большинстве случаев я думаю, что Agile производит больше артефактов, чем «водопад», возможно, не в той же форме. Но преобразование выходов во что-то, удовлетворяющее регуляторам, является сравнительно небольшой проблемой для решения.

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

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

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

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

ИТ в сфере здравоохранения может показаться предопределенной областью компьютерной науки; с его строгими стандартами (DICOM, HL7) кажется, что есть только один способ их реализации, но есть также много предпочтений и решений.

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

Как уже было отмечено, ответ - да.

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

Например, есть хороший опыт и практика применения Agile-подходов к регулируемым средам FDA.

Краткий ответ: да. Существует хороший блог о Agile в высокоуровневых средах, в котором даются некоторые советы.

Однако есть некоторые компромиссы, которые необходимо сделать. Рассмотрим Agile Manifesto :

Индивидуумы и взаимодействия над процессами и инструментами

Рабочее программное обеспечение над исчерпывающей документацией

Сотрудничество с клиентом в рамках переговоров по контракту

Реагирование на изменения после плана

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

С другой стороны, многие гибкие принципы очень хорошо вписываются в мир здравоохранения, в том числе:

• TDD и парное программирование - повышение качества
• Тесные отзывы клиентов - ранняя проверка - это здорово
• Итеративное планирование - регулирующие органы все о планировании

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

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

AAMI активно работает над Техническим информационным отчетом, озаглавленным:
AAMI TIR SW1, Руководство по использованию гибких практик при разработке программного обеспечения для медицинских устройств.

Я слышал, что это может быть опубликовано в 2012 году.

В нем обсуждается соответствие принципов Agile Manifesto (см. Ответ EpiGrads) нормативным требованиям, типичным процессам и другим практическим возможностям продукта, связанным с программным обеспечением для медицинских устройств.