You are here: Foswiki>Gnumed Web>GmManualReportGeneratorRu (11 Feb 2013, IvanLykov)EditAttach

Генератор отчётов GNUmed

GNUmed предлагает два принципиально разных способа для поиска в базе данных:

  1. по EMR текущего активного пациента
  2. по всей медицинской базе данных, независимо от активного пациента

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

Область действия

Плагин предназначен для создания простых отчетов. Мощность этого средства не выходит за рамки того, что можно сделать в PostgreSQL. Однако, можно расширить PostgreSQL процедурным языком "R" (на самом деле, любым другим), чтобы значительно высвободить статистическую мощь напрямую из SQL-запроса.

Для чего-либо более сложного (например, последующей обработке результатов отчета), нужно обратиться к пользовательским сценариям, генераторам страндартных отчетов или средствам интеллектуального анализа данных, таким как NetEpi.

Использование

Создание отчетов

Для создания отчета из базы данных необходимо выполнить запрос SQL. Запрос должен вводиться в поле Команда (SQL) плагина Отчеты. Нажмите далее кнопку [Пуск]. Результаты будут показаны в списке внизу. Столбцы списка будут соответствовать столбцам таблиц(ы) базы данных, собирающих данные из запроса. Можно использовать SQL синтаксис псевдонимов столбца AS, чтобы имена столбцов базы данных отражались ('преобразовывались'), КАК более понятные обозначения.

Вот некоторые подсказки:

  • не нужно беспокоиться о начальных или конечных пробелах/символах переноса строк
  • запрос может занимать несколько строк
  • не нужно - но можно - заканчивать запрос точкой с запятой (";")
  • можно вставить текст запроса откуда-нибудь через буфер обмена
  • можно перетащить файл в плагин Отчеты и GNUmed интерпретирует его содержимое, как запрос для выполнения
    • обратите внимание, что нужно перетащить файл в область плагина вне рабочего поля команды запроса (будет улучшено позднее).

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

  • запросы запускаются только на чтение с учетными данными пользователя, который вошел в этот клиент
    • возможны без записи в базу данных, даже не как побочный эффект запроса select my_writing_func()

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

  • можно ограничить запрос для текущего активного пациента, включив в оператор WHERE поле подстановки $<ID_active_patient>$ с чем-то вроде: <table_or_view_relatable_to.pk_identity> = $<ID_active_patient>$ или подобным

      EXISTS (
         SELECT 1
         FROM
            table_or_view_containing_else_relatable_to_pk_patient
         WHERE
            column_containing_pk = $<ID_active_patient>$
         )
      ;

Визуализация отчетов

Нажатие кнопки [Визуализировать] позволит выбрать столбец из списка результатов отчета из каждой x- и y- оси. Данные в этих столбцах извлекаются из отчета и отправляются для отображения в gnuplot.

Повторное использование определения отчета

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

Если нажать [Сохранить], определение отчета будет сохранено в базе данных. Если имя отчета уже известно в базе данных, имеющееся определение отчета будет перезаписано. Если не будет создано новое определение отчета.

Нажатие [Поделиться] вышлет определение отчета (имя и запрос - больше ничего) в список рассылки сообщества GNUmed для совместного использования. Оно будет анонимным. Если для него нужно получить авторство, то таковое необходимо активно приписать в списке рассылки.

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

Для вашей ориентировки кнопка [Схема] приведет к документации схемы базы данных GNUmed в нашей вики.

Запросы на выборку

Сколько неисключенных пациентов остается в базе данных практики?
   select count(*) from dem.identity
   where deleted is FALSE / TRUE
   where deceased is NULL / NOT NULL

Перечислить моих пациентов в этой базе данных (надеюсь, меньше 1024):
   select lastnames, firstnames, title, pk_identity AS pk_patient
   from dem.v_basic_person
   where dem.v_basic_person.lastnames is NOT NULL
   order by lastnames, firstnames

Перечислить пациентов с отдельным почтовым кодом
select number, street, dem.v_basic_person.lastnames, dem.v_basic_person.preferred, dem.v_basic_person.firstnames, suburb, urb, postcode, pk_identity as pk_patient
from
   dem.v_basic_person
      inner join
   dem.v_pat_addresses
      using (pk_identity)
where
   LOWER(dem.v_pat_addresses.postcode) = 'inputDesiredPostalCodeHereInLowerCase'
order by
   street, number

Перечислить пациентов, ожидающих более 14 дней (без указания waiting_zone):
select lastnames, firstnames, title, comment, waiting_time_formatted, pk_identity as pk_patient
   from
       clin.v_waiting_list
      where
         waiting_time < '14 days'
      and waiting_zone is NULL

A query that (new in gnumed_v9) can search for patients based on the diagnostic code
   select *
   from
      dem.v_basic_person
         inner join
      clin.v_coded_item_narrative
         using (pk_identity)
   where
      code = ...
      and coding_system = ...
      and soap_cat = ...
   ;

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

   select *
   from
      dem.v_basic_person
         inner join
      dem.v_person_comms / dem.v_person_jobs / dem.v_external_ids4identity
         using (pk_identity)
   where
      dem.v_person_comms.url = ... /
      dem.v_person_jobs.l10n_occupation = ... /
      dem.v_external_ids4identity.value = ...
   ;

Запрос, выбирающий сообщения из таблицы аудита для входящих, удаленные в течение последних 7 дней, упорядоченные по последнему измененному

SELECT *
FROM audit.log_message_inbox
WHERE
   fk_staff = <staff ID of provider>
      AND
   audit_action = 'DELETE'
      AND
   audit_when > (now() - '7 days'::interval)
ORDER BY
   <audit_when / orig_when / modified_when> DESC
;

Запрос, определяющий авторегистрацию физических лиц, например в результате импорта данных

SELECT  * from dem.clin_ext_id_type, dem.identity where
dem.clin_ext_id_type.name = "lab autoimport fake person" WHERE
dem.clin_ext_id_type.fk_person = dem.identity.pk
;

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

The patients I would most worry about would be those who
- remain our responsibility (they did not abandon us)
   --> last seen in the most recent 6 (?) months
- and have an active issue or episode of certainty of A or B or C that is
   --> persisting over multiple encounters
      >= 2 encounters if symptom(s) are "alarming" or "worsening"
      >= 3 encounters if B or C

Many patients have a chronic single symptoms at level A, and maybe a  
chronic symptom complex at level B, but &#8211; as long as their episode is  
not worsening (or provided the patient's episodes are not becoming more 
frequent which would be a separate clinically informative query) &#8211; then 
it may be tolerable to optionally and by default omit such patients with 
chronicity of > 6 or 9 months from inclusion in the result of a query if 
the purpose is "who must I make sure I do not overlook a condition that I 
should perhaps be diagnosing?"

Примечание по бэкэнду

Запросы отчета хранятся в cfg.report_query.
Topic revision: 11 Feb 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark