You are here: Foswiki>Gnumed Web>GmManualReferenceDataRu (29 Jan 2013, IvanLykov)EditAttach

Справочные данные

В некоторых случаях достаточно перейти на внешние данные через ссылку (например, веб-страницы). GNUmed обеспечивает для них различные меню и настраиваемые кнопки.

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

Хотя, такой импорт может быть сделан вручную через такие средства, как psql (конечно, с паролем gm-dbo), релиз 1.0 GNUmed вызывает поддержку пакетов скриптовых данных.

Пакеты данных

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

  • не стоит заранее загружать базу данных GNUmed потенциально нежелательной справочной информацией
  • загрузка может быть уменьшена по размеру
  • один простой шаг установки и обновления через меню GNUmed, которое может сделать любой администратор практики GNUmed (вооруженный паролем gm-dbo)

Текущие доступные пакеты данных позволяют

  • установить канадские лекарственные патентованные препараты и их ингредиенты и заполнить таблицу вакцин
  • заполнить, при отсутствии, анатомо-терапевтическо-химические классификационные коды (ATC - Anatomical Therapeutic Chemical ) для названий препаратов, которые соответствуют названиям INN или подключенным синонимам
  • изменить (верхний / нижний) регистр названий препаратов, используя систему TALLman для лучшего распознавания одинаково произносимых препаратов
  • размещены здесь: пакеты данных:

Файл конфигурации, в котором находятся ссылки на эти пакеты:

Общие инструкции по подготовке пакета данных:

  • положите все SQL в файл, называемый install-data-pack.sql
  • создайте zip-файл с соответствующим именем, который содержит файл install-data-pack.sql на верхнем уровне

  • файл SQL не может использовать psql-level \copy
  • уровень SQL COPY не может быть использован, потому, что (одно из):
    • файл данных должен находиться на сервере
    • файл данных должен быть доступен для чтения пользователю демона сервера
    • потребуется подключиться как суперпользователь (postgres)
  • не изменяйте схему базы данных за пределами схемы staging. - пакет данных даст сбой
  • при необходимости, можно использовать схему staging.
  • сначала DROP ваши таблицы организации, надстроенные в \unset ON_ERROR_STOP ... \set ON_ERROR_STOP 1
  • затем BEGIN транзакцию
  • затем (пере-) CREATE таблицы организации и сделайте всю работу, включая передачу данных в рабочие таблицы
  • затем commit транзакцию
  • затем DROP таблицы организации, опять же надстроенные в \unset ON_ERROR_STOP ... \set ON_ERROR_STOP 1
  • вышеуказанное может быть повторено внутри одного install-data-pack.sql, если имеется несколько порций самодостаточных данных (например, коды ATC и вакцин)
  • пакет данных должен быть перезапускаемым без каких-либо нежелательных эффектов, независимо, запускался он уже или нет, и заканчивался сбоем или нет - это означает, что он должен сначала проверяться на наличие до INSERT/UPDATE данных

Обзор ограничений и требований к справочным данным

Объединение справочных данных по медикаментам

Справочные данные по медикаментам могут охватывать несколько потенциальных источников:

  • брэндовые данные или о товарном знаке (они могут включать патентованные вакцины)
    • хранящиеся на ref.branded_drug
  • информация об активном ингредиенте или употребляемом веществе
    • хранящиеся в ref.consumable_substance, где строка должна точно содержать три атрибута {описание, дозировка, единица измерения}

Патентованные препараты получают внешний ключ в двух направлениях. Наиболее часто используется ссылка ref.lnk_substance2brand.pk, которая означает, что употребление патентованного препарата может быть связано с записью substance_use по пациенту. Второе направление - это вакцины, где ключ бренда является прямой ссылкой в таблице clin.vaccine.

Можно отслеживать источник данных по патентованным препаратам вашей практики, используя столбцы ref.branded_drug fk_data_source, external_code и external_code_type.

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

Если обновляете справочные данные, то также нужно учесть, что опустошение таблицы патентованных препаратов и потребляемых ингредиентов может быть даже нецелесообразно, когда не используются их записи (отсюда связаны внешними ключами), потому что эти таблицы могут также содержать:
  • в случае ref.branded_drug
    • несколько экземпляров 'вакцин-дженериков' is_fake для учета целого ряда показаний, когда практическое изготовление неизвестно (но, сказав это, GNUmed приходит с
функцией для воссоздания того, что случайно удаляется)
  • в случае ref.consumable_substance= …
    • различных безрецептурных ингредиентов (и, вероятно, неутвержденных)

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

При удалении брендов может помочь указание, что
  • строки в clin.substance_use ссылаются на ключ бренда косвенно через fk ref.lnk_substance2brand
  • строки в clin.substance_use не должны ссылаться на бренд – они альтернативно могут ссылаться на один ингредиент (независимо от торговой марки) из столбца fk_substance; это обеспечивает основу для отключения связи клинической записи с брендом, когда целесообразно. Одним из примеров может быть, когда аптека запоздало заменила неизвестный бренд для всего, что было зарегистрировано в GNUmed. Ретроспективный аудит записи GNUmed для отражения предела известной информации может быть разумен, но будут доступны бренды, которые имели только одно активное вещество.
  • строки в clin.vaccination будут ссылаться на clin.vaccine.pk, который сам ссылается на ref.branded_drug.pk (кроме того, будет существовать clin.vaccine.pk, представленный в clin.lnk_vaccine2inds и clin.vaccine_batches) и, таким образом, все эти ограничения ссылочной целостности должны быть соблюдены для удаления брендов, которые были связаны как вакцины

При добавлении брендов работа не завершена, пока:
  • эти бренды, являющиеся вакциной, вставляются в clin.vaccine, чьи столбцы 'id_route' и 'is_live' (и 'fk_brand') не могут быть NULL и
  • бренды невакцин (а, при необходимости, и вакцин) косвенно связаны с их составными веществами – которые могут существовать или уже нет – через одну или несколько ссылок в ref.lnk_substance2brand

Изменение лекарственных названий

Это может быть сделано на месте, к примеру:

  • исправление орфографических ошибок
  • если препарат выведен с рынка, как небезопасный (переименуйте его в: "НЕ НАЗНАЧАТЬ: orginal-drug-name")
  • применение методики TALLman для повышения безопасности препарата, который использует более отличающийся регистр букв аналогичных названий препаратов (и для которых GNUmed может на этот раз обладать доступным пакетом данных)
Topic revision: 29 Jan 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