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

Выпуск 172 13 мая 2008 г. Наблюдения. Заметки. Реплики. На суждения М.В.Прокошина в выпуске 171 откликнулась в гостевой книге сайта vmtavr2.narod.ru Татьяна. Привожу этот отклик. Уважаемый Михаил Владимирович! Мне сложно соглашаться или не соглашаться с Вашими замечаниями по программам Владимира Михайловича. Может быть Вы и правы, но скажите, пожалуйста, есть ли альтернативы АРМам В.М.Тавровского по содержанию? Я по И-нету пыталась найти хоть что-то похожее, чисто из любознательности, поскольку до реального использования каких-либо автоматизированных рабочих мест врача в нашем регионе ещё очень далеко. Может, Вам трудно поверить, но при освоении одной из приобретённых программ В.М. мне, врачу, не специалисту в области информационных технологий, пришлось обучать регистраторов просто работать на клавиатуре. Честное слово, им и мне было не до интерфейса. Главное, чтобы я могла объяснить, а работающие пользователи могли понять. А следующие заинтересованные лица (статистики, врачи, администрация) получили бы достоверную необходимую информацию. И ещё, чтобы программа была доступна для небогатого лечебного учреждения. И ещё, чтобы надёжна была в использовании. Вот и все требования, которые на сегодняшний день (подчёркиваю: на сегодняшний) предъявляются к медицинским программам на периферии и которым программы Тавровского соответствуют. Наверное, в центральных медучреждениях всё иначе, и можно двигаться дальше. ДАЛЬШЕ, но НЕ ВМЕСТО. В борьбе за внешний лоск и модность не потерять бы суть. По смыслу и глубине анализа альтернативы программам Тавровского не встречала. Было бы любопытно ознакомиться с таковыми, если они существуют. Спасибо. ТЕРМИНОЛОГИЯ: МОДУЛЬНОСТЬ Значение терминов "модули" и "модульность" зависит от контекста. Когда в описании автоматизированной системы говорят о таких модулях, как "администратор системы", "документооборот", "нормативно-справочная информация", "идентификация персоны", "ввод данных", "диетпитание" (примеры взяты из описания системы Интерин - http://www.interin.ru), то каждый раз имеют в виду группу задач или функций, которые выполняются одним и тем же компонентом программы - подпрограммой или процедурой. Хорошо бы эти (как правило, неотъемлемые!) компоненты так и называть, именно этими принятыми у программиcтов терминами, но... как сложилось, так сложилось. Однако пользователю важно иметь представление о модулях в другом понимании, о структуре, о составе всей медицинской информационной системы: существует она как некий монолит или допускает различные комбинации своих частей. Одно из определений термина "модуль" в словаре Ожегова и Шведовой - "Отделяемая, относительно самостоятельная часть какой-нибудь системы, организации". Это-то нас и занимает: отделяемые части. . О модульности системы в указанном понимании, говорят редко и мало. Между тем, она - в ряду важнейших для пользователя характеристик. От неё зависит гибкость системы, условия её приобретения, возможности наращивания и развития. Позволяет ли система ввести сначала только автоматизаацию работы врача и обработку информации на уровне учреждения, а всё остальное отложить до лучших времён? Можно ли какой-то из компонентов (модулей) системы использовать вообще независимо от других? В какой степени совершенствование одного компонента вынуждает к изменениям в других частях системы? Вопросы это сугубо практические: к поэтапному внедрению системы побуждают и элементарная осторожность, и финансовые соображения, и учёт настроений в коллективе, и особенности зданий, в которых размещено учреждение. "Всё или ничего" - не лучший принцип для главного врача, решившегося на автоматизацию. Не годится и принцип "С бору по сосенке": вводя частичную автоматизацию, надо быть уверенным, что следующие модули легко состыкуются с тем, что уже введено. Системы предлагаются разные - от локальных до всеобъемлющих. Изолированный АРМ врача, программа для профилактических медицинских осмотров, программы составления реестров для ФОМС или для льготных рецептов, - все эти продукты по необходимости должны вписываться в обычную информационную среду медицинского учреждения. Но предусмотрено ли их включение в будущую целостную автоматизированную систему? Задуманы ли они как составные части, как модули этой системы? Заложена ли в них возможность обмениваться информацией с другими компонентами не только в "ручном", но и в автоматическом режиме? Другая группа вопросов: что собой представляют системы, претендующие на полноту или даже всеохватность? Упомянутая выше система Интерин содержит буквально всё: стационар и поликлинику, бухгалтерию и аптечный склад, кадры и экономику, даже место для того, чтобы записать, какие вещи поступивший больной сдал в приёмном покое. Но всегда ли главный врач может и хочет ввести всё это разом? Можно ли разделить подобную систему на такие компоненты, которые до поры до времени будут функционировать отдельно, взаимодействуя с пока ещё не автоматизированной остальной средой? На какие именно? Какой, вообще, должна быть модульность медицинской системы с позиций пользователя? Естественно отталкиваться от разнообразия структуры, функций и калибра медицинских учреждений. Существуют и самостоятельные стационары и поликлиники, и больнично-поликлинические объединения - следовательно, системы "Стационар" и "Поликлиника" должны быть самостоятельными, но способными к стыковке. Разные объекты учреждения нуждаются в автоматизации в разной степени: одни - непременно с самого начала, другие могут и подождать. К первым относятся те, где необходима вся полнота истории болезни: клинические отделения стационара, кабинеты участковых врачей и "узких" специалистов поликлиники, кабинеты главного врача, его заместителей и медицинских статистиков. Соответственно, АРМы лечащих врачей и программы, которые осуществляют обработку и анализ данных для управления лечебно-диагностическим процессом, - это системообразующие компоненты, с них начинается настоящая автоматизация. Эти два типа программ - АРМы врача и "Управление" - связаны между собою достаточно жёстко: первые без вторых работают ущербно, вторые без первых не работают вообще. Тем не менее, они должны быть достаточно обособлены друг от друга, Во-первых, у каждого компонента - свои специфические задачи (задачи лечащего врача и задачи руководителя). Во-вторых, приобретать их надо в разных количествах: АРМы врача - по числу врачебных кабинетов в поликлинике и, как минимум, по числу клинических отделений в стационаре, "Управление" же сначала совершенно необходимо только медицинскому статистику, а уж потом потребуется и главному врачу, и его заместителям. Отсюда следует, что они должны представлять собою два разных, но постоянно и тесно взаимодействующих модуля. Особняком стоят объекты, вообще не имеющие отношения к медицинскому состоянию пациента: бухгалтерия, экономист, отдел кадров, аптека и проч. Идея так называемых комплексных систем, обеспечивающих в одной конструкции медицинскую и административно-хозяйственную деятельность, вглядит спорной. Какая нужда объединять функции, основанные на абсолютно разных первичных носителях информации, имеющие принципиально разные задачи и выполняющиеся по совершенно разным правилам? Не лучше ли автоматизировать их порознь, обеспечив только передачу той простой и очень ограниченной информации, которая нужна службам АХЧ от медицины и медицине от них? Если же всё-таки пойти на подобную интеграцию, то желательно предоставить руководителю учреждения свободу выбора: автоматизировать все эти службы или только некоторые из них, или вообще их не трогать. Для этого автоматизация административно-хозяйственных служб должна обеспечиваться отдельными модулями: "Бухгалтерия", "Кадры", "Аптека" и проч. К слову сказать, такие модули могут использоваться и сами по себе: и друг без друга, и без собственно медицинской системы. Это возможно именно потому, что их внешние связи немногочисленны, что большинство обратных связей замыкается внутри, в них самих. Широко распространённая автоматизация бухгалтерии - лучший тому пример. Но вернёмся к медицине. Стоит понять, автоматизация каких медицинских объектов стационара и поликлиники может быть отложена без ущерба для функционирования обязательного минимума: АРМов врача и программ анализа и управления. На мой взгляд, это - все те подразделения, где история болезни в своём полном виде не требуется, где нужны лишь её отдельные и немногочисленные реквизиты. Такова, например, лабораторная служба, куда АРМ врача должен передать запросы, а получить анализы. То и другое без особых проблем осуществляется и без автоматизации. Разумеется, когда появится возможность автоматизировать лаборатории, это принесёт новые удобства и освободит медицинских сестёр от ввода результатов обследования в истории болезни. Но возможности не всегда появляются быстро. Так что хорошо, чтобы программа "Лаборатории и диагностические кабинеты" существовала как модуль, который система легко принимает в свой состав, но и без которого её главные функции осуществляются вполне успешно. Другой пример - программа для регистрации временной нетрудоспособности ("Больничный лист"). Очень удобно, если такой модуль включается в систему для стационара или для поликлиники. Но и без него можно прожить. С другой стороны, этой программе так мало требуется от истории болезни, что её вполне можно использовать автономно, без автоматизации основной врачебной деятельности (если, конечно, программист сделал её именно как модуль). В том же ряду - программы для массовых медицинских осмотров, для флюорографической станции, для кабинета вакцинопрофилактики. Все соответствующие виды деятельности можно автоматизировать порознь, все они по типу задач могут функционировать самостоятельно. В свою очередь, АРМы врача и "Управление" могут функционировать, несмотря на отсутствие упомянутых программ. Но когда есть и то, и другое, естественно всё объединять, стыковывать. А это возможно лишь при условии, что каждая такая программа изначально задумана как модуль целостной системы. Наконец, по собственному опыту могу утверждать, что есть ещё два специфических объекта, автоматизация которых с самого начала вовсе не обязательна. Это приёмный покой в такой больнице, которая, как правило, не принимает больных по неотложным поводам, и регистратура в поликлинике. В больницах, оказывающих преимущественно плановую помощь, функции приёмного покоя редуцированы и почти не требуют участия врача: предъявляются документы, заполняется "паспортная" часть истории болезни и пациента провожают в отделение. Зато там, куда поступают для неотложной помощи, приёмный покой - важнейшее подразделение, здесь идёт интенсивная работа врачей: диагностика, лечение, сортировка, контакты со всеми отделениями, внешние контакты - со станциями скорой помощи, с поликлиникой, с милицей. Оно по особому организовано: здесь действует не один и тот же коллектив, а сменяющие друг друга бригады дежурных врачей. Поэтому АРМ врача приёмного покоя не может быть таким же, как АРМ врача отделения. Это - особый модуль. Но именно модуль, то есть отделяемая от системы часть. Там, где в ней острой необходимости нет, с её приобретением можно подождать. Но сама система должна быть готова к подключению такого модуля. Предполагаю, что в отношении регистратуры с мною многие не согласятся. Считается, что именно её автоматизация может дать много полезного, в том числе составление расписания врача, подсчёт его нагрузки, определение маршрута пациента. Однако, я располагаю опытом автоматизации и небольших, и очень крупных поликлиник(обслуживающих и 70, и 90 тысяч жителей) и убеждён, что регистратура - последний по важности объект автоматизации. За неё охотно берутся ввиду относительной простоты задачи. Но именно благодаря своей простоте этот объект так хорошо организован, что и без автоматизации функционирует вполне чётко: и больных к врачу направляет, и врача - на дом к больным. Спору нет, атвоматизация полезна и здесь. Речь только об очерёдности, о том, что вовсе нет необходимости всё делать одновременно. Наоборот, надо делать поэтапно всё, что можно. А для этого система должна быть модульной. В частности, регистратура в поликлинике должна быть автоматизирована именно с помощью отдельного модуля, а значит - тогда, когда у главного врача появятся для этого возможности. Модульная организация системы удобна и разработчику. Она позволяет глубже вникнуть в задачи и специфику функционирования каждого объекта автоматизации, а также в особенности его внешних информационных связей. Это важно и при создании системы, и на этапах её совершенствования и развития. С другой стороны, модульность сопряжена с особенностями организации базы данных, а тут есть разные подходы. Но это уже другая история. Таким образом, при знакомстве с медицинской информационной системой имеет смысл обращать внимание на степень её модульности. Ответ на вопрос об имеющихся модулях и о том, какой минимальный набор модулей обязателен с самого начала, может многое определить в стратегии главного врача.