|
ЗАЧЕМ И КАК |
|
Выпуск 15 18 января 2005 г. М.В.Прокошин, один из самых активных моих читателей,прислал очень важные замечания по поводу 13-го выпуска, где речь впервые зашла об АРМе врача. Занятно, что с этими замечаниями я согласен и в то же время готов настаивать на своём. Такое бывает лишь тогда, когда один и тот же предмет рассматривается в разном свете, в разных обстоятельствах. При ближайшем рассмотрении спор оказывается мнимым, понимание ситуации углубляется, противоречия побуждают не подавлять друг друга, а взаимно дополнять. Это достаточно интересно и важно, чтобы опять прервать последовательное изложение для ещё одного разговора в антракте. О системном подходе. О техническом прогрессе. О программистах. О сети. О единой истории болезни. О страховке информации. РАЗГОВОР В АНТРАКТЕ. О ТЕХНИЧЕСКОМ УРОВНЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ М.В.Прокошин. «Вы коснулись тех скользких технических мест, за которые Ваша система будет (и справедливо) критиковаться программистами-профессионалами. То, что касается систем и принципов управления, у Вас отлично написано. Выглядит просто как краткая выдержка из лекции по системному анализу - есть такой предмет, где изучают то, что Вы годами вырабатывали на основе опыта. Подозреваю, что у Вас таких предметов в свое время не было, но с подобными материалами по проектированию и функционированию систем Вы явно знакомы (это комплимент, потому что даже далеко не все те, кто учился этому, понимают и применяют принципы подобных вещей)». Я. Не совсем так. Я был зрелым врачом и исследователем, когда – в середине семидесятых – в научном обиходе появились такие термины, как системный подход, системный анализ, объект управления, управляющий блок, аналитический блок, обратная связь, алгоритм. Активно участвовал в ряде конференций на эту тему, общался с интересными математиками, читал кое-что и, конечно, старался применять узнанное в своей работе. Публиковал статьи о системном анализе в медицине. В 1997 написал книгу, первая глава которой называется «Системный анализ лечебно-диагностического процесса», в 1996-1998 гг. читал курс лекций на эту тему врачам-курсантам Тюменской медицинской академии. Давно убеждён, что успешная автоматизация медицинской практики возможно только на основе её анализа в качестве сложной, многоуровневой системы управления. Без этого будут получаться нежизнеспособные программные продукты. М.В.Прокошин.«Теперь о неприятном. Рассуждения о сети и расположении БД являются узкоспециализированными (применимы исключительно к Вашему комплексу). Эти положения спорны и некритичны. Я прекрасно понимаю Вашу точку зрения. Проистекает она из 1) возможно, некоторого отставания от технологического прогресса, не в упрек Вам будет сказано; 2) большого опыта работы в условиях крайней нищеты медицинских учреждений». Я. Конечно, Вы правы. Но при большой разработке отставание от стремительного прогресса неизбежно. Программисты знают, что после завершения программы хочется сделать её заново с учётом появившихся новшеств. Однако использование всё новых возможностей – не самоцель. Если задача решена и удовлетворяет пользователя, нет необходимости в бесконечных переделках только из-за того, что технический прогресс уже сделал следующий шаг. Я переходил от бейсика к Foxbase, затем – к Foxpro 2, затем – к Visual Foxpro, от ДОС – к Windows, от советских ДВК2 (слыхали о таких?) - к Роботронам, XT, Pentium. Переходил по мере того, как всё это появлялось, однако не потому, что это появлялось, а потому, что мне всё время не хватало скоростей, оперативной памяти и дисковой памяти. Но вот наступил другая пора. Теперь для решения медицинских задач, для сложных логических заключений, для обработки многолетних баз данных ресурсов хватает с огромным избытком. Внутренний стимул к поиску более совершенных средств отпал. Остался только внешний стимул – выглядеть «на уровне», «как у людей». А вот на это нет ни времени, ни сил. Силы отвлечены на другое, на специфическое для медицины: уже использованные технические возможности открыли такой простор для решения содержательных задач, что дай бог продвинуться как можно дальше на этом пути. И нищета медицинских учреждений сыграла свою роль. Но если жаловаться на нищету и ждать богатства, жизнь пройдёт в жалобах. Я не могу быть приверженцем принципа «Сначала условия – потом работа». Он претит мне как врачу. Есть или нет условия – врач лечит всегда. Вот и помогать ему надо всегда, используя то, что есть, в предлагаемых обстоятельствах. Не лишне заметить, что те, кто склонен выдвигать максимальные предварительные условия, редко бывают удовлетворены: пока они получат требуемое, прогресс шагнёт дальше, и можно не работать, а опять ставить условия. Вообще, работа врача – прекрасная модель целеустремлённой деятельности. Невозможно представить себе врача, который ничего не предпринимает, если ему не дали самых современных средств диагностики и лечения. А программистов таких я видел. И они были на хорошем счету: эрудиты и защитники принципов, не применяющие в деле ни этих принципов, ни эрудиции. А потому и вообще ничего не делающие. Но по объективным причинам! М.В.Прокошин. «В настоящее время системы файл-сервер перестают быть жизнеспособными по нескольким причинам: 1) супернизкая надежность при работе (критичность к техническим проблемам типа поломки железа и т.д.); 2) низкая надежность при разработке (невозможность автоматически поддерживать во всех местах ввода единые правила для связей таблиц и т.д.), что выливается опять же в ненадежность работы программ (хорошо, конечно, что Вы за долгие годы все АРМы отладили, но в условиях современной разработки это уже неприемлемо); 3) плохая масштабируемость (это зависит от технологии разработки программ, но в итоге дает свой печальный результат). Там, где нормально работают 5 пользователей, 50 работать не смогут с приемлемым временем отклика. Это можно не комментировать, я знаком с разными системами, в т.ч. и с собственной и уверяю, что бывают надобности пользователя, которые приводят именно к такому результату. Хорошо, если в Вашей предметной области Вы с этим не столкнулись. 4) что вторично, но весьма актуально в настоящий момент, коммерческая ценность систем, построенных на схеме файл-сервер неуклонно падает и уже весьма близка к нулю. В настоящий момент даже локальные системы на один компьютер делаются на базе СУБД, таких, как MS-SQL (и его малопользовательская бесплатная редакция MSDE), Oracle (и Personal Oracle), Sybase, Cache. Как минимум, у Access и FoxPro в современных версиях есть понятие единой БД (все хранится в одном файле), в которой автоматически поддерживаются связи, целостность, ограничения, транзакции и т.д., они остаются файл-серверами, но это является компромиссом по надежности работы и скорости и надежности разработки. Из современных ШИРОКО распространенных систем автоматизации в совершенно разных отраслях уже чрезвычайно мало опирающихся на старую систему работы с dbf и т.д.». Я. Признаю правоту своего оппонента. Ни один из этих постулатов невозможно опровергнуть. Но руководством к действию они могут быть, только если а) начать автоматизацию лечебно-диагностического процесса с нуля, б) иметь хорошую постановку задач и в) иметь хорошего программиста. Я с лёгким сердцем откажусь от своих программ, когда на смену им придут такие по-современному выполненные программы, которые будут решать те же содержательные задачи ничуть не хуже, чем это уже удаётся. Я сыграл роль программиста вынужденно, лишь потому, что надо было реализовать, воплотить, проверить на практике, отдать врачам, в работу то, что я узнал и понял о лечебно-диагностическом процессе. Не программы я считаю своей заслугой, а методическое обеспечение автоматизации, постановку задач и разработку алгоритмов их решения. Программирование потребовалось мне только потому, что иначе я не мог бы никому представить сделанное весомо, грубо, зримо. Удалось вычертить всё сложное здание, сделать его функциональным, продумать все закоулки, все коммуникации, учесть все штатные и нештатные ситуации жизни медицинских учреждений. Кому понадобился бы этот огромный чертёж с тысячами деталей, если бы само здание не было построено из подручных материалов? Его можно построить из новых, совершенных материалов, повышающих надёжность и функциональность? Не сомневаюсь. Стройте. Чертёж готов. Но в ожидании новых построек старые должны функционировать. Мечта не должна отрицать то, что уже реально существует, она должна его продолжать. Теперь о хороших программистах. За четверть века я встретил четырёх программистов, у которых кое-чему научился и которым сердечно благодарен. Все остальные встречи мешали работать. Мешали амбиции тех, кто уже сделал что-то своё, мешал максимализм («сначала надо создать условия»), мешали малограмотность и просто глупость, мешала абсолютная неподконтрольность вычислительных центров никому. Мешало и то, что я слишком далеко зашёл сам – включиться в мою работу в качестве соавторов уже никто не мог, это выглядело бы слишком некрасиво. Наверное, мне просто не повезло. Но судите сами. Зарисовки с натуры Этюд двадцать первый. «500 или 18» 1989. ВЦ Свердловского областного управления здравоохранением не справляется с обработкой выездных карт станции скорой помощи (там функционировала моя система и программное обеспечение, сделанное моим сотрудником). В Новосибирске, Новокузнецке, Тюмени справляются – здесь нет. Шёл далеко не первый месяц эксплуатации программы, когда случай привёл меня в это учреждение. Удивлённый, я вместе с директором ВЦ зашёл рано утром в операторскую, где данные карт набивались на магнитные носители. Работали несколько девушек-операторов. Одна из них за смену ввела 500 или 600 карт, другая…18. Директору потребовалось нанести такой визит ещё пару раз, и станция скорой помощи стала получать своевременные сводки и анализ работы. Этюд двадцать второй. «Сначала - условия» 1989. Тот же ВЦ Свердловского областного управления здравоохранением, страдающий от отсутствия задач для эксплуатации. К тому времени в Барнауле функционировал мой «Приёмный покой», сделанный под то, что там имелось – под ДВК-2. Это было странное, но доступное создание, с помощью которого моя программа всё-таки обеспечивала большую больницу скорой помощи о напряжённой работе дежурных врачей. Руководители Свердловского ВЦ просят у меня программы. Демонстрирую. - Хорошая программа. Но для неё нужны машины. - У вас есть ДВК-2? - Конечно.
- У вас есть другие?
- Других нет.
- Так зачем вы интересуетесь программами?
- А как же! ВЦ должен эксплуатировать какие-то задачи.
Этюд двадцать третий. «Искусственный интеллект»
1989. ВЦ Алтайского краевого отдела здравоохранения взял в эксплуатацию систему «Скорая помощь». Месяц за месяцем ВЦ обрабатывал только одну (центральную) подстанцию, на остальные 7 не хватало сил. Заведующий горздравотделом потребовал объяснений. Причина оказалась совсем уж несуразной. Карты выезда, как обычно, набивались на магнитные носители. При обработке программный контроль выдавал сообщения о дефектах и требовал их исправления с повторной обработкой. Программный контроль занимал секунды, но руководитель решил, что машине надо помочь – до ввода … поискать ошибки в картах вручную . Для этого создали группу из квалифицированных работников, которые предварительно полдня копались в сотнях карт, а уж потом давали их набивать на магнитный носитель. Когда группа был ликвидирована, все 8 подстанций стали обрабатываться без проблем. Можете не верить. Можете смеяться. Можете считать, что я преувеличил. Но это – умопомрачительная правда (или правда о помрачённых умах). В кабинете того руководителя висел лозунг: «Искусственный интеллект – к 2000 году».
Этюд двадцать четвёртый. «Похвалили»
1990. Барнаул. По моей постановке некая фирма (очень приятные люди) разрабатывает программу обработки талонов учёта заболеваний (статталон). Постановка простая и ясная, никаких хитростей, кроме контроля информации на вводе с учётом большого числа неподготовленных пользователей: медстатистики десятка поликлиник приходили в оргметодкабинет горздрава и вводили статталоны за прошлые сутки.
Разработка простой программы затянулась непомерно, и я попытался понять, как она реализуется в программах. Вооружился перечнем операторов, тоненькой, но толковой книжицей и листингом соответствующего раздела программы. Удивление моё было двойным. Во-первых, оказалось, что я с горем пополам могу этот листинг прочесть и понять. Но, во-вторых, обнаружились странности: одни и те же операции в разных местах каждый раз программировались сызнова, а я уже узнал, что такое процедура и передача параметров. Нахальным образом я сам переписал листинг, программа стала вдвое короче и вчетверо быстрее. Показал это программистам. Они меня похвалили, сказали, что это очень хорошо. И продолжали работать в прежнем духе. Вот тогда-то я отказался от услуг программистов и стал всё делать сам, лишь иногда прибегая к помощи толковых и добрых людей, да и то, чтобы перенять у них незнакомые мне приёмы.
Могу продолжать – всё будет в том же духе. Из Свердловска мне однажды привезли программу, которая включала в историю болезни фотографию пациента. Кому это может придти в голову? Кто будет требовать у поступающего пациента фотографию или брать для сканирования паспорт? Какую роль играет фотография для оценки состояния больного с диабетом или колитом? Зачем на это кто-то потратил силы ума? В одном краевом вычислительном центре мне с гордостью показывали дистанционную консультативную помощь: врач из сельской больницы отвечал на вопросы программы о больном, а от неё получал … шансы: 30% за аппендицит, 35% за колит и т.д. Как можно было додуматься до такого способа консультировать врача? Я знаю ВЦ, где каждый делает свою задачу и ничего не знает о соседних задачах, руководитель ничего не знает ни про одну из них. Я видел… Стоп, прекращаю.
Понимаю, что хорошие программисты непременно есть. Но почему они не работают в той области, которая меня занимает? Могу высказать три предположения. Прежде всего, потому, что область эта своеобразна, программы для неё нельзя сделать по какой-либо аналогии. Речь не только о массовом пользователе - речь ещё о высокопрофессиональной деятельности в условиях очень слабой формализации. И не информационная система нужна, а система управления. Нет здесь аналогии ни бухгалтерией, ни с продажей железнодорожных билетов. А значит, нужна профессиональная постановка задачи. Без неё хорошему программисту делать нечего. Далее, кроме постановки задачи, нужен требовательный пользователь, а главные врачи не могут ими быть. Программисты при главном враче – то же, что жрецы при фараоне. Фараон, как известно, живой бог, но только жрецы решают, что делать и чего не делать. Великолепные условия для застоя. Наконец, хорошим программистам надо хорошо платить – вот мы и опять скатимся к жалобам на нищету.
«Пока вы недовольны жизнью, она проходит». Взявшись за программирование в меру собственных сил, я только хотел делом, а не на словах показать, что и при этих силах, и при этой бедности, здесь и сейчас можно вырваться из той отсталости, которая характеризует работу с медицинской информацией. Если на деле показано, что это возможно при таких условиях, то при более благоприятных – тем паче.
М.В.Прокошин.Да, сеть не панацея, но сейчас уже даже при нищете здравоохранения смешно говорить об отсутствии сети. Это уже из серии "кто хочет работать - тот делает, кто не хочет - ищет отговорки". Стоимость прокладки сети и оборудования начального уровня просто смешная. Надежность же работы сети сейчас на витой паре весьма высока (если не говорить о том безобразии, когда зачастую провода лежат поперек коридора, потому как недосуг прибить к потолку, и все подряд о них запинаются. Но после 3-10 инцидентов с вырванными гнездами, обычно этот момент также улаживается)».
Я. >И правда - смешно. Но смехом дело не сдвинешь. С 1993 года моя система работает в крупной больнице нефтяников в Тюмени, а сеть появилась только летом 2004 года. Надо было подождать с внедрением до этого события? В конце 2004 г. систему ввели в одном учреждении Ханты-Мансийска, где сеть – только в одном из двух корпусов. Не стоило вводить? В Кировской областной больнице в 2000 году сеть охватывала 2 корпуса из 6, сейчас - 4 из 6. Отказаться от эксплуатации? Да и так ли это смешно, если в реальной жизни главный врач сталкивается то с отсутствием денег, то с нерасторопностью фирмы, которая берётся проложить сеть, то с некомпетентностью партнёра? Давайте смеяться, но одновременно будем готовы работать и при этих смешных обстоятельствах.
В той же Тюмени с начала 90-х работает с моей системой полтора десятка поликлиник разного калибра, в Барнауле – большущая поликлиника № 9. Нет там сетей. Если делать программы, которые работают только в сети, надо надолго отказаться от надежд автоматизации всех районных и участковых больниц – пусть ждут светлого будущего.
Я не против сети, яза то, чтобы программы могли работать и до того, как она появится у пользователя.
М.В.Прокошин.«Приятно, что у Вас в АРМ есть возможность переноса информации через дискеты, более того, десять лет назад она была жизненно необходима, но в современных условиях проще обеспечить бесперебойную работу сети. У нас за десять лет сеть ломалась 3 раза, два из них по причине поломок сервера, которые пользователю можно было вообще не заметить если бы у нас было нормальное клиент-серверное решение, а не FoxPro for DOS. Ликвидация поломок в минимальном варианте занимала от 1. до 8 ч. При НОРМАЛЬНОМ решении с использованием СУБД эти поломки вообще бы не сказались на пользователях или, при экономии на технике за счет надежности, затраты времени были бы порядка 1 ч. Про поломку на уровне сетевого оборудования и проводов я вообще не говорю, т.к. минимальные расходы на длинный кабель-переноску и гарантийное письмо, под которое можно взять дубликат HUBа в любой фирме в течение 1ч., могут обеспечить нормальную работу в самых экстремальных условиях. Беда не в технике, она в головах тех людей, которые в мед. учреждениях отвечают за сеть и автоматизацию. Уж извините, но на те деньги, что в больницах платят, профессионалы не идут, посему и приходится Вам до сих пор воевать с ветряными мельницами. И в любом случае, по возможности, надо настаивать на тендерах. Без них (без участия посторонних фирм, занимающихся делами ПРОФЕССИОНАЛЬНО) видим в учреждениях разруху, так как только этот вариант имеет какие-то гарантии, с дяди Васи же, который лампочки вкручивает, а по совместительству еще и сети тянет - гарантий никаких. Я
понимаю, что Вы по мере сил боретесь с непрофессионалами на ВСЕХ этапах мед. процесса, но по идее бороться с этим лучше не минимализмом в работе программ, а налаженным обслуживанием и тех. поддержкой (это опять же, увы, не уровень одиночки, поэтому я Вас совершенно не критикую - Вы делаете то, что можете, я лишь хочу показать существующие сейчас взгляды на автоматизацию)».<
Я. О современных взглядах нужно знать. Поэтому я с удовольствием привожу их здесь в Вашем изложении. Но посмотрите, множество условий выдвинутых Вами сводится к двум пунктам: надо ликвидировать бедность и косность. Борьба с бедностью – дело Президента. Борьба с косностью – и наше дело. Один из способов такой борьбы – сделать «через не могу» и убедить показом.
|