что значит спо в медицине
Что значит спо в медицине
Смотреть что такое «СПО» в других словарях:
спо́ра — спора … Русское словесное ударение
СПО — система программного обеспечения Словарь: С. Фадеев. Словарь сокращений современного русского языка. С. Пб.: Политехника, 1997. 527 с. СПО спуско подъёмные операции СПО сигнализатор предельных оборотов в маркировке Примеры использования … Словарь сокращений и аббревиатур
СПО — [спо], неизм., м. Секретно политический отдел ОГПу. ◘ В начале 20 х гг. СПО ОГПУ следил за деятельностью политических группировок. С 30 х гг. следит за гос и партаппаратом, за интеллигенцией, за “идеологическими” науками. Росси, т. 2, 384 … Толковый словарь языка Совдепии
споїти — дієслово доконаного виду підігнати, скріпити споїти дієслово доконаного виду зробити п яним або п яницею … Орфографічний словник української мови
СПО — СПО аббревиатура, может расшифровываться как Свободное программное обеспечение Сервисный пункт обслуживания Сеть пультовой охраны Сельское потребительское общество Синдром противоречий и обязательств Системное программное обеспечение… … Википедия
спо — сущ., кол во синонимов: 2 • обеспечение (32) • союз (57) Словарь синонимов ASIS. В.Н. Тришин. 2013 … Словарь синонимов
споёт(ся) — [спеть(ся)] … Словарь употребления буквы Ё
спо́ры — спор, мн. (ед. спора, ы, ж.). 1. Микроскопические зачатки низших (грибов, водорослей, лишайников) и высших (мохообразных, папоротникообразных и др.) растений, служащие для их размножения и сохранения в неблагоприятных условиях. 2. Одноклеточные и … Малый академический словарь
споїти — I спо їти див. споювати I. II сп оїти див. споювати II … Український тлумачний словник
СПО — или спецпредложение, SPO (англ.) Special Offer это готовый туристический продукт туроператорской компании, как правило, всегда имеет свой номер и дату выпуска. В большинстве компаний своем составляющем означает специальную цену на размещение в… … Лексикон туриста
СПО — см. Слой половинного ослабления … Большой медицинский словарь
СПО в медицине
Столик с подсветкой для проведения анализов
Олег Бройтман
Главными достоинствами свободного программного обеспечения (СПО) принято считать надежность и предсказуемость. Казалось бы, именно эти качества должны быть востребованы медициной. Тем не менее, если говорить о каких-то радикальных преимуществах СПО перед проприетарным софтом с точки зрения медицинских учреждений, то прежде всего следует иметь в виду два критерия. Во-первых, это стоимость решений, которая в случае применения СПО должна быть ниже. Конечно, сейчас в медицине есть деньги, и это позволяет лабораториям и госпиталям выходить на рынок в качестве покупателей, а не ждать государственных поставок, но совсем не обращать внимание на ценовой фактор не может позволить себе ни одна даже самая крупная и самая богатая клиника.
Во-вторых, это возможность тщательно инспектировать предлагаемые решения. В этом плане об открытом коде чаще говорят применительно к оборонной сфере. К медицине подобная риторика полностью подходит, разве что меньше людей об этом задумываются. Но, как мне представляется, это вопрос времени. Нельзя забывать, что относительное благополучие наступило совсем недавно и пока лечебные учреждения решают куда более актуальные для себя проблемы, которых накопилось очень много.
Пока у нас нет серьезных оснований для того, чтобы говорить о масштабных внедрениях СПО в медицине. Сегодня Windows — главная платформа в медицинских учреждениях. Что же является причиной этого — привычки пользователей или какие-то объективные обстоятельства?
Программист ГУ РНЦХ им. акад. Б. В. Петровского РАМН и сотрудник компании “БиоХимМак” Олег Бройтман отмечает следующее: “На мой взгляд, первая причина играет какую-то роль, но не является определяющей. Важно понимать, о каких именно пользователях идет речь. Если говорить о менеджерах по продажам медицинского оборудования, то их работа практически ничем не отличается от того, что делают их коллеги в других отраслях. И набор ПО аналогичный — MS Windows и MS Office. Со специалистами, имеющими отношение непосредственно к процессу лечения, ситуация обстоит несколько сложнее. Как известно, у пользователя нет привычки к платформе — есть привычка к интерфейсу. А он у медицинских программ слабо изменился со времен, когда писали АРМ’ы, работающие под управлением DOS. Сделать примерно то же самое, но под Linux — не слишком сложная задача”.
Однако, как известно, сейчас этим никто не занимается. Таким образом, получается, что правила игры определяют не пользователи, а разработчики. Поскольку программистов, имеющих дело только с Windows много, то отсюда и получается общая картина.
Говорить же о плохой обучаемости пользователей применительно к медицине — совершенно некорректно. В клиниках трудятся весьма грамотные люди, и проблем с переходом на другую платформу у них скорее всего не будет. Некоторые проблемы возможны из-за частично закрытого оборудования, что доставляет разработчикам много лишних хлопот. Правда, не столько технических, сколько организационных. Дело в том, что спецификации ко всем устройствам имеются. Но есть определенные трудности с их получением. Чаще всего производитель говорит, что есть устройство, есть программа под Windows и больше ничего не требуется. А когда все-таки присылает документацию, то оказывается, что составлена она из рук вон плохо.
В этой связи Олег Бройтман говорит: “В результате мы тратим дополнительные усилия на то, чтобы разобраться во всем самостоятельно. Хорошо еще, что все используемые протоколы вполне стандартны. Тем не менее приходится заниматься в некотором смысле хакерством — применять так называемые снифферы для понимания того, как работает аппаратура. Если же говорить о несовместимости устройств с Linux, то тут все нормально — стандартные разъемы, стандартные интерфейсы. Никаких принципиальных ограничений я не вижу”.
Казалось бы, самое время начать разговор о некоем заговоре производителей. Однако, вероятно, причины такого их поведения вполне прозаичны — они хотят снизить себестоимость своих решений. Причем компании экономят не только и не столько на качестве документации, сколько на поддержке пользователя. Значительно дешевле дать потребителю одну программу для узкого круга операционных систем — скажем, только для Windows 98 и XP, но не для Vista.
Если дать пользователю описание протокола, то появляется риск, что потом надо будет отвечать на вопросы, в новых моделях прибора реализовывать тот же протокол. Можно предложить заказчику программы для Linux, но их затем придется поддерживать, что связано с дополнительными расходами. Правда, в теории это увеличивает количество покупателей. То есть производители оборудования находятся в сложном положении.
Казалось бы, самое простое решение лежит в “однополярной” плоскости. Мол, есть одна система, для нее пишется одна программа, и не имеющий выбора пользователь будет удовлетворен. Но это не так. Даже пользователи, ничего, кроме Windows, не знающие, недовольны подходом “вот вам наша закрытая программа”. Медицине не нужны отдельные приложения — ей требуются комплексные решения. Закрытый инструмент, не умеющий хотя бы выдавать информацию в стандартных форматах, — это проблема.
И здесь СПО опять демонстрирует свои преимущества, скорее, в идеологическом смысле, а не техническом. СПО требует открытых стандартов и открытых протоколов без проприетарных расширений, открытых форматов данных, и такая открытость в медицине ценится, потому что позволяет создавать большие интегрированные решения, когда сведения хранятся в БД в стандартных форматах, информация перемещается между подразделениями и внутри подразделений по известным протоколам, везде можно наладить учёт, контроль, взаимодействие — знай только протоколы и форматы данных.
Говоря о положительных моментах открытости, Олег Бройтман приводит следующий пример: “Возьмем обычную лаборантскую плашку, в которой есть 96 лунок. В них надо накапать кровь пациентов, поверх добавить различные аллергены, а потом еще и реагенты. Представляете, как внимателен должен быть сотрудник, чтобы ничего не перепутать? Да еще с учетом того, что в день ему приходится готовить несколько таких плашек.
Вероятность ошибки очень высока. И в этом нет вины среднего медперсонала — в большинстве случаев это добросовестные грамотные люди. Но только слишком загруженные работой.
В помощь лаборанту изготавливаются столики с подсветкой из 96 двухцветных светодиодов. На него ставится плашка и наша программа Medap-RM показывает, куда надо капать какой материал и какой реагент. На устройстве есть клавиатура, позволяющая выбирать пациента и аллерген. Вероятность ошибки резко снижается. Да и время, необходимое для подготовки материалов для анализа, существенно сокращается.
Это устройство разработано группой инженеров из Минска. Кстати, все они пользуются Red Hat. Столик подключается к компьютеру по USB, и тип конвертера поддерживается Linux. Драйвер есть в ядре системы, пользователю надо просто присоединить устройство”.
Возможно, кому-то этот пример покажется не настолько масштабным, чтобы воспринимать его всерьез. Далекие от медицины люди наверняка ждали историй про роботов-хирургов. Увы, тот, кто умеет их сочинять, пишет не статьи, а фантастические рассказы.
Задачи медицинской информатики значительно приземленней и прагматичней. Есть две серьезные проблемы — возможность человеческой ошибки и длительное время обработки данных. На сегодняшний день они, на мой взгляд, носят первостепенный характер. Избитая фраза про цену минуты — это ведь не просто риторика.
То есть главные критерии — скорость и качество обработки информации. В случае использования проприетарных технологий и закрытых протоколов на пути создания интегрированных решений встают трудности, иногда непреодолимые. Происходит так называемый vendor lock-in, и клиенты остаются на милости производителя. А он не всегда откликается на насущные потребности пользователей.
К тому же нельзя забывать о цене. Конечно, с учетом стоимости всего аппаратно-программного комплекса экономия будет выражаться фактически в копейках. В этом случае весьма уместной будет аналогия — то мы говорили о минутах, то о копейках. Но вполне возможна ситуация, когда медицинскому учреждению не хватит одной копейки, а врачу вследствие этого не хватит одной минуты. К тому же, если говорить о бюджетных учреждениях, финансируемых государством, то экономия может получиться весьма солидной, поскольку таких больниц очень много и каждая нуждается в хорошей информационной системе. Поток пациентов в каждой очень велик. Поэтому речь может идти уже не о минутах — пока медсестра найдет карту больного, пока обработают результаты анализов и представят в удобном для врача виде. Причем на любом этапе есть вероятность человеческой ошибки.
Вот и получается, что в ряде случаев врач оказывается бессилен не по причине недостатка квалификации, а только потому, что информационная система оказалась не на высоте. И медицина тут, как говорится, бессильна.
Но насколько велики трудности, с которыми придется столкнуться медицине при ее возможном переходе на использование СПО? Олег Бройтман настроен весьма оптимистично: “На мой взгляд, велики только глаза у страха. В этом смысле очень показателен пример с внедрением СПО в систему образования. Еще до начала пилотного проекта много писалось и говорилось о несчастных учителях, которые увидят Linux и разбегутся. На практике же оказалось, что географию внедрения пришлось даже расширять, так много оказалось желающих. Если у кого и будут проблемы, то исключительно у нерадивых программистов, умеющих писать приложения только для одной ОС. В качестве примера хочу сослаться на разработанный нами программный комплекс Medap-RM, предназначенный для проведения иммуноферментного анализа. Он написан на языке Python, работает как в Windows, так и в Linux, причем интерфейс в обоих случаях почти одинаков. Медицинский работник даже не заметит, что операционная система на его компьютере изменилась. Мы следим за тем, чтобы наши программы могли обмениваться данными в стандартных форматах, поэтому из приложений можно собирать решения, как из кубиков”.
То есть каких-то технических проблем скорее всего не будет. Дело только за принятием решения.
Чужие успехи
Можно отметить, что один из крупнейших в мире открытый медицинский ИТ-проект, реализуемый на базе американской VistA VA, возник в результате длительного, поступательно-эволюционного развития. Хотя, по нынешним меркам, сама по себе VistA VA, пожалуй, уже сильно не впечатляет.
Зато впечатляет количество диалектов исходного языка программирования MUMPS, на котором она была создана, а также число американских ведомств и крупных медицинских компаний, создавших на их базе свои продукты. Сюда же можно отнести и достаточно широкую распространенность исходного кода VistA в составе различного ПО за пределами США.
Самым же, наверное, главным результатом от VistA стали не столько хорошие экономические метрики ее эксплуатации и весьма полезный для медиков функционал, сколько количество самих врачей, программистов, коммерческих ИТ-компаний разного масштаба, вовлеченных в согласованный процесс ее доработки и скоординированного развития.
Хотя в Европе мы не сможем найти решения, подобного VistA по своему масштабу, там тоже можно обнаружить целый ряд успешных, давно и широко применяемых разработок, получивших сертификаты, открывающие им дорогу в клинику. И развиваемых международными открытыми сообществами ИТ-специалистов и врачей.
Медицинская отрасль является вполне подходящим случаем для того, чтобы попытаться связно изложить общие вопросы по внедрению СПО в РФ и методики оценки его эффективности. Хотя бы по той причине, что текущие проблемы с эффективностью работы отечественного здравоохранения в целом, а не применительно к конкретному сервису или ИТ-продукту, наиболее очевидны.
Например, продвинутое, экономичное и передовое во всех отношениях решение для электронной регистратуры, безусловно, важно для того, чтобы как-то начать наводить в медотрасли порядок. Но само по себе оно не способно решить те проблемы, с которыми сталкиваются в ЛПУ пациенты, пусть даже чрезвычайно быстро и удобно записавшиеся на прием к государственному врачу через интернет или, скажем, инфомат.
Чрезвычайно сложно сейчас рассуждать в привычном для многих узкотехническом формате об эффективности медицинского ИТ, поскольку глубоко неясной остается эффективность самого процесса массового медобслуживания, вполне способного в своем текущем состоянии поглотить значительное количество всевозможных ресурсов без очевидной полезной отдачи.
Локальные проблемы государственного масштаба
Для узких ИТ-специалистов характерна немного другая логика рассуждений. В качестве отправной их точки, обычно берется некий уже готовый, популярный на западе СПО-продукт. В результате его рассмотрения быстро выясняется что он вполне сопоставим с проприетарными аналогами и даже в чем-то их превосходит. Открытость свободного продукта дает возможность объявить его адаптированной отечественной разработкой с минимальными трудозатратами на локализацию. При массовом внедрении, теоретически, можно добиться того, что такое решение станет весьма экономичным, а значит вполне оправданным. Отсюда и следует, что его нужно внедрять, не мешкая.
Необходимое же для его поддержки и развития российское сообщество должно, видимо, сформироваться само собой, немедленно после подписания соответствующего распоряжения правительства. А то, для какой именно отрасли продукт предназначен, насколько специфичны ее требования и в каком эта отрасль сейчас состоянии, многих сторонников СПО не особенно заботит. Часто принципиальным и горячим сторонникам СПО вообще это попросту неизвестно. Раз это может быть выгодно, значит и нужно внедрять везде. А если сообщества так и не появится, то это только лучше потому, что легче будет найти повод собрать с пользователей деньги.
В то же время, например, в США, аналогичные VistA (поддерживаемой Министерством Ветеранов) программные решения давно использует Indian Health Service (здравоохранение народов Аляски, племен американских индейцев и пр.), Пентагон и ряд других. Все эти решения весьма близки изначально и их, вдобавок, можно экономично объединить на базе СПО и передать сильному, развитому, давно сформировавшемуся сообществу.
Начавшаяся по принципу “от простого к сложному”, масштабная информатизация российской медицины дает хороший повод врачам и ИТ-специалистам, наконец, познакомиться друг с другом. И предоставляет последним возможность получить представление о том, что же на самом деле им, возможно, предстоит автоматизировать в наших, а не американских или же европейских ЛПУ. На базе СПО или какой-то еще.
Отказ от принуждения к СПО
Для формирования СПО-сообществ и создания свободных продуктов весьма губителен прерывистый характер всякого рода госинициатив, их стимулирующих. В сфере же здравоохранения, многие эксперты и конечные пользователи пока не успели ощутить и вкусить плодов последовательно реализуемой основной концепции первичной информатизации и модернизации. Тем более трудно этого ожидать в отношении такой специфичной продукции как массовые СПО-решения для медиков.
И, постепенно отказываясь от соблазнительной с виду первоначальной идеи сэкономить на централизации и масштабе, но стать при этом заложником успеха или неудачи очередного отраслевого госмонополиста, со ставшими привычными оффшорами в числе его компаний-соучредителей. Примелькавшимися настолько – что уже и не обращаешь на них особенного внимания.
Вопросы саморегулирования
Наряду с этим, на примере медицины мы также видим и создание новых консультативно-экспертных структур. Не исключено, что со временем они смогут оказывать достаточное, вполне самостоятельное влияние не только на процессы информатизации и автоматизации, но и решать задачи саморегулирования при минимальном вмешательстве государства в ту специфическую проблематику, к которой относятся и вопросы СПО. Где жесткое регулирование не только не особенно уместно, но и, главное, не особенно эффективно.
Хотя в наших министерствах сегодня наиболее востребованы экономисты, лечить людей и определять, что и как для этого нужно, как и прежде, продолжают врачи. “Сверху” решать такие узкопрофессиональные проблемы действительно сложно. Что хорошо видно на примере той же электронной медицинской карты (ЭМК). ГОСТ для нее создали уже достаточно давно. Но поля карты не закончили согласовывать до сих пор. А значит ощутимого, ожидаемого эффекта от централизации ЭМК все еще нет.
Вместе с тем, понятно, что всякого рода стандартизация полезна для практики, когда потребность в ней формируется и осознается самими работающими в отрасли экспертами и специалистами, а не спускается им предписанием свыше. Когда такие специалисты регулярно делятся своей компетентностью, предоставляют свои соображения и расчеты, а не запрашивают их в готовом виде от профильного министерства.
Сообща с медиками
Врач, в конечном счете, и определит то, насколько полезными окажутся для него усилия программистов, создающих ПО для отечественной медицины. По одной только этой причине, участие медиков в работе команд СПО-разработчиков более чем желательно. И, например, сообщества американских разработчиков VistA (“hardhats”), где в разработке ТЗ для решений и даже написании кода активно участвуют врачи, своей работой этот тезис подтверждают.
Следует понимать, что пока большинство врачей, трудящихся в медотрасли, в силу низких зарплат, вынуждены, скорее, решать вопросы изыскивания средств для повседневного существования, в работу таких сообществ смогут включиться лишь отдельные медики-энтузиасты.
Следовательно, пытаться внедрять СПО в медицину, абстрагируясь от текущих, злободневных проблем этой отрасли, где еще не у каждого регионального врача есть свой компьютер, довольно проблематично. Как бы нам ни хотелось побыстрее взять из опыта зарубежных стран самое лучшее, двинувшись передовым курсом, скажем, прямо на СПО, причем, кратчайшим путем.
Продукт или рынок?
Более чем деликатной темой является в той или иной степени централизованное внедрение в медицину продуктов крупных международных вендоров, повсеместное одномоментное принятие детально отработанных за рубежом систем стандартизации и пр. Ведь если сопоставлять одни только продукты, в отрыве от того, как они возникли, то в большинстве случаев можно сделать вывод, что они превосходят отечественные аналоги. В отношении интероперабельности в том числе.
В какой-то мере, от регулятора требуется сегодня, не особенно свойственное ему до этого, достаточно бережное и даже деликатное отношение к отечественным ИТ-компаниям, поверившим в серьезность его намерений и начавшим специализироваться в медицинской отрасли. А не одно лишь выторговывание выгодной цены поставки оборудования и зарубежного ПО.
Помимо этого, акцент на то, чтобы спустить сверху, из гособлака готовое комплексное решение, обязательное к повсеместному использованию, может привести к тому, что это выкинет с нарождающегося рынка потерявших интерес к теме небольших игроков. И это, замечательное и продуманное до мелочей, всеохватное решение окажется, в конечном счете, не особенно-то и нужным ни “осчастливленным” врачам, ни ИТ-специалистам.
Не говоря уже о том, что с точки зрения сурово-минималистичной инфраструктуры и необъятного размера территории, ставка на одни только облака пока рискованна в России как ни в одной другой стране мира. Всерьез же рассуждать, например, о равноправной конкуренции отечественного СПО с комплексными зарубежными решениями для медиков явно преждевременно.
Очень похожая проблема возникла, в частности, в ходе оснащения центров высокотехнологичной медицины. Да, зарубежное оборудование оказалось значительно лучше. Его централизованно закупили. И пришли к очевидному выводу о том, что данную процедуру придется проводить с периодичностью не реже чем раз в 5 лет, если мы будем настаивать, чтобы данные центры оставались центрами именно высокотехнологичной медицины, а не какой-то другой.
Соответственно, после первых, относительно быстрых, по нашим меркам, высокотехнологичных успехов, возникли вопросы о стимулировании отрасли отечественных производителей современного медоборудования. Применимые, по аналогии, и к развитию отечественной отрасли создания медицинского СПО, да и ПО вообще, почти в той же самой мере.
Быстро или правильно?
Как бы не привлекала идея решить разом все проблемы посредством реализации детально продуманной передовой концепции, у такого подхода есть свои естественные ограничители. Что мы видим не только на примере РФ, но и ряда других стран, где такого же рода централизованные попытки нельзя назвать вполне успешными.
Опыт показывает, что прописывание в такой концепции обязательного для всех и каждого типа ПО или сервиса возможно лишь в отдельных случаях. Например, когда при помощи конкретных облачных сервисов предстоит наладить централизованный сбор обязательной оперативной информации о деятельности ЛПУ, с акцентом на экономические метрики.
Чем дальше продвигается процесс в той или иной социальной сфере от этапа первичной госинформатизации и создания базовых условий для возникновения нормальной конкуренции в этих секторах, тем очевиднее становится ограниченность управленческих ресурсов. И тем закономернее выглядит отказ от попыток регламентировать из единого центра все и вся.
Дорогостоящие инфоматы, появившиеся усилиями чиновников в ходе реализации “Электронной России”, можно считать символом такого рода достаточно неэффективного подхода, что особенно заметно на примере медицины. Пока ими могут пользоваться те, кто в государственные поликлиники обычно ходит крайне редко. Представить себе, скажем, 90-летнего ветерана ВОВ, обратившегося к услугам инфомата вместо обычной регистратуры напротив, довольно сложно. Должно пройти существенное время, прежде чем можно будет с уверенностью говорить об инфоматах не как о PR-акции и поводе для отчетов о закупке техники, а об экономически и социально оправданном решении. Хотя, конечно, и они тоже, наверное, нужны. И каких-то вендоров-производителей стимулируют уже сегодня.
Критерием правильности выбранного отраслевым регулятором пути, можно, по-видимому считать постепенное возникновении в России успешных, специализированных в конкретной медицинской и др. областях, а не просто крупных с точки зрения валового оборота универсальных ИТ-компаний. В которых будут работать востребованные именно медиками-практиками ИТ-специалисты, так или иначе связавшие с данной отраслью свою жизнь, понявшие ее действительные проблемы. И, в какой-то мере, зависящие от того, удастся ли довести до мирового уровня наше здравоохранение.
Процесс интересней результата
Акцентированно говорить именно про СПО в медицине прямо сейчас, на этапе, когда основной акцент делается на облака, где тип ПО не особо существенен, явно преждевременно. Скорее разговор об этом зайдет тогда, когда у ЛПУ, в их основной массе, появится действительный интерес к поиску эффективных локальных ИТ-решений, а не новых поводов и способов осваивания бюджетных и страховых денег.
Ориентироваться на западные медицинские СПО-сообщества, где ведущая роль принадлежит программистам, получающим высокий и стабильный доход помимо СПО, и ищущим чем еще занять себя в свободное время врачам, в РФ объективно сложно. Раз это так, то о существенном объеме созданного свободным способом, актуального для медиков-практиков кода, говорить тоже трудно. Направлять же волевым путем всю информатизацию медицины именно по СПО-руслу – вообще рискованно.
Медицинское СПО почти невозможно представить без мотивированных чем-то еще, помимо одной только клятвы Гиппократа, людей. Расценивать его как универсальный для всех ЛПУ рецепт прямо сегодня, когда гораздо более актуальной задачей является, скажем, налаживание циркуляции полезного опыта применения любого медицинского ПО между регионами, нельзя.
Предстоящее появление в РФ сильных СПО-сообществ, специализирующихся в т.ч. в медицине, можно будет расценивать, прежде всего, как критерий оздоровления самой медотрасли. И уже затем – начать пользоваться СПО как одним из возможных инструментов для решения здравоохранительных задач. Можно даже предположить, что если СПО действительно так эффективно, как обещают ИТ-теоретики, то вышедшие из многолетней полу-коррупционной стагнации госмедики, рано или поздно отыщут его на рынке сами и обязательно внедрят.