CC BY
46
Медицинские информационные системы
Др
W-ЩШШ
kJH
I и информационные
технологии
ib
И.И.ЛИВШИЦ,
разработчик стоматологического программного комплекса MasterClinic, г.Санкт-Петербург
СОВРЕМЕННЫЕ МЕТОДЫ РАЗРАБОТКИ И ПЕРСПЕКТИВЫ РАЗВИТИЯ СИСТЕМ УПРАВЛЕНИЯ СТОМАТОЛОГИЧЕСКИХ КЛИНИК
Статья содержит некоторые наблюдения автора касательно современных методов разработки особого класса систем управления, предназначенных для автоматизации деятельности стоматологических клиник (далее СУСК). Из уровня техники известны два классических типа систем управления: автоматические (то есть функционирующие в определенных окружающих условиях полностью без участия человека-оператора) и автоматизированные (то есть выполняющие определенные действия под управлением человека). Применительно к СУСК корректно говорить только об автоматизированных системах, так как без участия человека лечебная деятельность пока принципиально невозможна. Далее все СУСК корректно выделить в особую группу для анализа, поскольку эти системы появились сравнительно недавно, не имеют строгих устоявшихся регламентов разработки, проектирования и эксплуатации. Принятое выделение в особую группу именно СУСК объективно обосновано спецификой бизнес-процессов, выделяемых для автоматизации, множеством взаимосвязанных уровней учета и высоким уровнем абстракции объектов автоматизации.
Автор более 6 лет принимает участие в разработке одной из известных отечественных СУСК -стоматологического программного комплекса MasterClinic и полагает возможным предложить к публичному обсуждению некоторые наблюдения. Автор заранее приносит свои извинения за излишне сжатый стиль изложения материала, беря в свое оправдание уважение к тем читателям, которые достаточно владеют предметом статьи или, напротив, считают ее малоинтересной.
ПРЕДМЕТНАЯ ОБЛАСТЬ
Предметной областью для применения СУСК является деятельность современной стоматологической клиники с наиболее полным вариантом прейскуранта оказываемых услуг и многоуровневой иерархической организацией управления. Будем полагать, что некоторая клиника работает 7 дней в неделю без выходных, оказывает все виды лечебной, диагностической и консультационной помощи, выполняет учет используемых материалов, проводит лечение пациентов по разным программам страхования, работает с несколькими зуботехническими лабораториями. Отдельно отметим, что клиника использует современные информационные технологии (далее ИТ), такие как радиовизиографы, системы управления базами данных (далее СУБД), сканеры, персональные компьютеры, объединенные в локальную вычислительную сеть (далее ЛВС).
© И.И.Лившиц, 2007 г.
Медицинские информационные системы
Предметная область для СУСК является набором общих бизнес-процессов, которые можно разделить на несколько классов: основные, вспомогательные и организационные (например, в соответствии с ГОСТ Р ИСО/МЭК 12207). Лечебная деятельность в клинике - это основной бизнес-процесс, от качества управления им зависит в первую очередь экономическая эффективность деятельности клиники. Далее, обеспечение консультационной помощи пациентам или управление документацией - это вспомогательные бизнес-процессы в клинике, от их результативности и эффективности зависят психологический контакт пациентов и врачей клиники, репутация клиники и перспективы дальнейшего роста (минимально стабильности) базы клиентов клиники. И, наконец, к организационным бизнес-процессам можно отнести управление ИТ-инфраструктурой и управление процессом обучения персонала клиники. Современная СУСК должна позволять автоматизировать произвольное множество любых перечисленных выше бизнес-процессов вне зависимости от типа, размера и специализации конкретной стоматологической клиники. Далее будут подробно рассмотрены ключевые моменты процесса разработки современной СУСК.
КОМАНДА ПРОЕКТА
Для успешного запуска и реализации проекта разработки современной СУСК, безусловно, необходима сыгранная команда профессионалов. Состав, роли и дисциплина в каждой команде всегда были уникальными, иногда базирующимися на известных стандартах (ИСО 9001, Rational Unified Process (RUP) или СараЬП^у Maturity Model (CMM) или ГОСТ/ГОСТ Р), иногда определяемыми неформально, иногда жестко регламентируемыми целым пакетом инструкций. Часто формат команды ИТ-проекта и регламент работы прозрачно следуют от принятых регламентов структуры-спонсора проекта, то есть источника финансирования ИТ-проек-та. Как противоположность группа независимых разработчиков, ведущих проект на собственные средст-
www.idmz.ru , Щ| 2007, ^
•4.
Л,
ва, может быть организована неформально и допускать гибкую перестройку текущей структуры и существующих регламентов в зависимости от изменений требований рынка.
Некоторые современные методики разработки ПО (например ХР - eXtreme Programming) прямо предписывают парную работу в непрерывном цикле «разработка» - «тестирование». Каждый в команде проекта должен иметь четко обозначенные права и обязанности, хотя на практике допускается совмещение для одной роли (например, для программиста) обязанности по созданию программного кода и тестирования готового прототипа у заказчика. Например, команда проекта стоматологического программного комплекса MasterClinic состоит из нескольких человек, их которых явно выделен директор проекта, разработчики, тестеры, служба сопровождения, служба маркетинга, группа консультантов по предметной области.
Считается весьма опасным, если в проекте нет четко определенных обязанностей для команды, планы работы не контролируются и допускают множественные произвольные изменения неавторизованными сотрудниками. Также недопустима работа команды в условиях несогласованных требований, в любом процессе должны четко и исчерпывающе подробно фиксироваться все требования по проекту. Отдельный вопрос - как именно устанавливать обязанности для команды проекта? Будет уместным рекомендовать базировать распределение обязанностей для команды проекта исходя из типа используемого процесса разработки ПО. Например, для коллектива, работающего по процессу ГОСТ/ГОСТ Р, возможно построение четкой функциональной или матричной структуры (исходя из численности персонала). Для коллектива, работающего по процессу ХР, например, по проекту стоматологического программного комплекса MasterClinic, обязанности распределены с учетом парного программирования и управления требованиями через единый документ «User Story», итерационный цикл составляет 1 неделю, полная новая версия выпускается 1 раз в квартал.
Медицинские информационные системы
щр
W-ЩШШ
kJH
и информационные
технологии
|Ь
□ПИСАНИЕ ОБЪЕКТОВ АВТОМАТИЗАЦИИ
Описание объектов автоматизации всегда для любых проектов было более чем сложной задачей. Суть проблемы даже не в том, чтобы в голове одного или нескольких аналитиков сложилась ясная и непротиворечивая картина, соответствующая реальной клинике, а в том, чтобы эта информация была пригодна для создания эффективной СУСК. Проблем более чем достаточно:
♦ персонал клиники не готов компетентно и внятно объяснить, что именно и как именно он реально делает на своем рабочем месте (например, человек понимает, что его можно завтра легко заменить одной автоматизированной функцией и боится быть уволенным);
♦ персонал клиники не желает делиться накопленной информацией или профессиональными навыками работы на определенном рабочем месте в клинике (например, старшая сестра не желает озвучить нормы среднего расхода материалов в клинике по целому ряду причин);
♦ реальные условия работы клиники меняются в силу изменения рыночных условий, требований законодательства или внутренних изменений бизнеса;
♦ изменение лицензионной политики компаний поставщиков ПО, оборудования или решений, которые применяются или планируются к внедрению в клинике.
Для проектирования современной СУСК наличие корректного описания объекта автоматизации является одним из краеугольных камней успеха проекта, в ином случае команда проекта обречена на постоянные переделки и доработки в цикле, которые в худшем случае могут привести к краху проекта (особенно при значительном затягивании сроков).
Описание объектов автоматизации может быть выполнено самыми различными способами, иначе говоря, в различной нотации - ГОСТ, UML, IDEF и пр. Нет необходимости явно «выпятить» какую-либо одну из нотаций как абсолютного лидера;
каждая команда для каждого конкретного ИТ-проек-та должна самостоятельно определить приемлемую нотацию, исходя из совокупности преимуществ. Например, для стоматологического программного комплекса MasterClinic в качестве нотации для описания объекта автоматизации выбрана нотация IDEF0 как основной стандарт для моделирования бизнеспроцессов, наиболее удобный для описания деятельности современной стоматологической клиники. Ряд публикаций, посвященных этой проблеме, был выполнен автором ранее в журналах «Врач и информационные технологии», «Менеджер здравоохранения» и специализированном издании «Дантист».
ПРОЦЕСС УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ
До начала работы команды проекта собственно по созданию программного кода СУСК в любом процессе необходимо определить детали процесса по управлению требованиями. О роли и необходимости регулярного управления требованиями по любому проекту говорилось несколько раз ранее, дополнительно нужно отметить ключевые аспекты этого процесса:
♦ единый документ, содержащий все требования по проекту;
♦ регламент внесения изменений в требования по проекту;
♦ механизм оперативного согласования требований с заказчиком;
♦ механизм оценки рисков по проекту и стоимости реализации требований;
♦ комплект нормативных документов для управления требованиями.
Процесс управления требованиями для абстрактного ИТ-проекта может быть реализован самыми разными способами. В каждом из упоминаемых выше процессов (ГОСТ, ИСО, СММ или ХР) великолепно разработаны комплекты регламентов, нормативных и отчетных документов («артефактов») в отношении и процесса управления требованиями. Например, ГОСТ 34.601 устанавливает, чтобы тре-
Медицинские информационные системы
www.idmz.ru
2007,
ГЧЯЯ
I Ы.МЯЯ
Пример документа «User Story»
стоматологического программного комплекса MasterClinic за декабрь 2005 г.
Таблица 1
№ п/п Клиника Дата получения требования Требование Шифр АРМ Представитель Статус требования Дата исполнения
i СолоДент 01-12-2005 Добавить отчет о рабочем времени каждого врача за месяц (количество отработанных часов и дней) GVR Требование Татьяны Ивановны Выполнено 05-12-2005
2 Добавить отчет о выручке, сданной в кассу каждым врачом за месяц Выполнено 05-12-2005
3 Добавить в отчет «Оборот материалов в клинике» стоимость материалов SMS Выполнено 05-12-2005
4 Создать новый отчет для анализа разницы автоматического списания материалов по итогам приемов и ручной выдачи по врачам Выполнено 05-12-2005
5 Идеальная пломба 02-12-2005 Изменить базовый набор данных для фильтра пациентов: Ф.И.О., дата рождения, баланс, количество приемов MRC Требование Жанны Анатольевны Анализ
6 Добавить фильтр по интервалу дат для рассылки по дню рождения Анализ
7 Добавить форму работы с блоками текстов для отчетов Анализ
8 Добавить форму работы с множеством отчетов (адрес печатать на обороте) Анализ
9 Добавить отчет анализа пациентов по конкретному профилю «Карта» Анализ
10 Добавить отчет анализа пациентов по конкретному номеру «Карты» Анализ
бования по проекту были согласованы с заказчиком и отражены в Техническом задании. Раздел 7 стандарта ИСО 9001:2000 содержит указания, чтобы требования к продукции (услуге) были определены, согласованы и поддерживались в актуальном состоянии. Регламент ХР также требует фиксации требований заказчика, например, в документе «User Story».
Нет необходимости выделять единственного и безусловного лидера в указанных выше стандартах для оптимального управления требованиями: каждая команда для каждого конкретного проекта должна самостоятельно определять приемлемый процесс из совокупности преимуществ. Например, для стоматологического программного комплекса MasterClinic в качестве стандарта для управления требованиями выбран регламент ХР, согласно которому любые требования заказчика фиксируются в едином документе «User Story». Этот документ
содержит все поступающие в команду проекта требования, от кого бы они не исходили и насколько фантастически не выглядели. Требования сведены в единый реестр, содержат статус («Выполнено», «В работе», «Отклонено», «Отказ заказчика»), актуальный на дату еженедельной публикации, и ряд служебных полей. В проекте MasterClinic любой представитель заказчика или команды проекта может получить доступ к файлу «User Story», опубликованному на сервере проекта, и оценить текущий ход реализации проекта, ожидаемый срок реализации конкретного требования и любую дополнительную информацию (табл.1).
МЕТОДЫ ПРОЕКТИРОВАНИЯ
Методы проектирования современного ПО, равно как и проектов СУСК, допускают множество вариантов и комбинаций традиционных методов(«во-допадная модель», «водопадная модель с обрат-
Медицинские информационные системы
щр
W-ЩШШ
kJH
и информационные
технологии
|Ь
ной связью», «спиральная модель», ХР и др.). Каждый из перечисленных методов может собрать под свои знамена множество преданных адептов, выполнивших достаточно самых серьезных и масштабных проектов, по этой причине нет необходимости тратить время уважаемых читателей на ненужные споры. Каждый ИТ-проект достоин своего процесса, и в каждом проекте должны быть регламенты для выполнения корректного проектирования:
♦ получение на каждом этапе жизненного цикла проекта согласованного решения, отражающего спроектированное решение СУСК в нужной детализации;
♦ обеспечение постоянной загрузки команды проекта исполнением текущей и реально необходимой работы по проекту на очередной стадии;
♦ гарантия для заказчика, что команда проекта правильно понимает поставленную задачу, обладает пониманием функционирования объекта автоматизации, корректно выполнила проектирование и работает по проекту СУСК по плану;
♦ гарантия для команды проекта, что заказчик согласовал выполненное проектирование для конкретного объекта автоматизации и можно выполнять поэтапное кодирование без риска отказа в приемке или переделок готовой СУСК.
Процесс проектирования в проекте стоматологического программного комплекса MasterClinic построен также по методологии ХР и использует публичный открытый принцип для определения приоритетов выполнения множества требований заказчика. Безусловно, архитектура СУСК в каждый момент подвергается самой строгой экспертизе для обеспечения устойчивого функционирования при реализации некой новой функции или множества функций. Образно говоря, строя следующий этаж, мы постоянно оцениваем и красоту здания, и комфорт будущих жильцов, и соблюдение строительных правил. С другой стороны, мы можем, например, сразу сделать комнаты, коридоры и игровые комнаты точно по заказу жильцов, если они не нарушают известных ограничений и законов физики.
Например, проектируя новый модуль инвентаризации в MasterClinic версии 4.5, было учтено не только требование ведения реестра помещений клиники (кроме кабинетов врачей еще учитываются рецепция, кабинет директора, бухгалтерия и пр.), но и требование назначения материально ответственных лиц (МОЛ) за оборудование, размещенное в каждом помещении. Эти два различных требования поступили от разных клиник, но были логически связаны в единое целое и реализованы последовательно и в структуре СУБД, и в программном коде, и в отчетных документах. Таким образом, заказчику предоставляется комплексно проработанный вариант построения (или проект реализации), его требования, которые можно далее обсуждать, улучшать и вносить оперативные изменения. Именно это преимущество процесса проектирования ХР нашло наибольшее практическое применение в проекте стоматологического программного комплекса MasterClinic.
МЕТОДЫ РАЗРАБОТКИ
Методы разработки современного ПО, которые, насколько известно автору, применяются при разработке СУСК, также различаются по своим основным характеристикам. Например, разработка СУСК на базе промышленных серверов СУБД (таких как Microsoft SQL Server, Sybase или Oracle) требует значительных человеческих ресурсов, обладающих высокой квалификацией в определенной специализации, например, управление собственно СУБД, интерфейс, бизнес-логика и пр. Для СУСК иной архитектуры (например, для MasterClinic) нет необходимости в многочисленной команде узконаправленных специалистов, вполне допускается (и даже приветствуется) универсализация участников небольшой команды программистов.
Если коротко рассмотреть методологии современных процессов разработки, можно повторно отметить процесс по ГоСт Р ИСО/МЭК 12207, процесс RUP, структуру MSF и ХР. Проект стоматологического программного комплекса MasterClinic в
Медицинские информационные системы
начале своего пути более 2-х лет использовал процесс в соответствии с ГОСТ 34.601 и РД 50-34.698, но дальнейшее развитие показало, что этот процесс недостаточно гибок и не позволяет с должной оперативностью реагировать на пожелания всех пользователей. С 2003 г. в качестве стандарта для управления процессом разработки выбран ХР, согласно которому все требования пользователей фиксируются в едином документе «User Story», и раз в неделю публикуется новая реализация системы. В случае, если в течение этой итерации удалось реализовать, например, всего 1 функцию (то есть полностью разработать функционал, протестировать и провести опытную эксплуатацию в «пилотном» режиме), новая реализация будет содержать всего 1 новую функцию. В ином варианте развития событий последующая итерация, например, может содержать до 10 новых отчетов, касающихся одного определенного аналитического блока. Этот принцип «быстрой обратной связи» очень удобен и для пользователей (они точно знают, что и когда может быть получено), и для программистов (что и когда должно быть выполнено).
На сайте проекта MasterClinic приведены два очень полезных документа: «Билль о правах программиста» и «Билль о правах заказчика» - http:// master-clinic.stom.ru/program.
МЕТОДЫ ТЕСТИРОВАНИЯ
Метод тестирования, применяемый при создании современного ПО, практически тесно связан с используемым методом разработки конкретного ИТ-проекта и является неотъемлемой частью этого процесса. Возвращаясь к изложенным выше кратким тезисам о методиках проектирования, разработки и управления требованиями, следует непременно явно указать полную преемственность используемых методик тестирования в аналогичных процессах: для процесса по ГОСТ Р ИСО/МЭК 12207, например, характерно многоступенчатое тестирование (комплексное и автономное, исполняемое на этапах предварительного тестирования, опытной эксплуатации и приема-сдачи проекта); для про-
www.idmz.ru , Щ| 2007, ^
•4.
Л,
цесса RUP тестирование - это отдельная дисциплина, которая в различном объеме выполняется на всех фазах процесса создания ПО, для MSF тестирование повторяет спиральный цикл развития проекта, отражая увеличение объема тестовых процедур в зависимости от роста масштаба проекта, и ХР содержит свою уникальную методику тестирования ПО.
Проект стоматологического программного комплекса MasterClinic, как уже отмечалось выше, использует процесс ХР, согласно которому процесс тестирования и процесс программирования неразделимы: сначала определяются требования, затем пишется набор тестов и только после этого выполняется кодирование. Как образно написали К.Бэк и М.Фаулер, девиз ХР можно характеризовать так: «Целься, целься, целься... пли!» - то есть процесс постоянно замыкается на общении с пользователем и постоянно уточняется цель создания конкретной функции, после чего функция программируется наилучшим образом. В чем преимущества такого подхода?
Для проекта MasterClinic наибольший эффект и одно из сильных конкурентных преимуществ заключается в сверхбыстрой обратной связи «требование»
- «проектирование» - «реализация» - «анализ прототипа». Команда проекта сразу может предоставить в клинику для заказчика действующий прототип нового ПО, более того, имеет возможность сделать несколько вариантов. Все возможные ошибки (неверные вызовы функций, некорректные именования полей, неоптимальные форматы данных и пр.) уже выполнены разработчиками, тестирование фактически завершено в момент создания функции. Поскольку предварительное тестирование прототипов фактически выполнено в момент создания кода, у заказчика тестируется общая логика работы конкретной функции, дизайн отчета, удобство работы в экранной форме.
МЕТРИКИ КАЧЕСТВА
Качество ПО уже давно стало расхожим выражением, термин «баги» известен даже неспециалистам в программировании, для которых пока-
Медицинские информационные системы
щр
W-ЩШШ
kJH
и информационные
технологии
|Ь
заны десятки фильмов про ужасных, злобных и всепроникающих хакеров. Разумеется, доля истины в этих шутках есть, но качество любой работы в любой отрасли всегда подчинялось и измерялось по особым методикам. Применительно к сфере создания ПО специалисты оперируют не абстрактными понятиями, а четкими категориями (или метриками), которые позволяют численно оценить (и сравнить) различные продукты в сфере ИТ. Наиболее часто используются такие метрики качества ПО, как количество ошибок на 1000 или 1 000 000 строк кода, количество, частота появления «багов», критичность обнаруженных «багов», скорость реагирования разработчика на появление «багов» в ПО - то есть время выпуска новой переработанной версии или специальной «заплатки» - «патча».
В России специалисты в сфере защиты информации используют нормативный документ, который оценивает качество ПО с точки зрения отсутствия «логических бомб» и иных недокументированных закладок. ПО оценивается по уровню НДВ или по уровню отсутствия недекларированных возможностей. Эта метрика не получила широкого распространения в ИТ-проектах в силу ряда причин, но сам принцип анализа и оценки ПО следует признать практически очень полезным. Иные российские стандарты ГОСТ/ГОСТ Р, применительно к сфере ИТ оперируют понятиями «верификация» и «валидация», которые призваны обеспечить наиболее приемлемые решения (алгоритмы, технологии, способы и пр.) построения качественного ПО. На практике обычно акцент делается на использование специальных шаблонов, регламентов и стандартов, призванных максимально снизить риск ошибки и уменьшить влияние «человеческого фактора» на процесс проектирования, разработки, тестирования и сопровождения ПО.
Применительно к СУСК автор может корректно говорить только о проекте MasterClinic, в котором качество ПО обеспечивается парной работой программистов и четкой прозрачной системой управления требованиями. Любое задание, внесенное
в «User Story», анализируется перед собственно кодированием, составляется блок тестов, которые дают возможность обеспечить исправление основных ошибок программирования. Особо следует отметить практику разделения в проекте MasterClinic тестирования (как части процесса программирования) и анализа прототипа (как части процесса управления требованиями). Качество ПО существенно зависит от реализации возможных вариантов использования конкретной функции применительно к множеству требований конкретного пользователя. Эти требования, как правило, не формализованы, и в клинике только после получения некоторого прототипа говорят: «Ну, конечно, нужно было сделать вот это и еще вот это, разве вам это сразу не было ясно?» В случае реализации быстрой обратной связи эта ситуация не критична, более того, разработчик должен предвидеть несколько возможных вариантов использования конкретной функции. Например, функция «Картотека» в «АРМ администратора» стоматологического программного комплекса MasterClinic позволяет не только найти пациента по неполным отрывочным данным (например, по фрагменту имени или фамилии), но и оперативно сформировать перечень пациентов, которые поступили в клинику в определенный день или не имеют какого-либо установленного реквизита.
ПЕРСПЕКТИВЫ РАЗВИТИЯ СУСК
Материалы, изложенные выше, относятся к процессу управления полным циклом создания современных СУСК. Автор считает полезным дополнительно предложить анализ перспектив развития современных СУСК с учетом оценок ряда прошедших выставок и научно-практических семинаров в Санкт-Петербурге. В июле 2005 года в СКК в Санкт-Петербурге проходила 1-я Международная выставка «Стоматологический салон — Санкт-Петербург», в ноябре 2005 г. также в СКК проходила 4-я Международная выставка «Дентал Парад». В рамках научных программ всех этих выставок проводились
Медицинские информационные системы
семинары по применению современных ИТ в управлении стоматологическими клиниками, в которых принимали участие представители проекта стоматологического программного комплекса MasterClinic. Интересно отметить следующие ключевые аспекты.
Посетители
Посетители выставок объективно могут быть разделены на 3 фокусные группы:
1. Менеджмент стоматологических клиник, которые либо слышали о некоторых СУСК, доступных на рынке в Российской Федерации, либо имеют представление и/или опыт работы, например, с системами «Dental-4-Windows», «Инфордент», MasterClinic или иными. Представители этой группы точно знают, что желают увидеть и просят на практике продемонстрировать конкретный функционал. Иногда демонстрация затягивается на несколько часов и может продолжиться уже в конкретной клинике, это в самом идеальном варианте для представителя проекта СУСК.
2. Врачи-стоматологи самой различной специализации, которые желают в инициативном порядке автоматизировать определенный вид учета в клинике. В самом лучшем случае, руководство клиники поручает этим врачам провести профессиональную экспертизу существующих СУСК для оценки возможностей внедрения в клинику. Для представителей разработчиков СУСК в момент обсуждения деталей ИТ-проекта очень важно оценить реальные потребности этой группы и продемонстрировать именно тот блок функционала, который будет наиболее востребован в данной конкретной клинике.
3. Врачи, иногда студенты старших курсов медицинских ВУЗов, которые просто интересуются современными технологиями, в том числе ИТ. Для этой группы в силу ряда особенностей работы на выставках наиболее предпочтительно проводить насколько это приемлемо общий информационный экскурс в предметную область, избегая использования специальной ИТ терминологии и глубокого погружения в детали СУСК.
www.idmz.ru , Щ| 2007, ^
•4.
Л,
Сложности продвижения ИТ
По практическим итогам участия в двух выставках автор должен особо отметить сложность проведения консультаций с высшим и средним менеджментом стоматологических клиник. Попробуем коротко проанализировать причины этих затруднений.
♦ Ограниченное использование ИТ в клиниках, крайне низкий уровень проникновения компьютерной техники в рабочее и домашнее окружение, следовательно, невысокий общий уровень «компьютерной грамотности».
♦ Сложность абстракции от примеров СУСК: если демонстрация какого-либо практического варианта использования не включает какой-либо один, узко специфический признак (например, МКБ), часто можно услышать однозначный вывод о том, что «система не работает». Комментарии разработчиков о настройке и адаптации базовых каталогов СУСК для конкретной клиники могут быть не приняты с должным вниманием.
♦ Сложность восприятия в целом ИТ, как инструмента менеджмента в современной клинике. Руководство клиник очень трудно понимает, как именно неосязаемое ПО может реально помочь в решении целого комплекса проблем. Приходилось слышать: «Вот стоит у меня кресло в клинике, оно стоит 15 000, я его вижу, оно работает. А как работает программа, если ее нельзя потрогать?» Очень важно показать, как именно и что именно может реально показать СУСК в ближайшие рабочие дни после внедрения: расписание, отчеты по кассе, оборот материалов и пр.
♦ Сложность обоснования расходов на ПО в клинику. Руководство клиники часто полагает, что покупка за 60 рублей одного компакт-диска в ближайшем подземном переходе поможет построить надежную, устойчиво работающую ИТ-инфраструктуру.
Более того, приходилось встречать на практике компьютерные мониторы, купленные «ну очень дешево» у знакомых студентов, которые стабильно не работают даже при стандартных настройках 1024х768 пикселей на частоте 60 Гц. Разумеется, все эти сложности только ухудшают отношение врачей, администраторов и ассистентов к современным ИТ.
31
Медицинские информационные системы
щр
W-ЩШШ
kJH
и информационные
технологии
|Ь
Архитектура
СУСК объективно разделяются на комплексные (состоят из множества функционально законченных программных компонентов) и мономодульные (состоят из единого программного исполняемого файла).
Первый класс СУСК позволяет для конкретной клиники предложить наиболее оптимальную конфигурацию, которая обеспечит эффективную автоматизацию определенного множества бизнес-процессов, необходимого менеджменту клиники. Например, стоматологический программный комплекс MasterClinic состоит из 9 полнофункциональных программных модулей и позволяет обеспечить необходимый уровень автоматизации для стоматологической клиники любого уровня. Размер модулей составляет от 280 Кбайт до 5 Мбайт, всего возможно более 30 оптимальных конфигураций для самых различных типов клиник.
Второй класс СУСК поставляется как единый программный модуль, который устанавливается на каждое рабочее место в клинике и должен быть сконфигурирован отдельно. Например, единый исполняемый файл программы Dental-4-Windows превышает 350 Мбайт и должен быть сконфигурирован для каждого рабочего места (врача, администратора, старшей сестры и прочие) вручную.
В перспективе ожидается сохранение двух существующих классов архитектуры СУСК. Возможно появление «гибридных» архитектур с применением специального вида ПО («промежуточного слоя») или использованием новомодных разработок с использованием Web-сервисов. Следует отметить, что с ростом минимального технического уровня для компьютеров, установленных на рабочих местах в клинике (технология Pentium Hiper Treading, минимальный размер оперативной памяти 512 Мбайт, пропускная способность ЛВС в 100 Мб/сек и пр.), различия в архитектуре могут нивелироваться, за исключением использования «ноутбуков» и компьютеров устаревшей комплектации.
Использование СУБД
СУСК используют 3 класса СУБД:
♦ промышленные СУБД (MS SQL, Sybase или Oracle);
♦ условно бесплатные СУБД (PostgreSQL);
♦ офисные СУБД (Access или Paradox).
Каждый класс СУБД имеет свои преимущества
и недостатки, следовательно, каждая СУСК должна продемонстрировать потенциальному заказчику тот минимум конкурентных преимуществ, которые позволят выбрать именно это решение. Например, система «Инфодент» базируется на СУБД Oracle, которая требует отдельного сервера для БД, дополнительно высококвалифицированного системного администратора, весьма значительных лицензионных платежей (особенно с учетом многоядерных процессоров), но предоставляет практически неограниченные возможность по масштабированию. С другой стороны, стоматологический программный комплекс MasterClinic использует СУБД Access, которая входит в состав широко распространенного пакета MS Office, не требует выделения отдельного сотрудника для администрирования, но ограничена 255 пользователями. Нужно отметить, что это ограничение автор полагает практически несущественным.
В перспективе ожидается постепенный переход на промышленные СУБД (это обусловлено постепенным снижением стоимости ПО и либерализацией лицензионной политики).
Принимая во внимание акцент компании Microsoft на сегменте малого и среднего бизнеса, можно прогнозировать дальнейшее снижение стоимости на MS SQL Server Standard Edition ниже 1000 долларов США с учетом 5 клиентских лицензий (сейчас стоимость лицензии составляет 1500 долларов США). Для СУБД Sybase одна клиентская лицензия стоит 80 долларов США и дальнейшего снижения не приходится ожидать. Использование СУБЛ Oracle в проектах для стоматологических клиник автор полагает экономически неэффективным.
Медицинские информационные системы
Сервисные возможности
Различные СУСК предоставляют своим пользователям уникальное множество сервисных функций, причем для современной клиники может быть востребован достаточно широкий спектр услуг: «горячая» линия сопровождения, возможность изменения существующей функции/отчета, возможность обучения всего персонала клиники, возможность разработки конкретного функционала для нужд клиники и пр. Каждая из доступных на рынке в Российской Федерации СУСК обеспечивает в той или иной мере свой уровень сервиса, демонстрируя своим потенциальным или существующим заказчикам наиболее привлекательные схемы работы.
Для стоматологического программного комплекса MasterClinic таким «фирменным» сервисом является гарантированный недельный цикл «требование клиники» - «готовый прототип» и принцип выполнения доработок для своих заказчиков бесплатно. Для наиболее активных клиник разработчики MasterClinic организовали «клуб директоров», в котором обсуждаются самые разные варианты развития основных модулей СУСК еще на этапе проектирования. Клиника, предлагающая свежую и оригинальную идею, становится «законодателем моды» в этом направлении и устанавливает свои требования к реализации функционала в соответствующем программном модуле MasterClinic.
В перспективе СУСК скорее всего сохранят свои фирменные сервисные возможности, развивая те направления, которые позволяют наиболее быстро развивать систему (для одной категории СУСК) или максимально увеличить поступление средств за поддержку (для другой категории СУСК). Автор полагает, что отдельный вид деятельности «ИТ-консалтинг» в ближайшие несколько лет не получит значительного развития по причинам, изложенным выше. Оплата работ по обследованию объекта автоматизации, проектированию ЛВС клиники, оптимизации организационной структуры клиники (не связанной напрямую с функционированием СУСК), по оценке автора, будет и далее «размываться» в совокупной стоимости проекта СУСК.
www.idmz.ru , Щ| 2007, ^
•4.
J,
Лицензионная политика СУСК
Виды лицензирования и стоимость различных СУСК, в настоящий момент доступных в Российской Федерации, существенно отличаются друг от друга. Известны фиксированная схема определения стоимости «сервер» + N «клиентов» (например, для СУСК «Dental-4-Windows»), схема наращивания функционала «базовый комплект» + «функция А» + «функция Б» (например, для СУСК «АП-Дент»). Для всех пользователей стоматологического программного комплекса MasterClinic доступны различные гибкие схемы лицензирования: схема фиксированных комплектов («Сервер + 5», «Сервер + 10», «Сервер + 20») и произвольный выбор любого количества отдельных программных модулей. Разработчики стоматологического программного комплекса MasterClinic считают своим долгом каждого потенциального пользователя проинформировать о преимуществах каждой схемы лицензирования:
Пример 1: для клиники на 4 стоматологических кабинета оптимальным предложением будет лицензия «Сервер + 5», экономия превысит 80% по сравнению с вариантом стоимости покупки отдельных компонентов.
Пример 2: для клиники на 10 рабочих мест (5 стоматологических кабинетов, администратор, главный врач, старшая сестра, директор) в случае отсутствия потребности в блоках страхового эксперта и маркетинга закупка лицензии «Сервер + 10» будет невыгодна, а наиболее эффективной будет следующая схема: «Сервер + 5» + «АРМ старшей медсестры».
В перспективе, по мнению автора, следует ожидать относительного выравнивания стоимости СУСК до 260-300долларов в пересчете на одно рабочее место клиники. Эта оценка справедлива и для СУСК, базирующихся на серверах СУБД класса MS SQL/Oracle, и для СУСК, использующих иные, в том числе офисные СУБД.
Автор полагает возможным провести аналогию между СУСК и системами автоматизации госпитального уровня (например «Медиалог»), которые обладают сопоставимыми функциональными характеристиками и уровнем цен на одно рабочее место в клинике. Также вероятно появление интегрированных программных решений в рамках наиболее известных СУСК (дополнительно - косметология, гигиена и пр.), стоимость которых может незначительно превысить существующий уровень цен на известные тиражируемые СУСК.
