Компьютерная история болезни

Третий этап – создание базы знаний и разработка экспертных систем, позволяющих, с одной  стороны, помочь врачу в выработке  оптимальной

стратегии в  ведении больного, с другой –  проанализировать полноту проведения необходимых мероприятий при конкретном диагнозе. В настоящее время Министерством здравоохранения РФ выработаны требования к созданию «Стандартных протоколов ведения больных» (приказ №303 от 3 августа 1999 г), работа по формированию таких протоколов идет по всей стране. Это внушает надежду, что в обозримом будущем на рынке появятся программные комплексы, позволяющие использовать эти знания в реальных клинических случаях.

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

В Межрегиональном  клинико-диагностическом центре г. Казани внедрена система электронного ведения истории болезни (ЭИБ) как стационарных, так и амбулаторных пациентов), позволяющая решить проблемы первого этапа. Создана локальная сеть, соединяющая серверы и рабочие места персонала со скоростью 100 мегабит в секунду. Это позволяет передавать информацию, включая мультимедийную (звук, изображения) с достаточной скоростью. Использование современных систем управления базами данных (Lotus Domino, DB2), медицинского оборудования с возможностью формирования цифровых данных с непосредственным подключением в сеть, решило проблему актуальности, удобства использования, простоты доступа к получаемой информации. Доступность рабочих мест, интуитивная понятность графического интерфейса, не требующая специальной подготовки, позволили преодолеть психологический барьер страха перед компьютером.

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

Реализованный удаленный доступ к системе через  Интернет по открытым каналам резко  увеличивает информационные возможности медиков.

По имеющейся  у автора информации, в настоящее  время разрабатывается концепция  встроенной в ЭИБ экспертной системы, использующей элементы самообучения и  опыт экспертов, заложенный в т.н. «протоколы ведения больных». Перспективой развития должно стать создание системы планирования и прогнозирования исхода лечения, экономических показателей, статистических показателей работы на различных уровнях (врач/отделение/служба/учреждение).

7. Примеры автоматизированных систем ведения амбулаторной истории болезни

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

Большинство АСВАИБ содержит модули для ведения медицинских записей, выполнения административно-финансовых функций, а также для формирования отчетов. Хотя многие общие принципы создания систем ведения истории болезни равным образом приложимы как к стационарному, так и к амбулаторному лечению, основные свойства этих систем будут описаны на примере четырех систем ведения амбулаторной истории болезни: COSTAR, RMRS (Regenstrief Medical Record System), TMR (the Medical Record) и STOR (Summary Time Oriented Record). Эти системы имеют долгую историю развития и их особенности широко освещались в литературе. 
 
    7. 1. Система COSTAR

Система COSTAR была разработана в конце 60-х годов Барнеттом и его коллегами в Лаборатории кибернетики Массачусетского общего госпиталя (Laboratory of Computer Science of Massachusetts General Hospital). Эта система проектировалась для обеспечения выполнения Гарвардской программы общественного здравоохранения HCHP (Harvard Community Health Plan), но затем она была пересмотрена, чтобы ее можно было использовать в других учреждениях, обеспечивающих амбулаторное обслуживание пациентов. Разработчики расширили функциональные возможности системы (например, обеспечили выполнение функций, связанных с оплатой лечения) и удалили из нее многие функции, оказавшиеся специфическими только для плана HCHP. В 1978 году версия системы, получившая название COSTAR 5, была объявлена доступной любой организации, желающей использовать ее или продавать как коммерческий продукт. В настоящее время учреждение, желающее установить систему COSTAR, может воспользоваться ее общедоступной версией (public domain) или приобрести одну из многих коммерческих версий, обладающих более широкими возможностями. Общее число пользователей системы COSTAR не известно; на проведенный в 1986 году опрос пользователей откликнулось более 110 мест, в которых она была установлена. Разработка системы COSTAR 5 преследовала две цели: (1) улучшить лечение пациентов за счет большей доступности и лучшей организации истории болезни и (2) улучшить возможности управления амбулаторным учреждением с помощью автоматизации административных, управленческих и финансовых функций. Для достижения этих целей разработчики системы выбрали модульный подход, позволяющий каждой организации настраивать систему на свои административные и клинические нужды и финансовые ограничения, а также обеспечили возможность постепенного наращивания модулей. Базовая система COSTAR 5 содержала модули для (1) обеспечения безопасности и целостности данных; (2) регистрации паспортных данных пациентов; (3) записи пациентов на прием; (4) формирования счетов на оплату лечения и финансовых отчетов; (5) сбора и хранения фрагментов истории болезни и (6) генерации отчетов управленческого характера. Для функционирования системы было достаточно установить только модули обеспечения безопасности данных и регистрации пациентов, а также минимальный вариант модуля ведения истории болезни; расширенные функции ведения истории болезни и другие модули были необязательными.

Система COSTAR могла  оперировать как полностью автоматизированная система ведения истории болезни. Будучи однажды введенными, все медицинские сведения могли быть получены в режиме оперативного доступа; тем самым потребность в бумажной истории болезни исключалась. Перед приходом пациента на прием система распечатывала реферат истории болезни, предназначенный для просмотра принимающим врачом, а также формализованный бланк приема, предназначенный для записи административных и медицинский сведений о пациенте. Никакая специфическая информация о пациенте в этот бланк не впечатывалась. В процессе приема пациентов врачи собирали медицинские данные и заполняли бланки приема. Они отмечали соответствующие диагнозы, параметры и симптомы в кодированных списках проблем, и указывали статус проблемы: M означало основную проблему (main), I - неактивную проблему (inactive) и так далее. Врачи могли вписать свои комментарии в специальное поле внизу бланка или надиктовать те сведения, которые должны были обрабатываться отдельно. После визита вспомогательный персонал вводил данные из бланка в компьютерную систему. В дополнение к бланку визита модуль ведения истории болезни позволял получить три стандартных выходных документа:

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

Специальные диаграммы, обобщающие хронологию заболеваний  и клинических исследований в  виде упорядоченного по датам списка клинических наблюдений и результатов лабораторных тестов.

Модуль генерации  отчетов управленческого характера  обеспечивал вывод множества  стандартных отчетов (например, числа  визитов по пациентам, по врачам или  по специальному виду услуги). Учреждения могли без труда добавить к системе вывод других периодических отчетов. Кроме того, система COSTAR обеспечивала работу со специальным языком медицинских запросов MQL (medical query language), который мог использоваться для выполнения произвольных заранее не запрограммированных сложных поисков информации в базе данных системы. 
 
    7. 2. Система RMRS

Система RMRS (Regenstrief Medical Record System) была разработана Макдональдом и его коллегами в Медицинском центре Университета Индианы (Indiana University Medical Center). Она была введена в эксплуатацию в Мемориальном госпитале Вишарда (Wishard Memorial Hospital) в 1974 году. В 1988 году она обеспечивала ведение историй болезни более чем 250000 пациентов, из них по меньшей мере для 50000 пациентов данные существовали 9 лет и более. В этой системе хранилось более 25 миллионов записей об отдельных наблюдениях за пациентами; все эти записи были закодированы и могли выбираться в режиме оперативного доступа. Система RMRS представляла собой часть более широкой системы обеспечения административной деятельности, обеспечивавшей запись пациентов на прием и формирование счетов на оплату лечения. Уникальной функцией компонента ведения истории болезни была система выдачи напоминаний, которая активно просматривала данные пациентов и выдавала врачам напоминания, основанные на 1400 закодированных протокольных правилах. Проведенное исследование по оцениванию полезности начальной версии системы продемонстрировало, что напоминания значительно улучшили поведение врачей в части назначения необходимых лабораторных тестов и лекарственной терапии, а также в части модификации планов лекарственной терапии.

Система RMRS обеспечивала диспетчеризацию записи на прием  и в преддверии визита пациента выдавала три документа:

1. Отчет по оценке качества, содержащий рекомендации врачу о профилактических процедурах, которые должны быть выполнены для пациента, о проблемах пациента, на которые надо обратить внимание, а также о противопоказаниях к лекарственной терапии (см. рис. 6. 16). Этот отчет по завершению визита удалялся из памяти системы.

2. Хронологический эпикриз, представляющий собой упорядоченную по датам информацию о пациенте, хранящуюся в клинической базе данных. 3. Бланк визита, представляющий собой специфический для данного пациента бланк, в который должны вписываться медицинские данные, полученные при визите пациента. Содержание бланка (списки проблем, активных лекарственных назначений, общераспространенных лабораторных тестов, а также наблюдений, которые должны быть выполнены) определялось системой в зависимости от имевшихся данных пациента по правилам, заданным врачами.

По завершению визита врач заполнял дневник истории  болезни, вносил изменения в список проблем, оформлял рецепты и заказы на лабораторные тесты, и все это  на бланке визита. Затем оператор вводил информацию о выполненных наблюдениях в клиническую базу данных. В систему RMRS можно было в закодированном виде вводить информацию о течении заболевания и сведения из дневника; однако из-за высокой стоимости ввода данных на практике вводилась лишь малая часть этих данных. Вместо этого копия заполненного бланка визита подшивалась в бумажную историю болезни. Таким образом, система RMRS не заменяла традиционную историю болезни, но дополняла ее. Результаты лабораторных тестов и информация об отпуске лекарств получались системой RMRS от систем клинической лаборатории и аптеки.

Медицинский язык запросов CARE использовался для получения  выборок из файлов с историями  болезни и для формирования отчета с оценками качества. Набор операторов языка CARE определял критерий поиска. Результатом выполнения запроса являлся список историй болезни, удовлетворявший критериям запроса. Результатом формирования отчета с оценками качества являлся перечень напоминаний, соответствующих критериям формирования. 
 
    7. 3. Система TMR

Система TMR (the Medical Record) разрабатывалась Стедом и Хаммондом в университете Дьюка с 1975 года. Первоначально целью разработки было исключение из обихода бумажной истории болезни. Поэтому разработчики системы основной акцент сделали на получение и хранение данных о лечении пациентов, хотя система TMR выполняла и такие функции, как планирование приема пациентов и формирование счетов на оплату лечения. К 1989 году эта система использовалась более чем в 25 местах США и Канады. Одна из версий системы TMR использовалась нефрологической клиникой университета Дьюка. Начиная с 1981 года для всех пациентов этой клиники велась компьютерная история болезни; других историй болезни у них не было. Для каждого пациента в систему вводились полный перечень диагнозов и процедур и велась хронологическая запись анамнеза и осмотров, результатов лабораторных тестов, лекарственных назначений и процедур.

В преддверии визита пациента система TMR просматривала  его историю болезни и выдавала бланк визита, в котором уже  были впечатаны последние клинические данные и назначенное лечение. Врач использовал этот бланк, чтобы получить уже имевшуюся информацию о пациенте и дополнить ее собственными данными. Хотя врачи могли вписывать все данные в этот бланк для последующего операторского ввода, они старались выполнять непосредственный ввод в систему лекарственных назначений, поскольку в этом случае система предупреждала их о возможных лекарственных аллергиях и лекарственных взаимодействиях, а также обеспечивала расчет правильной дозы.

Врачи могли  просматривать полную историю болезни с помощью видеотерминалов. Система TMR могла предоставлять им данные из истории болезни, сгруппированные по следующим трем направлениям: проблемы, хронология и визиты. Врачи могли просматривать последовательные результаты исследований или тестов как в табличном, так и в графическом виде. Система также могла генерировать повествовательные текстовые заключения, используя данные, которые регистрировались в бланках с помощью меню, допускавших многократный выбор. 
 
    7. 4. Система STOR

Система STOR (Summary Time Oriented Record) была разработана Уайтингом  О’Кифе и его помощниками в  Калифорнийском университете Сан-Франциско (USCF). В 1985 году, через шесть лет  после начала работы над пилотной системой, разработчики начали внедрять систему STOR как в стационарах, так и в амбулаторных учреждениях Калифорнийского университета. К 1988 году система STOR содержала 60000 амбулаторных историй болезни, охватывала 22 клиники, обслуживающих 200000 визитов пациентов ежегодно, и давала ответы на 2000 оперативных запросов в день. Исследование по оценке полезности системы показало, что врачи получали от системы STOR больше информации о пациенте, нежели от традиционной бумажной истории болезни.

Система STOR обеспечивала два вида информационных услуг: (1) компьютеризованное хранение и выборку амбулаторных историй болезни и (2) оперативное предоставление клинической информации о госпитализированных и амбулаторных пациентах в ответ на запросы пользователей. Для выполнения этих функций система STOR вела общую базу данных для госпитализированных и амбулаторных пациентов. Информация попадала в эту базу данных с помощью локальной вычислительной сети из семи автономных компьютерных систем подразделений и вспомогательных служб больницы. В число справок и отчетов, выдававшихся системой STOR в режиме реального времени, входили справки о течении заболевания, графики и таблицы, списки проблем и назначенного лечения, а также регистрационные сведения. Кроме того, в любое время на любом терминале системы STOR можно было получить экранные формы, содержащие в обратной хронологии клинические лабораторные данные, заключения, результаты радиологических и рентгенологических исследований, выписные эпикризы и лекарственные назначения, а также заключения по электрокардиограммам.