Сравниваете две платформы медицинских записей? Список функций — это не договор. Запросите письменную схему потоков данных и сценариев сбоев, затем назначьте именного владельца каждого ответа.
1. Кто отвечает за каждую часть сервиса?
Определите поставщика, медицинскую организацию и субподрядчиков. Опишите пределы системы, кто может ее использовать и кто контролирует результаты, применяемые в лечении. Разделите хостинг, внедрение, клиническую настройку и постоянную поддержку. Для каждой части назовите лицо, утверждающее релиз, и того, кто вправе приостановить развертывание при проблеме безопасности.
2. Что может происходить с данными пациентов?
Перечислите собираемые данные, разрешенные виды использования, права доступа, места хранения, резервные копии, сроки хранения и удаление. Явно укажите, могут ли данные использоваться для обучения модели. Проверьте реальную цепочку от регистрации до консультации, исправления и экспорта записи. Протестируйте ролевой доступ на примере пользователя и укажите, может ли поставщик видеть действующие записи пациентов во время поддержки.
3. Как обрабатываются инциденты безопасности?
Укажите средства контроля доступа, ведение журналов, контакты по инцидентам, шаги уведомления и информацию, которую каждая сторона должна предоставить. Пусть юрист проверит любые применимые требования к срокам. Определите начало отсчета события, сохранение журналов, ответственного за локализацию инцидента и доказательства, которые поставщик должен предоставить клинике. Отрепетируйте правдоподобное событие неправомерного доступа, а не полагайтесь только на имя контакта.
4. Что происходит, когда сервис останавливается?
Установите уровни сервиса, поддержку, резервное копирование и процедуры восстановления. Проверьте, как организация продолжит критическую работу во время сбоя. Установите измеримые цели восстановления и проведите тест восстановления с сотрудниками, использующими систему. Резервная копия, которую нельзя прочитать во время смены с пациентами, — не план непрерывности.
5. Кто проверяет решения и несет риск?
Укажите, когда квалифицированное лицо должно проверять результат, как исправляются ошибки и как распределяется ответственность. Не считайте маркетинговые заявления клинической валидацией. Определите момент, когда клиницист должен отменить или отклонить результат системы; документируйте обучение, изменения версий и отчетность об ошибках. Распределение коммерческого риска не заменяет клинический надзор.
6. Могут ли другие обрабатывать или перемещать данные?
Определите субпроцессоров и любую трансграничную обработку. Проверьте применимые разрешения и договорные гарантии для фактического сервиса. Требуйте предварительного уведомления о новом субпроцессоре или изменении места, порядка проверки и запасного варианта, если одобрение не получено. Составьте схему резервных копий и удаленного технического доступа, а не только основного хранилища.
7. Как перейти на другую платформу и прекратить договор?
Требуйте практичный формат экспорта, переходный период, доказательства удаления и приемочное испытание. Держите план выхода работоспособным даже после спора. Экспортируйте образец истории болезни, вложений и аудиторского следа в пригодный формат до запуска. Определите подтверждение удаления и доступ во время оспариваемого перехода.
До окончательного решения отнесите проект договора и описание системы адвокату с кувейтской квалификацией и соответствующему специалисту в здравоохранении.
Если клинический персонал потеряет доступ во время смены, кто предоставит пригодную копию записи, как быстро и кто сообщит команде? Поместите ответ, который можно проверить, в приложение к договору.
Связанная работа: здравоохранение и науки о жизни и защита данных и конфиденциальность.