Домен Healthcare – один из самых сложных для бизнес-аналитика и для IT в целом. Хотя спрос на технологические решения для здравоохранения растет, не многие IT-компании получают такие проекты. Зачастую им не хватает компетенций, специалистов, разбирающихся в специфике сферы, медицинской терминологии, регламентах, стандартах и их региональных отличиях.
ScienceSoft 17 лет занимается Healthcare-проектами для заказчиков из США, стран ЕС, ОАЭ. В нашей команде работают бизнес-аналитики, которые ориентируются в особенностях системы здравоохранения разных регионов, среди них есть специалисты с медицинским образованием и опытом в этой сфере.
Мы хотим поделиться накопленным опытом и рассказать о специфике работы бизнес-аналитика в домене Healthcare. Я уже сделала обзор домена и типов решений. И поговорила с коллегами, которые работают над Healthcare-проектами, чтобы разобраться, насколько важны доменные знания и чем аналитику может быть интересна именно эта предметная область.
Эта статья будет полезна тем, кто впервые работает с проектом для здравоохранения или интересуется этим доменом. Я составила список челленджей, с которыми может столкнуться бизнес-аналитик в Healthcare, и рассказала, что поможет с ними справиться.
Новый домен – уже челлендж, а если это еще и такая специфическая сфера, как здравоохранение, то потенциальных подводных камней можно ожидать еще больше. Но работа бизнес-аналитика и состоит в том, чтобы находить и решать проблемы, поэтому ваш предыдущий опыт и знание техник бизнес-анализа обязательно пригодятся. В Healthcare, как и в других доменах, будет много типичных сложностей для бизнес-аналитика, и в целом ваша работа будет идти по привычному плану. Но я выделила несколько аспектов, которые важно иметь в виду на старте, чтобы более рационально распределить свое время и приоритизировать задачи.
№1. Разобраться в бизнес-процессах
Healthcare – обширная сфера с большим количеством разнообразных участников (об этом мы уже рассказывали в этой статье). И бизнес-процессы в разных организациях будут отличаться в зависимости от страны, назначения и пользователей решения. Даже опытный в Healthcare бизнес-аналитик может почувствовать себя новичком, когда начнет работать над решением другого типа или другого рынка.
Система здравоохранения в каждой стране имеет свои особенности, которые бывает сложно понять, если ты живешь в другом государстве. Например, Healthcare США и Канады будут сильно отличаться, к тому же в каждом штате и провинции могут быть свои нюансы в законодательстве.
В основном разница касается оплаты медицинских услуг, участия системы страхования, сбора и обработки медицинской информации. Если какие-то процессы очень специфические, то лучше, чтобы на проекте была поддержка от subject matter expert. Если такой роли нет, то можно разобраться и самостоятельно, применяя техники бизнес-анализа, – взаимодействуем со стейкхолдерами, исследуем систему, проверяем свои гипотезы.
Запросите у заказчика документацию, где описываются бизнес-процессы. Источником информации может стать документация на текущую информационную систему, которую нужно заменить, или регламент бизнес-процесса, который будет автоматизирован. Можно организовать интервью со специалистами, которые будут будут использовать решение. Еще полезно исследовать аналогичные продукты от конкурентов.
Часто на Healthcare-проектах требуется интеграция системы с уже существующими на рынке решениями (к примеру в США это могут быть EMR/EHR-системы Cerner, Epic и др.). В таких случаях нужно заранее хорошо изучить функциональность продукта, с которым будет интеграция.
Чтобы не потеряться в обилии информации при погружении в домен, лучше составить план и расписать, что нужно детально изучить, с чем просто ознакомиться. Постепенно у вас сложится цельная картина, и составить более точные требования будет легче.
№2. Ориентироваться в профессиональных терминах
В Healthcare бизнес-аналитик может взаимодействовать со специалистами из разных направлений, связанных со здравоохранением. Это и врачи различных специализаций, и представители медтех-компаний, фармацевтических производств, госсектора и других организаций. В коммуникации с ними будет встречаться профессиональная лексика, в которой в первое время сложно ориентироваться.
Кроме медицинской терминологии, будет много аббревиатур и сокращений, описывающих процессы и систему. Со временем вы все запомните, но лучше сразу завести глоссарий, чтобы он всегда был под рукой. Такой словарь с определениями и синонимами лучше сделать в общем доступе для стейкхолдеров, чтобы унифицировать используемые понятия и быстрее понимать друг друга. Не стоит включать в глоссарий общеизвестные термины, чтобы не перегружать список. Добавляйте формулировки, которые уникальны для отрасли или организации, а также термины, для которых есть разночтения в трактовке.
Глоссарий – полезный источник бизнес-информации по проекту, поэтому его лучше создавать вначале и пополнять по ходу работы.
№3. Знать требования к решениям и стандарты безопасности
Сфера здравоохранения строго регулируется законодательством. Это касается и разработки решений для этой области. В первую очередь, бизнес-аналитику важно разбираться в стандартах о защите медицинской информации и персональных данных, ведь с этим вы столкнетесь практически на любом проекте. Такие регламенты подразумевают множество нюансов, которые следует учитывать на старте проекта.
В США правила обмена личной медицинской информацией устанавливает HIPAA (Health Insurance Portability and Accountability Act). Под его юрисдикцию попадают не только поставщики медицинских услуг, но и другие организации, связанные со здравоохранением, например, страховые компании и государственные учреждения.
В HIPAA есть раздел о приватности, который включает стандарты для хранения, передачи и доступа к медицинской информации (Electronic Protected Health Information). Если решение не соответствует этим стандартам, то его владельцу могут грозить штрафы и даже уголовная ответственность. К примеру, HIPAA требует обеспечить разный уровень доступа к медицинской информации (использование уникальных пользовательских IDs), отслеживание и отчетность по запросам данных, аварийный доступ и многие другие аспекты.
В ЕС HIPAA не действует, но есть общий регламент по защите персональных данных – GDPR (General Data Protection Regulation). Он имеет экстерриториальное действие, то есть применяется ко всем компаниям, обрабатывающим персональные данные резидентов и граждан ЕС, независимо от местонахождения юрлица.
В ОАЭ в 2019 году вышел Закон о медицинских данных, который регулирует использование информационных технологий и коммуникаций в сфере здравоохранения. В этом законе есть принципы о защите персональных данных, схожие с GDPR (ограничение цели сбора данных, меры безопасности, согласие на раскрытие информации).
Если вы работаете с другими регионами, то обязательно проверяйте местное законодательство относительно обработки персональных данных и медицинской информации.
При разработке софта для медицинских гаджетов (Software as a Medical Device) нужно учитывать класс безопасности устройства. Сама классификация может отличаться в разных странах, а это влияет на процедуру регистрации продукта для выхода на рынок. Бизнес-аналитик может готовить специальную документацию для подачи заявки (premarket submissions) в регулирующий орган (например, в США – это FDA (Food and Drug Administration)). По классификации безопасности устройств и процедуре регистрации продукта для выхода на рынок лучше проконсультироваться со специалистами, которые в этом хорошо разбираются (внутри компании, клиентом или найти эксперта со стороны). У нас в ScienceSoft есть Healthcare-консультант, который помогает в этих вопросах.
Как правило, заказчик и пользователи решения – это не все стейкхолдеры, потребности которых нужно учитывать при выявлении требований. В Healthcare еще есть регуляторы (регулирующие и контролирующие органы власти), поставщики дополнительных решений или услуг, партнеры, страховые организации и так далее. Чтобы определить все заинтересованные стороны, нужно ориентироваться в домене и понимать, как устроена система здравоохранения в стране, с которой вы работаете (об этом были пункты выше).
Внимательный анализ стейкхолдеров поможет точнее описать концепцию решения и выявить требования. Можно использовать техники, которые описаны в BABOK, к примеру, луковичную диаграмму, карту влияния, матрицу ответственности.
№4. Понять потребности пользователей
Основная сложность при работе с Healthcare-решениями – найти баланс между требованиями к безопасности, рекомендациями от регулирующих органов и удобством для пользователей.
Не всегда интересы целевой аудитории могут быть очевидными, поэтому не стоит ожидать, что сторона заказчика на них укажет. Когда вы определите все категории пользователей, важно исследовать их паттерны поведения и учитывать окружение, в котором они будут взаимодействовать с приложением (с помощью интервью, анкетирования, наблюдения и других доступных нам методов). К примеру, приложение нужно врачам во время обследования, а они работают в перчатках и очках, что, конечно же, будет влиять на то, как они пользуются интерфейсом.
Если же приложение будут использовать пожилые люди, то логично, что нужен интуитивно понятный интерфейс, максимально простая навигация с подсказками, визуальными сигналами, минимум контента на одном экране, крупный шрифт и так далее.
Очень важно понимать, как ведут себя пользователи, в каких условиях будут использовать софт, какие потребности и ограничения у них есть – все это будет влиять на требования к интерфейсу (от удобства использования до доступа к информации). В некоторых случаях не обойтись без тестирования прототипов на пользователях.
Не менее важный пункт – адаптивность интерфейса и доступность контента для людей с ограниченными возможностями. В некоторых странах это регламентируется законодательством и касается всех приложений, не только медицинских.
В США действует ADA – закон о гражданских правах, который
запрещает дискриминацию людей с инвалидностью во всех сферах жизни общества. По ADA, информационно-коммуникационные технологии относятся к местам общего доступа. А значит, приложения должны соответствовать ADA Accessibility Standards, которые ссылаются на Web Content Accessibility Guidelines (WCAG) (как и большинство законов других стран). Это международный свод стандартов, которым должны соответствовать приложения, чтобы быть доступным для всех категорий пользователей.
Есть и отдельные рекомендации по разработке интерфейсов для медицинских устройств. В США такие принципы опубликовало FDA. В документе сказано, что интерфейс должен быть спроектирован таким образом, чтобы снизить вероятность человеческой ошибки и риски неправильного использования.
№5. Работать с рисками неправильного использования
Многие решения для медицины в случае программного сбоя или ошибки использования могут нанести вред здоровью людей или даже привести к смерти, поэтому на Healthcare-проектах должна быть налажена четкая работа с рисками. Причем это важно не только, когда разрабатывается софт для управления медицинским устройством, но и для приложений, которые, казалось бы, просто собирают и анализируют информацию о здоровье пациентов. Даже незначительные ошибки в использовании здесь могут привести к серьезным последствием, например, ошибочному диагнозу и лечению. В документации все риски неправильного использования должны соотноситься с требованиями, которые их минимизируют.
№6. Соблюдать требования по ведению документации
На Healthcare-проектах могут быть особые требования к ведению документации. Заказчик не обязан об этом знать, поэтому перед стартом разработки обязательно проверьте этот аспект. Правила по ведению документации могут быть прописаны в международных стандартах (ISO, IEC и др.). Если решение нужно будет регистрировать, то шаблоны предоставления требований могут предлагать соответствующие организации, то есть FDA в США или BSI (British Standards Institution) в Великобритании.
На некоторых проектах бизнес-аналитику кроме основных стандартных документов, описывающих требования (SRS, user stories, и т.д.) нужно подготовить и другие артефакты, вроде матрицы трассировки. Если за дополнительные документы на проекте отвечает другой специалист, к примеру, Healthcare-консультант, то ему может понадобиться ваша помощь, например, в работе над рисками (Risk management plan, Risk management report).
Помимо правил для ведения документации, до старта проекта нужно ещё подготовить план утверждения требований. Это значит, что вы должны согласовать с клиентом, как будете предоставлять ему требования (например, письмом на почту) и утверждать документацию. Не игнорируйте этот этап, ведь упущения в коммуникации могут существенно влиять на ход проекта. Еще рекомендую все устные договоренности и обсуждения фиксировать в письмах или проектных документах, а затем подтверждать их актуальность у заказчика.
Автор: Татьяна Лебедева
