СИМПТОМЫ
В ГОМЕОПАТИЧЕСКИХ ПРОГРАМНЫХ ПРОДУКТАХ
формальная сумма
или
иерархическая формализация?
Москва. 2006 - 2007 гг.
________________________________________________________________
С идеями компьютерных решений в медицине, в том числе и с партнерскими системами, я познакомился на заре интерактивных технологий - в начале 80-х годов прошлого века.
С того момента, как стал участвовать в проектных разработках в области искусственного интеллекта и практическом воплощении этих идей в программные продукты, в первую очередь в экспертные системы.
Начав гомеопатическую практику, я сразу заинтересовался интеллектуальными разработками в этой сфере.
Первой такой разработкой оказалась 5-я версия RADAR'а. Отсюда и более чем 10-летний опыт работы именно с RADAR'ом от 5-й версии до 9-й.
Уже с шестой версии - это полноценная WINDOWS программа, аналитический блок которой сохранил, судя по всему, свою арифметику до сегодняшнего дня (интерфейс не в счет - кому какой нравится).
Хотя в мире на сегодняшний день такого рода продукта - и зарубежного и отечественного - великое множество: CARA, RADAR, MERCURY, McREPERTORY, БЕНИНГАУЗЕН, ГОМЕОПАТ-КЛАССИК, ПЕРЕСВЕТ, РАДУГА, и многие другие.
Сегодня «софтом» и «железом» - программами и компьютерами - никого не удивишь - ни компактностью, ни производительностью. Простая компактность в обиходе - уже большое облегчение в прямом смысле слова и, конечно, мобильность.
Например, реперторий J.T.Kent'a, можно перенести на Palm:
[Встроенная картинка не переводится] Реперториум Kent'a, перенесенный на Palm One Tungsten T 5.
Некоторые программы для Palm OS предоставляют удобство доступа и оставляют нетронутым привычный полиграфический вариант интерфейса. Удобство не только в компактности.
Можно перенести реперторий даже на Smartfon:
[Встроенная картинка не переводится]Реперторий Boericke, перенесенный на Smartfon Nokia 6681.
Никакой автоматизации и удобства доступа, только еще большая компактность! Но компактность, даже соединенная с большой памятью - это библиотека в кармане - и не более.
Сегодня деловая электроника - прежде всего облигатная связка: железо + профессиональный софт.
Для чего нужны софтовые продукты? Для того чтобы:
- создавать у врача иллюзию всесильности.
- создавать у пациента иллюзию продвинутости врача.
- облегчать доступ к информации.
- организовывать и оптимизировать Знания.
- приносить прибыль врачу.
- приносить прибыть разработчику
Привлекательность программного продукта возрастает в оптимизированном софте:
- при удобстве доступа к информации;
- в сочетании с компактностью железа;
- при удобстве анализа данных для умных врачей и для других.
С другой - разнообразие интерфейса позволяет реализовывать:
n - привязанности;
n - пристрастия;
n - привычки.
Для меня интерфейс RADAR'а - это привязанность, выросшая из привычки к полиграфическому виду репертория Кента.
[Встроенная картинка не переводится]
[Встроенная картинка не переводится]
Но как бы лояльно ни была представлена система, за врачом остается главное: выбор необычного, особенного, специфичного симптома. Никакой софт и железка ( в смысле software & hardware) не заменят мозг и талант.
Какие бы решения в программном продукте не предлагалась: от ручной репеторизации до полной автоматизации анализа - изначальное значение имеет факт - какой реперторий используется и как (я уже не говорю кем).
Мое мнение: лучше много разных реперториев по отдельности (что теперь извращенно, но реально организовано в 9-й версии RADAR'a), чем одно всеобъемлющее общежитие разных реперториев и разрозненных предложений разных авторов.
Априорно можно предположить, а на практике это только подтверждается, что в живом человеке таится всё множество открытых и испытанных, неиспытанных и неоткрытых лекарств из всех групп и царств, симптомами которых, или которого в каждом конкретном случае организм может отреагировать в зависимости от ситуации.
Не из-за этой ли всеобъемлющей потенции львиная доля симптоматики перекрестно встречается, как схожая, в патогенезах разных, но многочисленных лекарств? На что уже давно обратил внимание врачей J.W.Hutchison, предваряя свои заметки
о 700-х симптомах…
Мне кажется, что последнее десятилетие отразило тенденцию собирать статистику таких [неспецифических] симптомов в ревизованных или в генерированных реперториях.
Но оставим статистику для анализа результатов прувинга, а реперторизации придадим уникальность симптоматики для индивидуального случая.
Сам автор SYNTHESIS'а подчеркивает важность стабильности информации в рубриках репертория, которая зависит от корректности вводимых в реперторий сведений .
Ведь назначение препарата - это не технология выбора лекарства в системе, а талант выбора необычных симптомов в случае пациента; не механическая подстановка признаков в интерактиве с системой, а ввод полноценного специфичного для случая симптома.
СИМПТОМЫ в гомеопатии бывают очень НУЖНЫЕ:
- они открывают ограниченное число лекарств;
- или одно лекарство;
- они обладают понятийной окраской факта! (видимо таков и есть полноценный или необычный или специфичный симптом);
- сумма таких симптомов, как правило, сокращает число открываемых при реперторизации лекарств
СИМПТОМЫ в гомеопатии бывают и НЕ очень или совсем НЕНУЖНЫЕ:
- такие симптомы открывают «кучу» лекарств;
- несут неспецифичную информацию;
- не обладают понятийной окраской факта! (видимо не симптом, а простой признак);
- сумма таких признаков только усугубляет число открываемых при реперторизации лекарств.
Отсюда понятна очевидная и острая нужда в реперториях необычных (специфических, особенных) симптомов.
Последние 10 лет разбухание базовых реперториев в программных продуктах (в т.ч. и SYNTHESIS и COMPLETE) стало зашкаливать за разумные пределы. Причем оно шло по пути порой априорного введения частных, констатирующих, а не специфических признаков и рубрик, ревизии традиционных значений градаций препаратов в рубриках, что привело к сильным различиям в оценке одного случая традиционным реперторием (Кент) и расширенным (Милленниум).
Вот пример одной только рубрики GENERALS - AIR:
KENT view:
[Встроенная картинка не переводится]
MILLENNIUM view (progressive):
[Встроенная картинка не переводится]
Frederik Schroyens в одном из своих интервью заметил, что в SYNTHESIS'e 8 было 763000 добавлений препаратов. Сейчас этот показатель вырос до 950000. Что касается авторских ссылок, то их количество увеличилось с 1070000 до 1500 000.
Разумеется, после реструктуризации увеличиться количество рубрик, а значит, в версии 9.1 будет на 150 - 200 больше препаратов, а количество авторских ссылок возрастет на 200 - 300 тысяч.
Неужели мы стремимся к тому, чтобы в каждой рубрике были все препараты?
Любой реперторий (в т.ч. и внутри программного продукта) предназначен для того, чтобы построить взвешенный ряд гипотетических препаратов, подтвердить или отвергнуть которые мы можем только через Materia Medica.
В последнее время наблюдается растущая тенденция к реперторизации при помощи компьютерного поиска в Материа Медика.
НО программы поиска в Материа Медика основаны на статистическом словарном анализе. А метод статистического словарного анализа мало того, что нуждается в очень четкой настройке - это всегда лишь анализ по словам. Что всегда предполагает хвост ненужных слов, связанных в Материа Медика с поисковыми словами.
Реперторизировать таким способом по Материя Медика - мириться с космическим числом ошибок, что, мягко говоря, глупо.
Но и в распухаюших реперториях необычные симптомы оказались погребены под лавиной формальных частных признаков и нозологических рубрик, а суммирование таких рубрик, кроме прочего перегруженных числом введенных в них лекарств, не лучшим образом отражается на результатах реперторизации.
В экспертных системах (предлагаемых программными продуктами) нередко угадываются приоритеты ключевых симптомов. Приоритеты облигатные, а не факультативные, потому-то при убирании ключа из списка взятых в анализ признаков разваливается специфичность.
И разваливается часто без сохранения чувствительности. А продуктивные ножницы при синдромном подходе в диагностике - баланс между специфичностью и чувствительностью.
Арифметический аппарат аналитического блока и экспертных систем может быть любым: «Байес», кластеры, матрицы распознавания и др…
Если минимизировать замусоривание случая «ненужными» симптомами, то, в зависимости от авторского подхода, можно применить любое решающее правило, удобное для разработчика и аутентичное задаче распознавания.
Или применять интеллектуальные блоки типа Эршку.
Хотя я считаю наиболее естественным синдромный подход.
Синдромное построение партнерских систем, реализованное, например, в Институте Проблем Передачи Информации РАН, использует для диагностики, как многоуровневые связки признаков, созданные ранее при анализе верифицированной базы данных, так закрытое знание специалиста в виде готовых рекомендаций, представленных такими же согласованными связками признаков. Без обязательного обоснования этих связок, если
в опыте специалиста они дают верифицирующие результаты.
Такая многоуровневая связка - фактически клинический синдром, а система - совокупность дендроидных синдромных алгоритмов с единой архитектоникой и с единым набором так или иначе формализованных исходных признаков (реперториум Кента, например).
Каждому уровню такого древовидного синдрома присуща различная весовая настройка; какие-то связки симптомов требуют обязательного выполнения (одномоментного присутствия в анализируемом случае всех входящих в связку симптомов), а какие-то - частичного, как это и встречается в динамике патогенеза препарата и в динамике клинического случая.
Настойка этих «синдромных деревьев» позволяет при необходимости гибко смещать рекомендации системы в сторону специфичности или в сторону чувствительности. То есть отдавать преимущество скринингу или верификации.
Разные способы анализа обычно жестко запаивают в закрытую для доступа программу. Редко кто из разработчиков предоставляет пользователю право самому настраивать опции экспертной системы.
А зря. Такая возможность сравнения двух интеллектов - разработчика и пользователя - всегда продуктивна. Надо только, на всякий пожарный случай, предусмотреть возможность сброса не заводских настроек по default'у.
Различные подходы к реперторизации присутствуют реально в аналитическом блоке каждого программного продукта, как, например, в RADAR'е разные компаративные варианты анализа по весам и градациям.
Заключение
1. Корректно организованный программный продукт есть необходимое интеллектуальное средство в клинической, научной и методической работе грамотного гомеопата.
2. Тот же самый продукт, в руках неграмотного врача вполне может стать источником диагностических ошибок.
3. Не следует избегать исторически оправдавших себя иерархичных реперториев, аналогичных книгам Кента или Бенингаузена.
4. Пришла пора не наращивать, а сокращать в реперториях число «пустых тривиальных» симптомов и «раздутых» рубрик, особенно заполненных неиспытанными, непроверенными лекарствами.
5. Лучше несколько реперториев по отдельности в одном программном продукте, чем один, часто компилятивный, монстр.
6. Может быть, лучше генерировать новый реперторий с новыми весами и градациями лекарств, с новой топографией рубрик? Или пусть каждый делает эту работу для себя сам, (такие возможности есть во многих программных продуктах), чем менять веса и градации в каждой новой редакции популярных диагностических систем, иногда по нескольку раз у одного лекарства или у одной рубрики от версии к версии.
7. Нужно предоставлять пользователю возможность знакомства с идеологией экспертной системы и с математическим аппаратом, который в ней используется, позволять менять настройки, конечно в безопасных пределах.
8. Врач не должен обольщаться техническим совершенством программного продукта, а должен стремиться к совершенству выявления специфичных симптомов.
9. Назрела необходимость анализа проверенных временем и клиникой Материй Медика для построения репертория необычных симптомов.