22 января 2023 Новости

Publisher: новый компонент системы MainEDC™

Мы последовательно продолжая свою работу по улучшению системы MainEDC™, с радостью сообщаем, что в опытную эксплуатацию запущен новый компонент Системы – Publisher. Он позволяет в короткое время осуществлять перенос проектов с тестовой среды на рабочую, валидирован на стороне DM365 и имеет большое количество дополнительных опций.

После завершения периода опытной эксплуатации новый компонент будет передан непосредственно клиентам, которые смогут самостоятельно осуществлять переносы своих проектов, без запросов в Службу поддержки DM365 и ожидания. Обращаем ваше внимание на то, что подключение данной опции будет бесплатным – после согласования подхода к обучению и валидации компонента на вашей стороне (ваш персональный проектный менеджер DM365 свяжется с представителем вашей команды по данному вопросу не позднее апреля 2023 г.).

Однако, данный период имеет свои особенности, чем и вызвано настоящее обращение к вам:

1. Все переносы осуществляются в ручном режиме для обеспечения максимальной безопасности данных наших клиентов. В связи с отладкой, длительность реализации переноса временно увеличилась. Просим отнестись к этому с пониманием и учитывать, что перенос вашего проекта может быть осуществлен в течение 2-3 рабочих дней после обращения. Разумеется, мы прилагали и прилагаем все усилия, чтобы сократить этот срок, но просим планировать переносы с учетом данного обстоятельства. В идеале – извещать нас о желаемой дате переноса не позднее чем за 3 дня, так мы сможем гарантировать, что перенос будет осуществлен точно в запланированный срок.

2. Для осуществления переносов проектов, Службе поддержки необходимо иметь служебные роли с определенными полномочиями, как на тестовых и рабочих средах в целом, так и на конкретных проектах. На текущий момент, в случае необходимости переноса и отсутствия таких ролей, Служба поддержки предварительно запрашивает ваши разрешения на их создание, что дополнительно увеличивает время переноса. Для его сокращения просим вас заранее дать нам свое согласие на создание таких ролей по мере возникновения потребности в них по умолчанию. Заверяем вас, что данные роли используются и будут использованы только для реализации служебных функций, без какого-либо изменения данных. Кроме того, все действия всех пользователей Системы (включая и вышеуказанных) в обязательном порядке автоматически сохраняются в Audit Trail. После того как необходимость в этих служебных ролях отпадет, они будут незамедлительно удалены с ваших сред и проектов.

3. Новый механизм позволяет автоматически выгружать Release Note с описанием произведенного переноса конфигурации проекта (в отличие от старой формы, которая заполнялась вручную). Для новых переносов мы будем направлять вам выгрузку Release Note вместо старой формы PM-FRM-002-04. Если возникнут пожелания по модификации этой новой формы, мы с радостью готовы их принять и внедрить. Если по каким-то причинам для вас принципиально использование именно прежней формы, пожалуйста, известите нас.

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

1. В работе Службы поддержки достаточно часто возникают ситуации, когда клиенты сообщают о возникновении нештатных ситуаций у пользователей со стороны исследовательских центров (исследователей и фармацевтов), авторизующихся на вебсайтах класса *.investigator.site. При оказании необходимой помощи специалисты Службы поддержки пользуются аккаунтами со стороны CRO и авторизуются на вебсайтах класса *.mainedc.com. В настоящее время алгоритм работы Службы поддержки в таких случаях выглядит следующим образом:

• Попытка воспроизвести ситуацию со стороны CRO

• Попытка воспроизвести ситуацию путем создания соответствующего пользователя на внутренних тестовых средах DM365

• Попытка воспроизвести ситуацию путем создания соответствующего пользователя на тестовой среде клиента

• Обращение к вам с просьбой разрешить создание пользователя на рабочей среде (на данный момент в нашей практике еще не было ни одного случая, когда клиент в этом отказывал)

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

• В связи с этим просим вас, аналогично п.2, ИСКЛЮЧИТЕЛЬНО в тех случаях, когда Служба поддержки не смогла воспроизвести ситуацию со стороны CRO, разрешить без предварительного запроса вашего согласия создавать явно идентифицируемых пользователей (например, Helpdesk_Investigator или Helpdesk_Pharmacist соответственно) с целью воспроизведения ситуации и БЕЗ внесения/редактирования каких-либо данных. Разумеется, только в тех проектах и для тех центров, по которым будут возникать подобные запросы. После того, как задача будет решена, данные пользователи будут немедленно отключаться (постановкой флага EDC Access = No).

• Аналогично п.2 напоминаем , что все действия всех пользователей Системы (включая и вышеуказанных) в обязательном порядке автоматически сохраняются в Audit Trail.

• Мы понимаем, что подобное разрешение, в отличие от п.2, является гораздо более чувствительным, но считаем, что, в конечном итоге, это будет явно способствовать более оперативной реакции Службы поддержки на ваши запросы.

Благодарим за то, что вы позволяете нам становиться лучше.