Обзор программного обеспечения медицинского оборудования и алгоритм его тестирования

Пока нет оценок.
Пожалуйста, подождите...

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

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

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

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

При тестировании медицинского программного обеспечения алгоритм работы существенно не отличается от работы в других областях.

Он лишь имеет рад особенностей с использованием способа интерактивной методологии.

Как тестировать медицинское ПО?

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

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

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

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

Специалист по тестированию должен убедиться в отсутствии критических ошибок в коде.

Существуют хранилища персональных и клинических данных.

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

При разработке медицинских сервисов учитываются интересы пользователей.

Проверку стоит осуществлять со стороны пользователя, а потом прописывать тестовые сценарии.

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

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

Это может грозить штрафами и испорченной репутацией.

Качественное тестирование осуществляется путем:

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

Особое внимание следует уделить тестированию всех уровней:

  • проверка ПО (тестирование условий и требований относительно разрабатываемого продукта, использование автоматизации и беспрерывного тестирования, тестов продуктивности и т.п.);
  • требования проверки к ПО (тестирование безопасности, функциональных возможностей и т.п.);
  • требования проверки дизайна ПО (тестирование стандартов безопасности и дизайна, проверка спецификации на точность и соответствие);
  • проверка кода (тестирование документально подтвержденных требований к продукту, использование способов по выявлению дефектов и багов, анализ и проверка качества исходного кода);
  • использование одиночного тестирования;
  • требования к проверке на соответствие (тестирование соответствия нормам ISO 13485, IEC 62304, IEC 82304-1).

IEC 62304 — международные стандартные требования к жизненному циклу разработки медицинского ПО и программного обеспечения медицинских устройств.

Данные нормы поддерживаются как ЕС, так и США.

Классы безопасности

Согласно стандарту IEC 62304, ПО должно соответствовать классу безопасности:

  • Класс A: отсутствие нанесения вреда здоровью, исключен риск травмирования. Для данного класса характерной документацией к ПО является: план разработки и анализ требований ПО. Разработка программного модуля и тестирования системы. Выпуск продукта.
  • Класс B: возможность получения мелких травм. Для данного класса характерной документацией к ПО является: план разработки и анализ требований ПО. Архитектура проектирования ПО. Разработка и проверка программного модуля. Интеграция и тестирование ПО. Тестирование и выпуск продукта.
  • Класс C: возможность получения сложных травм, летальный исход. Для данного класса характерной документацией к ПО является: план разработки и анализ требований ПО. Архитектура проектирования ПО. Дизайн ПО. Разработка и проверка программного модуля. Интеграция и тестирование ПО. Тестирование и выпуск продукта.

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

Оставить комментарий