CC BY
101
2. Гулиев Я.И., Комаров С.И. Интегрированная распределенная информационная система крупного лечебно-диагностического учреждения // Стратегии здоровья: информационные технологии и интеллектуальное обеспечение меди-цины-97: тез. докл. IV междунар. форума. М., 1997.
3. Белышев А.Г., Гулиев Я.И., Морозов В.Ю. Построение медицинских систем с использованием объектных технологий // Программные системы: Теоретические основы и приложения: тр. Междунар. конф. / ИПС РАН, Переславль-Залесский;
под ред. А.К. Айлмазяна. М.: Наука. Физматлит, 1999. С. 169.
4. Малых В.Л., Пименов С.П., Хаткевич М.И. Объектно-реляционный подход к созданию больших информационных систем // Программные системы: Теоретические основы и приложения // Там же С. 177.
5. Айламазян А.К., Гулиев Я.И. Разработка информационных систем лечебно-профилактических учреждений: проблемы и решения: тез. докл. Междунар. форума. М.: Наука. Физматлит, 2000.
ИССЛЕДОВАНИЕ ТИПОВЫХ ПРОЦЕССОВ ИНТЕГРАЦИИ В МЕДИЦИНСКИХ ИНФОРМАЦИОННЫХ СИСТЕМАХ
(Работа поддержана грантом РФФИ 07-07-00290-а)
Ю.В. Козадой (ИПС им. А.К. Айламазяна РАН, г. Переславль-Залесский,
В статье проведен системный анализ проблемы интеграции в медицинских информационных системах, рассмотрены возможные подходы к их решению. Введен ряд классификаций по различным параметрам и рассмотрены преимущества и недостатки различных моделей интеграции. Результатом работы стало выделение наиболее эффективной схемы для типового процесса интеграции.
На основе предложенной модели был реализован ряд механизмов интеграции типовой медицинской информационной системы Интерин PROMIS с информационными системами различных разработчиков, потдвердивших эффективность выбранных решений.
Ключевые слова: интеграция, медицинские информационные системы, архитектура медицинских информационных систем.
При информатизации медицинского учреждения зачастую встает задача интеграции - объединения данных, получаемых от используемых информационных систем (ИС) различной специализации и различных разработчиков. Проблема интеграции тем острее, чем более жесткие требования (по быстроте взаимодействия, надежности, объемам передаваемых данных и т.п.) предъявляются к ее механизму.
Занимаясь разработкой ИС для медицинских учреждений, специалисты постоянно сталкиваются с задачей совместного использования данных несколькими ИС. Подходы к решению этой задачи могут быть разными.
По результатам обобщения разработки и эксплуатации интеграционных механизмов, объединяющих различные системы как медицинской, так и немедицинской направленности, типовой процесс интеграции медицинской информационной системы (МИС) можно свести к следующей схеме: определение типа интеграции по ряду классификаций, выбор транспортного агента и формата передачи данных, реализация механизма интеграции, реализация обработки ошибок в данных, утверждение регламента интеграции и разделение ответственности.
Рассмотрим подробнее указанные этапы, а также некоторые особенности процессов интеграции.
Классификация интеграций
По типам взаимодействия предлагается выделить несколько классификаций интеграционных процессов по различным признакам.
Односторонняя и двусторонняя интеграции.
Одним из определяющих признаков интеграции является направление передачи данных.
Наиболее простой тип - односторонняя интеграция, когда данные из одной системы выгружаются в другую (загружаются из другой). В этом случае интеграция происходит лишь на уровне данных и может, говоря формально, рассматриваться только для одной системы, например, в случае, когда интегрируемая система целиком формирует файл БД для интегрирующей системы, после чего в интегрирующей системе производится подмена файла, сама же она процесса интеграции не замечает. Примером такой интеграции может служить включение в процесс информационного обмена некой системы путем автоматизированного искусственного создания среды, в которой она работает.
Если необходимо производить интерактивный обмен данными, осуществлять передачу и контролировать ее результаты, используется двусторонняя интеграция - когда активными участниками процесса выступают обе системы. В этом случае при обмене данными одна система может реагировать на события, произошедшие (или вызванные) в другой системе. Так, например, интеграция на основе обмена сообщениями с подтверждением принятия сообщения уже является двусторонней. Двусторонняя интеграция характерна и для случаев, когда системы оперируют одной областью данных (например списком пациентов), причем и в случае, когда список ведется только в одной из систем, и при синхронизации списков обоих систем в реальном времени. В качестве примера
можно рассмотреть интеграцию с диагностическим или лабораторным оборудованием (либо лабораторной системой), когда из МИС поступает направление на проведение исследования, а в ответ направляется результат исследования.
Возможно и большее количество активных сторон в интеграции двух и более ИС.
Для эффективного контроля результатов интеграции и работы ее механизма предлагается использовать двусторонний тип интеграции, поскольку односторонние процессы менее гибки и не позволяют успешно решать возникающие проблемы. Однако односторонняя интеграция может быть исключительно полезной при включении в процессы информационного обмена эксплуатирующихся в медицинском учреждении замкнутых систем, модификация которых невозможна (нет связи с разработчиками и пр.).
Стоит заметить, что параллельно может быть организовано несколько процессов взаимодействия систем с использованием одного общего механизма интеграции. Такой подход довольно эффективен, поскольку осуществляется общий контроль для всех процессов интеграции, а спроектированный с учетом такой работы транспортный агент может обслуживать несколько процессов обмена данными одновременно. В этих случаях двустороннюю интеграцию корректно рассматривать как двустороннюю в пределах одного процесса интеграции. Пример такой интеграции - механизм обмена сообщениями, например, с экономической системой, где один тип сообщений обеспечивает синхронизацию списка договоров в МИС и экономической системе, а другой направляет информацию об оказанных услугах из МИС для формирования счетов.
Интеграция с медицинскими и немедицинскими системами. Зачастую имеет значение, с какой системой, медицинской или немедицинской, производится интеграция. При интеграции с медицинской системой передаваемые данные обычно являются элементами неких лечебно-диагностических мероприятий. В таких случаях, как правило, к интеграции предъявляются более строгие требования, большую важность приобретают время реакции системы на запрос, общее время обмена информацией, защищенность от потери и искажения данных и т.п. Интеграция же с немедицинской системой обычно не проводится в режиме реального времени, поэтому периоды между обменом данными могут быть более длительными и сам обмен зачастую носит односторонний характер.
Примером интеграции с медицинскими системами может служить взаимодействие МИС с лабораторными системами, диагностическим оборудованием, со сторонними МИС и т.п. Требуется постоянная актуализация данных, поскольку необходимо обслуживать случаи, когда в один день
пациент и будет внесен в МИС, и пройдет обследование, и получит диагностические документы на руки, для чего данные о нем должны быть реп-лицированы в диагностической системе за время его перемещения от регистратуры до кабинета.
Наиболее распространенными примерами интеграции МИС с немедицинскими системами является интеграция на уровне экономических подсистем, систем материального учета, со страховщиками и пр. В таких примерах, как правило, актуализация информации требуется значительно реже - несколько раз в месяц, для составления отчетности и согласований.
Автоматизированная и неавтоматизированная интеграция. Интеграцию ИС можно классифицировать либо как автоматизированный процесс обмена данными, либо как процесс, где присутствует ручное оперирование данными. Примерами могут являться интеграции с лабораторными системами (как правило, автоматизированные) и интеграции со сторонними немедицинскими организациями, в частности, со страховыми компаниями (часто реализованные в виде автоматической обработки данных, введенных вручную).
Качественное различие типов заключается в уровне адаптации внешних данных в МИС.
При полной автоматизации процесса обмена данными ошибок адаптации данных бывает существенно меньше, а случающиеся ошибки являются систематическими, что позволяет диагностировать причину их возникновения и устранить либо адаптировать МИС к обработке таких ошибок.
Опыт использования различных решений интеграции показывает, что при обработке ошибок в данных автоматизированного взаимодействия число ошибок и количество их разновидностей в несколько раз ниже, чем при обработке данных, вводимых вручную. В частности, при обработке полученных от страховых компаний списков прикрепленных по добровольному медицинскому страхованию (ДМС) пациентов, те списки, которые составлялись автоматизированно в ИС страховых компаний, потребовали 2-3 итерации разработки механизма интеграции, после чего обработка списков велась сотрудниками лечебного учреждения систематически в штатном режиме. Те списки, которые составляются страховыми компаниями вручную, регулярно вынуждают персонал затрачивать время на анализ и исправление все новых ошибок в этих списках даже после нескольких итераций разработки механизма интеграции.
Наличие обратной связи. Существенным различием в процессах интеграции является наличие/отсутствие обратной связи со стороны интегрируемой системы. Под обратной связью здесь понимается возможность получения информации и влияния на механизм интеграции со стороны интегрирующей системы.
В случае отсутствия обратной связи организация взаимодействия ограничена пересечением возможных механизмов интеграции, доступных в системах, а обработка ошибок возможна только в варианте адаптации системы к систематизированным ошибкам.
Примерами систем без наличия обратной связи могут служить системы, поддержка которых прекращена, находящиеся вне сферы влияния, архитектура которых не допускает изменений.
Системы с наличием обратной связи, как правило, позволяют строить более совершенные механизмы интеграции за счет своей адаптивности.
Транспортный агент и форматы
Важным моментом при построении интеграции является правильный выбор транспортного агента и формата передачи данных. Под транспортным агентом здесь подразумевается технический набор средств, позволяющий осуществлять физическую передачу данных из одной системы в другую.
Транспортного агента и формат данных необходимо выбирать исходя из классификации по указанным признакам, а также с учетом специфики данных. Так, например, для автоматизированных систем эффективным является выбор агента, основанного на стандартном протоколе передачи данных (например ODBC) между БД интегрируемых систем. В частности, при интеграции с диагностическим оборудованием либо системой целесообразно поддерживать постоянную возможность связи по какому-либо протоколу. Однако если данные формируются во внешней системе вручную либо требуется поддерживать возможность принятия кванта данных, составленного вручную, может оказаться удобным выбор менее технологичного, а то и вовсе нестандартного транспортного агента. Например, при работе со страховыми компаниями для обработки списков прикрепленных по ДМС пациентов в качестве транспортного агента применялись файлы Microsoft Excel. Это позволило совместить автоматизированное формирование таких файлов в одних страховых компаниях и формирование вручную в других.
От транспортного агента также могут зависеть скорость обмена данными при интеграции, надежность механизма интеграции, доступная полнота контроля работы механизма и многое другое.
В качестве транспортного агента при интеграции МИС наиболее корректным принято считать обмен сообщениями с использованием стандарта HL7. Необходимо заметить, что этот стандарт поддерживается целым рядом медицинского оборудования. Это особенно характерно для медицинских приборов зарубежного производства, поскольку стандарт HL7 получил заметное распространение в странах Европы и в США.
Поскольку применимость HL7 для всей отечественной системы здравоохранения неочевидна, а специалистов, имеющих навык работы с HL7, пока мало, многие ставят под сомнение целесообразность интеграции на основе HL7. Тем более что огромная доля подсистем, разработанных и эксплуатирующихся в различных медицинских учреждениях уже длительное время, была спроектирована без поддержки Ж7. Однако из стандарта ^7 можно почерпнуть ряд полезных идей и принципов. Так, механизм обмена сообщениями представляется наиболее предпочтительным, даже если эти сообщения специфичны для некой конкретной интеграции. Такой тип транспортного агента - один из лучших способов доставки данных и контроля с обеспечением разграничения ответственности на каждой стадии.
Безопасность
Одна из главных проблем при интеграции ИС - обеспечение информационной безопасности. Как правило, требуется защищать и транспортного агента, который физически передает данные, и каждую из интегрируемых систем. За исключением случаев, когда в рамках интеграции разрабатывается новый специфический транспортный агент, для каждого вида агентов существуют типовые решения для защиты либо известно, что выбранный агент защите не поддается.
Необходимо уделить внимание следующим аспектам:
- необходимо обеспечить безопасность данных, передаваемых транспортным агентом;
- данные, отраженные в интегрированной системе, защищаются средствами этой системы. Таким образом, если защищенная система интегрируется с системой, имеющей менее эффективную защиту, данные, которые в рамках интеграции могут передаваться между системами, следует считать защищенными на уровне менее защищенной системы.
В то время как транспортного агента можно защитить как техническими средствами (шифрование, ограничение доступа к каналу передачи и пр.), так и административными (например, организационно ограничить доступ к оборудованию, осуществляющему передачу данных), возможности защиты системы без наличия обратной связи бывают весьма ограниченными. Кроме того, необходимо проверять подлинность системы, участвующей в обмене данными.
Разграничение ответственности
Непременным элементом процесса интеграции является разграничение ответственности между интегрируемыми системами. В общих чертах процесс интеграции включает следующие этапы:
- подготовка данных для передачи системой А,
- отправка данных системой А,
- передача данных от системы А к системе Б,
- прием данных системой Б,
- сохранение полученных данных в структуре системы Б,
- отправка подтверждения принятия данных из системы Б в систему А,
- передача подтверждения от системы Б к системе А,
- прием подтверждения системой А.
Каждый из этих этапов должен попадать под
ответственность какой-либо из систем. Трудоемкость выявления системы, допустившей ошибку при передаче данных, напрямую зависит от количества этапов, ответственность за которые разделяется между системами.
Обработка ошибок
При интеграции систем неизбежно возникают ошибки в передаваемых данных. Их можно разделить на следующие типы.
- Ошибки из-за несоответствия моделей, архитектур либо структур систем и данных в системах: возникают при некорректной проекции данных одной системы на другую. Чаще всего это следствие недостаточной проработанности механизма интеграции. Некоторые из таких ошибок можно обрабатывать за счет сопоставления и вычисления.
- Ошибки, возникающие при некорректности данных: считаются допустимыми при функционировании внутри отдельной системы, поскольку в ней не происходит столкновения корректных и некорректных (либо некорректных с обеих сторон) данных. А при интеграции это может проявиться.
- Ошибки дублирования данных: вызывают определенные проблемы даже внутри отдельной системы, однако при интеграции сложность проблемы значительно вырастает.
Следует заметить: поскольку процесс интеграции ИС практически всегда основан на обмене данными, многие ошибки можно выявить, описать и устранить на основе нормальных форм, используемых в теории БД. Рассматривая интегрированные системы как целую БД, проводя параллели между понятиями БД и данными в процессе интеграции, можно выявить источник ошибок путем вычисления нарушений нормальных форм. То есть даже если в интегрируемых системах не соблюдаются нормальные формы, соблюдение их (хотя бы первых трех) в механизме интеграции может сократить количество ошибок и привести к более эффективному функционированию.
Подход представляется интересным для исследования, поскольку в случае корректного нахождения аналогий и применения нормальных форм общий принцип нормализации можно использовать для построения эффективного механизма интеграции.
Регламент процедуры обмена данными и временные интервалы
При интеграции систем практически всегда рассматриваются вопросы о том, как часто и в каких случаях должны попадать данные из одной системы в другую. Можно выделить три модели поведения при передаче данных - через определенные временные интервалы, по определенному событию, по запросу.
Рассмотрим их подробнее.
Передача данных через определенные временные интервалы. Эта модель, как правило, реализуется для систем, работающих параллельно на основе неких данных, передача которых лежит в основе интеграции. При таком подходе каждый временной интервал системы начинают с одинаковым синхронизированным набором данных, предполагая, что изменение этих данных в течение временного интервала не имеет значения для процессов, протекающих внутри системы. Данная схема считается одной из наиболее простых и часто используемых. Однако такая модель наиболее подвержена возникновению ошибок, поскольку лишь немногие интеграции действительно абсолютно не зависят от изменения данных в течение временного интервала. Наблюдения показывают, что при достаточно активной работе учреждения в сфере, затрагивающей участвующую в процессе интеграции область данных, значимые изменения регулярно случаются. И чем больше временной интервал, тем больше ошибок возникает при обмене данными. Проблема заключается в том, что, несмотря на длину интервала, которую диктует непосредственно участвующий в интеграции процесс, в системе могут протекать и другие процессы, косвенно использующие эти данные, причем процессы рассчитаны на совершенно иной временной интервал дискретизации. Опыт внедрения показывает, что следует выбирать минимальные из допустимых временные интервалы, а при наличии возможности лучше и вовсе отказаться от данной модели в пользу передачи данных по определенному событию.
Примером передачи данных через определенные временные интервалы может служить ежедневная выгрузка данных о пациентах в специализированную систему скорой помощи.
Передача данных по определенному событию. Данная модель часто используется в случаях, когда в процессе обмена передается не просто общий набор данных, а некие информационные объекты, построенные на основе этих данных. В таком случае требуется передать и сами данные, и связь между ними, данные необходимо передать целым набором, так как частичная передача однотипных данных не дает нужного результата. Кроме того, такая модель более удобна для контроля передачи, поскольку данные поступают отдельными квантами, которые можно протоколировать.
Модель предполагает равномерную нагрузку, так как однотипные события в лечебных процессах обычно не обладают высокой плотностью для создания пиковых нагрузок на транспортного агента.
Эта модель наиболее подходит для механизма интеграции на основе обмена сообщениями.
Преимуществом данного подхода также является асинхронность передачи данных с их востребованностью. Так, данные подготавливаются для передачи максимально рано и могут быть востребованы по мере их доставки транспортным агентом.
Недостатком модели является ее непригодность для передачи интенсивного постоянного потока элементарных данных даже при их небольшом совокупном объеме. Примером такой модели являются практически все интеграции с медицинским оборудованием.
Передача данных по запросу является моделью, в общем случае наиболее эффективно использующей транспортного агента. Данные передаются только по требованию системы, причем с указанием в запросе заявки на конкретные данные. Это минимизирует нагрузку на транспортного агента в целом, однако может создавать значительную пиковую нагрузку в момент запроса. Следовательно, такая модель оптимальна при достаточно малой пиковой нагрузке в момент запроса.
Недостатком модели является зависимость от работоспособности транспортного агента в момент запроса. Так, если транспортный агент в момент запроса не может доставить данные, то их ожидание равносильно ожиданию транспортного агента. Предпочтительнее случай, когда получение данных происходит заблаговременно.
Примерами для этой модели являются некоторые интеграции с лабораторными системами, которым периодически требуется запрашивать дополнительные данные о пациенте.
Регламент передачи данныгх. Выбранная модель с указанием ее параметров должна быть описана в соответствующем регламенте и утверждена заинтересованными сторонами, как правило, представителями от разработчиков систем и от медицинских учреждений, использующих ИС.
Пересечение интегрируемых систем
В ряде случаев интегрированные системы могут пересекаться в сфере действий. Например, в одной системе по данным, доступным с помощью интеграции, можно построить отчетность, которая отражает деятельность другой системы. Это особо актуально при интеграции с системами без наличия обратной связи. В частности, за счет интеграции с системой, поддержка которой прекращена, можно развивать дополнительный функционал, недоступный в исходной системе.
Различия в представлениях данных
Неприятной особенностью является такая интеграция, при которой одни и те же данные требуется представлять в различной форме. В частности, это относится к большим системам, охватывающим разные подразделения учреждения. Различные подразделения могут оперировать одними исходными данными, представляя их в разных формах. Например, наименование договора либо услуги по ряду причин может иметь различия в написании или даже в обозначении.
Сопоставление и вычисление данных
При интеграции систем часто возникает необходимость в сопоставлении данных. Это относится к случаям, когда одни и те же данные параллельно ведутся в интегрируемых системах и обмен данными содержит в себе некую проекцию данных и их отношений из одной системы в другую. Бывает, что из схемы данных и административных регламентов можно вычислить однозначное соответствие. Однако в некоторых случаях набор данных, которые может предоставить одна система, меньше набора данных, необходимых для создания (или идентификации) информационного объекта в другой системе. В таком случае нужно либо пытаться выполнить вычисление требуемых данных, либо административно определить процесс дополнения набора передаваемых данных до требуемого.
Например, из лабораторной системы можно извлечь данные о проведенном исследовании пациента, в которых, однако, отсутствует информация о договоре на ДМС, по которому была оказана такая услуга. Учитывая административно утвержденную невозможность оказания услуг пациенту одновременно по нескольким договорам ДМС, есть возможность вычислить договор, по которому была оказана услуга, после чего использовать эту информацию для предоставления отчетов в страховую компанию.
Необходимо отметить, что некоторые данные могут быть как сопоставлены, так и вычислены. В этом случае не всегда однозначно следует выбирать сопоставление: есть вероятность, что данные, вычисляемые внутри МИС, могут оказаться более корректными либо более удобными для использования в системе. Выбор метода дополнения данных необходимо определить на основе анализа репрезентативной выборки данных, на которых основана интеграция.
Проблемы интеграции в МИС
На основании изложенного можно выделить ряд общих проблем, возникающих при интеграции в МИС: использование закрытых, неописанных форматов; ошибки операторов систем; зависимость от технического обеспечения связи из-за физической удаленности систем; необходимость
защиты систем и механизма интеграции от угроз информационной безопасности; наличие систем без поддержки и прочих закрытых систем, интеграция с которыми проводится в одностороннем порядке; отсутствие регламентов и проблемы с разграничением ответственности за ошибки обмена данными; затягивающиеся сроки реализации интеграции ввиду количества участвующих сторон и их инертности; необходимость тщательного анализа структур данных, участвующих в обмене в рамках интеграции.
С учетом различных интеграций типовой МИС Интерин PROMIS (разработка ИПС РАН) с лабораторными, диагностическими, экономическими, страховыми и прочими системами, а также со специализированными подсистемами отдельных медицинских учреждений обобщена типовая схема интеграции. Выделены основные модели интеграции, рассмотрены типичные преимущества и недостатки моделей; выявлены и классифицированы наиболее распространенные ошибки в обмене данных интегрированных систем.
Поскольку не существует МИС, охватывающих все процессы медицинского учреждения без исключения, вопрос интеграции крайне актуален для любой устанавливающейся в клиниках и больницах ИС. Однако наиболее актуален он при плавном внедрении, когда на время замещения имеющейся подсистемы модулями МИС требуется сохранить работоспособность новой системы в связке с имеющейся подсистемой.
Из всех означенных типовых процессов интеграции наиболее эффективным в общем случае представляется двусторонняя интеграция систем на основе обмена сообщениями (возможно, стандарт HL7) и передачи данных по событию с учтенными и обоснованными нарушениями аналогий нормальных форм либо без подобных нарушений.
С учетом данных выводов в МИС Интерин PROMIS был реализован ряд механизмов интеграции, в частности, с экономической подсистемой корпорации «Парус», лабораторными системами (УниверЛаб, Ilims), собственными разработками медицинских учреждений. Реализованные механизмы показали высокую степень адаптивности, устойчивости к ошибкам и отличное качество контроля интеграции.
Литература
1. Гулиев Я.И., Хаткевич М.И. Процесс и документ в медицинских информационных системах // Программные системы: теория и приложения: тр. Междунар. конф. / ИПС РАН, Переславль-Залесский; под ред. С.М. Абрамова. В 2 т. М.: Физматлит. 2004. Т. 2. С. 169.
2. Малых В.Л., Пименов С.П., Хаткевич М.И. Объектно-реляционный подход к созданию больших информационных систем // Программные системы: Теоретические основы и приложения: тр. Междунар. конф. / ИПС РАН, Переславль-Залесский; под ред. А.К. Айламазяна. М.: Наука. Физматлит, 1999. C. 177.
3. Интегрированная распределенная информационная система лечебного учреждения (ИНТЕРИН) / Я.И. Гулиев [и др.] // Программные продукты и системы. 1997. № 3.
ПРЕЦЕДЕНТЫ В МЕДИЦИНСКИХ ИНФОРМАЦИОННЫХ СИСТЕМАХ
В.Л. Малых, к.т.н.; Я.И. Гулиев, к.т.н. (ИПС им. А.К. Айламазяна РАН, г. Переславль-Залесский, [email protected])
Целью работы является обоснование целесообразности широкого использования прецедентов в медицинских информационных системах. Прецеденты вводятся на основе построения отображений определенных на множествах наблюдаемых событий различных классов. Приведены примеры практической апробации этой идеи, намечены дальнейшие многообещающие перспективы использования прецедентов.
Ключевые слова: прецеденты, информационная система, медицинская информационная система, архитектура информационной системы, лечебно-диагностический процесс.
Современные интегрированные медицинские информационные системы (МИС) ориентированы на всестороннюю автоматизацию и детальный контроль лечебно-диагностического процесса (ЛДП). Сам ЛДП состоит из потока событий, ассоциированных с различными лечебно-диагностическими мероприятиями: осмотрами, диагностическими исследованиями, лабораторными анализами, лечебными назначениями, процедурами и манипуляциями, оперативными вмешательствами. События ассоциируются с участвующими в них субъектами: пациентами, врачами, прочим меди-
цинским персоналом. События обладают темпоральными свойствами: датой и временем возникновения, длительностью протекания. Каждое событие ЛДП является по своей сути уникальным, единичным и относится к конкретному пациенту, определенному времени, содержит свой набор значений именованных атрибутов, например, ассоциацию с основным или сопутствующим диагнозом. МИС фиксирует множество таких единичных событий в своей БД. Для крупных лечебных заведений количество детально фиксируемых событий ЛДП исчисляется миллионами в год.
