Русские сообщения в правилах.

Правила в OpenClinica загружаются из XML файлов, которые должны быть сохранены в ANSI. Тут возникает проблема, как загрузить сообщение на русском языке, особенно если у нас на компьютере не русская локаль.
Делается это просто, но придется непосредственно залезть в базу данных.
Вносим в наше правило какое-нибудь уникально сообщение, например:

<Message>RULE 1 MESSAGE</Message>

Сохраняем файл и загружаем его в ОпК.
Теперь запускаем pgAdmin, подключаемся к базе данных openclinica и открываем Query.
Убираем все из окна и вводим следующий SQL оператор:

update rule_action set message = 'Сообщение правила 1'
where message = 'RULE 1 MESSAGE';

нажимаем F5 и убеждаемся что все выполнено без ошибок.
Теперь при срабатывании правила будет появляться новое сообщение на русском языке.

Новая версия. OpenClinica 3.3

Между тем новая версия уже доступна для загрузки.

Проблема при экспорте данных

Неприятный баг обнаружился при экспорте данных.

При попытке экспортировать некоторые датасеты появляется сообщение об ошибке:

The extract data job failed with the message:
For input string: "19,7"
More information may be available in the log files.   

Ошибка как-то связана с неанглийскими данными (в интернете ссылки на эту ошибку у других неаглосаксов здесь и здесь) но носит какой-то несистематический характер - в сообщении об ошибке появляются разные цифры ("20,2","20,8","4,8", "1,1" ...), иногда удавалось экспортировать в ODM, иногда - нет.

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

В другой форме убрал из датасета все даты - все равно ошибка.

Как предположение можно рассматривать несоответствие форматов дат в ОпК и на сервере, проверить.

Сообщение об ошибке не переведено на русский, значит его нет в файлах properties. Видимо часть относительно нового кода.

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

Новая версия. OpenClinica 3.2

Новая версия доступна для загрузки.
https://community.openclinica.com/project/openclinica
Обещают существенное улучшение функции печати форм.

Rule Designer для всех

В OpenClinica есть удобный инструмент для создания правил - Rule Designer. Однако доступен он только в платной версии. Что же делать если не хочется раскошеливаться а XML самому писать лень? Все очень просто - на сайте OpenClinica есть демо полной версии.
https://www.openclinica.com/self-guided-demo
То есть можно загрузить туда свои формы и пожалуйста, пользуйтесь дизайнером сколько угодно.
Правда ваши формы будут видны всем посетителям сайта, но ведь у вас не секретное исследование? :-)

Особенности вывода формы на печать

методом проб удалось выяснить интересную особенность.

Если не присваивать объектам формы группу (оставить колонку GROUP_LABEL во вкладке Items пустой) то форма выводится на печать примерно так же, как на экран.

Если же задать группу, то во-первых вся группа выводится в строчку, а во-вторых HTML тэги превращается в текст. Причем даже в поле INSTRUCTIONS, которое относится к вкладке, а не к отдельному объекту.

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

Правила

Первое правило относительно правил. ОКл не принимает XML в Unicode. Только ANSI.
Сообщение об ошибке: 

Content is not allowed in prolog.

Резервное копирование

Бекап и восстановление описаны здесь:
http://en.wikibooks.org/wiki/OpenClinica_User_Manual/BackupAndRestore

Ограничения на вычисления в формах

При задании формы можно сделать поля вычисляемыми.
Для этого надо ...
Однако возможность вычислений ограничена.
В частности нельзя использовать поля типа дата.
Решается проблема внедрением в страницу кода на JavaScript.
Скрипт нужно поместить в поле INSTRUCTIONS.
Однако,  в инструкции к разделу не может быть больше 2000 символов, так что с программированием особенно не развернешься.

Пример:
http://en.wikibooks.org/wiki/OpenClinica_User_Manual/AgeField

Полностью удалить пациента или форму

Так чтобы духу их не было.
Тут придется работать на уровне базы данных, в веб-интерфейсе этого нет.
Как это сделать - здесь:
https://community.openclinica.com/removing-crf-andor-subject-completely
(надо зарегистрироваться и залогиниться на форумай ОпК, чтобы видеть запись.

Чтобы полностью очистить базу, надо с помощью PGAdmin удалить базу данных openclinica. При следующем старте программы база будет создана заново. Пароль администратора будет переустановлен.

Еще о случайных числах в идентификаторе формы.

Я уже писал, что случайные цифры в идентификаторах это плохо. Например тем, что если мы захотим использовать формы на другом сервере, то называться там они будут по другому и соответственно придется менять правила, к ним относящиеся.
Как выясняется OpenClinica может добавлять случайные числа к идентификатору в неожиданных ситуациях.
Например, я создаю форму с именем CONDITIONAL_INPUT, программа создает идентификатор F_CONDITIONAL_  Имя формы можно потом поменять, а идентификатор - нет.
Положим, потом я захотел создать форму CONDITIONAL_INPUT_2, так вот для нее OID будет уже что-то вроде F_CONDITIONAL_1587, то есть вылезают те самые нежелательные случайные числа.
А надо было называть форму N2_CONDITIONAL_INPUT, меняя начало, а не конец, и все было бы в порядке.

Простейшая логика в форме

Классический пример - спрятать поле с вопросом о беременности, если пациент мужчина.
Делается это просто. Допустим у нас есть две переменные: Sex с возможными заначениями 1,2 и Pregnant. Тогда в описании переменной Pregnant в поле ITEM_DISPLAY_STATUS пишем

HIDE а в SIMPLE_CONDITIONAL_DISPLAY список из трех элементов, разделенных запятой:

Sex,2,Поле должно быть пустым.

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

Как может получиться такая ошибка? Например, пришел к нам пациент, мы решили, что он женщина, о чем сделали соответствующую запись в форме, на вопрос о беременность ответили Нет. А потом выяснили, что пациент у нас мужчина. Меняем пол на М, вопрос о беременности должен исчезнуть, но там у нас уже есть ответ, значит, чтобы не было ошибки нужно его убрать.

Тут возникает небольшая проблема с полем типа Select, решение описано здесь.

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

Более сложная логика описывается Правилами, об этом поговорим отдельно.

Null в элементе ввода Select

Игода бывает нужно предоставить пользователю оставить поле пустым (в частности, это может понадобиться при управлении доступом к полям, об этом в следующей заметке). В случае с селектом это не всегда просто. В OpenClinica какой-то элемент уже будет выбран. При задании параметров визита можно установить значенит для отсутствующих данных (вроде N/A или Нет информации), они будут добавлены во все селекты в форме, но прграмма будет их воспринимать именно как некое значение, а не Null.
Решение у этой проблемы такое: в эксельном файле параметров формы надо задать величину DEFAULT_VALUE - Null.  Тогда в селекте появится строка Null и система будет ее трактовать именно как пустую. Например если сделать это поле обязательным, то она будет ругаться при попытке сохранить его с пустым значением.
Единственно неприятно так это то, что в форме так и будет написано - Null. Это во-первых не по-русски, а во вторых потребует дополнительных пояснений для пользователей далеких от программирования. Можно ли сделать, чтобы вместо ненужного слова была пустая строка, я пока не знаю.

Добавление.
Все гораздо проще:

RESPONSE_OPTIONS_TEXT	RESPONSE_VALUES_OR_CALCULATIONS
,Yes,No	,1,0

И будет вам пустая строка.

А еще можно вставить любой текст в DEFAULT_VALUE, например: (введите что-нибудь)
Будет работать так же, как Null

Небольшой трюк при создании формы с русским именем.

Имя ИРК выводится и на экран и на печать, поэтому при рускоязычном проекте лучше, чтобы и имя было русское.

Однако, если при создании сразу указать имя по-русски, то OpenClinica присвоит ей идентификатор случайным образом. Что-нибудь вроде F_6623. Это конечно неудобно при дальнейшей работе.

Поэтому сначала, в эксельном файле с описанием надо задать имя латинскими буквами. После загрузки будет создан идетнтификатор вида: F_VASH_LAT_TEXT. Теперь можно войти в режим редактирования и поменять название на русское. Идентефикатор меняться не будет.

Выгрузка данных

С выгрузкой данных в юникоде есть проблемы.
Решение здесь:
https://docs.openclinica.com/3.1/technical-documents/openclinica-and-internationalization/openclinica-data-extract-file-format
Если коротко: открыть файл в Блокноте, сохранить в кодировке Unicode. После этого можно открывать в Экселе.

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

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

Группировка пациентов внутри исследования

Для группировки пациентов предусмотрены Сайты (Site) 
https://docs.openclinica.com/3.1/study-setup/build-study/create-site
это могут быть любые группы, но обычно под этим понимают различные медицинские учреждения. Иерархия не предусмотрена.
Пациент должен быть прикреплен к одному сайту. Можно переводить пациента с места на место.
Доступ пользователей к сайтам определяется ролями. Можно разрешить доступ ко всем, нескольким или единственному сайту.

Кроме того можно завести сколько угодно Subject Group это может быть группировка по любым признакам - возраст, режим лечения и т.д. Доступ пользователей к таким группам не ограничивается.

Импорт данных

https://docs.openclinica.com/3.1/openclinica-user-guide/submit-data-module-overview/import-data

These are OpenClinica requirements to import data:

• The Study exists - логично
• Event Definitions for the data being imported exist - логично
• Event CRFs for the data being imported must exist - данные, которых нет ни в одной форме для ОпК не существуют. Нет возражений
• Study Subjects for the data being imported exist - а вот это фигня какя-то. То есть новых пациентов списком загнать не удасться.
• Study Subjects must be scheduled for the Study Events for which the data is being imported - то есть незапланированое событие внести неудасться. Это минус. Но в нашем случае не смертельный - сначала вносим вручную данные визита, затем к ним подгружаем данные из другой системы.

"The imported data for a CRF for a Subject replaces any data that was already captured for that Subject for that CRF."
то есть нельзя совмещать в одной и той же форме данные, которые вводятся вручную, с данными, которые потом подгружаются из другой системы - ранее внесенные данные будут стерты.

"Automatic checks for the imported data are limited and not as robust as when the data is entered manually in the CRF web interface."
Это не проблема, раз данные вносились в другую систему, то там они и проверялись.

"If there are any calculated value fields in the CRF, you need to either supply the correct data in the import file or open and save the CRFs manually to generate them."
это не сложно, но об этом надо помнить.

Данные должны быть в XML

Всякие Эксельные таблицы просто так импортировать не удасться, надо их где-то агрегировать и переводить в XML

Чтобы сгенерировать XML надо получить из ОпК Идентификаторы объектов (OId). Общие идентификаторы для исследования есть в Study metadata file, который надо выгружать вручную один раз.
OId для пациентов предсказуемы, это SS_ плюс уникальный идентификатор пациента, который мы задаем при его создании.

В некоторых случаях OId генерируются случайным образом при создании объекта, таких случаев надо избегать.

Импорт данных можно проводить в автоматическом режиме, создав для него задание
https://docs.openclinica.com/3.1/brief-overview/jobs#content-title-4364

Как быстро перевести на русский файлы xxx.properties

• Открываем файл xxx.properties в Блокноте
• Заменяем все ' =' на '=' (апострофы не вводим)
• Заменяем все '= ' на '='
• Сохраняем файл как  xxx.properties.csv указываем UTF-8 (если не поставить UTF-8 Эксель не будет спрашивать, какой у нас разделитель)
• Открываем файл в Экселе как csv с разделителем = Получаем две колонки - свойства и их значения
• Выделяем вторую колонку, копируем 
• Открываем Гугл Переводчик, устанавливаем перевод с английского на русский (или какой другой язык) и пейстим в поле для исходного текста.
• Выделяем полученый перевод, копируем
• В экселе делаем пейст в третью колонку. Проверяем, чтобы перевод совпадал с оригиналом по строкам. В конце бывают проблемы, если надо, повторяем по частям.
• Заменяем все ' .' на '.', ' ,' на ',', ' )' на ')' (переводчик вставляет лишние пробелы).
•  < / A> на  < /a>
•  < A HREF  -  <a href
• вообще обратить внимание на page_messages.properties html - теги, апострофы и т.д.
• В ячейку D1 забиваем формулу =IF(ISBLANK(A1),"",IF(ISBLANK(C1), A1, A1 & " = "  & C1)) и растягиваем на всю колонку. (Трудно понять, но надо запомнить - копирую формулу отсюда - выдает ошибку, копирую из другоро эксельного файла - работает).
• Сохраняем файл как  xxx.properties.xlsx
• копируем четвертую колонку в пустой файл в Блокноте, сохраняем как  xxx_ru.properties.txt, не забываем про UTF-8
• конвертируем файл xxx_ru.properties.txt в понятный Джаве формат при помощи native2ascii http://citforum.ru/internet/javascript/java_rbint.shtml#7 Результат сохраняем в файле  xxx_ru.properties
• native2ascii -encoding UTF8 C:\MyFolder\admin_ru.properties.txt C:\MyFolder\admin_ru.properties

В итоге имеем хоть местами криво, но полностью переведенный интерфейс. Дальше можем спокойно вручную править перевод в Эксельном файле, конвертируя результат по мере готовности.

Существующая реализация русской версии OpenClinica

По адресу
http://ecrf.pro/index.html
можно посмотреть на работающую реализацию русифицированой ОпенКлиники.
Там же есть хорошая инструкция по конфигурированию Мозилы для автоматического переключения интерфейса на русский язык.
http://ecrf.pro/local.html
Однако сами файлы с переведенными сообщениями хозяева похоже выкладывать в открытый доступ не хотят.
Нехорошо, можно сказать, что такая жадность подрывает дух опенсорсного програмирования.

Неприятная особенность многоязычного интерфейса в OpenClinica

Формально OpenClinica поддерживает многоязычность в интерфейсе, существет поддержка для восьми языков (русского нет) и если есть желание, можно сделать перевод самостоятельно.
Как - описано здесь:
https://docs.openclinica.com/3.1/technical-documents/openclinica-and-internationalization/translate-openclinica-new-languages-or-
Однако, с пользовательскими формами не все так просто. Каждая форма может быть создана только в одном экземпляре, то есть в реальности только на одном языке.
То есть стандартный интерфейс пользователь будет видеть на своем родном, а вот с  основной начинкой разнообразия не предусмотрено.
На первый взгляд возможны два варианта, как решить эту проблему: или создавать отдельные формы для каждого нужного языка или пытаться дать перевод на несколько языков в одной форме.
Первый вариант неудобен тем, что пользователю придется выбирать форму на нужном языке вручную, кроме того не уверен что можно сделать так, чтобы данные вносились из разных форм в одни и те же переменные.
Второй вариант годится для очень немногословных форм да и врядли его можно применять более чем для двух языков.

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

К счастью, для нашего текущего проекта эти ограничения несущественны, поскольку все формы будут на русском.

PS.
В демо версии можно увидеть двуязычные формы (английский/испанский)
надо разобраться, как они это делают.

Если внести данные в английскую форму, то по-испански ее уже не откроешь.

О локализации

В документации раздел о локализации здесь:
https://docs.openclinica.com/3.1/technical-documents/openclinica-and-internationalization

В настоящий момент в стандартной поставке русского языка нет.

Первый

Этот блог создан для заметок о локализации и вообще о работе с программой OpenClinica.
Никакой системы, никакой литературной обработки, просто важные моменты, которые надо где-то сохранить.
Может кому еще пригодится.