Справочные данные
В некоторых случаях достаточно перейти на внешние данные через ссылку (например, веб-страницы). 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 может на этот раз обладать доступным пакетом данных)