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

Принципы хранения информации GNUmed - рассуждение после разработки базы данных

Общие понятия

1. Акцент на клинической информации для GP

Сначала и прежде всего учитывайте, что вся БД предназначена для наилучшего хранения: данных по оказанию медицинской помощи на уровне GP

2. Независимость клиента (режим презентации)

Информация хранится независимо от того, каким образом она отображается.

3. Соответствие версии клиента и базы данных

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

Указанное верно, за исключением случаев, когда клиент GNUmed запускается в режиме --debug. В рабочих условиях люди не должны использовать режим --debug, за исключением случаев, когда:

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

4. Защита данных

  • всегда используйте внешние ключи надлежащего типа данных, проверяйте ограничения, триггеры и правила для защиты целостности клинических данных
  • по умолчанию, транзакции базы данных только для чтения
    • если просто подключиться к базе данных, доступ ко всему, что имеете, будет только для чтения, независимо от того, какие разрешения у ваших таблиц
    • если нужно записать данные, понадобится задать транзакцию на чтение-запись:
      • set default_transaction_read_only to off
      • оно применимо, пока соединение открыто
    • если доступ к базе данных через модуль промежуточного ПО GNUmed gmPG2.py, то нужно явно запросить подключение на чтение-запись, при необходимости такового

Хранение отдельных типов данных

  • формы для заполнения и отправки на печать/факс/e-mail и т.д.

1. Обзор клинических таблиц

[не завершен! Желательно добавить диаграмму, показывающую также отношения, подобно 1:n или n:m для важных клинических таблиц]

Таблица прототипа всей клинической информации: clin_root_item (является абстрактной, то есть она никогда не используется для хранения информации, а скорее, как шаблон для извлечения из нее дочерних таблиц)

Таблица 'clin_root_item' наследует ее поля для вторичных/дочерних таблиц (перечислены здесь без таблиц аудита "log_"):

  • allergy
  • clin_aux_note
  • clin_medication
  • clin_narrative
  • form_instances
  • lab_request
  • referral
  • test_result
  • vaccination

2. Свободный текст & коды/типы/категории

Подход состоит в хранении freetext (так как это основной тип информации для GP) и расширения через целевые таблицы, такие как таблицы кода или типа (см. 3.).

3. Тип и кодирование клинической информации

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

Осуществляется двумя способами:

  • Все потомки clin_root_item наследуют поля soap_cat. В этой области одна из фиксированных категорий SOAP (S/O/A/P) должна назначаться для этой строки. Некоторые дочерние таблицы имеют свое значение soap_cat, фиксированное через ограничение.

  • Любая строка в дочерней clin_root_item может быть "помечена" произвольным количеством типов (отношение многие-к-многим между clin_root_item и clin_item_type через lnk_type2item).

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

Другими словами, тип — это атрибут содержания, пока код имеет (представляет) контент - выраженный на языке "кода".

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

  • S: то, что было сообщено (Субъективно)
  • O: то, что было выявлено (Объективно)
  • A: какое было мнение по этому поводу (Оценка)
  • P: что было сделано (запланировано сделать) (План)

4. Наследование из clin_root_item

Имеется множество клинических таблиц, подобных vaccination, allergy, lab_request (см. 1.). Все, выходящие за рамки описательного свободного текста (но часто включенные), являются более специализированными, расширенными клиническими таблицами. Некоторые расширенные таблицы, конечно же, все еще отсутствуют, такие как медикаменты и т.д.

Способом посмотреть схему для клинического материала (или "Где и какую клиническую информацию размещать?") является:

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

  • таблица clin_root_item предоставляет основные поля, которые должны иметь все клинические элементы, например, аудит, обращение, случай, категория soap и описательное поле

  • дочерние таблицы clin_root_item расширяют простое повествование с большими клиническими полями

Пример: Таблица вакцинации (одна из дочерних clin_root_item)

encounter                   episode (-- optionally --> health issue)
         \                /
           clin_root_item --> type(s)
           --------------
           - soap_cat
           - narrative
               ^
               |
           (inherits)
               |
           vaccination
           -----------
           - additional fields
           - ...
         /                     \
  vaccine                       schedule

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

Клинические описания, таким образом, преднамеренно объединены, а не разбросаны по нескольким таблицам. Ключевой фактор дополняет для облегчения текстовой поиск!

PostgreSQL vs других баз данных

Проект собран на основе Postgresql с учетом его сильных сторон, включая ссылочную целостность, поддержку наследования, триггеры и ряд других соображений. Хотя некоторые утверждают, что программа может и должна уметь работать "с любой серверной частью", 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