СИМПТОМЫ
В ГОМЕОПАТИЧЕСКИХ ПРОГРАМНЫХ ПРОДУКТАХ
 
формальная сумма
или
иерархическая формализация?
 
 
Москва. 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. Назрела необходимость анализа проверенных временем и клиникой Материй Медика для построения репертория необычных симптомов.