Публикации

    Важное на форуме

Длительность ПДА у онкологических больных

Гипернатриемия

Летальный исход как реакция на лидокаин

Токсический эффект от передозировки бупивакаина


 
 

<<< вернуться на главную страницу раздела

Программный Полигон

Долгое время на сайте Critical существовал раздел, в котором мы публиковали информацию о программных разработках, выпускаемых аналитическим отделом компании «ИнтелТек». Постепенно наш интерес сместился от изготовления отдельных программных инструментов в область разработки новых информационных технологий клинической направленности. Предполагая, что теоретические и алгоритмические наработки в этом направлении могут быть интересны только узким специалистам из области ИТ, мы закрыли этот раздел. Однако сейчас нам все чаще приходится оказывать консультативную помощь лечебным учреждениям в нелегком процессе внедрения больших программных систем и мы понимаем, что наш пятнадцатилетний опыт становится интересен не только нам самим. Кроме этого в стенах нашей лаборатории мы отрабатываем технические решения для создания информационных систем нового поколения. Вполне возможно, что сейчас, когда внедрение различных «Электронных историй болезни» начинает приобретать массовый характер, многим нашим читателям может быть интересно, чего мы вправе ожидать или требовать от компьютерных технологий в ближайшем будущем. Для того, чтобы поделиться с вами своими мыслями на этот счет, мы снова открываем на сайте рубрику «Программный полигон». В отличие от многочисленных журнальных публикаций мы предполагаем не просто умозрительно анализировать сложившуюся ситуацию, а прогнозировать возможные пути развития медицинских информационных систем на основе отработанных в нашей лаборатории технических решений.
Для начала мы хотим познакомить вас с одним из наших проектов, который имеет рабочее название:

Комплекс интерактивного конструирования медицинских информационных систем.

и первой публикацией на эту тему, которую мы назовем

«Постановка задачи или десять проблем медицинского программостроения»

За последние 15 лет медицинские информационные системы (МИС) постепенно превратились из безумно дорогих, уникальных программных продуктов в достаточно обыденное явление нашей реальности. Раньше основной проблемой при приобретении подобных систем была их стоимость, и посему доступны они были только крупным ведущим российским клиникам. Теперь же серьезные сложности с внедрением достойного программного комплекса начинаются с его выбора.
Если вы наберете в поисковой системе Яндекс ключевые слова «Медицинская информационная система», то немедленно получите радостное известие о нахождении 45 МИЛЛИОНОВ страниц, на которых в той или иной форме упоминаются многочисленные творения российских программистов. Мы оставим за рамками этой публикации попытки сравнительного анализа существующих продуктов, но обязательно обратим внимание на то, что прошедшие годы не сделали процессы выбора, внедрения и эксплуатации систем проще и удобнее.
Все это время аналитический отдел компании ИнтелТек внимательно отслеживал существующие тенденции в медицинском программо-строении и результатом этого мониторинга явилась разработка определенной концепции построения универсальных систем хранения и обработки медицинской информации. В поддержку этой концепции создан ряд программных инструментов, которые могут быть использованы в качестве фундамента информационной системы нового поколения.
Для того, чтобы понять идеи, лежащие в основе наших разработок, давайте попытаемся выделить общие недостатки, которые в тех или иных комбинация встречаются в существующих системах. Из всего их многообразия хотелось бы обратить внимание на десять наиболее важных:

1. К сожалению, а может быть и к счастью у каждого лечебного учреждения есть своя специфика работы с информацией, свой бизнесс-процесс. Клиники отличаются не только своими потребностями в обработке информации, но и своими техническими возможностями. В идеале, для каждой них нужна индивидуальная программная система. Однако создание заказных программ слишком затратно и требует огромного времени. Многие из существующих программных продуктов имеют достаточно широкие возможности настройки, но этого чаще всего не хватает для отражения всей специфики конкретного лечебного учреждения. В нашем понимании современная МИС должна обладать возможностями конструктора Лего и собираться из разнообразных функциональных блоков самим заказчиком. Очень жаль, но удачной реализации этого подхода среди существующих коммерческих продуктов пока не наблюдается.
2. Большинство из систем не предоставляют возможность непосредственно на рабочем месте врача оперативно изменять рабочий интерфейс программы и дополнять существующие структуры данных для хранения информации. Это сильно снижает удобство использования медицинских программных комплексов. Расширение возможностей приобретенной программы обычно выливается в существенные затраты. Тем не менее, современные технологии разработки ПО вполне могут изменить сложившуюся ситуацию. Все уже давно привыкли к простоте и логичности рабочего стола Windows. Он позволяет быстро и удобно порождать новую информацию и работать с ней в форме документов и файлов. Но мало кто из разработчиков МИС задумывался над тем, что подобным образом можно работать и с клинической информацией. Только квантом обработки данных в этом случае должен является не файл-документ, а клинически-значимый параметр.
3. Очень многие МИС реализуют простой перевод существующей логики «бумажного» процесса работы с клиническими данными на «безбумажные» рельсы. Это, как правило, приводит к тому, что эффективность работы ЛПУ при внедрении подобных систем никак не изменяется. Единственным существенным выигрышем от применения подобных систем является скорость и простота порождения разного рода отчетности о проделанной работе.
4. Подавляющее число программных комплексов имеет очень невыгодный баланс между тем количеством врачебного труда, который потребляет система и той реальной помощью в процессе принятия клинических решений, которую возвращает система врачу.
5. Наблюдается практически полное отсутствие клинически-ориентированной логики обработки информации. Для большинства систем логика обработки и хранения информации для пациента с травмой позвоночника не будет отличаться от таковой, при работе с беременной женщиной с подозрением на преэклампсию.
6. В процессе эксплуатации существующих МИС не накапливается совокупность формализованных знаний о том, как оптимально можно лечить или диагностировать ту или иную патологию. Отсутствует возможность направления данных в централизованную аналитическую систему для выработки подобных решений.
7. Мы не наблюдаем реализации очень важного для врача инструмента - научно-обоснованной системы оценки рисков возникновения тех или иных осложнений или вероятностных прогнозов динамики клинической ситуации.
8. Отсутствует автоматический мониторинг развития опасных патологий, страхующий деятельность врачей, осуществляющий первичный прием.
9. В настоящий момент у нас существует достаточно много медицинских специалистов высокого класса, но они никогда не смогут проконсультировать всех желающих. Появление телемедицинских систем немного снимает остроту этой проблемы. Но подобные системы дистанционного общения решают лишь транспортную проблему, но не решают проблему дефицита времени консультирующих врачей. Более существенную помощь в расширении узкого горлышка доступности высококвалифицированных специалистов способны оказать системы управления базами знаний. Т.е. мы не можем «клонировать» самих специалистов, но современные технологии инжиниринга знаний позволяют клонировать существенную часть их знаний и данных об успешной тактике лечения. Подобные технологии отрабатываются медицинскими кибернетиками не один десяток лет, но практически отсутствуют в коммерчески поставляемых программных системах.
10. Вполне очевидно, что для каждого конкретного клинического случая существует «идеальный специалист», который чаще других сталкивался с подобным течением заболевания, и будет иметь наилучшую результативность в сложившейся ситуации. На первый взгляд существование компьютерной системы, оперативно определяющей подобную пару больной-врач, может показаться фантастикой. В реальности мы и не наблюдаем этих возможностей в существующих продуктах. Но, как это не странно, в современных компьютерных технологиях уже отработаны подходы, позволяющие решать подобные задачи. И ассоциативное перенаправление данных пациентов на контроль конкретных узко-профильных специалистов - вполне достижимая цель.

В этой публикации мы сконцентрируемся на первом пункте из этого списка. Конечно, над реализацией мечты о создании информационного Лего-Лэнда нашей команде придется еще немало поработать. Но тактика приближения к цели выбрана таким образом, что конкретную пользу от существующих программных компонентов наши партнеры могут получать уже сейчас. Это возможно благодаря особенностям компоновки наших разработок.
Представьте себе большую папку-скоросшиватель. На ее обложке записана вся информация, необходимая вам для манипулирования этой папкой, как единым объектом. Если вы собираетесь построить электронную регистратуру, то такая папка может выполнять для вас роль амбулаторной карты и несет в себе информацию о паспортных данных пациента и его уникальных и неизменяемых данных (например, группе крови). Каждому пациенту может соответствовать только одна папка. В эту папку вы можете вкладывать неограниченное количество листов, каждый из которых соответствует определенному аспекту обслуживания больного. Например, один лист соответствует одному врачебному приему в поликлинике. Несколько таких листов, скрепленных вместе, образуют законченный клинический случай. Информация на каждом листе строго структурирована. Далее мы будем называть такие листы – протоколами.
Опытный пользователь сразу отметит, что под подобное описание попадает большинство существующих систем электронного медицинского документооборота. И что листами мы вполне можем называть обычные формы ввода данных любой компьютерной программы. Внешне это действительно так – для пользователя наш протокол выглядит как типичная анкета для заполнения данных. Серьезные отличия спрятаны внутри.
Для нас протокол это не просто список параметров с описанием их свойств, это – программный объект, наделенный целым рядом функциональных возможностей. Полная программная реализация такого объекта обеспечивает:
- автоматическую интерпретацию введенных данных на основании заложенных оценочных алгоритмов
- мониторинг критических наборов признаков или симптомов для сторожевой диагностики опасных патологий
- возможность визуализации факторов риска для тех или иных исходов по мере накопления в системе данных
- возможность выполнения автоматического статистического анализа на предмет выявления скрытых зависимостей

Для того, чтобы сконструировать простейший вариант информационной системы, вам достаточно создать свой набор протоколов. Один из наших программных инструментов предоставляет вам эту возможность непосредственно на сайте Эксперт-центр Critical. Пожалуй, впервые в российском интернете мы предоставляем всем желающим возможность интерактивно поучаствовать в создании своих собственных информационных систем. Первый шаг на этом пути – работа с конструктором структуры протокола.
С этого момента свободный доступ к on-line конструктору открыт для всех желающих по адресу:

http://www.critical.ru/protocol/

Как работать с этим инструментом мы подробно расскажем в следующей публикации «Программного полигона». А сейчас, те из наших читателей, кто предпочитает разбираться с техникой, не читая инструкций, могут самостоятельно поэкспериментировать с системой. Для того, чтобы не начинать с нуля, один из наших рабочих протоколов доступен в конструкторе в качестве стартового шаблона. Это протокол электронной карты ведения беременных женщин одной из российских клиник.
Работая с конструктором важно знать и помнить следующие моменты:

1. Система спроектирована для работы с текущей версией браузера Mozilla Firefox. На других браузерах она не будет работать быстро и корректно.
2. Для входа в систему необходимо ввести e-mail и пароль. Вы не должны знать эти данные заранее. Вам нужно просто их придумать, ввести и запомнить. Для каждой такой пары создается свой протокол, который в дальнейшем может неограниченное количество раз редактироваться.
3. В настоящий момент система настроена таким образом, что для каждой пары e-mail – пароль может существовать только один протокол. Повторное создание протокола с уже существующей парой e-mail – пароль означает для системы команду на стирание предыдущей версии этого протокола.

Удачи вам в конструировании!