БАИС: за миллион лет до нашей эры::Журнал СА 7-8.2017
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Архив номеров
Контакты
   

  Опросы
  Статьи

Рынок труда  

Системные администраторы по-прежнему востребованы и незаменимы

Системные администраторы, практически, есть везде. Порой их не видно и не слышно,

 Читать далее...

Учебные центры  

Карьерные мечты нужно воплощать! А мы поможем

Школа Bell Integrator открывает свои двери для всех, кто хочет освоить перспективную

 Читать далее...

Гость номера  

Дмитрий Галов: «Нельзя сказать, что люди становятся доверчивее, скорее эволюционирует ландшафт киберугроз»

Использование мобильных устройств растет. А вместе с ними быстро растет количество мобильных

 Читать далее...

Прошу слова  

Твердая рука в бархатной перчатке: принципы soft skills

Лауреат Нобелевской премии, специалист по рынку труда, профессор Лондонской школы экономики Кристофер

 Читать далее...

Как хорошо вы это знаете  

Портал Инкоманд. Для чего он? Для кого? Какие проблемы решает?

Компания «ЕМДЕВ» – создатель интернет-портала, предлагает всем желающим протестировать себя на

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 10033
Комментарии: 0
Потоковая обработка данных

 Читать далее...

19.03.2018г.
Просмотров: 8242
Комментарии: 0
Релевантный поиск с использованием Elasticsearch и Solr

 Читать далее...

19.03.2018г.
Просмотров: 8343
Комментарии: 0
Конкурентное программирование на SCALA

 Читать далее...

19.03.2018г.
Просмотров: 5298
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 5977
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

Друзья сайта  

 БАИС: за миллион лет до нашей эры

Архив номеров / 2017 / Выпуск №7-8 (176-177) / БАИС: за миллион лет до нашей эры

Рубрика: Разработка /  Проектирование

Константин Токмачев КОНСТАНТИН ТОКМАЧЕВ, ЗАО «Русское море», системный аналитик, ciril2@proc.ru

БАИС: за миллион лет до нашей эры

Многие передовые идеи БАИС рубежа 70-80-х годов прошлого века остались невостребованными, другие реализованы, но вызывают разочарование

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

Сначала позвонил мой однокашник по МБФ2, человек, которого я не видел лет сорок, и предложил внедрить в московской клинической больнице программы дифференциальной диагностики. Комичность ситуации была в том, что внедрять он предлагал дипломные работы, выполненные нами в середине 70-х! «Лежу тут после обширного инфаркта, захожу к медицинским статистикам и вижу, что в больнице вообще нет автоматизации, даже программ дифференциальной диагностики. Давай, внедрим наши дипломные работы?»

Потом другой однокашник по МБФ, которого тоже не встречал со времени выпуска, рассказал, что их московский медицинский НИИ подает заявку на грант по теме разработки электронной истории болезни пациента. «Неужели этого еще нет? – удивился я. – Ведь это была одна из первых задач медицинской информатики…» – «Программы, которая объединила бы медицинские данные пациента из разных источников и могла бы предоставить их в распоряжение врача в любой стране и в любом медицинском учреждении по типу кредитной истории, не существует. Хотя подобные данные не только обеспечили бы преемственность в лечении, но могли бы создать объективную основу для компьютерного скрининга ирегиональной медицинской статистики».

Наконец, бывшая коллега по проекту АСУ «Стационар»3, внедряющая БАИС (на основе популярной в США СУБД Cache) в крупном московском медицинском центре, рассказала, что компьютерная система используется минимально. Сложная медицинская информация типа рентгенограмм или ЭКГ не вносится в базу данных. По сути, электронный документ используется в пределах своего древнего бумажного аналога и даже меньше. Задачи управления стационаром, связанные с движением больных, диспетчеризацией диагностических исследований и лечебных процедур, с автоматизацией медицинских записей, с автоматической дифференциальной диагностикой, не решаются и даже не ставятся.

Несмотря на колоссальный прогресс за 40 лет, что-то важное в медицинской информатике осталось «за бортом». Технологии хранения и обмена информацией достигли невиданных высот. А вот методы принятия управленческих решений, которые могли бы базироваться на той самой актуальной хранимой информации, исчезли. Компьютер позволил автоматизировать документооборот и создать новые методы диагностики типа КТ, новые интерфейсы медицинских приборов типа УЗИ и т.д. Но в практике принятия решений – основное, по сути, направление компьютеризации 70-80-х – наблюдался явный регресс. Современному читателю нужно напомнить про целый класс задач управления, которые были поставлены и решены в 70-е годы и благополучно забыты ныне, возможно, не заслуженно.

Сразу скажем, методическую основу решения этих задач составили методы кибернетики, математические методы «исследования операций» (Operations Research), включая имитационное моделирование, и методы Computer Science, в том числе связанные с базами данных (Data Base), математической лингвистикой и искусственным интеллектом.

У меня даже возникла догадка, почему все это забылось. Математические методы исследования операций, методы искусственного интеллекта превосходят человеческие возможности в сфере организации деятельности. Эта конкуренция припринятии управленческих решений не нужна ни врачам, ни медицинским администраторам. Нужен ли гроссмейстерам компьютер Deep Blue, обыгрывающий их в шахматы! Напомним, на заре промышленной революции в Англии, в начале XIX века, даже возникло протестное движение луддитов. Люди разрушали машины, которые оказались конкурентоспособнее и вытесняли их из сферы производства. Кстати, современные программы искусственного интеллекта уже превосходят по уровню IQ среднего обывателя.

Возможно, кто-то подумает, что виной всему – наша безалаберность и техническое отставание. Это все есть. Но, судя по рассказам знакомых из-за рубежа (США, Германия), там аналогичная картина. Медицинский истэблишмент ограничивает глубину автоматизации в больнице. В качестве главных причин предъявляются проблемы медицинской деонтологии (конфиденциальность медицинских данных, ответственность лечащего врача перед пациентом) и связанные с ними юридические вопросы. Наверное, все так. Медицинские данные – это приватная информация. Врач вроде бы несет личную ответственность за принятие решений.

Но, во-первых, эта ответственность нередко доводится до абсурда, когда из соображений личной безопасности врач не выходит за рамки утвержденной стандартной процедуры лечения и принципиально не слушает ничьих советов. А ведь консилиум врачей разных специальностей всегда был сильнейшей стороной медицины.

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

Дифференциальная диагностика

Какие же задачи и на какой технике решались в те давние годы? Задачи автоматической диагностики решались на ЭВМ МИР-1, языком программирования был язык АлМир, вариант языка АЛГОЛ-60. Машина представляла собой большой письменный стол с тумбами, с вмонтированной посредине пишущей машинкой и световым табло сбоку, отражающим содержимое регистров. Других внешних устройств, насколько помню, не было вообще. Программа и данные вводились спишущей машинки, на нее же шла распечатка результатов. Оперативная память – 4К.

Опишем кратко задачу дифференциальной диагностики [1]. В качестве метода решения использовался метод статистического последовательного анализа А. Вальда. Например, в задаче дифференциальной диагностики трех степеней активности ревматоидного артрита (тема моего диплома) на стадии обучения алгоритма распознавания использовался выверенный массив порядка 100 историй болезни и порядка 40 показателей исследований, проведенных больным.

Расчетная медицина становится медициной виртуальной. Лечить человека – то же, что ремонтировать автомобиль или отлаживать программу

Результаты диагностических исследований предполагались статистически независимыми, что подтверждалось расчетом коэффициентов корреляции и проверкой гипотезы об отличии коэффициентов корреляции от нуля. В ходе последовательного анализа на очередном шаге вычислялись три попарных «отношения правдоподобия» (Likelihood Relation) с учетом результата очередного исследования. При выходе за границы одного из отношений два отношения спроигравшей гипотезой отбрасывались, а одно продолжало вычисляться, соответственно, до своего выхода за границы или до исчерпания списка исследований.

«Фишка» последовательного анализа была в том, что для принятия решения, как правило, не нужно было проводить все исследования. В среднем требовалось не 40, а где-то четыре-пять. Что принципиально снижало стоимость диагностики, сокращало время диагностики (и сроки пребывания в стационаре) и меньше травмировало больного. Более того, цепочка исследований могла быть упорядочена по их информативности для диагностики, что вело к скорейшему достижению результата.

На современном уровне упорядоченные по информативности исследования могли бы составить «план диагностики», назначенный врачом. Они могли бы проводиться в реальном времени пребывания больного в стационаре, так что расчет возобновлялся бы с каждым новым исследованием. Еще одним важным приложением метода была удаленная диагностика, когда результаты исследований присылались с периферии и обратно отправлялся поставленный машиной дифференциальный диагноз.

Вспомним добрым словом автора прикладной методики и руководителя дипломных работ кандидата физико-математических наук, выпускника физфака МГУ, преподавателя кафедры математики МБФ А.В Степанова и завкафедрой математики МБФ доктора физико-математических наук П.И. Кузнецова. За медицинскую часть дипломов отвечал кандидат медицинских наук Л.С. Киценко.

Еще раз отметим, работы проводились в середине 70-х; ничего подобного мы не имеем в практике современного стационара.

АСУ «Стационар»

Говоря о БАИС в СССР в конце 70-х – начале 80-х, нельзя не вспомнить добрым словом двух талантливых ученых и хороших организаторов – докторов медицинских наук С.А. Гаспаряна и В.А. Бояджяна. Во многом благодаря ихэнтузиазму и организационным способностям на базе городской клинической больницы № 31 г. Москвы была разработана и внедрена в эксплуатацию одна из первых БАИС в стране – типовая АСУ «Стационар».

Какие же задачи входили в состав БАИС на рубеже 70-80-х? Как выглядел технический комплекс, как эксплуатировалась система? Первая очередь АСУ «Стационар» разрабатывалась на мини-ЭВМ M-6000 (советский аналог Hewlett Packard, производимый в Северодонецке). Вычислительный комплекс занимал большой зал, метров 40, где на фальшполе по периметру располагались стойки ЭВМ и внешние устройства – печатная машинка в качестве консоли, считыватель перфоленты, дисковый накопитель, пара накопителей на магнитной ленте, устройство быстрой печати. Оперативная память М-6000 составляла 32К. Емкость магнитного диска была порядка 2MB. Имелось несколько видеотерминалов, накоторых работала мультитерминальная программа ввода информации по «маске» документа. Видеотерминалы не были консолями. В операционную систему М-6000 входили только текстовый редактор, трансляторы с Ассемблера иФортрана, загрузчик программ Loader и драйверы внешних устройств. По сути, все программное обеспечение (ПО) писалось «от железа». Естественно, не было никаких баз данных и т.п. Ввод и отладка программ шла с консоли; текст программы можно было распечатать; команды редактора вводились вслепую и адресовались по номеру строки и номеру символа, глядя на распечатку.

В первую очередь АСУ «Стационар» входили четыре задачи: «Аптека», «Коечный фонд», «Диспетчеризация» и «Статистика». «Аптека» была изолированной задачей, которая нам досталась, кажется, от разработчиков из ИПУ (Институт проблем управления АН СССР). В ней учитывались лекарства, приход/расход/остаток, и никакой привязки к пациентам стационара не было. Задачи же «Коечный фонд», «Диспетчеризация» и «Статистика» образовали единую систему саббревиатурой КоДиСта, о которой я хочу рассказать [2].

Может возникнуть резонный вопрос, как при столь ограниченных вычислительных ресурсах могла эксплуатироваться АСУ многопрофильной больницы коек на 500? Отвечаю. В «первой очереди» внедрения система эксплуатировалась операторами. Ввод и выдача информации были строго упорядочены по времени. Информация ежедневно собиралась из отделений на бумажных носителях (стандартные больничные документы, которые не отменялись). Периодическая машинная отчетность (стандартная и дополненная) разносилась по отделениям и передавалась главврачу. Оперативные задачи – ошибки ввода, противоречивая информация из отделений – решались в реальном времени путем консультаций с персоналом. Заметим, что во «второй очереди» проекта, базирующейся на нескольких мини-ЭВМ СМ-4 (аналог PDP-1140), видеотерминалы и устройства печати были вынесены в подразделения, и с системой работал средний медперсонал.

Медицинские записи

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

Эксплуатация БАИС позволяла накопить и проанализировать в различных разрезах реальные данные о ходе лечебно-диагностического процесса

Идея позиционной медицинской записи восходила к средневековому философу Раймонду Луллию и его машине Ars Magna, которая умела выстраивать утверждения путем механического перебора слов и автоматического извлечения следствий из посылок по типу Аристотелевского силлогизма. Речь шла о том, чтобы создать грамматический шаблон медицинского предложения того или иного типа (диагноз, назначение и т.п.). Шаблон был сложносочиненным повествовательным предложением. Члены простых предложений (подлежащее, сказуемое, определение, обстоятельства места, времени) занимали определенные позиции, которые заполнялись подходящими частями речи (именами существительными, прилагательными, глаголами, наречиями), взятыми из специальных словарей.

Отметим здесь серьезность и комплексность при разработке АСУ «Стационар» в СССР. Наряду с техническим отделом (ЭВМ), отделами проектирования ПО и программирования, отделом эксплуатации АСУ имелся большой отдел информационного обеспечения, который и разрабатывал, например, прикладные словари и классификаторы медицинских терминов. (Всего в проекте работали до 60 человек.)

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

Больничная статистика

Задача «Статистика» в принципе была самой простой. Речь шла об автоматизации составления больничных отчетов по документу Форма № 266 – «карта выбывшего из стационара». Когда массив документов оказался на компьютере, аппетиты пользователей неимоверно выросли. Эру стандартных отчетов сменила эра произвольных запросов. Как мы говорили, баз данных для хранения информации на М-6000 не существовало. Поэтому мы сразу решили, раз все равно придется программировать, создать самый современный вариант базы данных – реляционную базу данных с языком исчисления предикатов в качестве языка произвольного запроса, благо в нашем распоряжении оказались недавние (1972года) пионерские статьи британского математика Эдгара Кодда, изобретателя реляционных баз. Это было правильное решение, поскольку в итоге мы получили «бесплатную» СУБД и для всех последующих задач.

Скажем несколько слов о нашей реализации реляционной СУБД с языком произвольного запроса. В качестве языка запроса использовался язык исчисления предикатов, похожий на привычный математический сленг, где указывается, какие файлы (отношения) пробегают какие переменные, каким условиям переменные должны удовлетворять, какие координаты или функции от них нужно получить в проекции. Другим вариантом проекции была строка функций-статистик типа количества записей, среднего значения числового данного и т.п., в том же стиле, что агрегатные функции современного языка SQL. При трансляции формулы запроса создавался заголовок, где свободные переменные предшествовали переменным, связанным кванторами; логическая формула условий выборки приводилась к дизъюнктивной форме. Для простоты обработки все функции и предикаты имели префиксную запись – имя из сигнатуры, потом – аргументы. Коттранслированной формуле запроса применялся «алгоритм редукции» Кодда, переводивший формулу в цепочку операций реляционной алгебры. При выполнении операций алгебры достраивались недостающие индексы.

Управление коечным фондом

«Коечный фонд» – это «движок», техническая задача (хотя у нее есть и собственный интерес). По-сути, система «Коечный фонд» формирует основу, к которой крепятся события, произошедшие с пациентом в больнице, – диагностические исследования, хирургические операции, лечебные процедуры, медикаментозное лечение и т.д. Система основана на двух документах – лицевой части истории болезни, заполняемой в приемном отделении, и Формы № 7 – листка учета движения пациентов отделения, где указывается, кто из пациентов прибыл, кто выписан, кто переведен в другое отделение и т.п. Ежедневный ввод и обработка Форм № 7 позволяет произвести перекрестный контроль информации одвижении больных, поданной из отделений. Задача позволяет подсчитать экономически важные характеристики больницы – средний койко-день в разрезе по отделениям и по стационару в целом, трафик движения больных через отделения стационара. В результате решения задачи системе становится известно текущее местоположение каждого больного, что позволяет планировать лечебно-диагностические мероприятия с учетом территориальной близости специальных подразделений к отделению, исключить лишние перемещения, что может быть существенно для крупной многопрофильной больницы, занимающей большую территорию. Пока пациент «движется» по отделениям стационара, чтомоделируется в рамках подсистемы «Коечный фонд», ему проводят диагностические исследования и лечебные процедуры, что находит отражение в дополнительных листах истории болезни, которую подсистема «Коечный фонд» как будто «тащит» за больным по отделениям вплоть до выписки.

Диспетчеризация исследований и процедур

Типичной задачей оперативного управления стационаром является задача диспетчеризации диагностических исследований и лечебных процедур («Диспетчеризация» [3]). Медицинская сестра вносит в компьютер в лист назначений больного врачебные назначения на исследования и процедуры. Далее система автоматически составляет расписания проведения исследований и процедур, формируя списки больных для подразделений, с указанием ФИО пациента, вида процедуры, времени ее начала и конца и т.п. Также и для пациента формируется расписание на день, где перечислены назначенные на завтра процедуры, сроки их начала и т.п.

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

Математические методы, которые используются в задачах «Коечный фонд» и «Диспетчеризация», – это теория массового обслуживания, модели которой позволяют рассчитать средние сроки ожидания и средние размеры очередей. Присоставлении расписаний исследований и процедур в крупной многопрофильной больнице с обширной территорией может подключаться транспортная задача линейного программирования, где минимизируется пройденный больными суммарный километраж.

Оптимизация структуры больницы

Сегодня даже как-то неловко произносить слово «оптимизация». Перед глазами сразу появляются предприниматели, умело уходящие от налогов, или чиновники, закрывающие роддома в провинции «для пользы рожениц». Но вообще-то этотермин философии Лейбница и означает не мошенничество и не шарлатанство, а поиск «наилучшего решения». Знаменитая фраза Лейбница «все к лучшему в этом лучшем из миров» (осмеянная Вольтером в повести «Кандид») означала, кстати, что господь бог из всех возможных траекторий развития универсума выбирает наилучшую или «оптимальную». Нам, правда, не всегда, понятен его выбор.

То, о чем только мечтали организаторы здравоохранения в начале 80-х, до какой-то степени достигнуто спустя тридцать лет

Задача сокращения койко-дня (среднего срока пребывания больного на койке) была актуальна для отечественных больниц во времена СССР. Ведь финансирование больниц осуществлялось от количества коек, так что сокращение койко-дня и тем самым увеличение потока больных при постоянном числе коек и, следовательно, постоянных затратах означало одновременно и удешевление медицинской помощи в расчете на пациента, и повышение производительности труда.

Автоматизированные подсистемы БАИС – «Коечный фонд», «Диспетчеризация» и даже «Больничная статистика» – прямо или косвенно способствовали сокращению койко-дня. Но это сокращение носило ситуативный характер. Ускорялись отдельные этапы лечебно-диагностического процесса (Л-ДП), скажем, сокращались сроки проведения исследований за счет составления расписаний, но организация оставалась традиционной.

В то же время эксплуатация БАИС позволяла накопить и проанализировать в различных разрезах реальные данные о ходе Л-ДП – по нозологиям, по подразделениям и т.д. И тут выяснилось, что списки лечебно-диагностических процедур, проводимых пациентам, избыточны и недостаточно специфичны для нозологий; на уровне первоначальной диагностики допускалось много ошибок, что в итоге затягивало лечение и снижало его качество; сроки пребывания в стационаре часто не были обоснованы и т.д. Стало ясно, что нужно организовать Л-ДП в некотором новом стиле, например, рассмотреть медицинское учреждение как систему массового обслуживания (СМО), а койко-день – как срок обслуживания всистеме, ее выходной параметр. Тогда задача сокращения койко-дня в больнице становилась задачей сокращения срока обслуживания за счет реорганизации структуры системы.

Имитационная модель медицинского учреждения

Опыт разработки БАИС и появившаяся в 70-е годы новая математическая дисциплина «методы исследования операций» (Operations Research) показали, что работа медицинского учреждения может быть формализована. В медицинском учреждении, как в любой СМО, существует некий перечень операций или «услуг», оказываемых пациенту медперсоналом. Каждая операция оценивается рядом параметров – временем проведения, стоимостью, расходными материалами ит.д. Л-ДП пациента формально описывается последовательностью выполнения этих операций. Л-ДП стационара – многокомпонентная СМО, в которой случайно «блуждают» пациенты. Каждое подразделение – это отдельная СМО, возможно, тоже многокомпонентная и иерархическая, со своим списком услуг и набором «обслуживающих аппаратов» (да простят меня врачи).

Задачу оптимизации структуры стационара в целях минимизации койко-дня можно было решить методом Монте-Карло. Для каждого диагноза выстраивается примерный маршрут прохождения через стационар. На больницу падает случайный поток пациентов, распределение которых по диагнозам соответствует собранной статистике. Врач приемного отделения с определенной вероятностью ставит предварительный диагноз, и больной получает примерный маршрут: диагностические процедуры, хирургические операции, лечебные процедуры и т.п. Подразделения – обслуживающие подсистемы – в зависимости от пропускной способности и потока пациентов характеризуются очередями и сроками обслуживания. Задав параметры системы – набор подсистем и поток пациентов, – можно рассчитать средний койко-день, средние длины очередей к подразделениям и средние сроки обслуживания. На выходе определяется «слабое звено» – элемент, тормозящий работу системы. Пересмотру могут подлежать штатные расписания, техническое оснащение (в сторону увеличения или уменьшения), примерная цепочка назначений пациенту при данном диагнозе и т.п. Повторим, параметры модели могут быть получены за счет статистики, собираемой действующей БАИС. Так что оптимизация структуры может (и должна) быть регулярно решаемой задачей.

Программа имитационной модели медицинского учреждения SIM.PAS была написана на языке Турбо-Паскаль. Напомним, язык PASCAL – это предшественник DELPHI и языка C++ Бьерна Страуструпа в плане объектно-ориентированного программирования. Язык PASCAL (названный в честь французского философа и математика Блеза Паскаля, изобретателя одной из первых вычислительных машин) синтаксически содержал функции, возвращающие единственное значение и принимающие входные параметры как локальные (т.е. не меняющие данные в вызывающей программе). Заметим, функции могли быть рекурсивными. PASCAL включал составные типы данных и массивы из них (предтеча объектов и ихсвойств). Для переменных любых типов PASCAL допускал организацию динамических ссылочных структур, что было крайне удобно при моделировании очередей в СМО. Наконец, синтаксис PASCAL позволял обойтись без известного оператора GOTO, способного неразрешимо запутать программный код. Американец Николас Вирт (N. Wirth), создатель языка PASCAL, преследовал цель не только лучшей «читаемости» программы, но в пределе даже автоматической проверки логической корректности кода (например, исключить зацикливания и коррупцию данных программы из подпрограмм).

Для моделирования входного потока в программе SIM.PAS использовалось распределение Пуассона. Для моделирования СМО применялись и другие распределения: дискретные типа полиномиального и непрерывные – нормальное, равномерное. Имитационная модель была параметризована. Точнее, был создан прикладной скрипт, что-то вроде описания дерева сборки и загрузки в память программы с подпрограммами. В текстовом профайле можно было задать множество подразделений, необходимые характеристики подразделений, маршруты (Л-ДП) пациентов, наборы операций, выполняемых в подразделениях, и сроки выполнения этих операций. Профайлы могли ссылаться друг на друга, такчто в базе данных накапливалось много «лексем» (описаний подразделений, групп подразделений и целых медучреждений – поликлиника/стационар), позволяющих быстро записать новую медицинскую структуру. Программа SIM.PAS запускалась с параметром профайла. Задавался также условный период времени (неделя, месяц). Многократный прогон программы (метод Монте-Карло) позволял вычислить статистические характеристики работы медучреждения и егоподразделений (сроки ожидания/длины очередей) как СМО пациентов.

Заметим, в статье упомянуты по крайней мере три оптимизационных задачи: минимизация числа диагностических исследований при дифференциальной диагностике (метод последовательного анализа А. Вальда); минимизация метража, пройденного больными к подразделениям (транспортная задача линейного программирования); наконец, минимизация среднего срока пребывания больного в стационаре (имитационная модель больницы как СМО, поиск «слабого звена» методом Монте-Карло).

То, о чем только мечтали организаторы здравоохранения в начале 80-х, – алгоритмизация и формализация действий врача и медперсонала в целях их оптимизации – до какой-то степени достигнуто сегодня, спустя тридцать лет. Благодаря формализации медицина стала расчетной, из мистического искусства Асклепия – сына Аполлона – превратилась в рутинное «медицинское обслуживание». Это «обслуживание» в сравнении с таинством Асклепия легко учитывать, планировать и финансировать. Но, как многие замечают сегодня, эта формализация не радует. Нас неявно приучают к мысли, что мы ничем не отличаемся от машин, раз нас лечат механически.

Расчетная медицина становится медициной виртуальной. Лечить человека – то же, что ремонтировать автомобиль или отлаживать программу. Скоро это можно будет поручить роботу. Не придем ли мы к тому, что и самого человека, егоорганизм мы механизируем, создав – вместо мистической тайны – гомункула или биоробота, состоящего из удобных и расчетных имплантов, протезов, ЭКО, трансплантатов и т.д.? Кстати, мозг – тоже один из органов нашего тела. Егоработу, как и работу других органов, мы стремимся упростить и формализовать. Сделать его надежным и контролируемым, как программа на языке PASCAL. Не совершаем ли мы серьезной ошибки, убеждая себя, что мы – те же технические устройства? Как писал немецкий философ М. Хайдеггер, «может, наоборот, оказаться, что природа как раз утаивает свое существо в той своей стороне, которой она повертывается к технически овладевающему ею человеку»…

  1. П.И. Кузнецов, Л.А. Пчелинцев, А.В. Степанов. Диагностика как управляемый случайный процесс. Доклады академии наук СССР. 1974. Том 218, № 5.
  2. Токмачев К.Ю. Решение задач управления больницей с использованием мини-ЭВМ. Автореферат канд. мед. наук. – М., 1989.
  3. Токмачев К.Ю. Метод автоматизированного составления расписаний работы больничных диагностических подразделений. // «Советское здравоохранение». – М.: Медицина, 1985, № 10.

1 БАИС – Больничная Автоматизированная Информационная Система.

2 Речь о выпускниках МБФ – Медико-биологического факультета 2-го МОЛГМИ им. Н.И. Пирогова.

3 Проект типовой АСУ «Стационар» разрабатывался на рубеже 70-80 годов на базе больницы № 31 г. Москвы.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru