CC BY
86
ISSN 2079-3316 ПРОГРАММНЫЕ СИСТЕМЫ: ТЕОРИЯ И ПРИЛОЖЕНИЯ №3(30), 2016, с. 79-97 удк 61:007
Д. В. Белышев, Е. В. Кочуров
Перспективные методы работы с данными в медицинских информационных системах
Аннотация. В работе рассматриваются перспективные методы работы с данными в медицинских информационных системах (МИС). Выполняется анализ требований к технологиям представления данных в медицинских информационных системах, предлагается подход к формированию специализированных хранилищ данных, учитывающих требования к данным, предъявляемые МИС. Также предлагается подход к решению задачи обмена данными медицинской информационной системы с другими компонентами в распределенной информационной среде.
Ключевые слова и фразы: медицинская информационная система, хранилища данных, адаптивная архитектура.
Введение
Медицинские информационные системы и в среде экспертного сообщества, и на уровне высших органов государственной власти признаны необходимым инструментом для повышения качества оказания населению медицинской помощи. О важной роли МИС в работе медицинских организаций и системы управления медицинской помощи говорилось на прошедшем 22 апреля 2016 года заседании Экспертного совета по здравоохранению Комитета Совета федерации по социальной политике [1]. Там же отмечалось, что рассматривается три уровня функционирования медицинских информационных систем: федеральные, региональные и госпитальные МИС. Важнейшей задачей информатизации медицины в целом обозначается создание единого структурированного информационного пространства здравоохранения, формирование систем мониторинга здоровья и здравоохранения в регионах и федеральном центре, для чего требуется развитие единых стандартов функционирования информационных систем и взаимодействия между ними.
© © ©
Д. В. Белышев, Е. В. Кочуров, 2016
Институт программных систем имени А. К. Айламазяна РАН, 2016 Программные системы: теория и приложения, 2016
Задача эффективного представления данных медицинских информационных систем является непростой, в силу того, что данные в МИС достаточно различны по смыслу (медицинские, учетные, финансовые), по формату (структурированные, слабо структурированные и неструктурированные), по методам представления и т.п. Анализ методов представления данных в медицинских информационных системах приведен в работе [2]. Для эффективной практической реализации методов обработки данных в МИС требуется обеспечить выбор и провести адаптацию наиболее подходящих для этого технологий.
В настоящей работе будут исследованы две ключевые, на наш взгляд, проблемы представления и хранения данных в МИС:
• повышение эффективности работы с данными разных типов, включая унификацию методов хранения, повышение производительности и упрощение методов манипуляции данными;
• обеспечение обмена данными разных типов в сложных распределенных информационных системах.
Решение обозначенных проблем мы видим в разработке технологии универсальных хранилищ данных.
1. Технологии эффективного представления данных в медицинских информационных системах
Современные медицинские информационные системы являются подклассом ERP-систем (англ. Enterprise Resource Planning, планирование ресурсов предприятия), в силу чего МИС производят обработку различных типов данных: медицинских, статистических, данных материального, финансового и кадрового учета, а также всевозможных вспомогательных сведений, так или иначе касающихся лечебно-диагностического процесса. Все данные, с которыми имеет дело медицинская информационная система, можно условно разделить на три группы по способу представления [2]:
• структурированные данные простых типов (числа, строки, даты), которые хорошо укладываются в понятие реляционных структур;
• слабо структурированные документы, под ними мы понимаем объекты, внутренняя структура которых прозрачна для МИС, но недоступна для операций реляционной алгебры;
• неструктурированные (в большинстве своем бинарные) объекты разных форматов (графические, документы различных офисных редакторов, специализированные бинарные объекты), с содержимым которых МИС непосредственно не работает.
Методы работы с описанными группами данных достаточно сильно отличаются. Современные универсальные системы управления базами данных, несомненно, позволяют манипулировать данными всех типов, но на практике такая унификация обычно представляет собой компромисс: если для одних задач принятое техническое решение эффективно, то для других оно же создает определенные трудности. Для эффективного решения задач и учета их специфики сформировалось два течения развития технологий создания СУБД — это реляционные и нереляционные базы данных [3]. Формально, они могут обладать сопоставимыми выразительными возможностями, но в практике их использования все же прослеживается ориентация на разные классы задач. Рассматривая задачи, решаемые МИС, мы видим, что они почти в равной степени требуют как реляционного, так и нереляционного подходов, поскольку все три приведенные выше группы типов данных представлены в медицинских информационных системах очень широко. Вне зависимости от того, какое направление развития разработчиком МИС было выбрано, ему приходится сталкиваться со сложностями, организуя эффективное управление различными типами данных. Всё это заставляет разработчиков МИС либо пытаться унифицировать требования к работе с данными, тем самым ухудшая потребительские свойства своих продуктов, либо применять комбинированные решения, включающие в себя как реляционные, так и нереляционные хранилища. Опыт специалистов Группы компаний Ин-терин в реализации медицинской информационной системы Интерин PROMIS [4] также свидетельствует о необходимости комбинированного представления данных [5], получившего название «объектно-реляционный подход». Разработанная еще в 1996 году технология «информационных объектов» оказалась достаточно успешной и позволила эффективно создавать крупные медицинские информационные системы. Вместе с тем, в связи с повышением требований к МИС, особенно в части интеграции в единые информационные пространства, создаваемых на ведомственном, региональном и федеральном уровнях, необходимо дальнейшее развитие технологий работы с данными в медицинских информационных системах.
1.1. Универсальные хранилища данных в медицинских информационных системах
Задача повышения скорости и эффективности обработки разных типов данных заставляет искать специализированные методы работы с ними, чтобы за счет учета особенностей и ограничений специализированного класса медицинских информационных систем обеспечить необходимый прирост производительности обработки информации и удобства работы с ней.
Предлагаемый подход получил название «универсальные хранилища данных в медицинских информационных системах» (далее «хранилища»). Основные условия и требования, предъявляемые к хранилищам:
• хранилища предполагается строить с использованием существующих промышленных реляционных СУБД;
• первичными единицами хранения данных должны служить документы — слабоструктурированные объекты, которые, в свою очередь, могут содержать данные, требующие четкой структуры и быстрого доступа;
• работа с хорошо структурированной информацией, для которой требуется обеспечить быстрый доступ из пользовательского интерфейса (поиск и показ списков), а также эффективное формирование статистических и аналитических отчетов, должна обеспечиваться за счет индексации хранилищ в реляционных структурах (подобные принципы лежат в основе многих NoSQL баз данных, например, MongoDB [6] или CouchDB [7]).
Важным следствием описываемого подхода является закрепление главенствующей роли медицинского документа перед статистическим реестром. Соблюдение этого принципа, как мы увидим далее, позволяет согласовать медицинскую и учетную политику в МИС, закрепив связь статистического, финансового и материального учета с первичными медицинскими документами. Помимо обеспечения логической целостности медицинского и учетного контуров системы, документ-ориентированная технология хранения данных позволяет более технологично решать вопросы, связанные с интеграционными процессами, обеспечивающими взаимодействие МИС медицинской организации с другими информационными системами.
Частным, но достаточно важным случаем работы МИС является формирование «учетного контура» работы системы, при котором данные вносятся операторами с бумажных носителей [8]. Такой режим работы наиболее важен на начальных этапах создания информационной системы управления медицинской организации, а также и в дальнейшем применяется для ряда задач. Учетный режим предполагает непосредственную работу с плоскими реестрами учетных данных, что входит в противоречие с документ-ориентированным подходом к работе в системе. Следуя принципу первенства документа перед статистическим реестром, решение должно строиться через введение дополнительных первичных учетных документов по всем основным типам данных, чтобы даже в случае отсутствия полноценных врачебных документов технология работы с реестрами не нарушалась.
1.2. Особенности представления данных учетных регистров
В группе структурированных данных, которыми оперирует МИС, выделяется подкласс учетных задач, связанных с финансовыми и товарно-материальными операциями. В работе [2] было показано, что наиболее подходящим техническим решением для этих задач является использование учетных регистров, основывающихся на принципах бухгалтерского учета. Перечислим основные возможности, которые требуются от такой структуры данных:
• фиксация операций с указанием даты операции, документа-источника, аналитических, суммовых и количественных значений, подлежащих учету;
• формирование сальдовых, оборотных, оборотно-сальдовых ведомостей в различных аналитических срезах;
• обеспечение ссылочной целостности данных об операции в части связи с документом-источником и используемой в аналитических срезах НСИ.
Технической особенностью формирования сальдовых и оборотных ведомостей является вычислительная сложность получения оборотов за длительные периоды, а также остатков по срезам, в которых за время работы системы накопился значительный массив операций. Для решения этой проблемы используются предвычисленные таблицы полных остатков за все интервалы времени по каждой встречающейся комбинации значений аналитического среза, а также регулярные срезы остатков с интервалом, выбираемым исходя из прогнозируемого
объема данных: месяц, квартал, год. Выбор подходящего интервала обеспечивает баланс между объемом избыточного хранения данных и скоростью формирования отчетности.
Чтобы получить лучшее представление о методах работы с учетными данными, рассмотрим требование логической целостности данных, обеспечение которого является критически важным для построения системы учета. Ранее мы отмечали, что учетные и медицинские данные принципиально различаются между собой, поэтому различны методы их хранения и обработки. Объединение этих данных в общих структурах значительно усложняет работу МИС. Одна из основных причин, в силу которой разработчики прибегают к такому объединению — это обеспечение логической целостности медицинской и учетной информации и обусловленности прихода и расхода соответствующими медицинскими документами. Принимая решение о разделении двух этих сущностей, необходимо обеспечить их непротиворечивость, и это условие накладывает серьезные ограничения на способы представления и алгоритмы работы как с учетными данными, так и медицинскими документами.
Очевидно, что проводки, фиксируемые в учетных регистрах, должны быть связаны с обосновывающими их первичными документами. При этом, с одной стороны, сами документы могут быть различны и, как следствие, могут находиться как в одном хранилище, так и располагаться физически в разных хранилищах, с другой стороны, могут формироваться разные учетные регистры из одного типа документов. Таким образом, возникает необходимость поддерживать ассоциативную связь многие-ко-многим: произвольные хранилища документов могут формировать произвольные регистры учета. Приведем некоторые примеры, иллюстрирующие данное утверждение.
Рассмотрим два регистра учета, которые точно должны иметь различную структуру и храниться независимо друг от друга — это регистр учета оказанных услуг и регистр учета материальных ценностей. Рассмотрим счет 20 «Основное производство», на котором будут учитываться оказанные пациенту услуги; он будет иметь только денежное представление. В то же время счет 10 «Материалы», где будет вестись учет расхода ТМЦ, помимо суммового должен иметь натуральное выражение. Одним из типов документов, обуславливающих оказание услуг и расход ТМЦ, может быть «Прием врача-стоматолога». В этом документе врачом описывается лечебно-диагностический процесс и дается обоснование оказанного лечения, которое в конечном
итоге находит свое отражение в предоставлении определенных услуг и приводит к расходу некоторого количества материальных ценностей. Командой для проведения операций по учетным регистрам является подтверждение готовности (подписание) электронного документа врачом. В этот момент согласно настроенным типовым операциям должны быть выполнены две проводки по 20 и 10 счетам для учета оказанных услуг и расхода материальных ценностей. При этом для обеих проводок, физически расположенных в разных учетных регистрах, будет использован общий обуславливающий документ. В дальнейшем вся эта структура должна будет изменяться синхронно: так, в случае необходимости корректировки врачом документа, должна быть проверена возможность корректировки и соответствующих проводок. Здесь необходимо учитывать, что задействованные проводки могут быть включены в уже закрытые периоды. Это накладывает дополнительные ограничения на работу врачей с документами. Описанная дисциплина несомненно усложняет работу пользователей в системе, поскольку корректировки документов производятся достаточно часто, однако она обеспечивает непротиворечивость данных.
Рассмотрим другой пример, который иллюстрирует работу с одним регистром для нескольких различных документов. Предположим, что на счете 20 «Основное производство» будут фиксироваться все оказываемые в организации медицинские услуги. Первичные документы, которые обуславливают оказание услуг, могут быть очень различны: это осмотры врачей лечебного профиля в поликлинике, консультации и диагностические обследования в параклинических службах, результаты лабораторных исследований. Услуги фиксируются при регистрации оперативных вмешательств, пребывании пациента на койке в стационаре и т.п. Также штатной является ситуация одновременной работы врачей в информационной системе и операторов по вводу данных в МИС с бумажных носителей. В обоих случаях регистрируется факт врачебного приема, но в одном случае в качестве первичного документа выступает полноценный медицинский осмотр, а в другом — некоторый учетный бланк, фиксирующий только статистические характеристики проведенного врачом приема. Вместе с тем, вне зависимости от типа документа, метода его регистрации и физического хранилища, учет оказанных услуг должен вестись в одном учетном регистре, отражающем состояние счета 20 «Основное производство».
Р ис.1. Схема взаимодействия хранилищ документов и учетных регистров
Таким образом, организацию хранения учетных регистров и их связи с первичными медицинскими документами можно отобразить следующей схемой (рис. 1). Рисунок иллюстрирует возможные связи между хранилищами документов и учетных регистров.
2. Методы построения универсальных хранилищ данных в 1МИС
Отметим, что помимо уже сформулированных требований к методам работы с данными в МИС, важным требованием к структурам хранения данных является возможность изменять представление одних; и тех же данных в соответствии с изменяющимися тсловиями функционирования информационной системы. Для выполнения данного требования хаынилища должны иметь возможность динамически менять степенв структурированности данных — как повышать уровень реляционной детализации в влучаях, когда необходимы дополнительные аналитические возможности или возникаюы новые требования к ссылочной целостности, так и наоборот — снижать, упаковывая выводимые из интенсивного употребления данные в слабоструктурированные или неструктурированные формы, уменьшая тем самым объемы хранимых СУБД данных и нагрузку по проверке связности.
Подобные преобразования требуют обеспечить универсальную инфраструктуру доступа к данным, чтобы смена физического представления данных не требовала перестройки прикладных модулей системы. Обычно эту задачу решают ORM-фреймворки (Object-Relational Mapping, объектно-реляционное отображение) [9].
Рис. 2. Схема компонент хранилища данных
Используя перечисленные выше принципы и подходы (Мо80Ь базы данных, СЖМ-фреймворки, объектно-реляционный подход, бухгалтерские модели учета, стандарт представления медицинских данных орепЕНИ,), мы предлагаем следующий компонентный состав универсальных хранилищ данных в МИС:
• модуль реляционных связей, отвечающий за управление набором внешних ключей объекта данных;
• модуль слабоструктурированных данных, позволяющий присоединять к объекту набор данных произвольной структуры, а также индексировать их в целях повышения производительности запросов;
• модуль неструктурированных данных, обеспечивающий возможность присоединять к документу бинарные данные;
• модуль учетных функций, обеспечивающий поддержку учетных операций в системе;
• модуль версионности, позволяющий организовать хранение историчных данных.
На различных этапах жизненного цикла системы одно и то же свойство объекта, в зависимости от текущих потребностей, может поддерживаться разными модулями. Более того, совместное использование нескольких модулей позволяет сократить число сущностей, необходимых для моделирования тех или иных понятий предметной области.
Структура описываемых хранилищ данных представлена на схеме (рис. 2). На рисунке указано, что системные поля, реляционные связи
и слабоструктурированные данные физически располагаются в одной реляционной таблице, при этом обеспечивается поддержка широкого спектра решений: от полностью реляционного хранения, когда все без исключения поля будут явно вынесены в таблицу с необходимыми внешними ключами, до полностью объектного хранения, когда все данные будут представлены в слабоструктурированном виде. С каждой основной таблицей хранилища может быть ассоциировано несколько индексных таблиц, куда будут синхронно выгружаться данные из объектной (слабоструктурированной) части хранилища. Для крупных (в частности, бинарных) объектов возможно использование специального объектного хранилища, реализация которого может быть выполнена как в виде реляционных таблиц, так и в виде автономного сервиса, содержащего объекты в файловой системе вне базы данных.
2.1. Модуль реляционных связей
При моделировании понятий предметной области данный модуль позволяет устанавливать классические реляционные связи между сущностями, обеспечивая строгую ссылочную целостность данных стандартными средствами реляционной СУБД.
Модуль реляционных связей позволяет выделять из слабоструктурированных объектов хранилища отдельные атрибуты, которые должны участвовать в реляционных связях в качестве стандартных внешних ключей. При этом, если поле добавляется к таблице, в которой уже содержатся данные, происходит автоматическое заполнение поля из других модулей, если это возможно. Таким образом, часть вопросов конвертации данных при обновлениях системы решается автоматически.
2.2. Модуль слабоструктурированных данных
Данный модуль представляет собой контейнер, допускающий хранение данных произвольной текстовой структуры, и является подходящим способом хранения для большинства документов (в частности врачебных). Это позволяет избежать правки схемы данных в случаях, когда меняется состав реквизитов документов, формат обмена данными со сторонними системами и т.п. Следует учесть, что просто хранить данные недостаточно, необходимо иметь возможность искать, классифицировать, строить отчеты — т.е. обеспечить реляционный доступ к ним. Эту задачу решает механизм индексирования:
по слабоструктурированному документу можно построить множество индексов, которые с точки зрения реляционной СУБД являются обычными таблицами и представлениями. Главное их отличие в том, что их структура диктуется не содержанием данных, а способом их использования. Такой подход к слабоструктурированным документам активно развивается в ряде платформ, а в наиболее чистой и яркой форме реализован в СУБД CouchDB, как способ работы с большими данными (Big Data) [7].
2.3. Модуль неструктурированных данных
Модуль обеспечивает манипуляции с бинарными (как правило, мультимедийными) данными больших размеров, включая размещение, поиск, предоставление по запросу, а также обладает возможностью выносить эти данные за пределы СУБД с целью снижения стоимости обслуживания базы данных. Файлы, прикрепленные таким способом к сущности в базе данных, рассматриваются как ее составная часть при модификации, копировании, репликации и прочих операциях.
2.4. Модуль учетных функций
Модуль позволяет присоединять к объекту данных набор учетных операций, отражающих движение по учетным регистрам. С точки зрения объекта, набор операций является фрагментом данных строго определенной структуры, которая интерпретируется механизмом учетных регистров как движение по соответствующим регистрам. С одной стороны, хранение учетных операций достаточно специфично в сравнении с прочими данными — учетная операция имеет плоский набор данных, который включает особый состав системных полей, в частности, ссылку на документ-источник, набор ссылочных аналитических полей, набор суммовых и количественных полей. Далее, учетный регистр сопровождается вспомогательными таблицами остатков и специфичным API взаимодействия. Указанные особенности достаточны для того, чтобы учетные регистры выделились в самостоятельный механизм. С другой стороны, любая операция обязана иметь основание — документ-источник, что делает данные учетных регистров зависимыми от основного хранилища данных.
2.5. Модуль версионности
Одним из существенных требований к медицинским информационным системам является необходимость видеть историю изменений по подавляющему большинству объектов данных, что также декларируется в технологии орепЕНИ [10], поэтому решение задачи версионности также включено в качестве модуля хранилища.
Каждое действие по изменению объекта данных приводит к созданию историчного среза состояния объекта, что дает ряд полезных возможностей:
• просмотр данных за прошедшие периоды происходит в контексте состояния нормативно-справочной информации, действовавшей на тот момент;
• повторное формирование отчетов за прошедший период всегда дает идентичный результат;
• версионность дает возможность автоматического разрешения конфликтов репликации класса «изменение измененной записи»;
• в случае расследований изменений критических данных имеется возможность восстановить полную картину, получив информацию не только о том, кто и когда изменял данные, но и что конкретно было изменено.
С точки зрения функционирования системы механизм версион-ности является полностью прозрачным: при обращении к данным система всегда предоставляет их в состоянии, актуальном контексту обращения. В части реализации он может быть выполнен или на тех же структурах данных (записи в таком случае должны иметь соответствующие статусы), или на дублирующих структурах. В таком случае при любой модификации данных (изменение, удаление) предварительно должны выгружаться текущие значения.
3. Методы организации обмена данными в распределенной МИС
Мы уже отмечали, что информатизация здравоохранения тесно связана с агрегацией данных во внешние информационные хранилища и с обменом данными между смежными информационными системами, поэтому хранилища данных должны обеспечивать эффективную работу в распределенных информационных системах. Результаты исследований мультипликативных структур для МИС медицинских
организаций, имеющих сложную внутреннюю организацию, приведены в ряде публикаций [11—13].
Выше мы отмечали, что в медицинских информационных системах ключевым объектом представления информации является документ, все остальные сущности являются по отношению к документу производными. Также нужно отметить, что хорошо себя зарекомендовал подход к репликации документ-ориентированных данных, когда реплицируемым объектом является документ, инкапсулирующий все необходимые для понимания содержания документа данные внутри своей структуры. Этот подход значительно упрощает задачу обмена данными, т.к. резко сокращает номенклатуру типов конфликтов репликации. В основном это достигается за счет ряда особенностей документ-ориентированного хранения данных:
• присвоение глобально-уникальных идентификаторов объектам данных;
• сведение числа внешних ключей (foreign keys) к минимуму;
• реализация механизмов версионности, работающих на уровне документа, как целого объекта, а не на уровне некоторых отдельных его частей.
Таким образом, слабоструктурированные и неструктурированные документы реплицируются с автоматическим разрешением большинства конфликтов:
• изменение измененной записи решается принятием двух версий в их хронологическом порядке;
• удаление измененной записи решается принятием версии и ее последующим удалением;
• удаление удаленной записи решается удалением.
Изменение удаленной записи решается либо вручную, либо настройкой политики: удалять или сохранять такую запись.
Для структурированных объектов данных, содержащих внешние ключи, не существует надежного метода репликации класса MasterMaster («главный-главный»), допускающего изменения данных на любом из взаимодействующих узлов (серверов). Для решения этой проблемы используется кластеризация данных по узлам: каждый кластер взаимосвязанных по внешним ключам данных может изменяться строго на одном мастер-узле. Например, в простейшем случае, система может быть настроена так, чтобы НСИ допускалось править исключительно на главном узле. В более сложных случаях, из НСИ могут
выделяться фрагменты, редактируемые на локальных узлах. Такая организация данных позволяет использовать стандартные методы разрешения конфликтов репликации, устоявшиеся для конфигурации Master-Slave («главный-подчиненный»).
Дополнительной сложностью репликации является репликация проводок учетных регистров. У проводок, в отличие от НСИ и слабоструктурированных документов, имеется необходимость выполнения бизнес-правил после приема данных: узел, принимающий пакет документов и связанных с ним операций, должен гарантировать, что правила (например, допустимый порог остатков по счетам) в результате сеанса репликации не будут нарушены. Методы решения конфликтов данного типа могут быть следующими:
• принимать данные инкрементально, с соблюдением хронологии операций;
• выделять единственный мастер-узел, который имеет право на проведение определенной группы операций;
• генерировать исключение и возвращать узлу-отправителю отказ в приеме для явного разрешения конфликта;
• автоматизировать разрешение конфликтов.
Ниже рассмотрим перечисленные методы боле подробно.
3.1. Инкрементальность и соблюдение хронологии
Метод инкрементальности (когда действие «принять» или «отклонить» выполняется над каждой операцией в отдельности, а не для пакета целиком) и соблюдения хронологии решает две задачи. Во-первых, соблюдение естественной хронологии операций в нормальной ситуации обеспечит выполнение всех бизнес-правил, т.к. будут исключены ситуации, когда списание со счета обрабатывается раньше, чем зачисление. Здесь следует отметить, что хронология операций не обязательно совпадает с хронологией ввода документов. Задача бизнес-правил учетного регистра состоит в том, чтобы обеспечивать целостность остатков на любой момент времени именно в хронологии операций. Во-вторых, в случае конфликта слияния операций по одному счету с разных узлов, как минимум, операции, предшествующие конфликтной, будут приняты.
Кроме того, инкрементальность подразумевает пропуск только операций, производимых со счетами, по которым возник конфликт.
Другими словами, из пакета репликации отклоняются только те операции (вместе с их документами-источниками), которые образуют цепочку движения конфликтного остатка. Однако, следует отметить, что пропуск только конфликтной операции, а не всей цепочки, может привести к наведенным конфликтам, усугубляющим ситуацию.
3.2. Выделение мастер-узла
Сложность этого метода заключается в том, что иногда требуются счета, агрегирующие операции, производящиеся на различных узлах, но использующие различные срезы аналитики. Например, система бюджетирования в распределенной архитектуре подразумевает общий план бюджетных счетов, и каждая организация проводит операции по данным счетам с указанием в качестве аналитического среза идентификатора своей организации.
Обеспечение бесконфликтности здесь достигается за счет согласованного конфигурирования доступных к проведению операций аналитических срезов на каждом узле и бизнес-правил. Под согласованностью в данном случае подразумевается, что запрещающие бизнес-правила конфигурируются таким образом, чтобы в каждом конкретном случае применения рассчитываться по набору данных, сформированному строго на одном узле.
3.3. Разрешение конфликтов
Очевидно, что описанных выше способов для предотвращения конфликтов недостаточно — всегда остается возможность ошибки конфигурирования или наведенных конфликтов, возникающих из-за конфликтов, накопленных и еще не разрешенных в предыдущих сеансах репликации. В этом случае репликация учетных регистров помимо стандартных может порождать специфический тип конфликта: нарушение бизнес-правила учетного регистра.
Узел-получатель, обнаружив операцию, приводящую к невозможности выполнения бизнес-правила, отклоняет из пакета репликации всю цепочку операций движения конфликтного остатка и отправляет сообщение администратору.
Администратор системы анализирует причину конфликта, устраняет ее и проводит внештатный сеанс репликации, доставляющий только данные разрешенного конфликта.
3.4. Автоматизация разрешения конфликтов
Некоторые виды конфликтов, не связанные с ошибками конфигурирования, могут разрешаться автоматически. Например, со счетами учета, используемыми для учета финансовых и материальных средств между организациями, типична ситуация, когда организация-получатель реплицирует на главный узел операцию прихода, для которой на главном узле еще нет операции расхода от организации-отправителя. В этом случае важна согласованность некоторых бизнес-правил в конечном счете, со скидкой на разрыв во времени. Будем называть такие бизнес правила «слабыми».
Механизм репликации принимает операции, нарушающие слабые бизнес-правила, но после прохождения полного цикла репликации, когда узел-получатель имеет актуальный набор операций со всех узлов, выполнение слабых бизнес-правил перепроверяется и, при необходимости, происходит оповещение администратора.
Заключение
В настоящей работе продолжено начатое в [2] исследование проблемы представления данных в медицинских информационных системах. В настоящее время МИС должны быть адаптивны к изменяющимся условиям функционирования и взаимодействию в сложных информационных комплексах, что повышает требования к технологиям представления, хранения и передачи данных. Реализация предложенных подходов должна существенно повысить потребительские качества разрабатываемых информационных систем, расширить их возможности и снизить затраты на разработку и сопровождение прикладных решений.
Список литературы
[1] Заседание Экспертного совета по здравоохранению Комитета Совета федерации по социальной политике, URL: http://council.gov.ru/ events/news/67020/ t 79
[2] Д. В. Белышев, Е. В. Кочуров. «Анализ методов хранения данных в медицинских информационных системах с адаптивной архитектурой», Программные системы: теория и приложения, 7:2 (2016), с. 85-103, URL: http://psta.psiras.ru/read/psta2016_2_85-103.pdf t 80,83,94
[3] М. Р. Когаловский. Энциклопедия технологий баз данных, Финансы и статистика, М., 2002. t 81
[4] Я. И. Гулиев, С. И. Комаров, В. Л. Малых, Г. С. Осипов, С. П. Пименов, М. И. Хаткевич. «Интегрированная распределенная информационная система лечебного учреждения (ИНТЕРИН)», Программные продукты и системы, 1997, №3. t 81
[5] В. Л. Малых, С. П. Пименов, М. И. Хаткевич. «Объектно-реляционный подход к созданию больших информационных систем», Программные системы: Теоретические основы и приложения, ред. А. К. Айламазян, Наука. Физматлит, М., 1999, с. 177. t 81
[6] MongoDB: база данных, URL: https://www.mongodb.com/ t 82
[7] Apache CouchDB: база данных, URL: http://couchdb.apache.org/t82,89
[8] М. С. Смирнов, М. И. Хаткевич. «Опыт комплексной информатизации многопрофильного лечебно-профилактического учреждения на основе системы Интерин PROMIS», Кремлевская медицина. Клинический вестник, 2012, №1, с. 85-89. t 83
[9] ORM: база данных, URL: https://ru.wikipedia.org/wiki/ORM t 86
[10] openEHR: база данных, URL: http://www.openehr.org/ t 90
[11] С. И. Комаров, Д. В. Алимов. «Мультипликативные структуры крупных ЛПУ», Врач и информационные технологии, 2015, №4, с. 24-32. t 91
[12] Д. В. Алимов, С. И. Комаров. «Особенности применения механизма многокомпонентности при информатизации крупных ЛПУ», Врач и информационные технологии, 2014, №5, с. 29-36. t 91
[13] Д. В. Алимов. «Поддержка многокомпонентности в медицинских информационных системах», Программные продукты и системы, 2009, №2, с. 31-34. t 91
Рекомендовал к публикации к.т.н. Я. И. Гулиев
Пример ссылки на эту публикацию:
Д. В. Белышев, Е. В. Кочуров. «Перспективные методы работы с данными в медицинских информационных системах», Программные системы: теория и приложения, 2016, 7:3(30), с. 79-97. URL: http://psta.psiras .ru/read/psta2016_3_79-97.pdf
Об авторах:
Дмитрий Владимирович Белышев
кандидат технических наук, заведующий лабораторией Исследовательского центра медицинской информатики Института программных систем им. А.К. Айламазяна РАН. Научные интересы: медицинские информационные системы, образовательные технологии, теория управления
e-mail: belyshev@interin.ru
Евгений Владимирович Кочуров
научный сотрудник Исследовательского центра медицинской информатики Института программных систем им. А.К. Айламазяна РАН. Научные интересы: логика, конструктивный синтез программ, моделирование бизнес-процессов e-mail: kochurov@interin.ru
Dmitriy Belyshev, Eugeniy Kochurov. Advanced Methods of Data Management in Healthcare Information Systems.
Abstract. The paper deals with advanced methods of managing data in healthcare information systems (HISs). The authors of the paper analyze the requirements imposed on technologies of representing data in HISs. The paper further proposes an approach to forming specialized data warehouses considering the data requirements. Moreover, the paper proposes an approach to solving the problem of sharing data between a healthcare information system and other components of a distributed information environment. (In Russian).
Key words and phrases: healthcare information system, data storage, adaptive software architecture.
© D. V. Belyshev, E. V. Kochurov, 2016 © Ailamazyan Program System Institute of RAS, 2016 © Program systems: Theory and Applications, 2016
References
[1] Zasedaniye Ekspertnogo soveta po zdravookhraneniyu Komiteta Soveta federatsii po sotsial'noy politike, URL: http://council.gov.ru/events/news/67020/
[2] D.V. Belyshev, Ye. V. Kochurov. "Analiz metodov khraneniya dannykh v meditsinskikh informatsionnykh sistemakh s adaptivnoy arkhitekturoy", Programmnyye sistemy: teoriya i prilozheniya, 7:2 (2016), pp. 85—103, URL: http://psta.psiras.ru/read/psta2016_2_85-103.pdf
[3] M. R. Kogalovskiy. Entsiklopediya tekhnologiy baz dannykh, Finansy i statistika, M., 2002.
[4] Ya. I. Guliyev, S.I. Komarov, V.L. Malykh, G.S. Osipov, S. P. Pimenov, M. I. Khatkevich. "Integrirovannaya raspredelennaya informatsionnaya sistema lechebnogo uchrezhdeniya (INTERIN)", Programmnyye produkty i sistemy, 1997, no.3.
[5] V.L. Malykh, S. P. Pimenov, M.I. Khatkevich. "Ob"yektno-relyatsionnyy podkhod k sozdaniyu bol'shikh informatsionnykh sistem", Programmnyye sistemy: Teoreticheskiye osnovy i prilozheniya, ed. A. K. Aylamazyan, Nauka. Fizmatlit, M., 1999, pp. 177.
[6] MongoDB: baza dannykh, URL: https://www.mongodb.com/
[7] Apache CouchDB: baza dannykh, URL: http://couchdb.apache.org/
[8] M. S. Smirnov, M. I. Khatkevich. "Opyt kompleksnoy informatizatsii mnogoprofil'nogo lechebno-profilakticheskogo uchrezhdeniya na osnove sistemy Interin PROMIS", Kremlevskaya meditsina. Klinicheskiy vestnik, 2012, no.1, pp. 85-89.
[9] ORM: baza dannykh, URL: https://ru.wikipedia.org/wiki/ORM
[10] openEHR: baza dannykh, URL: http://www.openehr.org/
[11] S. I. Komarov, D.V. Alimov. "Mul'tiplikativnyye struktury krupnykh LPU", Vrach i informatsionnyye tekhnologii, 2015, no.4, pp. 24-32.
[12] D. V. Alimov, S. I. Komarov. "Osobennosti primeneniya mekhanizma mnogokomponentnosti pri informatizatsii krupnykh LPU", Vrach i informatsionnyye tekhnologii, 2014, no.5, pp. 29-36.
[13] D. V. Alimov. "Podderzhkamnogokomponentnostivmeditsinskikhinformatsionnykh sistemakh", Programmnyye produkty i sistemy, 2009, no.2, pp. 31-34.
Sample citation of this publication:
Dmitriy Belyshev, Eugeniy Kochurov. "Advanced Methods of Data Management in Healthcare Information Systems", Program systems: theory and applications, 2016, 7:3(30), pp. 79-97. (In Russian). URL: http://psta.psiras.ru/read/psta2016_3_79- 97.pdf
