ЗАЧЕМ И КАК автоматизировать лечебно-диагностический процесс

Выпуск 54 18 октября 2005 г. В предыдущем выпуске проблема различных технических решений при автоматизации ЛДП была обозначена, но не раскрыта. Между тем, она остра и актуальна. Давно я с нею сталкиваюсь, а теперь, затронув её, получил отклики, мимо которых пройти нельзя. Так что подождёт скорая помощь - сегодня я предлагаю читателям материалы своей интенсивной переписки с тремя опытными специалистами. Мои коллеги не знакомы друг с другом, но все они живо интересуются проблемами автоматизации ЛДП. Их суждения, использованные мною, - это цитаты из писем последних дней, лишь иногда и слегка подправленные и произвольно скомпонованные в форме беседы. Понимаю, такой приём неизбежно даёт последнее слово мне, но, право же, я старался не злоупотребить этим преимуществом, а главное - легко уступлю его: в ближайшем выпуске обещаю опубликовать всякое возражение или дополнение, которое сделают мои искренне уважаемые собеседники, - тогда уж без своих комментариев. Представлю участников: Александр Владимирович Гусев - разработчик медицинской информационной системы (Карельский НМЦ СЗО РАМН, Кондопога), Михаил Владимирович Прокошин- разработчик немедицинских систем (комитет по финансам Администрации Алтайского края, Барнаул), N.N. - разработчик крупного медицинского проекта, Владимир Михайлович Тавровский - ваш покорный слуга. Итак, БЕСЕДА, КОТОРОЙ НЕ БЫЛО О терминах А.В. Ваша последняя рассылка, Владимир Михайлович, меня расстроила. Говорить, что медицинская информационная система (МИС) - бессодержательный термин, неправильно. А термин "Автоматизация" - содержательный? Выдадим врачам автоматы - и у нас будет "Автоматизация"? В.М. Компьютеры всё-таки выдадим, а не автоматы. А.В. Каждый понимает слова по-разному - кто-то знает, как оно произошло, кто-то ориентируется на корень слова и т.д. В.М. Но ведь надо стремиться к взаимопониманию! Не к разному, а к сходному пониманию слов. Для этого составляются толковые словари. Вначале было Слово. Творение - потом. А.В. Вообще, информатика (Computing Seince у американцев) - это уже устоявшаяся наука, и в ней есть прописные истины, принятые во всем мире. И коль мы используем достижения этой науки, то имеет ли смысл идти в чужой монастырь со своим уставом? В.М. В чужой монастырь - не надо. А о своей родной речи, о её чистоте и точности кто же позаботится, если не мы? Кстати, Computing - это ведь не "информационная", а "компьютерная" Seince. Согласен, что новый русский термин "информатика" обозначает вполне определённую науку, но это не снимает неопределённости с термина "информационная система". А.В. Как бы там ни было, мне кажется жестоким и неуместным отметать всё, что наработано в теории построения информационных систем, и ругать это "бессодержательным". В.М. Ну, почему же ругать и отметать? Вероятно, я взял излишне резкий тон, и он заслоняет простую мысль: термины должны быть максимально информативны. Наверное, та же причина породила и другое недоразумение. Я противопоставляю термину "МИС" формулировку "автоматизированное управление лечебно-диагностическим процессом". Согласитесь, это более конкретно и дополнительно кое к чему обязывает. Ключевое слово здесь - "управление". Не упускайте его, пожалуйста. В конце концов, МИС можно считать родовым понятием, а мою формулировку - видовым. О разных платформах и разных подходах А.В. Все-таки выносить вердикт о перспективности той или иной программно-аппаратной технологии должны (и могут) только специалисты в этой области. Если в FoxPro… В.М. Прошу прощенья: в Visual FoxРro! А.В. …удобно что-то делать людям, далеким от программирования, это ещё не значит, что все программисты должны принять точку зрения о большой перспективности этой технологии, понимаете? В.М. Понимаю. Но надо позаботиться и о перспективности той или иной технологии самого ЛДП, которая будет вложена в систему. А здесь вердикт - не за программистом. Заложите не то, что на самом деле является сущностью медицинской практики, - не будет перспективы развития по существу. А.В. Допустим. Но вернёмся к программированию. Сделать из очень хорошей платформы отличную систему можно, хотя это и дорого и сложно,… В.М. То-то и оно. А денег мало. А потребности нарастают уже сегодня. А.В. …но сделать из посредственной платформы даже не отличную, а хотя бы хорошую систему - задача гиблая. Она, конечно, будет работать. Ее создатель будет свято верить в неповторимость своего шедевра и будет готов перегрызть глотку любому, кто с этим не согласиться. В.М. Да уж! Если будет работать, не отстаивать её - грех. А.В. Но надо быть честным с самим собой. То, что кто-то выбрал FoxPro,… В.М. Visual FoxРro! А.В. - это дело сугубо личное. Это его выбор с точки зрения удобства работы, личной производительности и т.д. Это - субъективно. Безусловно, программист будет лучше работать и давать лучший результат именно в той среде, где ему удобно, - он там всё знает, тратит минимум времени и т.д. Но что будет через 3-5 лет? В.М. А что будет? Будет разнобой. И среди программистов, и особенно среди конечных пользователей. Они только-только пробуждаются и, пробудившись, каждый видит лишь то, что лежит прямо перед ним. А.В. Не скажите. Не так уж давно были отличные платформы - Clipper, Paradox и т.д. Под них была масса программ. И вот представим: есть ЛПУ с отличной системой, удовлетворяющей всех. Но на старой платформе. Согласитесь, придет день, когда разработчик покинет ЛПУ. Что тогда? Надо искать нового. Есть шансы, что возьмут грамотного и молодого специалиста. И что же? Ему надо забросить современные, открытые и масштабируемые языки программирования и перейти на Clipper? В.М. Ох, кто бы мне объяснил, что такое "масштабируемость"! Может быть, и мои программы масштабируемые? А ведь Ваш пример можно перевернуть. Вот уже используется такая программа в ЛПУ. И что же? Главному врачу надо от неё отказаться? Не проще ли сохранить связи со специалистами, которые знают старую платформу? Их мало? Ну и что? Сегодня мало и тех и других, не востребованы они. Будут востребованы - появятся. И потом, если уж говорить о моих программах, не Clipper и не FoxPro им потребуются, а Visual FoxPro - это нечто иное. А.В. Но вот Вам аналогия. В сельской больничке, о которой Вы говорите, не стало врача - старенькой бабушки, которая как-то справлялась с лечением местного населения: заваривала им травки и т.д. Пришел молодой врач, а ситуация-то в больничке не меняется и вряд ли скоро изменится. Что же Вы посоветуете такому врачу? Забыть свои знания и изучать, какие бабушка травки заваривала? Или всё-таки попытаться воспользоваться современными знаниями и пусть и в отвратительных условиях, но применять их? В.М. Современный - не синоним хорошего, несовременный не значит - негодный. Современный - это всего лишь созданный и принятый на ура современниками. Но времена проходят, а реальный быт полон вещами, которые были так созданы века назад, что не нуждаются и сегодня в коренных преобразованиях: они полностью соответствуют своему назначению. Колесо, швейная игла, очки, таблица умножения, велосипед - кому сегодня придёт в голову рассуждать, современны они или нет? Они необходимы. А аналогия с травками не годится. Не паллиативы я предлагаю, а полноценную технологию работы врача. Соглашусь: во вчерашней обёртке, без высокотехнологичной расфасовки. Но не следует путать современность формы и адекватность содержания. А.В. Программное обеспечение - не только форма. И сегодняшний выбор очевиден - дело за сервис-ориентированными технологиями, СУБД на архитектуре "Клиент-Сервер", объектно-ориентированным программированием и т.д. Если кому-то все это кажется не нужным, - то это, конечно, имеет право на жизнь... В.М. А разве Visual FoxPro 6 этому противоречит? Открываю руководство М.Базияна "Использование Visual FoxPro 6" (М.-СПБ-Киев,2000). Часть 4-ая - "Объектно-ориентированное программирование". Страница 793 - о технологии клиент/сервер. Страница 796 - "Работа с базами данных в сети Web". Щёлкаю Help к самой VFP - "объектно-ориентированное программирование", "приложения клиент/сервер". Можно критически оценивать, как этими методами воспользовался я, но сама VFP их не исключает, наоборот - предполагает. А.В. Но всё-таки противопоставлять себя многомиллиардной индустрии и доказывать, что сеть - излишество, а перенос информации на дискетах (Вы в курсе, что объемы производства floppy-дисководов и носителей для них сокращается от года к году в разы?) - это единственное, что надо, я бы не стал, дабы не вызывать смех и снисходительное отношение к себе у профессионалов. В.М. Теперь уже Вы горячитесь. Смеяться не грешно, но такого я не говорил. Я лишь утверждаю, что система должна быть работоспособной и без сети, и при частичной готовности сети, и при авариях в сети. Иначе не только больнички и бабушки - крупные учреждения долго не смогут воспользоваться тем, что мы с Вами делаем. М.В. Не так уж всё однозначно, Александр Владимирович. Объем продаж флоппи-дисков и вправду резко падает, зато продажи флеш-памяти резко растут. Конечно, между отдельными врачами перенос данных - уже архаизм (данные должны собираться в единой базе), но вот обмен данными (статистикой и отдельно взятыми историями болезни) между различными уровнями управления, организациями, подразделениями - это нормально, выгодно и организационно правильно. И не важно, с помощью каких средств это делается. Так что не надо превозносить дискеты, но и отказываться от них не стоит. В.М. Вы как сговорились! Не превозношу я дискеты. И истории болезни у меня - в единой базе для всех врачей отделения. Следите за приёмами, дорогие оппоненты: вы приписываете мне несуществующий недостаток, а потом наносите по нему звонкий удар! А.В. У Вас, Владимир Михайлович, есть огромная ценность - Ваши знания и опыт использования информационных технологий в практике врача. И нужно, чтобы этот опыт изучали и перенимали. Ваша монография просто бесценна для программистов - она даёт глубокое понимание предметной области. Но не стоит высказывать беспрекословные суждения обо всем, что вертится вокруг автоматизации медицины, - этим Вы понижаете ценность своего труда и интеллекта. Потому что профессионал в области программирования, увидев в Вашем тексте явное несоответствие с текущими технологиями, сделает вполне очевидный вывод: раз это безнадежно устарело, значит и все остальное - тоже. А это - не так. В.М. Но Вы же не сделали этот "очевидный" вывод! А монографии уже 8 лет. И только теперь она нашла заинтересованного читателя-программиста. Это наводит на размышления. Идеи, которые Вас заинтересовали, развивались и в последующие годы, а главное - воплотились в действующих программах. Теперь вопрос: что ценнее, что доказательнее - идеи 8-летней давности или их сегодняшнее состояние и воплощение? М.В. Ваша проблема, Владимир Михайлович, - новые технологии, к которым Вы не привыкли. Но по-другому в этом мире уже никогда не будет. Как же иначе, помимо них, хотите Вы передать свои know-how преемникам ? Вам просто надо по этому поводу подумать: а что, если попытаться встроиться в эту цепочку. Как, в каком виде, в какой мере? В.М. В конечном счёте, понимаю: хорошо бы перейти на самую современную платформу. Но этого я, одиночка, уже не смогу. А что же, всё наработанное и эффективное надо сразу, сейчас забраковать? И пользователя, успешно работающего, получающего весомый результат, огорошить тем, что у него - отсталость? От чего отсталость? По содержанию - полноценная медицинская технология, пока что не имеющая себе равных. Но, вполне возможно, с запрограммированным отставанием от технического будущего. Вот уж, действительно, беда, если это так! Где выход? В какое положение мы с вами поставим пользователя? Что ему выбирать? Современную техническую систему с недостаточно проработанным содержанием или адекватное содержание, не поддержанное современными техническими средствами? Объединить усилия? N.N. А мы предлагаем Вам сотрудничество, Владимир Михайлович! Компания разрабатывает технически абсолютно современный проект на платформе Оракл и внедряет его в целом регионе. В.М. Но в чём может состоять это сотрудничество, если у меня уже - готовый продукт? N.N. Но вы же хотите его развивать и тиражировать? Вот давайте и сделаем лучшую в России систему по техническим средствам и по медицинскому наполнению (в отношении второго надеемся на Вас). В.М. Звучит заманчиво. Не мог и мечтать о таком сотрудничестве. Но как это можно реализовать? Ведь у вас уже есть система. И основана она на других принципах, и ориентирована на применение сразу в регионе. Тут не может не быть подводных камней. Что я, по Вашему, должен делать? N.N. Нам от Вас нужно только то, что Вы имеете. Ваш вариант показался нам очень хорошим и, самое главное, - работающим. Поэтому было бы очень хорошо, чтобы Вы описали то, что у Вас уже сделано, плюс то, что Вы хотели бы сами реализовать нового. В.М. Плохо понимаю, как это всё будет. И не исказится ли то, чем я больше всего дорожу, - методология ЛДП? Почему нельзя просто взять мой продукт и развивать и тиражировать его вашими средствами? М.В. Почему другие не могут или не хотят использовать Ваш продукт в готовом виде? Да потому, прежде всего, что изначально были нацелены на разработку собственного продукта. Есть, конечно, вариант: взять готовый продукт и пустить его в эксплуатацию, выгадав время для создания аналога на Оракл (переносить на него весь Ваш комплекс - сроки немалые). Мне, правда, не нравится выбор Оракла: он хорош при работе с большими базами данных, а Ваш-то подход - БД распределенные и маленькие. Ораклу нужны более сложные администрирование и настройка эффективности, нежели с более мелкими БД, посему внедрение и сопровождение его сложнее. N.N. Михаил Владимирович прав: мы делаем централизованную базу данных. Врач сможет входить в свой АРМ с любого компьютера и даже дома за счет web-технологий. И уже есть готовый продукт. Но его надо модифицировать - правильно ставить задачу и её реализовывать, описать врачебные (административные) функции, дать алгоритм их выполнения, показать, как это должно выглядеть, чтобы врачу или медсестре было удобно. В.М. Но как же при готовом продукте ставить задачу? Ведь задача когда-то уже была поставлена. Вероятнее всего, она была сформулирована не опытным врачом а программистом. А это переделывать - не очень перспективное занятие. М.В. Это верно. К сожалению, программистский подход слишком прост: "выделите мне врача, пусть он мне напишет то, что делает сейчас каждый день, и то, чего он хочет еще от системы". Врач послушно пишет, программист программирует, все довольны. N.N. Согласен. Вы абсолютно правы. Программисты действовали именно так. Кроме того, они абсолютно уверены, что правы. М.В. Только приводит такой подход к нулю. N.N. Похоже, к сожалению. Я врач. В принципе, всё можно сделать самому: кто и что делает, примерно понятно, все учётные и отчётные формы есть в инете. Даже жалобы, анамнез и протоколы операций есть (16 кафедр писали полгода). Нет тонкостей, функций контроля и помощи, напоминаний, предупреждений и т.д. - вот это нужно, это самое сложное, это и есть в моем понимании полноценная постановка задачи. В.М. Наверное, сможете и сами. Почему бы нет? Надо лишь помнить, что целое - больше, чем сумма частей. Помните, как старый Финн оживлял изрубленного Руслана? Мало было сложить все члены - их пришлось ещё полить сначала мёртвой, а потом живой водой (срастить и вдохнуть жизнь). А этого в инете не сыщешь. М.В. Я работаю в комитете по финансам края. Автоматизированная система бюджетного финансирования, которая по сложности и разнообразию, конечно же, не сравнится с врачебной деятельностью, осваивалась мной в течение пары лет плотного общения, после чего я более-менее стал понимать детали процесса. В течение этих лет программа росла и сильно изменялась, потому что понимание приходило постепенно. Пользователь никогда не сможет рассказать всё сразу: что-то упустит, что-то просто сам не представляет, как это должно быть при автоматизации. Так что в любом случае постановщиками должны быть врачи, причем "понюхавшие автоматизации", а уж потом их результаты должны как-то обрабатывать программисты. И для удачного результата необходим итеративный процесс, когда можно сделать очередной кусочек, дать пользователю, посмотреть, как он будет применяться, внести правки, и лишь через несколько таких этапов можно будет остановиться. В.М. Вот именно. И по ходу постановки определяется, какой будет база данных, чтобы она соответствовала и повседневным запросам врача, и целям управления, и разнообразным задачам анализа на разных уровнях, и ещё была надёжно защищена от потерь, и проч. и проч. Об архитектуре базы данных В.М. Архитектура базы данных особенно важна. Большая больница - это далеко не всё здравоохранение. Большинство больниц всё же имеет размеры совершенно не такие, чтобы требовался Оракл. Стоимость системы и её обслуживании для них будет чрезмерно высока. А уж представьте, как это будет выглядеть в сельской больнице! Больница может иметь отдалённые филиалы. Делать оптоволоконную связь с каждым, чтобы нормально работать с центральной базой, - это далеко не лучший вариант. Делать же по базе в каждом таком филиале - очень дорого. N.N. Планируется информатизировать не одну больницу, а около полутора сотен медицинских учреждения и органы управления здравоохранением. М.В. И что: планируется, чтобы на каждом рабочем месте врача любой сельской больницы был круглосуточный Интернет ? А надежность решения? Стоимость простоя? N.N. Технологии конечно дорогие, но заказчик готов платить за эти технологии. М.В. Но ведь, кроме пары-тройки регионов, сделать подобную систему нигде больше не реально! Для примера: Интернет в Алтайском крае только в следующем году обещают добросить уже до всех районов, но пропускная способность канала варьируется от 2 Мбит/с до 64 Кбит/с на район. Какая полоса из этого достанется больнице? И как будет работать Интернет-приложение на рабочем месте ? Это ведь не домашнее пролистывание страничек, где я вполне могу минутное ожидание скачивания странички совместить с кофе. А во что выльется стоимость недоступности истории болезни в случае, когда в райцентр привезут больного, жизнь которого решают минуты? В.М. Тут Вы сгущаете краски: бумажные копии истории болезни всё равно будут. М.В. Пусть так. Но ведь не всякий главврач согласится держать базу неизвестно где в областном центре, где к ней имеет полный доступ неизвестно кто (включая начальство!). А как быть с закрытыми сведениями, с врачебной тайной? С Указом президента № 611? Если вести обмен данными по Интернет, то их хоть шифруй, хоть не шифруй... Пароль для архива - ещё не защита. Я по долгу службы постоянно вынужден охлаждать тех, кто готов всё вынести в Интернет. После этого им уже не хочется брать на себя потенциальную ответственность за явное нарушение закона. Благо, что пока у нас еще не было в стране уголовных дел по поводу хищения и подделки электронной информации. В.М. Я придерживаюсь такого правила: при автоматизации защищённость и надёжность данных не должны быть меньше, чем те же характеристики в традиционных условиях. Когда истории болезни хранятся в архиве, в регистратуре, в ординаторских, в кабинетах участковых врачей, это далеко не полная, но защищённость. На первых порах не надо требовать от автоматизированных систем большего. А вот меньшее, по моему, можно получить, если всё хранить в одном месте. М.В. В том-то и дело. В надёжности при такой архитектуре есть свои изъяны. Если возникнет проблема с базой/железом - это будет ЧП уровня всей огромной больницы! Расходы на hot-swap-серверное решение на базе кластера - очень недешевое решение. Если же разбивать базу на отдельные независимые отделения, каждое со своей базой и делать обмен между ними, как у Владимира Михайловича сейчас, то любые ЧП скажутся гораздо менее, потеря пары часов будет стоить во много раз меньше. И, наконец, в регионах специалистов по Ораклу раз-два и обчёлся, и стоят они столько, что не каждая больница сможет это себе позволить. N.N. Специалистов по Ораклу мы предусматриваем: есть местный институт информатизации. Там же имеется гигантский сервер. Продумана система защиты информации и защиты от сбоев за счет того, что имеется надсервер. Наконец, система активно использует web технологии. М.В. Не сомневаюсь, что в конкретном случае всё предусмотрено. Но это возможно только в исключительных условиях. А о web-технологиях надо сказать особо. Они невероятно модны. Но имеют свои проблемы и ограничения, очень существенные, если речь пойдёт не об информационной системе, а о системе управления. Управление предполагает интенсивный обмен информацией между человеком и компьютером. Если при информационной системе время отклика может достигать минут, то при системе управления оно должно измеряться в секундах. А алгоритмы-то усложняются! Должны идти постоянные обращения к серверу, в зависимости от вводимых полей, и идти выдача советов, смена информации. В общем, логика экранной формы должна работать "на ходу"! А с этим-то web-технологии справляются ... так себе. Использование чистой web-технологии практически несовместимо с идеологией работы врача, которую предлагает система Владимира Михайловича! В.М. То есть, скрестить две системы нельзя? М.В. Может быть, скрещивание и возможно, но усилий это требует немалых и потенциальный успех я бы не взялся предсказывать. Работа врача - это не финансовая транзакция, которая включает десяток килобайт данных, здесь объем оперативного информационного обмена может измеряться в мегабайтах! Даже если использовать чистые технологии использования броузера в качестве клиента (т.е. на сервере абсолютно вся логика), при каждом изменении некоторых полей на сервере должны отрабатываться некоторые запросы, оперативное выполнение которых при невозможности на этапе составления ТЗ прогнозировать нагрузку на сервер БД представляется мне весьма сомнительным. В.М. Теперь Вы вообще преимущества Оракл отрицаете? М.В. Нисколько. Мой вывод сводится к следующему. В центре, где данные консолидируются и делается анализ по больнице/городу/области, Оракл допустим, но не как единственная база, а лишь для итоговой обработки данных. Текущая же работа врачей должна идти с СУБД уровня отделения. Между прочим, почему не MSSQL, который легко масштабируется от персональной СУБД до датацентра? В.М. Но какое же заключение должен я, малограмотный, из всего услышанного сделать? Ведь нет у меня этих проблем. Ни по стоимости, ни по надёжности, ни по специалистам. И, заметьте, не только в отношении стационара (ведь Вы, N.N., пока имеете только стационар), а и по всем видам поликлинических учреждений и по городу в целом. Нет, нет, готов принять на веру: будущее за новыми платформами. Но ведь отсюда ещё не следует, что только за ними. За автомобилем - и настоящее и будущее, но он не стал единственным средством передвижения даже в городе. Кое-где - только на ишаке: и недорого, и вынослив, и неприхотлив, и - главное - пройдёт по любой тропе. Не перестали же разводить ишаков! М.В. Но всё равно для маркетинга совершенно необходимо переложить Ваш продукт на более достойно звучащую (и имеющую определенные плюсы) современную платформу типа Оракл или MSSQL. В.М. Для маркетинга - наверное. А по существу - не убеждён. И совмещение двух готовых систем не могу себе представить. Как к тому, что уже сделано другими, можно привить мою работу? Боюсь, не прививается. М.В. Ну, да, фактически это означает, что принимающая Вас сторона уничтожает свои наработки и берется за Ваши. Не многие на это способны. Как правило, такое может сделать настоящий бизнесмен с дальним прицелом. Вот только есть ли сейчас такие на стыке ИТ и медицины? Идём навстречу и разминёмся? А.В. Я поймал себя на таком сравнении: и Вы, Владимир Михайлович, и я хотим построить некий новый дом для врачей. Цели у нас одинаковые, а пути разные. Вы построили не всю, но большую часть дома и сразу же вдохнули в него жизнь. В этом доме (читаем - системе) есть масса внутренних, самостоятельных и отлаженных процессов, которые имеют непробиваемую аргументацию в своем существовании. Этот дом уже сейчас - живой. А мы пошли по другому пути. Мы строим каркас сразу целого дома. Это строительство - наперёд, на вырост. И только сейчас мы подошли к тому, что надо заполнять это здание живыми процессами. В.М. Выразительная метафора! Добавлю, что мой путь был абсолютно рискованным, статистически безнадёжным, полной авантюрой. Это чистая случайность, что, не зная даже термина "формализация", я сразу удачно формализовал историю болезни. И в руках оказалась та генетическая пылинка, из которой всё логично выросло само собою. Как полноценный организм из ДНК. Ваш путь изначального планирования абсолютно надёжен - дом будет построен. Но есть опасность не учесть многих и важных условий, которые непременно понадобятся "живым процессам". А.В. Думаю, оба подхода имеют право на жизнь. И уже тем более здорово, что есть возможность пообщаться с коллегами, идущими по другим направлениям, избежать каких-то известных граблей и почерпнуть всё ценное, что уже накоплено. В.М. Грабли, которые перед Вами, называются прокрустовым ложем. Размещая обитателей, потребности которых полностью не изучены, в умозрительно спланированном доме, как бы не пришлось то отсекать те их функции, которые туда не втискиваются, то искусственно вводить новые, чтобы заполнить пустоты. Мои же грабли - несовременная внешность и отсутствие тех средств, которые сегодня считаются признаками перспективности. Боюсь, не избежим мы неприятностей. Не удаётся нам сойтись на одном пути: каждый дорожит тем, что сделал сам. Там, где опоздали с сотрудничеством, появляются соперничество и упущенные возможности. Дело осложняется непросвещённостью и нетребовательностью пользователей. Это мы, сконструировавшие идеальный лечебно-диагностический процесс, сами вынуждены ставить этому процессу (и себе) идеальные требования. Оценивалась бы медицина, действительно, по конечному результату, пользователь быстро бы сориентировался, что ему нужно. И мы были бы ближе к истине. Не судьба. А.В. Всё равно, важен сам процесс созидания, а не бездействия. Что же будет? В.М.Согласен, но хотелось бы большего. Впрочем, есть и такой лозунг: "Больше систем, хороших и разных". Может быть, надо думать не о том, чтобы всё выстроить по единым техническим стандартам, а об информационной совместимости и взаимодействии разных работоспособных систем? Пусть внизу работают разные системы. Это позволит наилучшим образом учитывать разнообразие конкретных условий и потребностей. А объединить их в слаженный конгломерат - это ведь вопрос чистой техники, только техники. Достаточно создать способы передачи данных из одной системы в другую и в общие системы верхнего уровня. Нет необходимости передавать буквально всё. Нет нужды передавать немедленно. На каждом уровне - свой ограниченный круг задач и свои ритмы работы. Только для этих задач и с этой ритмичностью нужна там информация. В конце концов, всё сводится к тому, чтобы наилучшим образом на каждом уровне получать наилучший конечный результат и в этом смысле удовлетворить каждого пользователя. На этом бы сосредоточиться...