Автоматизированный способ диагностики (варианты)
Формула / Реферат
1. Автоматизированный способ диагностики, содержащий следующие шаги:
ввод в компьютер списка заболеваний, каждое из которых связано со списком симптомов, а каждый упомянутый симптом связан со списком вопросов, причём упомянутые симптомы и вопросы могут быть различными для каждого заболевания;
повторяющееся задание вопросов из числа выбранных из списков вопросов для получения ответов, при этом упомянутые ответы устанавливают симптомы, каждый из которых вносит своё значение в накопленное общее значение для каждого упомянутого заболевания;
регулирование последовательности задания вопросов из выбранных упомянутых списков вопросов для обеспечения последовательности вопросов, характеризующих медицинское состояние пациента; и
определение того, достигает или превышает упомянутое накопленное общее значение порогового значения, принятого для соответствующего заболевания, с учётом которого устанавливается диагноз.
2. Способ по п.1, в котором упомянутый симптом устанавливается на основании наличия или отсутствия одного или более других симптомов.
3. Способ по п.1, в котором наличие выбранного набора упомянутых симптомов прибавляет дополнительное значение к накопленному общему значению, по меньшей мере, одного из заболеваний.
4. Способ по п.1, в котором упомянутый симптом в первый выбранный момент диагностического процесса имеет иное значение, нежели тот же симптом во второй выбранный момент процесса.
5. Способ по п.1, в котором значение упомянутого симптома, сообщённого при первой степени тяжести, отличается от значения этого симптома, сообщённого при второй степени тяжести.
6. Способ по п.1, в котором выбранный набор упомянутых симптомов, появляющихся в определённой последовательности во времени, прибавляет к общему значению иное накопленное значение, нежели накопления индивидуальных значений выбранного набора симптомов, не появляющихся в определённой последовательности.
7. Способ по п.1, в котором последовательность начала или окончания выбранного набора упомянутых симптомов прибавляет к общему значению иное значение, нежели накопленные индивидуальные значения выбранных симптомов, взятых поодиночке.
8. Способ по п.1, в котором упомянутое заболевание принимается для дальнейшего диагностического исследования на основании накопленного упомянутого общего значения.
9. Способ по п.1, в котором упомянутое заболевание исключается из дальнейшего диагностического исследования на основании накопленного упомянутого общего значения.
10. Способ по п.1, в котором упомянутые вопросы по заболеваниям, считающимся неотложными, задаются раньше, чем вопросы по заболеваниям, не являющимися неотложными.
11. Способ по п.1, дополнительно содержащий шаг, определяющий меньше упомянутое накопленное общее значение для заболевания, чем установленное пороговое исключающее значение, чтобы исключить упомянутый возможный диагноз.
12. Способ по п.8, в котором устанавливается степень уверенности констатации определённого упомянутого заболевания.
13. Способ по п.9, в котором устанавливается степень уверенности исключения определённого упомянутого заболевания.
14. Способ по п.1, в котором множество упомянутых диагнозов накапливаются в дифференциальный диагностический список упомянутого конкретного пациента, при этом каждый упомянутый диагноз имеет свою степень уверенности.
15. Способ по п.1, в котором каждый упомянутый вопрос, заданный пациенту, вносит связанное с этим вопросом значение в упомянутое накопленное общее значение для, по меньшей мере, одного упомянутого заболевания.
16. Автоматизированный способ диагностики, содержащий следующие шаги:
ввод в компьютер списка заболеваний, каждое из которых связано с первым списком симптомов, а каждый симптом связан с первым списком вопросов, причём упомянутые симптомы и вопросы могут быть различными для каждого упомянутого заболевания;
повторяющееся задание упомянутых вопросов из числа выбранных из списков вопросов для получения ответов, при этом упомянутые ответы устанавливают симптомы, каждый упомянутый установленный симптом вносит своё значение в упомянутое накопленное общее значение для упомянутого заболевания, при этом дальнейшие вопросы задаются повторно для получения ответов спустя заданный промежуток времени, причём список упомянутых вопросов и список упомянутых симптомов, спустя заданный промежуток времени, могут быть иными, нежели упомянутый первый список вопросов и упомянутый первый список симптомов;
регулирование последовательности задания вопросов из упомянутых выбранных списков вопросов для обеспечения последовательности вопросов, характеризующих медицинское состояние пациента; и
определение того, достигает или превышает упомянутое накопленное общее значение, порогового значения, принятого для соответствующего заболевания, с учётом которого устанавливается диагноз.
17. Способ по п.16, в котором упомянутый симптом устанавливается на основании наличия или отсутствия одного или более других симптомов.
18. Способ по п.16, в котором наличие упомянутого выбранного набора симптомов прибавляет дополнительное значение к упомянутому накопленному общему значению, по меньшей мере, одного из заболеваний.
19. Способ по п.16, в котором упомянутый симптом в первый выбранный момент диагностического процесса имеет иное значение, нежели тот же симптом во второй выбранный момент процесса.
20. Способ по п.16, в котором значение упомянутого симптома, сообщённого при первой степени тяжести, отличается от значения этого симптома, сообщённого при второй степени тяжести.
21. Способ по п.16, в котором выбранный упомянутый набор симптомов, появляющихся в определённой последовательности во времени, прибавляет к упомянутому общему значению иное накопленное значение, нежели накопления индивидуальных значений выбранного набора симптомов, не появляющихся в определённой последовательности.
22. Способ по п.16, в котором упомянутая последовательность начала или окончания выбранного набора симптомов прибавляет к упомянутому общему значению иное значение, нежели накопленные индивидуальные значения выбранных симптомов, взятых поодиночке.
23. Способ по п.16, в котором упомянутое заболевание принимается для дальнейшего диагностического исследования на основании упомянутого накопленного общего значения.
24. Способ по п.16, в котором упомянутое заболевание исключается из дальнейшего диагностического исследования на основании упомянутого накопленного общего значения.
25. Способ по п.16, в котором упомянутые вопросы по заболеваниям, считающимся неотложными, задаются раньше, чем вопросы по заболеваниям, не являющимися неотложными.
26. Способ по п.16, дополнительно содержащий шаг, определяющий меньше упомянутое накопленное общее значение для заболевания, чем установленное пороговое исключающее значение, чтобы исключить упомянутый возможный диагноз.
27. Способ по п.23, в котором устанавливается степень уверенности констатации заболевания.
28. Способ по п.24, в котором устанавливается степень уверенности исключения заболевания.
29. Способ по п.16, в котором упомянутое множество диагнозов накапливаются в дифференциальный диагностический список упомянутого конкретного пациента, при этом каждый упомянутый диагноз имеет свою степень уверенности.
30. Способ по п.16, в котором каждый упомянутый вопрос, заданный пациенту, вносит связанное с этим вопросом значение в упомянутое накопленное общее значение, по меньшей мере, для одного упомянутого заболевания.
31. Способ по п.16, в котором заданный промежуток времени определяется врачом.'
32. Способ по п.31, в котором врач определяет упомянутый набор промежутков времени для конкретного заболевания, при этом любой упомянутый промежуток времени может иметь иную продолжительность, чем другие промежутки времени.
33. Способ по п.32, в котором для каждого упомянутого определённого промежутка времени компьютер сохраняет упомянутые списки симптомов и упомянутые списки вопросов для каждого симптома.
34. Способ по п.32, в котором упомянутые вопросы составляютёя так, чтобы отслеживать развитие заболевания во времени.
Текст
1 Существующий уровень техники Область изобретения Настоящее изобретение относится к автоматизированным медицинским диагностическим системам. Конкретнее, изобретение относится к автоматизированной системе для основанного на времени диагноза жалобы пациента путм использования динамических структур данных. Описание известной техники Затраты на здравоохранение в настоящее время представляют значительную часть валового национального продукта Соединнных Штатов и растут быстрее, чем любой другой компонент индекса потребительских цен. Кроме того обычно из-за неспособности оплатить медицинские услуги, многие люди лишены доступа даже к самому элементарному медицинскому обслуживанию и информации. Медицинская помощь многим людям задерживается либо препятствуется из-за стоимости, временных ограничений или неудобства. Многие заболевания могли бы быть предотвращены, если бы общественность имела универсальный, неограниченный и простой доступ к медицинской информации. Подобным же образом, раннее обнаружение и лечение многих заболеваний могло бы предотвратить развитие у пациентов тяжлых стадий заболевания, лечение которых является значительной частью финансового бремени нашей национальной системы здравоохранения. Очевидно, что Соединнные Штаты столкнулись с гигантскими здравоохранительными проблемами, и что имеющиеся решения ненаджны. Прежние попытки заняться проблемами здравоохранения содержали различные формы автоматизации. Некоторые из этих попыток имели форму телефонной библиотеки ответов на медицинские вопросы. Другие попытки были направлены на обеспечение врачей автоматизированной помощью, используемой в процессе обследования пациента. Эти способы включали в себя статические процедуры или алгоритмы. Желательным же был автоматизированный способ предоставления пациенту медицинских рекомендаций и диагностики, который работал бы быстро, эффективно и точно. Такая система медицинских рекомендаций должна быть модульной, чтобы позволить расширение для новых типов медицинских проблем или способов обнаружения. Один из способов проведения интервью с пациентом содержит медицинские диагностические сценарии. Требуется эффективный способ представления медицинских знаний экспертов в своих областях в формате сценария. Эти сценарии должны использовать динамические структуры, чтобы быстро и эффективно ставить пациенту диагноз. 2 Раскрытие изобретения Обработка на основе списков является способом диагностирования заболеваний, который работает путм сведения заболеваний, симптомов и вопросов в набор вложенных списков Заболевание, Симптом и Вопрос (ЗСВ) таким образом, чтобы эти списки могли обрабатываться для выработки диалога с пациентом. Каждый вопрос к пациенту вырабатывает один из набора определнных ответов, а каждый ответ вырабатывает один из набора определнных вопросов. Так устанавливается диалог, выявляющий симптомы у пациента. Симптомы обрабатываются и оцениваются с целью предположить наличие болезни или исключить е. Набор констатируемых заболеваний устанавливает диагноз. Система обработки на основе списков организует медицинские знания в виде формальных структурированных списков или массивов, а затем применяет к этим спискам специальный алгоритм, чтобы автоматически выбрать следующий вопрос. Ответы на вопросы ведут к другим вопросам и, в конце концов, к диагнозу. В одном выполнении изобретения описывается автоматизированный диагностический способ, содержащий следующие операции: введение в компьютер списка заболеваний, причм каждое заболевание связано со списком симптомов, а каждый симптом связан со списком вопросов; повторяющееся задавание вопросов для извлечения ответов, причм ответы устанавливают симптомы и каждый установленный симптом вносит сво значение для заболевания; и определение того, достигают ли или превосходят ли накопленные значения порог, чтобы поставить диагноз. Система медицинских рекомендаций содержит также основанный на географическом принципе список дифференциальных диагнозов в популяции, к которой принадлежит пациент,который при обработке процессором списков превращается в специфический дифференциальный диагноз пациента. Система содержит также таблицу, в которой хранится частота заболеваний, что позволяет системе производить оценку пациента с помощью вероятностей или встречаемости заболеваний в популяции, к которой принадлежит пациент. Система может также дать специфические для пациента и контекстно-зависимые рекомендации к лабораторным проверкам варианта и по методам представления варианта для дальнейшей помощи в определении диагноза. Система может вызывать функцию повторного запуска, обеспечивающую лабораторные проверки варианта и методы представления варианта, подлежащие выполнению, а затем доставить результаты пациенту,ответственному за здоровье пациента, либо другому желательному лицу. Система может вызывать функцию повторного запуска, позволяя пациенту выполнить физическое обследование 3 обратиться к системе для дополнительного уточнения диагноза. Краткое описание чертежей Фиг. 1 а является функциональной схемой,показывающей компоненты представленного предпочтительного выполнения автоматизированной системы медицинской диагностики и советов по лечению (МДСЛ) по настоящему изобретению. Фиг. 1 б является функциональной схемой,иллюстрирующей компоненты пользовательского/пациентского компьютера системы МДСЛ, показанной на фиг. 1 а. Фиг. 2 является функциональной схемой,иллюстрирующей набор процессов, файлов и баз данных, используемых системой по фиг. 1 а. Фиг. 3 а является схемой процесса выработки автономного медицинского диагностического сценария (МДС), используемого при создании сценарного файла для базы данных МДС,показанной на фиг. 2. Фиг. 3 б является схемой, показывающей возможную иерархию списков ЗСВ для сценария на двух различных промежутках времени. Фиг. 4 а является блок-схемой алгоритма части приписанных заболеваний процесса сбора и организации медицинских знаний, показанного на фиг. 3 а. Фиг. 4 б является блок-схемой алгоритма части собранного знания о заболевании процесса сбора и организации медицинских знаний,показанного на фиг. 3 а. Фиг. 5 является блок-схемой алгоритма процесса сценарного компилятора, показанного на фиг. 3 а. Фиг. 6 а является функциональной схемой,показывающей конфигурацию, используемую во время работы диагностического сценарного ядра. Фиг. 6 б является функциональной схемой,показывающей набор структур и вводов, использующихся во время работы сценарного ядра, и выводов, производимых системой МДСЛ. Фиг. 7 является высокоуровневой блоксхемой алгоритма пользовательского процесса для системы МДСЛ по фиг. 1. Фиг. 8 а является блок-схемой процесса диагностического сценарного ядра, используемого при выполнении процесса интерактивного интервью, показанного на фиг. 7. Фиг. 8 б является блок-схемой алгоритма процесса распределения советов, показанного на фиг. 8 а. Фиг. 9 является блок-схемой алгоритма частей процесса сценарного ядра списка ЗСВ,показанного на фиг. 8 а, для основанной на списках обработки. Фиг. 10 является функциональной схемой,показывающей часть списков, используемых во время работы сценарного ядра списка ЗСВ, показанного на фиг. 8 а. 4 Фиг. 11 является ещ одной блок-схемой алгоритма процесса сценарного ядра списка ЗСВ, показанного на фиг. 8 а. Фиг. 12 является блок-схемой алгоритма процесса выбора симптома (выбор предполагаемого симптома), идентифицированного на фиг. 11. Фиг. 13 является блок-схемой алгоритма процесса обработки ответа (обработка ответа пользователя), идентифицированного на фиг. 11. Фиг. 14 является блок-схемой алгоритма процесса обновления списков заболеваний(обновление информации во временном списке заболеваний на основании обновлнного списка симптомов и устранение констатируемых или исключаемых заболеваний), идентифицированного на фиг. 11. Фиг. 15 является высокоуровневой блоксхемой алгоритма альтернативного выполнения для выработки медицинских рекомендаций или диагноза в системе МДСЛ по фиг. 1 а. Подробное описание предпочтительного выполнения Последующее подробное описание предпочтительного выполнения представляет описание определнных конкретных выполнений настоящего изобретения. Однако настоящее изобретение может быть воплощено во множестве различных способов, как определяется и покрывается формулой изобретения. В этом описании делается ссылка на чертежи, на которых повсюду подобные части обозначены подобными цифрами. Для удобства обсуждение предпочтительного выполнения будет разделено на следующие главные разделы: Обзор системы; Медицинские диагностические сценарии; Подробности считывания знаний; Подробности выработки сценария; Подробности выполнения сценария и Преимущества основанной на списках обработки.I. Обзор системы Система медицинской диагностики и советов по лечению (МДСЛ) является компьютерной системой, которая проводит автоматизированные интервью пациентов в целях установления медицинского диагноза. Для проведения интервью МДСЛ использует базу данных медицинских диагностических сценариев (МДС). Каждый МДС содержит данные и команды,требуемые для интервьюирования пациента относительно конкретных медицинских состояний и для вывода диагноза. Сценарии поддерживаются содержащимися в МДСЛ другими базами данных заболеваний, симптомов, лечения, медикаментов, специалистов, - короче говоря, всей информации, необходимой для медицинского диагноза и совета. Симптомы могут определяться как часть исторической информации, часть информации, полученной из обследования физического состояния, например самостоятель 5 ной проверки физического состояния, результатов лабораторной проверки, или результатов метода представления варианта. По фиг. 1 а будет описана функциональная схема предпочтительного выполнения системы 100 МДСЛ. Система 100 МДСЛ содержит сетевое облако 102, которое может представлять собой локальную вычислительную сеть (ЛВС),территориальную сеть (ТС), Интернет или иное обслуживание соединений. Программы и базы данных МДСЛ предпочтительно располагаются на группе серверов 108, которые предпочтительно соединены посредством ЛВС 106 и шлюза 104 с сетью 102. Альтернативно, программы и базы данных МДСЛ располагаются на отдельном сервере 110, который использует аппаратное и программное обеспечение 112 сетевого интерфейса. Серверы 108/110 МДСЛ хранят списки заболеваний/симптомов/вопросов (ЗСВ), описанные ниже. Сеть 102 может соединяться с пользовательским компьютером 116, к примеру, с помощью модема или с помощью сетевой интерфейсной карты. Пользователь 114 может использовать на компьютере 116 средство 120 поиска для удалнного доступа к программам МДСЛ с помощью клавиатуры и/или указательного устройства и визуального дисплея, такого как монитор 118. Альтернативно, средство 120 поиска не используется, когда программы МДСЛ выполняются в компьютере 116 в локальном режиме. Видеокамера 122 может быть по желанию подсоединена к компьютеру 116 для обеспечения визуального ввода, такого как визуальные симптомы. Для связи с серверами 108/110 МДСЛ могут использоваться различные иные устройства. Если серверы оборудованы аппаратным обеспечением распознавания голоса или тонального набора номера, пользователь может связываться с программой МДСЛ с помощью телефона 124. Телефонное выполнение описывается в совместно поданной заявке заявителя, озаглавленной Автоматизированная медицинская система диагностики и советов по лечениюUS 08/176041, которая включена сюда посредством ссылки. Другие соединительные устройства для связи с серверами 108/100 МДСЛ включают в себя портативный персональный компьютер с модемом или интерфейсом беспроводной связи,кабельное интерфейсное устройство 128, соединнное с визуальным дисплеем 130, или спутниковая антенна 132, соединнная со спутниковым примником 134 и телевизором 136. Представлены и другие способы связи между пользователем 114 и серверами 108/110 МДСЛ. На фиг. 1 б диаграмма предпочтительного в настоящее время пользовательского/пациентского компьютера показывает несколько возможных соединений с сетью. Для проигрывания сценария используется специальная про 001835 6 грамма, называемая сценарное ядро, которая считывает файл МДС и использует его коды для выполнения таких касающихся интервью действий, как вывод пациенту вопроса и ввод ответа. Сценарии также собирают ответы пациента,оценивают эти ответы, ставят диагноз и обновляют медицинскую запись пациента. Сценарное ядро предпочтительно располагается в пользовательском компьютере. Сценарное ядро может сохраняться на жстком диске или на CD-ROM и загружается в основную память или кэшпамять для выполнения. Компоненты предпочтительного компьютера 116, используемого пользователем 114 автоматизированной системы 100 МДСЛ по настоящему изобретению, показаны на фиг. 1 б. Альтернативно, вместо компьютера 116 могут использоваться другие устройства для проведения медицинского интервью, такие как показанные на фиг. 1 а. Компьютер 102 содержит внутри контура 116 несколько компонентов. Телефонная линия 106 соединяет телефонную сеть 158 общего пользования с компьютером 116 через модем 160. Телефонная сеть 158 может соединяться с сетью 102, имеющей соединения с серверами 108/110 системы МДСЛ. Альтернативно,пользователь может подсоединиться к сети 102 с помощью сетевой интерфейсной карты 164. В данном документе слова пользователь и пациент используются взаимозаменяемо. Однако следует понимать, что пользователь может действовать, как доверенное лицо пациента. В таком случае, пользователь регистрируется в качестве ассистента пациента. Аппаратное обеспечение и системное программное обеспечение подбираются с учтом двух основных концепций: стыкуемость с другими операционными системами и использование промышленных стандартных компонентов. Таким образом, система может быть более гибкой и обеспечит свободную рыночную конкуренцию для постоянного усовершенствования продукта при одновременном понижении стоимости. Хотя ссылка будет делаться на определнное аппаратное и программное обеспечение,следует понимать, что в настоящей системе может использоваться множество различных компонентов. Компьютер 116 предпочтительно является персональным компьютером с микропроцессором 170 Intel Pentium. Другие компьютеры, такие как Apple Macintosh, Amiga, Digital Equipment Corporation VAX или IBM mainframe, также могут быть использованы. Модем 160 или сетевая интерфейсная карта 164 соединяются с шиной 162 стандартной промышленной архитектуры (ISA) или связывания периферийных компонентов (PCI). Шина 162 связывает микропроцессор 170 с несколькими периферийными устройствами посредством контроллеров (микросхем или плат). 7 Компьютерная шина 162 имеет несколько периферийных устройств, подсоединнных к ней через адаптеры или контроллеры. Видеоадаптерная плата 172, предпочтительно SVGA или лучшего разрешения, соединяется с видеомонитором 118. Схема 176 последовательной связи соединяется с указательным устройством,таким как мышь 178. В другом выполнении вместо схемы 176 можно использовать схему параллельной связи. Клавиатурная контроллерная схема 180 связана с клавиатурой 182. К шине 162 предпочтительно подсоединены дисковод 184 жсткого диска объмом 500 Мб или более и дисковод 186 CD-ROM. Жсткий диск 184 хранит файлы базы данных, такие как файлы пациента, другие файлы МДСЛ, и двоичные вспомогательные файлы. Диск 186 CD-ROM также хранит файлы базы данных, такие как файлы для пациентов, использующих компьютер 116, и двоичные вспомогательные файлы. Основная память 190 соединена с микропроцессором 170. В предпочтительном в настоящее время выполнении компьютер 116 предпочтительно работает в операционной системе 192 Windows 95. Память 190 выполняет диагностическое сценарное ядро 194 и сценарное ядро 196 списка заболеваний/симптомов/вопросов (ЗСВ). Программа сценарного ядра написана на Borland Delphi Pascal версииII. По фиг. 2 будет описан набор процессов,файлов и баз данных, используемых системой 100 МДСЛ. За исключением процесса сценарного ядра, базы данных МДС, базы данных Методов представления и базы данных Лабораторных проверок, которые описываются ниже, эти процессы, файлы и базы данных были описаны в совместно поданной настоящим Заявителем заявке, озаглавленной Автоматизированная система диагностики и советов по лечениюUS 08/176041. Система 100 МДСЛ использует несколько основных процессов и связанных с ними баз данных. Набор процессов 210 регистрации пациента используется системой 100 для идентификации пациента, который был предварительно зарегистрирован в системе одним из трх способов: 1) запросом пациентского идентификационного номера (ПИН); 2) идентификацией ассистента, который был ранее зарегистрирован в системе путм запроса ассистентского идентификационного номера (АИН); 3) идентификацией пациента, имеющего ассистента, который был предварительно зарегистрирован в системе путм запроса пациентского идентификационного номера. Набор процессов 212 используется для регистрации пациента или ассистента. Если пользователь является пациентом, системой используется процесс регистрации пациента для регистрации новых или обратившихся впервые пациентов. Если пользователь не является пациентом, система использует процесс регистрации ассистента для регистрации новых или обра 001835 8 тившихся впервые ассистентов. Затем, если пациент ещ не зарегистрирован, система для регистрации пациента использует процесс регистрации подопечного пациента. Когда пользователь записался или зарегистрировался, система обеспечивает выбор процессов. Основным процессом, рассматриваемым в данном выполнении, является диагностический процесс 220, который ставит диагноз пациенту. Оценочный процесс 220 осуществляет доступ к базе данных лабораторных проверок вариантов и методов представления вариантов,чтобы посоветовать подходящие для данного пациента в данный момент времени проверки, и к таблице 250 лечения для получения текущей информации о лечении для конкретного заболевания или диагноза. В другом выполнении добавлены другие альтернативы для доступа к другим медицинским информационным процессам. С этими процессами связаны база 240 данных записи пациентов и ассистентов, база 242 данных историй консультаций, база 244 данных ответов пациента, база 246 данных объектов медицинских карт, база 248 данных средств лечения пациента, база 252 данных ожидания, база 254 данных медицинской карты пациента, база 256 данных медицинских диагностических сценариев (МДС), база 258 данных методов описания и база 260 данных лабораторных проверок.II. Медицинские диагностические сценарии Медицинский диагностический сценарий(МДС) является запрограммированным диалогом с пациентом с целью выработки одного или нескольких диагнозов состояния пациента. Разработка МДС включает в себя такие последовательные операции, как сбор медицинских диагностических знаний, выражение их в терминах,которые могут быть понятны пациенту, организация их в полезную последовательность, компиляция е в проигрываемый сценарий, его проверка, выстраивание его для конкретной среды связи, включение его в набор других сценариев и поддерживающих баз данных, и упаковка его для использования пациентом. Написание сценария подразумевает ранние операции сбора медицинских знаний и переработки их в логический поток вопросов, который в конце концов приводит к постановке диагноза. Очевидно, что только врач с опытом диагностирования конкретного набора заболеваний может выполнить эти операции, а система МДСЛ выработала несколько автоматизированных способов для их поддержки. Изобретение предпочтительно использует один частный способ, называемый основанной на списках обработкой, начинающийся со списков заболеваний, симптомов и вопросов. Эти списки перерабатываются затем в проигрываемый сценарий с помощью основанного на списках инструмента разработки сценария. С помощью инструмента разработки сценария автор 9 может писать и редактировать исходный сценарий, компилировать его в файл исполняемого сценария, воспроизводить сценарий и устанавливать различные опции сценария, чтобы протестировать, оценить и точно настроить сценарий. Основанный на списках сценарий состоит из специально отформатированного текстового файла, в котором автор задат элементы сценария в виде нескольких списков. Списком высшего уровня является список заболеваний, которые будет рассматривать этот сценарий. Для каждого заболевания сценарий перечисляет симптомы и их значения. Для каждого симптома автор предоставляет список вопросов и их значений, которые выявят симптомы. Для каждого вопроса автор предоставляет множество текстовых объектов, в том числе текстовую преамбулу, которая вводит вопрос. После того, как все эти списки подготовлены для сценария, следующим шагом является компиляция сценария, т.е. преобразование его в специально закодированный сценарный файл, который может воспроизводиться, или прогоняться для пациента. Для прогона сценария на фазе разработки инструмент разработки сценария выбирает подходящее следующее заболевание и подходящий следующий симптом для этого заболевания. Он отображает текст вопроса и ожидает ответа от пациента. На основании ответа пациента инструмент разработки сценария обновляет информацию для данного заболевания и переходит к следующему симптому. Сценарий останавливается, когда достигается некоторое условие (установленное автором), такое как первое заболевание, констатируемое в качестве диагноза, или когда все заболевания рассмотрены. Во время фазы разработки автор сценария может устанавливать различные опции, изменяющие путь, которым сценарий выбирает следующее заболевание и следующий симптом и то, как долго будет работать сценарий. Эта опционная характеристика позволяет автору экспериментировать со сценарием для нахождения наилучших установок. Следовательно, тремя главными фазами сценария являются: 1) сбор знаний, 2) выработка сценария и 3) выполнения сценария. Автор сценария использует все три фазы при создании и тестировании сценария. Пациент использует фазу выполнения сценария в ходе использования системы 100 МДСЛ. Фазы сценария 1. Сбор знаний. Фаза сбора знаний включает в себя все задачи, необходимые для выявления у медицинского эксперта знаний относительно диагностики данного заболевания и сведения этих знаний в удобную для выработки сценария форму. Эта фаза обычно начинается с того, что руководитель разработки сценария изъявляет необходимость в сценарии для диагностирования заболе 001835 10 вания, такого как малярия. Затем следуют такие задачи, как определение объма сценария, исследование медицинских текстов, интервьюирование авторов и других экспертов, форматирование наборов вопросов и ответов, установление последовательности вопросов и, если используется автоматизированный инструмент сбора знаний, запуск потока вопросов в проверочной установке. Эта фаза завершается набором исходных документов, по возможности, автоматизированных, которые содержат (по меньшей мере) всю информацию, необходимую для написания сценария, который может правильно диагностировать заболевание, например в виде малярия/не малярия, когда в него вводятся проверочные ответы для пациента, который болен/не болен малярией. В этот момент ничего не известно об окончательной форме сценария,платформе, на которой он будет прогоняться,или даже о естественном языке, на котором будет осуществляться связь с пациентом. 2. Выработка сценария. В фазе выработки сценария сценарий вырабатывается в виде относительно небольшого диагностического алгоритма, реализованного в программе. На этой фазе цель состоит в том,чтобы сделать сценарий автоматизированным представлением авторского подхода к диагностированию заболевания или иной медицинской проблемы, такой как малярия. Сценарий содержит данные и процессы, чтобы выработать хороший первый вопрос, чтобы взвесить ответ,чтобы использовать ответ для выработки ещ одного вопроса, и так далее до тех пор, пока сценарий не сможет, наконец, сообщить запрашивающей стороне, что ответы говорят о малярии или не малярии, и дать соответствующий уровень доверительности. Заметим, что сценарий не является одиночной программой, которая может быть запущена для реального пациента. Предпочтительно, сценарий знает только одну основную жалобу, такую как малярия, и не диагностирует другие медицинские проблемы, такие как подагра или астма. Этот сценарий должен стать одним из примерно 40000 сценариев в сценарной базе данных, в различных видах и форматах. Сценарий теперь должен быть переведн на подходящий естественный язык (немецкий, испанский),поддержан подходящим механизмом обработки ошибок, переработан в подходящий язык программирования (C, Java, HTML), отформатирован для подходящей среды (PC, Mac, телефон,ЛВС, ТС, Интернет) и связан с системой поддержки (базы данных, метафункции, пациентские записи, регистрация сеанса связи). Затем сценарий подвергается обширной проверке системе отладки, которая задат сценарию различные зафиксированные наборы ответов пациентов с известными приемлемыми 11 диагнозами, чтобы убедиться, что сценарий вырабатывает правильный выход. Наконец, сценарий готов к инсталляции в систему предъявления. Он может быть сохранн в сценарной базе данных или присоединн к набору сценариев, записываемых на CD-ROM,либо доставлен в больницу по сети Интернет. Какая бы форма библиотеки сценариев ни использовалась, сценарий должен быть индексирован и зарегистрирован с помощью программного обеспечения Менеджера сценариев. В конце этой фазы сценарий является последней частью официальной работающей медицинской диагностической системы, которая может использоваться реальными пациентами для реального диагностирования реальных проблем. 3. Исполнение сценария. В фазе исполнения сценария сценарий рано или поздно исполняется. Конечно, сеанс связи с пациентом не начинается с диагностического сценария малярии. Медицинская диагностическая система, открытая для широкой общественности, очевидно, имеет некоторые административные задачи, которые должны быть выполнены до какого-либо медицинского диагностирования. Прежде всего, нежелательны случаи, когда пароль и социальный страховой номер запрашиваются у пациента, находящегося в тяжлом состоянии. Поэтому вероятнее всего система запустит сначала подсистему Скорой помощи (СП) для любого, кто регистрируется на системе МДСЛ. Подсистема СП состоит из нескольких десятков сценариев, определяющих,находится ли пациент в опасном для жизни состоянии, которое требует немедленной первой помощи в виде терапии или совета. У пациента тяжлое состояние, Дышит ли пациент,Есть ли у пациента кровотечение - некоторые из вопросов, которые задат подсистема СП. После того, как система исключила случаи тяжлого состояния, система может замедлиться, чтобы идентифицировать пациента и основную жалобу (жалобы). Затем система вызывает подсистему Маршрутизации сценариев, работа которой заключается в определении общей проблемной области пациента. На основании этой информации система Маршрутизации сценариев затем выбирает последовательность сценариев высшего уровня, которые соответствуют основной жалобе пациента. Например, при сильной температуре, после того, как более очевидные сценарии для аппендицита, кишечного гриппа, пищевого отравления дали ответ нет диагноза, сценарий маршрутизации может,наконец, решить попробовать малярию. Теперь,наконец, воспроизводится образцовый сценарий для малярии, который мы разработали в этом документе. Сценарии не являются программами, действующими самостоятельно. Сценарии - это потоки данных, запускаемые сценарным 12 ядром, которое ищет сценарий для следующего вопроса, задаваемого пациенту, и форматирует этот вопрос для передачи (на экран, в телефонную линию, или на сайт Интернета). Ответы пациента также собираются сценарным ядром,форматируются для сценария и используются для выбора из сценария следующего вопроса. Это взаимодействие сценария и сценарного ядра может привлекать для определения следующего вопроса медицинскую запись пациента, информацию, уже полученную в ходе текущего сеанса связи, и даже некоторые мета-функции. В конце сценария процесс возвращает управление сценарию маршрутизации тропических заболеваний и сообщает ответы данного пациента указывают на наличие Malaria Falciparum со значением 1350 из 1000, или ответы этого пациента дают только 420 из 1000, поэтому я исключаю малярию. Сценарий маршрутизации, вызвавший сценарий для малярии, может теперь в первую очередь решить осуществить доступ к другому диагностическому сценарию, либо решить обратиться к запрашивающему с каким-либо ответом, таким как ответы этого пациента указывают на вероятность 237/1000 наличия какого-либо тропического заболевания. Характеристики сценария Диагностические сценарии на временной основе Концепция диагностического сценария на временной основе расширяет диагностические сценарии ЗСВ во временном измерении. Вместо одного диагностического сценария автор сценария предлагает несколько сценариев, например,один на каждый час в ходе болезни. Сценарии вырабатываются по истечении определнного времени, прошедшего с момента появления симптомов, в соответствии с наилучшим суждением автора. Например, сценарий инфаркта миокарда использовал бы в качестве интервала один час или менее, в отличие от малярии. Во время прогона диагностическая система использует диагностический сценарий, ближайший к случаю конкретного пациента. Сценарий содержит выведенные симптомы, которые добавляют дополнительное значение заболеваниям,подходящим под предсказанную схему. Система спрашивает пациента, когда появились симптомы и, основываясь частично на этой информации, выбирает подходящий сценарий из набора сценариев на временной основе. Когда выбран правильный сценарий, он исполняется. Это означает, что каждый сценарий из множества сценариев на временной основе может иметь несколько отличные симптомы и значения, так что автор придат зависящим от времени симптомам дополнительные значения для тех заболеваний, временные схемы которых подходят для данного пациента. Эти значения автоматически добавляются сценарным ядром при запуске. Заметим, что эти зависящие от времени симптомы будут описанными ниже Выведенными симптомами. 13 Каждый автор алгоритма должен составить, приписать или рассчитать вопросы и подходящие значения для (к примеру) каждого часа развития заболевания. Затем, когда пациент получает консультацию у системы, одним из первых задаваемых вопросов является Когда (или как давно) начались ваши симптомы. Затем пациент будет общаться со сценарием, наиболее близким ко времени, прошедшему с момента начала симптомов. Выведенные симптомы Заметим, что симптом определяется как любая составляющая данных, известных о пациенте прямо или выведенно, в том числе имя,возраст, пол и т.д. Выведенным симптомом является симптом, который устанавливается на основании присутствия или отсутствия одного или нескольких других симптомов. Концепция выведенных симптомов позволяет автору сценария указывать сценарному ядру, что какойлибо данный симптом (или набор симптомов) предполагает или исключает один или несколько других симптомов. Это позволяет автору воплощать соотношения реального мира в основанный на списках сценарий, который, в свою очередь, позволяет ядру основанного на списках сценария делать логические заключения, упраздняющие излишние вопросы из списка и делающие сценарий более сфокусированным. Очевидным примером является пациентмужчина, которому не должно задаваться вопросов относительно женской половой системы. Врач-человек подразумевает это, но это надо объяснить сценарному ядру. Автор сценария просто создат список симптомов в виде: Если симптом А, то симптом Б. Например: пациент мужского пола подразумевает пациент НЕ женского пола, и пациенту делали аппендэктомию подразумевает у пациента нет аппендикса. Используя логические операторы, такие как И, ИЛИ или НЕ, можно построить очень сложные связи между симптомами, которые приводятся в действие с помощью относительно небольшого количества вопросов. Выведенные симптомы перечисляются в исходном сценарии как таблица команд типа ЕСЛИ А, ТО Б. Каждый раз, когда ядро принимает от пациента новый симптом, оно также проверяет таблицу выведенных симптомов, чтобы выяснить, подразумеваются ли какие-либо иные симптомы. Синергистические симптомы Синергистическими симптомами являются симптомы, которые показывают, что у какоголибо конкретного пациента наличествует набор других симптомов, которые имеют особую диагностическую важность при их одновременном присутствии. В основанном на списке ЗСВ исходном сценарии каждый симптом имеет определнное конкретное значение для диагности 001835 14 рования заболевания, но наличие определнного набора может добавить дополнительное значение в пользу диагноза. К примеру, малярия классически диагностируется, начиная с наличия ознобов, жара и потения (причиной которых является агент-возбудитель малярии, проходящий свой цикл воспроизведения в крови). Наличие ознобов или жара или потения по отдельности, вероятно, не обязательно предполагает малярию как диагноз пациента, но установление всех трх этих симптомов должно включать опрос относительно малярии. Концепция синергистических симптомов поддерживает этот внутренний спусковой механизм утверждением, таким как наличие ознобов И наличие жара И наличие потения подразумевает возможно,малярия. Синергистические симптомы также имеют важное использование при определении синдрома, т.е., отдельных наборов симптомов,появляющихся вместе так часто, что у общественности они имеют собственное имя, например, СПИД. Автор сценария может использовать синергистические симптомы для определения синдрома, который для него важен.III. Подробности сбора знаний Начальной задачей сбора знаний для сценария является идентификация включаемых в сценарий заболеваний, приписывание каждому заболеванию приоритета и установление медицинских специалистов для разработки частей сценария для заболевания, в которых они специализируются. Каждый медицинский специалист вырабатывает затем подходящие списки,необходимые для заболеваний. Это можно обобщить следующим образом:-предварительно проверить списки с помощью проверочных инструментов, специально разработанных для этой цели; и-написать списки в виде текстовых файлов с помощью любого текстового процессора, работающего в кодах ASCII. Основанный на списках способ обработки начинается с набора скоординированных списков, которые собирают элементы диагностирования отдельной здравоохранительной проблемы. В этой фазе медицинские эксперты записывают свои диагностические умения и технологии в виде нескольких списков. Для этого эксперты предпочтительно могут использовать любое коммерчески доступное программное обеспечение текстового процессора, способное давать выходной файл в коде ASCII. 15 Списки в кодах ASCII для сценария состоят из трх типов списков, вложенных следующим образом:-один список заболеваний, идентифицирующий все заболевания, которые будут рассматриваться сценарием, и ранжирующий их по порядку, в котором они должны рассматриваться для диагностирования;-один список симптомов для каждого заболевания, идентифицирующий симптомы и приписывающий значение каждому симптому для определения вклада, который этот симптом вносит в диагностирование заболевания;-один список вопросов для каждого симптома, который идентифицирует один или несколько снабжнных значениями вопросов, которые выявят у пациента симптом. Для целей автоматизированной медицинской диагностики данные медицинского диагноза организованы в иерархическую классификацию, основанную на том общем принципе, что заболевания имеют симптомы, а симптомы выявляются у пациентов с помощью вопросов. Заболеванием является состояние здоровья, требующее лечения или внимания, такое как болезнь, недомогание, недуг, болезненное состояние, проблема, затруднение, дисфункция,и т.д. Чтобы поставить диагноз пациенту,имеющему конкретные жалобы, система МДСЛ начинает со списка возможных заболеваний,при которых проявляются эти жалобы, и на основании ответов пациента уменьшает его до списка диагнозов. Симптомом является любая информация, которую система МДСЛ имеет о пациенте. Это, в частности:-предыдущие обращения к МДСЛ (например, история жалоб пациента и развитие);-физические показатели (например, показатели жизненно важных функций) и результаты самостоятельных или произведенных с помощью ассистента действий по проверке физического состояния;-показатели, проявления, представления,аспекты и т.д. Для каждого заболевания подготавливается список симптомов. Каждому симптому приписывается значение, представляющее вероятность того, что у пациента имеется заболевание, давшее этот симптом. Для упрощения расчтов система МДСЛ использует пороговое значение констатации 1000, чтобы признать заболевание в качестве диагноза, хотя могут использоваться и другие пороговые значения. Система также использует пороговое значение исключения, чтобы официально признать, 001835 16 что пациент не имеет заболевания. Как пороговое значение констатации, так и пороговое значение исключения могут изменяться с помощью набора факторов чувствительности. Это позволяет настроить пороговые значения, например,для отдельных пациентов. Множество факторов чувствительности будет дополнительно обсуждено ниже. На практике, значение является мерой готовности ставящего диагноз врача констатировать заболевание, давшее симптом. Это значение может также быть использовано как условная вероятность того, что у пациента есть заболевание, давшее симптом. Это можно использовать, если это удобно, для применения к симптомам анализа байесовской вероятности. Симптом выявляется набором из одного или нескольких вопросов, часто сопровождающихся информацией или инструкциями о том,как отвечать на вопрос. Набор узлов, необходимых для выявления симптома, называется потоком, поскольку обычно он содержит разветвляющийся поток вопросов, часто нарисованных на небольшой блок-схеме потока,который описывает, как может происходить диалог с пациентом. Чтобы ввести диагностические данные,разработанные медицинским экспертом, в систему МДСЛ, эти данные надо организовать и отформатировать. Для этой цели используется текстовый файл и был разработан формат текстового файла. Предпочтительно используются коды символов ASCII, но может быть использован любой строго определнный код текстовых символов, такой, как EBCDIC. Сценарий состоит из следующих сегментов или групп данных: А. Заболевания, подлежащие диагностированию в терминах симптомов, снабжнных значениями; Б. Симптомы, подлежащие выявлению с помощью потоков или подразумеваемые другими симптомами; В. Выводы, логически связывающие симптомы; Г. Потоки, состоящие из путей через узлы; Д. Пути, идущие к узлам вопросов; Е. Тексты, информирующие пациента и/или дающие ему советы; Ж. Вопросы, задаваемые пациенту для ответа; З. Ключи, сигнализирующие о конкретном ответе пациента. Эти сегменты являются частью следующих разделов сценарного источника или текстового файла. Раздел заголовка Раздел заголовка содержит данные, применяемые ко всему сценарию, такие как формат сценария, и набор симптомов, содержащих основную жалобу пациента. 17 Раздел заболеваний Раздел заболеваний перечисляет заболевания, которые могут диагностироваться данным сценарием, их симптомы и значения симптомов в отношении диагноза. Когда сценарий запущен во время фазы разработки сценария, инструмент разработки сценария выбирает одно из заболеваний в качестве следующего, а затем выбирает один из симптомов этого заболевания в качестве следующего. Какое заболевание и какой симптом выбраны в качестве следующего, зависит от Опций запуска, которые выбираются автором. Заданной по умолчанию последовательностью является порядок, в котором заболевания и их симптомы перечислены в этом разделе. Название заболевания Название заболевания является уникальной меткой для заболевания, используемой для идентификации заболевания. Она используется только внутренне и никогда не видна пациенту. КОДIСD-9 Специальный код, используемый в медицине для идентификации заболевания. Формальное заглавие Формальное заглавие заболевания Формальное заглавие используется здесь потому,что общепринятые названия для болезни, или акронимы, могут быть добавлены в будущих форматах. Название симптома Название симптома, который является частью диагностической картины или отпечатком пальцев болезни. Симптом подробно определяется в разделе симптомов. В контексте списка ЗСВ симптом является конкретным подробным фактом о пациенте, который может быть предположен, удостоверен, выявлен или выведен. Автор свободен определять в качестве симптома (симптомов) любые данные. Если это полезно для автора, симптомы могут содержать немедицинские факты, такие, как имя, ранг и порядковый номер пациента. Это делается с целью дать автору свободу выражения своего медицинского опыта путм определения элементарных симптомов и группировки их любым удобным образом. Для разработки симптома автор может представить набор снабжнных значениями вопросов, который бы уникальным образом подтверждал или отрицал симптом. Если это не проблематично, автор определяет симптом (в разделе симптомов) в терминах вопросов и ответов. Если симптом представляется слишком сложным, автор может разделить симптом на части, обработать каждою часть симптома и задать вопросы относительно этой части, Автор может позволить пациенту установить каждую часть по отдельности, а затем использовать механизм заключения из раздела заключений, чтобы установить основной симптом. 18 Значение симптома Величина, которую данный симптом добавляет к общему значению заболевания. Технически эта величина может быть любым числом от -10000 до +10000, реально же это, как правило, небольшое целое положительное число. Как было написано, сценарное ядро обрабатывает значения, чтобы начислить очки заболеванию. Когда установлено наличие у пациента симптома, сценарное ядро добавляет значение симптома к общему значению заболевания. Когда заболевание предпочтительно набирает 1000 очков, сценарное ядро констатирует заболевание. Простое арифметическое сложение значений может не отражать конкретный путь, которым симптом вносит вклад или указывает на наличие заболевания. Одним из решений для автора является сделать первую догадку о значении, запустить сценарий, посмотреть, как изменяется значение заболевания при каждом вопросе и ответе, а затем вернуться к перебалансировке симптомов. Технология синергистических симптомов может быть полезна автору при разработке стратегии для значений. Если существуют два симптома А и Б, которые, при условии их одновременного наличия у пациента, несут большее значение, чем каждый отдельно, то может быть определн искусственный третий симптом В,который выводится из наличия и А, и Б и добавляет дополнительное значение заболеванию. Симптом В не имеет связанных с ним вопросов,это внутренний призрачный симптом, используемый лишь для прибавления или вычитания значений на основании наличия или отсутствия других симптомов. Раздел симптомов Раздел симптомов перечисляет и описывает все симптомы, о которых идт речь в других частях сценария. Для каждого симптома этот раздел определяет поток вопросов, используемый для выявления симптома. Название симптома Название симптома является уникальной меткой для симптома и используется для идентификации симптома в других частях сценария. Название используется только внутренне, и никогда не показывается пациенту. Название потока Слово поток используется для описания специфического набора снабжнных значениями вопросов, задаваемых в определнной последовательности, которая может быть нарисована в виде блок-схемы потока. Таким образом,поток представляет отдельную группу вопросов. Поскольку один поток может выявить один из нескольких симптомов, несколько симптомов обычно будут определять для использования один и тот же поток вопросов. Некоторые симптомы (например, симптомы основной жалобы) не имеют связанного с ними потока вопросов. Раздел заключений Раздел заключений перечисляет логические выводы между симптомами, чтобы сценарное ядро знало, какие симптомы влекут за собой другие симптомы. Каждая строка этого раздела определяет один или несколько симптомов, которые совместно влекут за собой другой симптом. Т.е. каждая строка задает параметры для логической формулы вида: если симптом А и симптом Б и симптом В,то симптом Г. Заключения для симптомов могут образовывать цепи, так что один выводимый симптом может выводить другой симптом самостоятельно или в сочетании с другими симптомами. Одним из использований этого раздела может быть установление синдромных симптомов, так что определнный набор симптомов у пациента автоматически устанавливает единый коллективный симптом. Этот комбинированный симптом может также использоваться для добавления (или вычитания) дополнительного значения, если присутствует конкретный набор симптомов, т.е. обеспечивает синергию нескольких симптомов, выявленных у пациента одновременно. Раздел потоков Раздел потоков перечисляет все потоки в сценарии и определяет последовательность вопросов и симптомов, которые могут быть выявлены с помощью потока. Поток - сокращение для блок-схемы потока вопросов. Он представлен в виде сложного вопроса, который установит один или несколько симптомов. Читатели, знакомые с основанными на ветвлении сценариями, знают, что поток может служить для содержания или вызова целого, основанного на ветвлении сценария, который возвращает один из нескольких кодов ответа. Общепринято, что необходимо задать пациенту несколько вопросов для выявления у пациента одного конкретного симптома. К примеру, могут потребоваться некоторые предварительные вопросы (Курили ли Вы когданибудь, чтобы установить стадию, за которой последуют более конкретные вопросы (Сколько всего времени в годах, Вы курили), чтобы точно определить симптом пациента. Весь поток может содержать 20 вопросов по поводу курения и может выявлять один из нескольких таких симптомов, как: никогда не курил; случайный курильщик, курил 20 лет и до сих пор курит; курил 10 лет подряд, а затем бросил 10 лет назад. Каждый узел в блок-схеме потока кодируется в соответствии с путм, необходимым для прохождения от первого узла потока до данного узла. Эти пути используются для идентификации того, какое действие должно быть предпринято в каждом узле. 20 Раздел вопросов Раздел вопросов определяет подробности вопросов, подразумеваемых названием в разделе потоков. Подробности включают в себя преамбулу, текущий вопрос, клавиши, которые может нажимать пациент (на телефонной клавиатуре) и (для графических интерфейсов) название кнопки, используемой для каждого ответа. Текстпреамбулы. Преамбулой является текст, произносимый или показываемый пациенту перед тем, как задатся сам вопрос. Он может продолжать предыдущий вопрос, вводить новую тему, определять некоторые термины и информировать пациента, почему задатся данный вопрос и как на него отвечать. Здесь датся только название текста; сам текст задатся в разделе текстов. Если для вопроса не существует преамбулы, это отражается путм подстановки цифры ноль. Текствопроса Текстом вопроса является сам текущий вопрос. В то время, как преамбула имеет длину от 10 до 100 строк, вопрос обычно краток и требует очень определнного ответа, который может быть выражен нажатием одной из кнопок или щелчком мыши на ней. Здесь задатся только название текста вопроса; сам текст датся в разделе текстов. Действительныекнопки Набор действительных кнопок сообщает сценарному ядру, какие кнопки может нажимать или щелкать пациент.Kнопка 1 кнопкаN Это названия кнопок, используемые только в версиях сценария для графических дисплеев. Они сообщают ядру, как помечена каждая кнопка, например, ДА, НЕТ и НЕ УВЕРЕН. Раздел текстов Раздел текстов перечисляет сами тексты всех текстовых единиц, на названия которых имеются ссылки в других разделах, таких как преамбулы, названия и тексты вопросов. Задав уникальное название для каждого текста и набрав текст в разделе текстов, автор может использовать один и тот же текст в нескольких местах. Размещение всех текстов, предназначенных для пациента, в одном месте упрощает также обработку сценария, такую как запись текста для использования в телефонной сети или форматирование текста для показа на экране. Сценарий может переводиться на иностранный язык путм замены его раздела текстов эквивалентным текстом на другом языке. Описание чертежей по сбору знаний Теперь по фиг. 3 а будет описан автономный процесс 280 выработки сценария ЗСВ. Начиная с процесса 284, медицинские знания собираются и организуются в списочные файлы. Данные для списочных файлов собираются для одного или нескольких медицинских авторов 282. Процесс 284 имеет две части. Первая часть 21 обычно выполняется координатором сценария или руководящим автором для назначения заболеваний, а вторая часть - для сбора знаний о заболевании для каждого заболевания в сценарии. Часть для сбора знаний о заболевании обычно выполняется несколькими медицинскими экспертами, каждым в своей области. Часть назначения заболеваний из процесса 284 будет дополнительно описана в связи с фиг. 4 а, а часть сбора знаний о заболевании из процесса 284 будет дополнительно описана в связи с фиг. 4 б. Выходом процесса 284 является электронный текст, такой как файл в кодах ASCII. Этот электронный текст находится в форме списков ЗСВ, таких как списки 286 заболеваний, симптомов и вопросов. В Приложении содержится пример сценария для малярии. Этот сценарий является одним представлением списка ЗСВ. Графический пример списков ЗСВ на временной основе для сценария показан на фиг. 3 б. Показаны примерный сценарий 320 для времениT1 и сценарий 322 для времени Т 2. Каждый из этих двух сценариев содержит список 324 вопросов. Этот чертж предназначен показать иерархию списков заболеваний, симптомов и вопросов и является всего лишь примером. Заметим, что заболевание может ссылаться на симптомы, которые описаны в других заболеваниях,а симптом может ссылаться на вопросы, которые определены в других симптомах. Таким образом, симптомы и связанные с ними вопросы могут повторно использоваться различными медицинскими авторами. По фиг. 3 а, процесс 280 движется в состояние 290, которое берт списки ЗСВ в формате электронного текста и обрабатывает их с помощью инструмента разработки данных сценария. Сценарный компилятор 292 работает в тесном сотрудничестве с инструментом разработки данных сценария для выработки файла МДС. Процесс 280 может использовать инструмент разработки данных сценария и сценарный компилятор в итеративном режиме для выработки окончательного файла МДС. В состоянии 294 файл МДС записывается в базу данных 300 МДС служебной программой 298 менеджера базы данных МДС. Файл 296 МДС находится предпочтительно в двоичном формате. В примерном представлении файла МДС, показанном на фиг. 3 а под цифрой 296', МДС предпочтительно содержит раздел данных заголовка, раздел основного списка заболеваний, раздел основного списка симптомов, раздел основных потоков, раздел основного списка вопросов и раздел основного списка текстов. В другом выполнении медицинские авторы могут писать сценарии на языке медицинской терминологии или в виде узлов и ветвей, как показано состоянием 302. Другие средства создания сценария,которые могут содержать компиляторы, показаны в состоянии 304 для выработки МДС 296. 22 По фиг. 4 а будет описан процесс 350 приписывания заболеваний процесса 284 сбора и организации медицинских знаний. Процесс 350 обычно будет выполняться координатором сценария, хотя эти задачи могут выполнять и другие медицинские профессионалы, используемые системой МДСЛ. Процесс 350 предпочтительно выполняется не компьютером, а координатором сценария, который может использовать компьютер в качестве помощи для завершения следующих шагов. Начиная с исходного состояния 352, процесс 350 переходит в состояние 354, в котором определяется главная жалоба, связанная с текущим сценарием. Главная жалоба содержит симптомы, о которых пациент может изначально сообщить системе при описании основной проблемы, по которой запрашивается консультация. Переходя к состоянию 356, координатор сценария определяет список заболеваний, которые диагностируются с помощью данного сценария. Эти заболевания должны обеспечивать диагноз по главной жалобе. В список вводятся название заболевания, дескриптор и код Международной классификации заболеваний (ICD-9) для данного заболевания. При переходе в состояние 358 заболевания расставляются по вероятности появления в общей популяции, к которой принадлежит пациент, например,в стране или регионе страны. Переходя в состояние 360, координатор сценария приписывает заболеваниям приоритеты, основываясь на неотложности и/или серьзности заболевания. На основании приписанных приоритетов сценарное ядро может быть направлено на проверку сначала тех заболеваний, которые имеют приписанные им указатели неотложности или серьзности. В состоянии 362 координатор сценария передает заболевания для данного сценария для дальнейшей разработки одному или нескольким медицинским специалистам. С помощью компьютерной сети, такой как Интернет,и базы данных списков ЗСВ, можно параллельно разрабатывать много сценариев. Разработчики болезней могут работать параллельно, делая вопросы и инструкции доступными для всех остальных авторов через базу данных и сеть. Это обеспечивает быструю разработку сценариев. Процесс 350 заканчивается в конечном состоянии 364. По фиг. 4 б будет описана часть 380 сбора знаний о заболеваниях из процесса 284 сбора и организации медицинских знаний. Процесс 380 также обычно выполняется не компьютером, а медицинским специалистом или экспертом, который может использовать компьютер для ввода знаний о конкретном заболевании. Последующие шаги выполняются специалистом по данному заболеванию, который назначен координатором сценария в состоянии 362 на фиг. 4 а. Начиная с начального состояния 382, процесс 380 переходит в состояние 384 решения,где медицинский специалист определяет, следу 23 ет ли сделать сценарий сценарием на временной основе. То есть, для отслеживания течения заболевания во времени должны быть созданы несколько сценариев, образующих семейство сценариев, разделнных последовательными интервалами времени. Если определяется необходимость сценария на временной основе, процесс 380 переходит в состояние 386, в котором определяется временной интервал между сценариями в семействе сценариев. Например, автор сценария может решить выработать сценарий для каждых двух часов в ходе 48-часового периода времени. По завершении определения временного интервала для семейства сценариев,или если сценарий лучше представить в виде единичного сценария, процесс 380 продолжается в состоянии 388, в котором медицинский специалист идентифицирует пороговое значение констатации и пороговое значение исключения для каждого назначенного ему заболевания. Переходя в состояние 390, медицинский специалист идентифицирует набор релевантных симптомов для каждого назначенного ему заболевания. Список симптомов содержит название симптома, дескриптор и, по меньшей мере, одно значение, как описано ниже. Продолжая в состоянии 392, медицинский специалист идентифицирует любые релевантные соотношения,возникающие после ответов, и симптомы, идентифицируемые этими соотношениями. Возникающие после ответов соотношения могут содержать одновременные или синергистические соотношения, когда два или более симптомов,появляющихся совместно, могут иметь большее значение для диагностирования заболевания,чем сумма значений этих симптомов, появляющихся по отдельности. Последовательным соотношением является такое соотношение, когда симптомы появляются один за другим, что может дать большее значение при диагностировании заболевания, чем сумма значений каждого из симптомов, появляющихся по отдельности. Вариантом последовательного соотношения является соотношение, когда последовательность начала или конца симптомов дат значение, отличное от того, которое симптомы дают по отдельности. Выведенными соотношениями являются те, при которых наличие одного симптома влечт за собой наличие другого симптома. Автор может также установить соотношения во времени для установленных симптомов и дополнительно обрабатываемых после ответов симптомов. Соотношения, возникающие после ответов, могут также задействовать обработку для прояснения симптома, анализ массиваPQRST, или прояснение тяжести симптома. Массив PQRST является N-мерным массивом с различными признаками или аспектами болевого симптома, заданными по одному измерению. Например, массив PQRST может иметь двадцать два измерения. 24 Переходя в состояние 394, медицинский специалист приписывает значение каждому симптому заболевания. Для симптомов, имеющих связанный с ними диапазон, такой как болезненность или другой тип тяжести симптома,медицинский специалист может задавать некоторый диапазон значений, связанных с тяжестью этого симптома. Значения симптома накапливаются в очки для каждого заболевания,имеющего данный симптом. Значения могут быть либо положительными, либо отрицательными, что приводит к получению положительного или отрицательного количества очков. Переходя к состоянию 396, медицинский специалист определяет для каждого симптома поток узлов вопросов для выявления или определения симптома. Некоторые симптомы могут быть определены с помощью одного вопроса, но большинство симптомов могут потребовать нескольких вопросов для того, чтобы их выявить. Для симптомов, требующих нескольких вопросов, в состоянии 397 значения присваиваются возможным ответам на вопросы. Таким образом, этот тип симптомов может иметь диапазон,связанных с симптомом значений. Переходя к состоянию 398, для каждого вопросного узла потока вопросов медицинский специалист пишет текстовые объекты для вопросного узла,чтобы обеспечить введение или разъяснение,инструкции, рекомендации и сами вопросы для пациента. Инструкции могут определять диапазон запрашиваемых значений (набор ответов),или другие способы форматирования ожидаемых ответов. Введения или разъяснения даются,чтобы помочь пациенту понять, о чем вопрос,почему этот вопрос задатся, и задают пространство возможных ответов. Для каждого симптома автор составляет поток вопросов, который используется для выявления симптома. Используемый автором поток вопросов может быть потоком вопросов другого врача. К примеру, предположим, что симптомом является депрессия. Чтобы установить симптом депрессия, один врач может спросить: У Вас депрессия. Это можно назвать Вопрос о депрессии 1. Предположим,что автору это не нравится. Это очень кратко и реально не выявляет того, что хочется. Поэтому автор смотрит далее по базе данных вопросов. Автор может найти и просмотреть поток вопросов о депрессии 2. Этот поток вопросов гораздо более тщательно разработан. В этом потоке вопрос У Вас депрессия врач разбил на список из 10 вопросов. Подвопросы могут даже быть другими вопросами в базе данных. В этом потоке вопросов пациенту задаются десять вопросов. Каждый вопрос имеет разное значение, и после ответа на все вопросы подсчитывается итог, и если он достигает порогового значения, определнного автором вопроса, то этот врач скажет,что у пациента присутствует симптом депрессия. 25 В другом примере пусть автор хочет задать вопрос о тошноте при мигрени. Автор изучает банк вопросов. Автор может найти пятьдесят различных вопросов о тошноте. Один из вопросов гласит Вас тошнит. Вопрос неприемлем для автора сценария по мигрени. Другой автор предлагает поток вопросов, содержащий десять снабжнных значениями подвопросов. Если даваемое ими количество очков достигает определнного этим автором порога, то этот врач скажет, что у пациента тошнота. Автору сценария по мигрени этот поток нравится почти как он есть, но ему хочется изменить одно из значений одного из снабжнных значениями подвопросов. В этой ситуации автор сценария по мигрени сохраняет новый вопрос с измененным значением, как (n+1)-й вопрос о тошноте. Теперь, когда автор сценария по мигрени использует новую версию или другую версию вопроса о тошноте, она может быть снабжена значением,разумеется, отличающимся при определении разных заболеваний. Если в потоках вопросов не разрешены вопросы с разными значениями, то, по определению, все вопросы будут оценены одинаково. Но если автор, разрабатывающий заболевание, пытается понять, скажем, наличие болей в животе,он попросит пациента провести последовательность действий, таких как Пожалуйста, покашляйте. Болит ли у Вас при этом живот. Если пациент ответит да, автор может попросить пациента надавить на живот и спросит, есть ли боль. Обычно автор, разрабатывающий заболевание, просит пациента выполнить много таких действий для установления симптома болей в животе. Однако эти вопросы имеют неодинаковую важность при определении болей в животе. Если пациенту больно при надавливании на живот, то это более важный показатель, чем боль при покашливании. После того, как в состоянии 398 завершены узлы вопросов, медицинский специалист определяет в состоянии 400 решения, необходим ли другой интервал для сценария на временной основе. Если другого интервала не требуется или текущий сценарий не является сценарием на временной основе, процесс 380 заканчивается в состоянии 402 выхода из программы. Если, однако, требуется другой временной интервал в сценарии на временной основе, процесс 380 переходит назад в состояние 388 для повторного прохождения шагов 388-400 для другого временного интервала в семействе сценариев.IV. Подробности выработки сценария Внутри системы МДСЛ основанные на списках данные медицинских диагнозов хранятся в виде сценариев. Эти файлы являются диагностическим интерфейсом между врачомчеловеком и интервьюируемым пациентом. При запуске файл МДС запускается сценарным ядром, которое является общей программой, 001835 26 загружающей файлы МДС и запускающей сценарий, основанный на данных и инструкциях,закодированных в этом файле. Диагностические данные хранятся в виде списков заболеваний,симптомов, вопросов и текстовых узлов. Содержание ориентированного на списки файла МДС отражает содержание спискового файла в кодах ASCII. Главное различие между ними состоит в том, что данные текстового файла хранятся в виде сегментов текстовых строк из линейных последовательностей символов, в то время, как данные файла МДС скомпонованы в списки двоичных целых чисел. Второе отличие в том, что данные файла МДС организованы и обеспечены перекрстными ссылками для поддержания автономного доступа к данным. Файл МДС предпочтительно форматируется как один очень большой массив 32-битных двоичных целых чисел. Этот большой массив затем помещается в блоки различной длины,которые содержат данные. Поскольку позиция блока в файле сама по себе является числом, она может использоваться в качестве данных для соединения одного блока с другим блоком. Физически эти блоки независимы от какого-либо языка программирования или операционной системы, и могут переноситься на любое компьютерное аппаратное обеспечение, которое способно хранить файлы, состоящие из 32 битных чисел. Логически эти блоки могут быть вложены или соединены произвольным образом для образования структур данных, такие как связанные списки, стеки, очереди, деревья и сети. Файл МДС форматируется в виде нескольких сегментных блоков, называемых основными списками, следующим образом:- Основной список текстов. Для подготовки файла МДС списочный файл в кодах ASCII считывается и преобразуется в файл МДС посредством сценарного компилятора. Этот процесс состоит из построчного считывания текстового файла в кодах ASCII,компилирования подходящего сегмента соответствующего выходного файла МДС, и вырабатывания списков перекрстных ссылок для быстрых поисков. Поскольку некоторые символы могут быть использованы до того, как они определены, программа преобразования должна делать два прохода через файл. Во время первого прохода все строки считываются, переводятся в блоки файла МДС, а их символы сохраняются в таблице. Во время второго прохода символы заменяются их действительными адресами в блоке. Естественно, могут использоваться и другие способы компиляции. 27 Программа преобразования, разумеется,может выполнять любое количество проверок качества и содержательности, таких как обнаружение неверных форматов, потерянных сегментов, дублированных символов, неиспользуемых символов, типографских ошибок и т.д. Будучи связанной с простым текстовым редактором, программа преобразования может позволять автору сценария делать исправления в списковом файле в кодах ASCII, а затем повторно прогонять программу преобразования до тех пор, пока она не примет файл. Этот цикл редактирования служит для раннего отслеживания фундаментальных и типографских ошибок. После того, как сценарий скомпилирован,автор сценария проверяет сценарий, чтобы определить, действует ли он так, как предполагалось. Если это не так, автор сценария может,например, отрегулировать значения симптомов/вопросов, точно настроить слова и фразы для вопросных узлов и зафиксировать логические и медицинские ошибки. Затем автор сценария перекомпилирует и вновь запускает сценарий до тех пор, пока он не заработает, как должно. По фиг. 5 будет описан сценарный компилятор 292. Списки ЗСВ, находящиеся в формате электронного текста, таком как коды ASCII,собираются при помощи инструмента разработки данных сценария, а затем обрабатываются сценарным компилятором 292. Начиная с начального состояния 420, сценарный компилятор обрабатывает исходный сценарий, выявляя полноту, содержательность и единообразие. В этом состоянии идентифицируются синтаксические ошибки. После того, как все проблемные области скорректированы, компилятор переходит к состоянию 424 и преобразует сценарий из исходного формата в формат сохраняемого файла,который является двоичным форматом. Оставаясь в состоянии 426, сценарный компилятор 292 дополняет сценарий для доступа к различным базам данных МДСЛ, показанным на фиг. 2, и инфраструктурой или системой поддержки МДСЛ. Сценарный компилятор завершает сво действие в состоянии 428 выхода из программы.V. Подробности исполнения сценария. Обзор Когда пациент осуществляет доступ в систему 100 МДСЛ для диагностирования, система управляет начальным контактом с пациентом,идентифицирует пациента, решает, какое обслуживание необходимо пациенту, выбирает правильный файл МДС и стартует сценарное ядро. Это сценарное ядро начинает подчиняться закодированным в нм одно за другим указаниям. Эффектом подчинения закодированным указаниям является интервью с пациентом. В конце интервью сценарий направляет ядро на выполнение подходящих конечных действий (обновление баз данных, закрывание файлов, регистрация сеанса связи) и в конце концов возвраща 001835 28 ет компьютерное управление системе 100 МДСЛ. Использование файла МДС для управления сценарным ядром для проведения автономного интервью описано ниже. Сопроводительные операции, требующиеся для доступа к файлам базы данных, вывода информации пациенту, ввода ответов пациента и печати отчтов,выполняются операционной системой, в которой запускается сценарное ядро. Режим прогона во времени для способа обработки, основанной на списках, вырабатывает ориентированный на списки файл МДС. Это означает, что на каждом шаге должны просматриваться списки заболеваний, симптомов и вопросов для того, чтобы определить следующий вопрос или действие сценария. Сценарное ядро должно больше работать с использованием способа, основанного на списках, чем с помощью способа, основанного на ветвлении. Файл МДС является, по существу, медицинской энциклопедией человеческих заболеваний, хранимой с вертикальной организацией от верхнеуровневого списка заболеваний к единичному вопросу, выявляющему один аспект симптома одного заболевания. Чтобы запустить такую структуру данных в виде сценария, требуется инвертировать эту структуру, т.е. представить пациенту в виде потока последовательных вопросов. Чтобы сделать это в режиме прогона во времени, сценарное ядро сначала просматривает основной список заболеваний файла МДС для выбора следующего предполагаемого заболевания. Затем ядро просматривает список симптомов выбранного заболевания для выбора следующего симптома, о котором следует спросить. Затем ядро просматривает набор вопросов для выбранного симптома, чтобы выбрать вопрос, который следует задать следующим. Ядро задат вопрос пациенту, получает ответ, обновляет различные, снабжнные значениями списки и повторяет процесс до тех пор,пока не достигнет диагноза или не переберт все заболевания. Общим результатом является выработка диагностического диалога между сценарием и пациентом, который завершается постановкой диагноза. Когда сценарий запущен, сценарий поддерживает набор симптомов пациента в виде временного динамического списка, называемогоtеmр-список. Каждый новый симптом записывается в этот набор и используется для обновления списка предполагаемых заболеваний. Таким образом, ответы пациента выстраивают профиль здоровья, который используется для выбора следующих заболевания, симптома и вопроса. Профиль имеет несколько использований.- он используется для обновления всех предполагаемых заболеваний, для помощи в выборе следующего заболевания;- он может использоваться для статистических сравнений случаев;- он позволяет системе МДСЛ динамически менять поток вопросов, основываясь на состоянии здоровья конкретного пациента;- он позволяет системе МДСЛ прервать сценарий и продолжить его позднее, сохранив профиль и перезагрузив его позже для продолжения сценария. Когда сценарное ядро начинает работу, у него есть находящийся в интерактивном режиме пациент и сценарий (т.е. файл МДС). Ядро открывает файл МДС для установления доступа к закодированным спискам заболеваний, симптомов и вопросов. Оно также открывает запись пациента, чтобы получить медицинскую историю пациента и результаты прошлых сеансов связи с данным пациентом, если они были. Начиная с этого места, файл МДС управляет ходом интервью, направляя ядро на следующий шаг интервью. В конце интервью сценарий направляет ядро на выполнение подходящих конечных действий (обновление баз данных, закрывание файлов, регистрация сеанса связи) и, в конце концов, возвращает компьютерное управление системе МДСЛ. Интересным аспектом данного объяснения обработки, основанной на списках, является алгоритм, использующийся для задания пациенту вопроса и построения набора симптомов для постановки диагноза. Этот алгоритм состоит из основного цикла, анализирующего и обновляющего набор симптомов пациента до тех пор,пока не достигнет некоторого прерывающего цикл условия. Основной цикл содержит следующие общие шаги:- анализ набора симптомов пациента;- выбор следующего предполагаемого заболевания;- выбор следующего предполагаемого симптома;- выбор задаваемого следующим вопроса;- представление вопроса пациенту и обработка ответа;- обновление набора симптомов на основании ответа;- выполнение послеответной обработки набора симптомов;- зацикливание для анализа набора симптомов пациента. Этот основной цикл продолжается до тех пор, пока сценарий не закончится некоторым выходным действием, таким как формулирование диагноза, сообщение советов по лечению или отсылка пациента к другому сценарию. Описание чертежей исполнения сценария По фиг. 6 а будет описана общая конфигурация системы МДСЛ для действия диагностического сценарного ядра 190. Диагностическое сценарное ядро 190 взаимодействует с системой 440 поддержки МДСЛ так, чтобы получить доступ ко множеству баз данных 442 системы 30 МДСЛ и иметь возможности ввода и вывода для различных субъектов медицинского сообщества. Система 440 поддержки МДСЛ содержит процессы, показанные на фиг. 2, в том числе процесс 210 входа, процесс 212 регистрации и диагностический процесс 220. В систему 440 поддержки МДСЛ входят также процессы для выполнения ввода и вывода врачом 444, пациентом 114 и здравоохранительными организациями 446, такими как организация по охране здоровья (003). Система 440 поддержки МДСЛ использует сеть 102 связи, показанную ранее на фиг. 1 а и 1 б. Базы 442 данных, показанные на фиг. 6 а, содержат базы данных, показанные ранее на фиг. 2, а также содержат другие базы данных, такие как базы данных по заболеваниям человека, лекарствам и взаимовлиянию лекарств, человеческой анатомии, таблица регулирования информации и географическое распределение частоты заболеваний. Таблица регулирования информации является таблицей регулирующих и правовых правил, дающая системе знать, сколько информации можно раскрыть пациенту. По фиг. 6 б будут описаны структуры, вводы и выводы, используемые в ходе действия диагностического сценарного ядра. Основываясь на вводе от пользователя 460, записях из базы 254 данных медицинской истории пациента и информации, доступной из центральных баз 442 данных МДСЛ, из базы данных 300 МДС выбирается МДС 296. Альтернативно, если диагностическое сценарное ядро 190 запущено на персональном компьютере пациента, вместо баз данных МДСЛ, хранимых в центральном компьютере, может осуществляться доступ к хранилищу 184 местных данных пользователя. Однако медицинскую историю пациента более практично хранить в центральной базе данных по нескольким причинам: безопасность записей,органы здравоохранения в любой точке мира имеют доступ, необходимый для анализа, подбора диагноза к любым новым видам лечения так, что пациент может быть быстро оповещн системой, и т.д. МДС 296 доступен диагностическому сценарному ядру 190, которое выполняет интервьюирование пациента. Сценарное ядро 190 может записывать информацию, полученную в ходе интервью с пациентом, либо в центральную базу 254 данных медицинской истории пациентов, либо в локальное хранилище 184 пользовательских данных. По завершении текущего сценария, либо если запускаются дополнительные сценарии, может вырабатываться медицинский диагноз или совет 462. Этот диагноз или совет предпочтительно сообщается врачу 464,выводится для пользователя 466 и сохраняется в центральных базах данных МДСЛ или локальном хранилище 184 данных пользователя. Если необходимо, могут вырабатываться другие отчты 468. Как будет описано позже, существуют 31 ситуации, когда диагноз может не сообщаться напрямую пользователю, а вместо этого отправляется врачу для последующего сообщения его пользователю. По фиг. 7 будет описан общий процесс 480 высшего уровня для пользователя во время сеанса связи с системой 100 МДСЛ. Процесс 480 начинается в начальном состоянии 481 и переходит в состояние 482 для идентификации опасной ситуации. Набор начальных жстко закодированных выводимых на экран вопросов используется для идентификации опасной ситуации. Когда опасная ситуация идентифицирована, пользователю дается подходящая рекомендация, например, позвонить в службу 911. Состояние 482 и последующие состояния 484, 486 и 488 в основном описаны в совместно поданной Заявителем патентной заявке, озаглавленной Автоматизированная система медицинской диагностики и советов по лечению, US08/176041. Если процесс 480 определяет, что опасной ситуации нет, процесс продолжается в состоянии 484 и конфиденциально идентифицирует пользователя. Как описано в совместно поданной Заявителем заявке, пользователем может быть пациент или ассистент пациента. Могут использоваться пароли, идентификационные номера, образцы голоса или другие виды способов идентификации. Если пациент вошл в систему правильно, процесс 480 переходит в состояние 486 для выполнения необходимых административных задач. Переходя в состояние 488, процесс 480 осуществляет доступ к медицинским базам данных МДСЛ (фиг. 2) и системным файлам и программам. В состоянии 490 проводится автономное интервью с пользователем. Автономное интервью предпочтительно выполняется процессом 490 диагностического сценарного ядра. Однако могут использоваться другие способы выполнения автономного интервью, такие как запуск программы или исполнение сценария. Пользовательский процесс 480 заканчивается в конечном состоянии 492. По фиг. 8 а будет описан процесс 490 диагностического сценарного ядра. Начиная с начального состояния 492, процесс 490 сценарного ядра переходит в состояние 494 для выполнения функции маршрутизатора сценария. Маршрутизатор сценария выбирает подходящий сценарий ЗСВ, основанный на таких входных параметрах, как: симптомы главной жалобы пациента, время, прошедшее с момента возникновения симптомов, прошлая медицинская история пациента, результаты любых других сценариев, или предшествующие по времени результаты текущего семейства сценариев. Идентификация главной жалобы пациента является алгоритмической. Главные жалобы могут классифицироваться следующим образом: затронутая анатомическая система, причина проблемы пациента, например, травма или инфекция, алфавитный список главных жалоб, номера жалоб 32 в ICD-9, либо номера для главных жалоб по каталогу МДСЛ. После того, как был выбран подходящий сценарий ЗСВ, процесс 490 продолжается в состоянии 496, для извлечения выбранного сценария из базы 300 данных сценариев (фиг. 6 б). В это время процесс 490 диагностического сценарного ядра заставляет сценарное ядро 500 списка ЗСВ использовать списки ЗСВ для выполнения интервью с пациентом. Сценарное ядро 500 списка ЗСВ будет дополнительно описано по фиг. 9 и 11. Процесс 490 диагностического сценарного ядра обрабатывает результаты сценария ядра ЗСВ в состоянии 502. В состоянии 502 выполняются различные виды обработки, как показано для примера состояниями 506-526, описываемыми ниже. Одно из действий, которые могут выполняться в состоянии 502, содержит определение степени уверенности для заболеваний в списке констатируемых заболеваний и в списке исключаемых заболеваний. Степень уверенности для некоторых или всех диагнозов в списках констатируемых и исключаемых заболеваний может сообщаться пациенту и/или врачу. Диагнозы из списков констатируемых и исключаемых заболеваний и связанные с ними степени уверенности компилируются в список дифференциальных диагнозов. Различные способы определения степени уверенности для диагноза включают в себя, к примеру, таблицу степеней уверенности или множество факторов чувствительности. Факторы чувствительности были ранее описаны в выданном Заявителю патенте США 5594638, озаглавленном Автоматизированная система медицинской диагностики,содержащая функцию повторного входа и факторы чувствительности. Следующее действие,выполняемое процессом 490, зависит от типа результата, как определено состоянием 504 решения. Теперь будут описаны различные примерные типы результатов. В состоянии 506 процесс 490 диагностического сценарного ядра отсылает пациента к другому сценарию, которое выбирается на шаге 494, как было описано ранее. В состоянии 508 процесс 490 вырабатывает подходящий диагноз или совет. При переходе к функции 510 совет выдатся подходящей стороне. Функция 510 будет дополнительно описана в связи с фиг. 8 б. После того, как выдан совет, процесс 490 заканчивается в конечном состоянии 512. В состоянии 514 процесс 490 выполняет специальный мета-анализ. Диагностическое сценарное ядро изучает, как конкретный симптом изменяется или растт со временем при данном заболевании. В состоянии 516 процесс 490 сохраняет результаты, собранные в ходе сценария, в пациентские записи. В состоянии 518 процесс 490 направляет пациента на осуществление доступа к библиотеке медицинской информации, являющейся частью системы 100 33 МДСЛ. В состоянии 520 процесс 490 составляет расписание для более позднего продолжения сценария, который был временно приостановлен. Обычно это происходит, когда пациент не в состоянии завершить весь сценарий в течение одного сеанса связи. В ситуации, когда ни одно из заболеваний не достигло порогового значения констатации, диагностическое сценарное ядро имеет возможность предоставить пациенту список заболеваний, имеющих наибольшие значения, в порядке убывания вероятностей. В такой ситуации в состоянии 522 процесс 490 может предписать повторить сеанс связи спустя некоторое время, и посмотреть, будет ли позже поставлен диагноз. Характеристики повторного входа описаны в совместно поданной Заявителем заявке, озаглавленной Автоматизированная система медицинской диагностики и советов по лечению. В состоянии 524 процесс 490 просит пациента выполнить проверки и снова проконсультироваться с системой. Эти проверки могут содержать действия по самопроверке,проверки методов представления (258 на фиг. 2) или лабораторные проверки (260, фиг. 2). В состоянии 526 процесс направляет любые срочные результаты здравоохранительному органу. Процесс 490 заканчивается в конечном состоянии 512. По фиг. 8 б будет описана функция 510 предоставления диагноза или совета. Начиная с начального состояния 511, функция 510 переходит в состояние 512, в котором результаты различных списков сопоставляются из-за того, что одно или несколько заболеваний достигли порогового значения. Переходя в состояние 515,функция 510 проверяет наличие в таблице лечений подходящего и текущего лечения для поставленных системой диагнозов. Переходя в состояние 517, функция 510 определяет, кто должен получить диагноз или рекомендацию. Частично это выполняется путм консультации в таблице 519 регулирования информации. Таблица регулирования информации определяет тип информации, которая может быть сообщена пациенту, в зависимости от различных факторов, таких как страна проживания пациента. В результате консультации в таблице 519 регулирования информации диагноз или совет сообщаются пациенту 114, врачу 444, здравоохранительной организации 446 или другому субъекту 521, который может осуществлять легальный доступ или которому необходимо знать эту медицинскую информацию. Многое из этой информации может быть сообщено пациенту и должно быть сообщено врачу этого пациента. Например, что констатировано, что исключено,и каков специфический дифференциальный диагноз пациента То есть после того, как пациент ответил на все вопросы, всем различным заболеваниям могут быть проставлены очки. Это очень полезно для врача. Таблица 519 регулирования информации использует информацию, 001835 34 доступную в пациентской записи, такую как почтовый индекс или телефонный код пациента для определения его местонахождения. По фиг. 9 будет описан процесс 500 сценарного ядра ЗСВ. Начиная с начального состояния 530, процесс 500 переходит в состояние 532, осуществляя доступ к выбранному файлу списка ЗСВ, переданному ему диагностическим сценарным ядром. Переходя в состояние 534,процесс 500 инициализирует временные списки,используемые сценарным ядром. По фиг. 10 процесс 500 инициализирует подлежащий очистке временный список 552 симптомов и инициализирует временный список 550 заболеваний, чтобы иметь все заболевания основного списка 324 заболеваний. В этот момент процесс 500 выбирает для обработки одно из заболеваний, а затем выбирает симптом, который должен подтверждаться при этом заболевании. Для того, чтобы определить наличие или отсутствие этого симптома у пациента, процесс 500 продолжается в состоянии 536, чтобы выбрать первый вопрос по этому симптому для задания его пациенту. В состоянии 538 процесс 500 задат этот вопрос пациенту. В состоянии 540 процесс 500 получает ответ пациента и проверяет корректность ответа в соответствии с заданным вопросом. Затем ответ пациента используется для обновления в состоянии 542 временных списков ЗСВ. Переходя к состоянию 544 решения, процесс 500 определяет, поставлен ли диагноз или наступил ли конец сценария. Если нет, процесс 500 переходит в состояние 546 для выбора либо следующего вопроса по текущему симптому,либо, если все вопросы по данному симптому заданы, для перехода к следующему симптому текущего заболевания. Если все вопросы по текущему заболеванию заданы, процесс 500 переходит к следующему заболеванию и задат вопросы, необходимые для этого заболевания. Процесс 500 зацикливается в состояниях 538546 до тех пор, пока на достигнут конец сценария, не поставлен диагноз, пользователь не попросил отложить сценарий или пока сценарное ядро не определит, что сценарий должен быть прерван. Когда поставлен диагноз или достигнут конец, процесс 500 либо выдат диагноз в состоянии 541, либо отсылает пациента к другому сценарию в состоянии 543, либо приостанавливает текущий сценарий в состоянии 545,либо прерывает текущий сценарий в состоянии 547. Процесс 500 завершается в конечном состоянии 548. По фиг. 10 будет описана часть списков,используемых во время прогона сценарного ядра 500 списков ЗСВ. На основании ввода 460 пользователя и времени, с которого начались симптомы, сценарный маршрутизатор 494 (фиг. 8 а) диагностического сценарного ядра 490 идентифицирует сценарий, который следует передать сценарному ядру 500 списков ЗСВ. Записи 35 текущего пациента из медицинской истории 254 пациента также используются сценарным маршрутизатором 494. С помощью медицинского диагностического сценария, полученного от сценарного маршрутизатора, сценарное ядро 500 списков ЗСВ осуществляет доступ к основному списку 324 заболеваний. Заболевания из основного списка заболеваний копируются во временный список 550 заболеваний. В подходящий момент во время действия сценарного ядра 500 списков ЗСВ симптомы из основного списка 326 симптомов текущего заболевания выборочно копируются во временный список 552 симптомов, как будет описано по фиг. 12. В ходе установления симптомов во время интервью с пациентом значение симптомов и/или значение ответов будут добавлены к количеству очков текущего заболевания во временном списке 550 заболеваний. Когда количество очков для отдельного заболевания достигает порогового значения констатации, заболевание переносится в список 554 констатируемых заболеваний. Альтернативно, если количество очков текущего заболевания достигает порогового значения исключения, заболевание переносится в список 556 исключаемых заболеваний. Установленные симптомы, констатируемые заболевания, исключаемые заболевания и заболевания,которые нельзя ни констатировать, ни исключать, могут все сохраняться в медицинской истории 254 пациента. При завершении сценария или при истечении времени сценария или в контрольной точке во время сценария, заболевания,оставшиеся во временном списке 550 заболеваний, могут также вписываться в медицинскую историю 254 пациента. Альтернативно информация о симптомах и заболеваниях пациента может записываться в локальное хранилище 184 пользовательских данных (фиг. 6 б) вместо центральной медицинской истории 254 пациента. По фиг. 11 будет описано действие сценарного ядра 500 списков ЗСВ. Это описание даст больше подробностей, чем обзор процесса сценарного ядра, данный по фиг. 9. Начиная с начального состояния 580, процесс 500 сценарного ядра переходит в состояние 582, в котором из основного списка 324 заболеваний сценария инициализируется временный список 550 заболеваний (фиг. 10). Переходя в состояние 584,процесс сценарного ядра осуществляет доступ к пациентским данным текущего и/или предыдущих сеансов связи пациента. Процесс 500 сценарного ядра использует систему 440 поддержки МДСЛ (фиг. 6 а) и базы данных 442 для получения пациентских и любых других необходимых данных. Альтернативно пациентские данные могут быть затребованы из локального хранилища 184 пользовательских данных (фиг. 6 б). Переходя в состояние 586, процесс 500 сценарного ядра выбирает предполагаемое заболевание. При выборе порядка заболеваний,подлежащих рассмотрению, могут использо 001835 36 ваться различные способы. К примеру, наиболее неотложные заболевания могут рассматриваться первыми, затем идут серьзные заболевания, а затем - общие заболевания. Альтернативно или в сочетании с моделью неотложности/серьзности, первые подлежащие рассмотрению заболевания могут быть наиболее преобладающими в популяции, к которой относится пациент. Процесс сценарного ядра может использовать номер телефона, почтовый индекс или другие источники информации о местонахождении из истории пациента, чтобы идентифицировать группу или местонахождение популяции, к которой принадлежит пациент. Альтернативой для выбора порядка заболеваний после запуска процесса является использование заболевания с наибольшей суммой значений симптомов, т.е. заболевание, которое наиболее близко к постановке диагноза. Предпочтительно координатор сценария размещает заболевания для текущего сценария в том порядке, в котором они будут рассматриваться. После того, как определено текущее подлежащее рассмотрению заболевание, процесс 500 сценарного ядра переходит к процессу 588 выбора предполагаемого симптома. Процесс 588 определяет предполагаемые симптомы для текущего заболевания и будет дополнительно описан в связи с фиг. 12. Процесс 500 сценарного ядра проверяет,установлен ли в состоянии 590 решения нулевой флаг выбранного симптома, который может быть установлен во время процесса 588. Если флаг выбранного симптома для текущего заболевания равен нулю, процесс 590 переходит к состоянию 616 решения, чтобы определить, есть ли ещ заболевания, подлежащие рассмотрению. Если, однако, флаг выбранного симптома не равен нулю, процесс 500 сценарного ядра переходит в состояние 592 для выбора потока вопросов, представляемого пациенту. С каждым симптомом связан логический поток вопросов,который может выявить этот симптом. Логический поток может быть представлен как сложный вопрос, т.е. вопрос, который состоит из нескольких вопросов и может вызвать один из нескольких ответов. Предпочтительно должен выбираться поток вопросов, который содержит,т.е. может вырабатывать в качестве ответов,симптом, который в текущий момент имеет наивысшие шансы предопределить констатацию рассматриваемого заболевания. Переходя в состояние 594, процесс 500 сценарного ядра исполняет текущий узел потока. Переходя в состояние 596, процесс 500 сценарного ядра предъявляет вопросную часть узла потока пользователю. Каждый вопрос предпочтительно состоит из информационного текста, текста инструкции и вопроса. Для предъявления вопроса сценарий сначала выводит пациенту информационный текст, затем текст инструкции, а затем 37 текст вопроса. Текст вопроса указывает пациенту, что в настоящий момент ожидается ответ. Продолжая, сценарное ядро обрабатывает ответ пользователя в процессе 598 обработки ответа. Процесс 598 будет дополнительно описан по фиг. 13. Узел потока предпочтительно бывает трх типов: симптом, вопрос или программа. Процесс 500 сценарного ядра определяет тип узла потока в состоянии 600 решения. Если типом узла является вопрос или программа, процесс 500 сценарного ядра переходит в состояние 594 (вопросный цикл Q) для исполнения следующего узла потока. Если, однако,узел имеет тип симптом, процесс 500 переходит в состояние 602 для обновления временного списка 552 симптомов (фиг. 10), основываясь на полученном от пациента ответе. На основании этого ответа текущему симптому присваивается значение. Альтернативно, если текущий симптом использует много вопросов, некоторые из которых имеют связанные с ними значения,значение (если оно есть) для текущих вопросов накапливается для текущего симптома. Когда сценарий ЗСВ обнаружил симптом,он обновляет все заболевания, имеющие этот симптом. То есть один ответ пациента может изменить значения симптомов всех предполагаемых болезней. Это помогает одному или нескольким заболеваниям стать ближе к диагностическим пороговым значениям. Переходя к функции 604, процесс 500 сценарного ядра выполняет послеответную обработку для дальнейшего обновления временного списка 552 симптомов. Примерами послеответной обработки являются соотношения если-то,соотношения одновременности, соотношения последовательности и другие подобные типы соотношений. Например, если значение тяжести симптома равно 9, то значение 75 может быть добавлено к диагнозу желчная колика, а значение 50 может быть вычтено из диагноза аппендицит. Другие послеответные соотношения были обсуждены ранее по фиг. 4 б (сбор знаний о заболевании). После того, как послеответная обработка завершена, процесс 500 сценарного ядра переходит к процессу 606 обновления списка заболеваний. В процессе 606 сценарное ядро обновляет очки во временных списках заболеваний на основании обновленного временного списка 552 симптомов и устраняет констатированные или исключенные заболевания. Процесс 606 обновления списка заболеваний будет дополнительно описан по фиг. 14. По завершении процесса 606 некоторые заболевания могут быть констатированы или исключены, таким образом уменьшается длина временного списка 550 заболеваний (фиг. 10). Если, однако, ни пороговое значение констатации, ни пороговое значение исключения не было достигнуто, заболевание не удаляется из временного списка заболеваний. Таким образом,в состоянии 608 обновленный временный спи 001835 38 сок заболеваний и обновленный временный список симптомов оставляются для следующей итерации проверки симптомов и заболеваний. Переходя к состоянию 610 решения, процесс 500 сценарного ядра определяет, остались ли симптомы для текущего заболевания во временном списке 552 симптомов. Если да, то процесс 500 сценарного ядра выбирает симптом с наибольшим значением, основываясь на абсолютной величине, а затем переходит в состояние 592 (цикл симптомов S) для выбора потока вопросов для этого нового симптома. Если, однако, не осталось дополнительных симптомов во временном списке 552 симптомов, что определяется в состоянии 610 решения, то процесс 500 сценарного ядра переходит в состояние 614 для стирания текущего заболевания из временного списка 550 заболеваний. Переходя в состояние 616 решения, процесс 500 сценарного ядра определяет, пуст ли временный список 550 заболеваний для текущего сценария. Если нет, процесс 500 сценарного ядра переходит в состояние 586 (цикл заболеваний D), чтобы рассмотреть следующее заболевание из сценария. Если временный список 550 заболеваний пуст для текущего сценария, процесс 500 сценарного ядра переходит к состоянию 618 решения, определяя тип результата сценария. В состоянии 620 одним из возможных результатов является то, что одно или несколько заболеваний были констатированы или исключены. В состоянии 622 другим типом результата является то, что сценарное ядро определило отсылку к другому сценарию или к другому обслуживанию. Процесс 500 сценарного ядра завершается в состоянии 624 выхода из программы и возвращается к диагностическому процессу 490 (фиг. 8 а). По фиг. 12 будет описан процесс 588 выбора симптомов, на который давалась ссылка на фиг. 11. Начиная с начального состояния 640,процесс 588 выбора симптома переходит в состояние 642, чтобы очистить временный список 552 симптомов (фиг. 10). Переходя в состояние 644, процесс 588 выбора симптома осуществляет доступ к текущему заболеванию в основном списке 324 заболеваний сценария (фиг. 10). Переходя в состояние 646, процесс 588 идентифицирует следующий симптом текущего заболевания. Переходя в состояние 648 решения, процесс 588 определяет, исполнялся ли ранее для этого пациента поток вопросов для этого симптома. Например, симптом мог быть определн для другого заболевания или даже в другом сценарии для данного пациента. Если поток вопросов ранее не исполнялся, процесс 588 переходит в состояние 650 и добавляет симптом во временный список симптомов. После добавления симптома во временный список симптомов,либо, если поток вопросов данного симптома ранее исполнялся, процесс 588 переходит к состоянию 652 решения. В состоянии 652 решения 39 процесс 588 определяет, есть ли ещ симптомы для текущего заболевания. Если да, то процесс 588 возвращается в состояние 646 для идентификации следующего симптома текущего заболевания. Если для текущего заболевания больше нет симптомов, что определяется в состоянии 652,процесс 588 продолжается в состоянии 654 решения, чтобы определить, пуст ли временный список 552 симптомов. Если да, процесс 588 выбора симптома переходит в состояние 656 для исключения текущего заболевания из временного списка 550 заболеваний. Это происходит, к примеру, если все симптомы для заболевания были рассмотрены ранее в этом или другом сценарии. В этой ситуации процесс 588 выбора симптома возвратит в состояние 658 нулевой флаг симптома. Возвращаясь в состояние 654 решения, если процесс 588 выбора симптома определяет, что временный список симптомов не пуст, исполнение продолжается в состоянии 660, в котором временный список симптомов сортируется по абсолютным величинам значений. Переходя в состояние 662, процесс 588 выбирает симптом с наибольшей абсолютной величиной значения. Процесс 588 выбора симптома возвращается в состоянии 664 к процессу 500(фиг. 11) с выбранным симптомом. По фиг. 13 будет описан процесс 598 обработки ответа, на который датся ссылка на фиг. 11. Начиная с начального состояния 690, процесс 598 переходит в состояние 692 для проверки действительности ответа пользователя. Переходя в состояние 694 решения, процесс 598 определяет, действителен ли ответ. Если ответ недействителен, процесс 598 переходит в состояние 696, чтобы повторить вывод пользователю текста вопроса, а затем возвращается в состояние 692 для проверки действительности ответа пользователя. Во время процесса 598 обработки ответа возникает проверка ситуации истечения времени. Истечение времени оценивается, чтобы понять, означает ли он возможную потерю сознания или изменение умственного состояния. Если да, может быть вызвана подпрограмма умственного состояния либо,например, вызвана бригада скорой помощи. Если в состоянии 694 ответ определяется как действительный, процесс 598 переходит к состоянию 698 решения, определяя тип узла,обрабатываемого в текущий момент сценарным ядром 500 ЗСВ. Если это узел типа симптом,процесс 598 переходит в состояние 700 для выбора значения симптома, связанного с текущим узлом потока. Узел типа симптом возвращает симптом в виде ответа на сложный вопрос. Затем в состоянии 702 процессу 500 сценарного ядра симптома (фиг. 11) возвращается значение симптома. Если узел является узлом типа вопрос, процесс 598 переходит в состояние 704 для преобразования ответа в цифровое обозначение пути. Переходя в состояние 706, процесс 40 598 добавляет это цифровое обозначение пути к названию пути текущего узла потока. Состояния 704 и 706 используются для идентификации следующего исполняемого вопросного узла. Возвращаясь к состоянию 698 решения, если тип узла определн как программа, процесс 598 переходит в состояние 710. В состоянии 710 процесс 598 выполняет программу, на которую указывает данный узел, и получает цифровое обозначение выхода из программы. Продолжаясь в состоянии 712, процесс 598 добавляет цифровое обозначение выхода к названию пути текущего узла потока. Состояния 710 и 712 используются для идентификации следующего исполняемого вопросного узла. Программа, исполняемая в состоянии 710, может быть подсценарием или другой функцией или процедурой, необходимой для выявления у пациента дополнительной медицинской информации. По завершении состояния 706 или 712 процесс 598 выходит в состояние 708 выхода из программы в процесс 500 сценарного ядра ЗСВ (фиг. 11). По фиг. 14 будет описан процесс 606 обновления списка заболеваний, на который делается ссылка на фиг. 11. Начиная с начального состояния 730, процесс 606 переходит к состоянию 732 для доступа к временному списку 550 заболеваний (фиг. 10). Продолжаясь в состоянии 734 решения, процесс 606 определяет, есть ли ещ заболевания во временном списке 550 заболеваний. Если нет, то процесс 606 выходит в состояние 736 выхода из программы в процессе 500 сценарного ядра ЗСВ (фиг. 11). Однако,если во временном списке есть ещ заболевания, процесс 606 переходит в состояние 738 для доступа к следующему заболеванию во временном списке 550 заболеваний. Переходя в состояние 740 решения, процесс 606 определяет,содержит ли текущее заболевание симптом, по которому пациент уже дал ответы, или какиелибо из его симптомов, полученных в послеответной обработке, таких как определнные функцией 604 (фиг. 11). Если да, процесс 606 переходит в состояние 742 и добавляет значение симптома, полученного послеответной обработкой, или симптома, по которому пациент дал ответы, к очкам текущего заболевания. Переходя в состояние 744 решения, процесс 606 определяет, есть ли дополнительные симптомы,имеющие значения, которые должны быть добавлены к очкам текущего заболевания. Это обычно будет происходить, если существует несколько симптомов, выявленных послеответной обработкой. Если да, процесс 606 возвращается в состояние 742, чтобы добавить значение этих дополнительных симптомов к очкам заболевания. Если более нет симптомов, которые необходимо обрабатывать, что определяется в состоянии 744, процесс 606 переходит к состоянию 746 решения. В состоянии 746 решения процесс 606 определяет, достигло или превысило ли количест 41 во очков заболевания пороговое значение констатации. Предпочтительно пороговое значение констатации имеет величину 1000, но могут использоваться и другие пороговые значения констатации. Если да, то процесс 606 переходит в состояние 748, добавляя текущее заболевание в список 554 констатируемых заболеваний (фиг. 10). Переходя в состояние 750, процесс 606 удаляет текущее заболевание из временного списка 550 заболеваний (фиг. 10), а затем возвращается к состоянию 734 решения, чтобы определить,есть ли ещ заболевания во временном списке 550. Если в состоянии 746 решения определено,что значение не достигло и не превысило порогового значения констатации, процесс 606 переходит к состоянию 752 решения. В состоянии 752 решения процесс 606 определяет, достигло или превысило ли количество очков заболевания пороговое значение исключения. Если да,процесс 606 переходит в состояние 754, чтобы добавить текущее заболевание в список 556 исключаемых заболеваний (фиг. 10). Переходя в состояние 750, процесс 606 удаляет текущее заболевание из временного списка 550 заболеваний и возвращается к состоянию 734 решения для проверки наличия дополнительных заболеваний во временном списке 550 заболеваний. Возвращаясь к состоянию 752 решения,если определено, что количество очков заболевания не меньше или равно пороговому значению исключения, процесс 606 возвращается к состоянию 734 решения для проверки наличия дополнительных заболеваний во временном списке 550 заболеваний. Возвращаясь к состоянию 740 решения, если текущее заболевание не содержит симптомов, по которым пациент только что ответил, или каких-либо симптомов, выявленных послеответной обработкой, процесс 606 возвращается к состоянию 734 решения для проверки наличия дополнительных заболеваний во временном списке 550. Использование порогового значения констатации и порогового значения исключения имеет определнные следствия:- значение симптома может быть задано как положительное или отрицательное число;- для каждого заболевания сохраняются два набегающих значения: одно положительное и одно отрицательное;- положительные значения симптомов добавляются к положительному счту, а отрицательные - к отрицательному счту;- используются два пороговых значения,одно положительное (например, 1000 или 10000) для констатирования заболеваний, и одно отрицательное (например, -1000 или -10000) для исключения заболеваний;- когда положительное значение достигает или превышает положительное пороговое значение, заболевание констатируется;- когда отрицательное значение достигает или превышает отрицательное пороговое значение, заболевание исключается;- если значение заболевания не достигает ни одного из пороговых значений к концу сценария, оно оставляется в списке неопределнных болезней, который может храниться в медицинской истории пациента. По фиг. 15 будет описано альтернативное выполнение выработки медицинского совета или диагноза с помощью сценариев, основанных на ветвлении. Начиная с начального состояния 782, процесс 780 основанного на ветвлении сценария переходит к состоянию 784,открывая файл основанного на ветвлении медицинского диагностического сценария. Переходя в состояние 786, процесс 780 устанавливает данные пациента из текущего и/или предыдущих сеансов связи с пациентом. Сценарный процесс 780 переходит в состояние 788 и начинает с первого в сценарии вопроса. Переходя в состояние 790, сценарный процесс 780 предъявляет пользователю текущий вопрос. В состоянии 792 сценарный процесс 780 ожидает действительного ответа пользователя. Переходя в состояние 794, сценарный процесс 780 записывает ответ пользователя. В состоянии 796 сценарный процесс 780 идт к узлу, соответствующему ответу пользователя. Переходя в состояние 798 решения, процесс 780 сценария определяет, является ли следующий узел узлом выхода. Если нет, процесс 780 продолжается в состоянии 790 и предъявляет пользователю следующий вопрос. Сценарный процесс 780 зацикливается в состояниях 790-798 в соответствии с последовательностью заданных узлов сценария до тех пор, пока не достигнут узел выхода. Когда узел выхода достигнут, сценарный процесс 780 переходит к состоянию 800 решения для определения типа результата сценария. Основанный на ветвлении сценарий 802 может выдать диагноз в состоянии 802 выхода, совет в состоянии 804 выхода или отсылку к другому сценарию в состоянии 806 выхода.VI. Преимущества основанной на списках обработки Основанная на списках система обработки обеспечивает преимущества в скорости, точности и полноте над остальными способами медицинского диагностирования. В частности, основанная на списках обработка организует медицинские знания в списки,которые могут обрабатывать другие лица; представляет диагноз таким образом, что можно проверить его корректность и полноту; вырабатывает лучшие сценарии, чем может создать человек с помощью основанных на ветвлении сценариев; упрощает обновление сценариев при изменении медицинских знаний; обеспечивает тестирование автоматическими средствами; 43 может использоваться как вызываемая из основанных на ветвлении сценариев функция; не зависит от компьютерных платформы,среды и языка; позволяет легче переводить сценарии на другие естественные языки; отражает реальный способ врачебной диагностики. Приложение Пример основанного на списках сценария ЗСВ Данный листинг показывает более обширный пример файла в кодах ASCII, который содержит списки, используемые в качестве отправной точки для основанной на списках обработки. Этот список приводится только с целью показать форматы и соотношения. Он может не нести правильной или полной медицинской информации. Основная жалоба для данного примера сценария - недомогание.snottropics ftropics не был недавно в тропикахfptest не тестировался на наличие плазмодиевfptest тест на плазмодии негативный тест + на P. malariae тест + на смешанные плазмодии 1 приступ O-Т-П продолжительностью 1 день 1 приступ О-Т-П продолжительностью 2-3 дня 1 приступ O-Т-П неизвестной продолжительности 2 приступа О-Т-П с интервалом 48 ч 2 приступа O-Т-П с интервалом 72 ч 2 приступа О-Т-П, неизвестный интервал 3+ приступа О-Т-П каждые 48 ч 3+ приступа О-Т-П каждые 72 ч 3+ приступа О-Т-П,интервал неизвестен ступ Сколько времени прошло между этими двумя приступами На сколько отстояли друг от друга эти приступы У Вас температура У Вас была усталость или сонливость Какие плазмодии были обнаружены в крови Проходили ли Вы тест на плазмодии в крови У Вас потения Были ли Вы недавно в тропикахVIVAX 2-3 ДНЯ ТРИ+ 48 Ч 72 Ч НЕТ НИ ОДНОГО ОДИН ДРУГОЙ ДВА ДО ОДНОГО ДНЯ ДА У вас были ознобы, температура и потение Сколько приступов O-Т-П у Вас было У Вас были приступы OТ-П в таком порядке У вас ознобы Сколько длился 1 при ФОРМУЛА ИЗОБРЕТЕНИЯ 1. Автоматизированный способ диагностики, содержащий следующие шаги: ввод в компьютер списка заболеваний, каждое из которых связано со списком симптомов,а каждый упомянутый симптом связан со списком вопросов, причм упомянутые симптомы и вопросы могут быть различными для каждого заболевания; повторяющееся задание вопросов из числа выбранных из списков вопросов для получения ответов, при этом упомянутые ответы устанавливают симптомы, каждый из которых вносит сво значение в накопленное общее значение для каждого упомянутого заболевания; регулирование последовательности задания вопросов из выбранных упомянутых списков вопросов для обеспечения последовательности вопросов, характеризующих медицинское состояние пациента; и определение того, достигает или превышает упомянутое накопленное общее значение порогового значения, принятого для соответствующего заболевания, с учтом которого устанавливается диагноз. 2. Способ по п.1, в котором упомянутый симптом устанавливается на основании наличия или отсутствия одного или более других симптомов. 3. Способ по п.1, в котором наличие выбранного набора упомянутых симптомов прибавляет дополнительное значение к накопленному общему значению, по меньшей мере, одного из заболеваний. 4. Способ по п.1, в котором упомянутый симптом в первый выбранный момент диагностического процесса имеет иное значение, нежели тот же симптом во второй выбранный момент процесса. 5. Способ по п.1, в котором значение упомянутого симптома, сообщнного при первой степени тяжести, отличается от значения этого симптома, сообщнного при второй степени тяжести. 49 6. Способ по п.1, в котором выбранный набор упомянутых симптомов, появляющихся в определнной последовательности во времени,прибавляет к общему значению иное накопленное значение, нежели накопления индивидуальных значений выбранного набора симптомов, не появляющихся в определнной последовательности. 7. Способ по п.1, в котором последовательность начала или окончания выбранного набора упомянутых симптомов прибавляет к общему значению иное значение, нежели накопленные индивидуальные значения выбранных симптомов, взятых поодиночке. 8. Способ по п.1, в котором упомянутое заболевание принимается для дальнейшего диагностического исследования на основании накопленного упомянутого общего значения. 9. Способ по п.1, в котором упомянутое заболевание исключается из дальнейшего диагностического исследования на основании накопленного упомянутого общего значения. 10. Способ по п.1, в котором упомянутые вопросы по заболеваниям, считающимся неотложными, задаются раньше, чем вопросы по заболеваниям, не являющимися неотложными. 11. Способ по п.1, дополнительно содержащий шаг, определяющий меньше упомянутое накопленное общее значение для заболевания,чем установленное пороговое исключающее значение, чтобы исключить упомянутый возможный диагноз. 12. Способ по п.8, в котором устанавливается степень уверенности констатации определнного упомянутого заболевания. 13. Способ по п.9, в котором устанавливается степень уверенности исключения определнного упомянутого заболевания. 14. Способ по п.1, в котором множество упомянутых диагнозов накапливаются в дифференциальный диагностический список упомянутого конкретного пациента, при этом каждый упомянутый диагноз имеет свою степень уверенности. 15. Способ по п.1, в котором каждый упомянутый вопрос, заданный пациенту, вносит связанное с этим вопросом значение в упомянутое накопленное общее значение для, по меньшей мере, одного упомянутого заболевания. 16. Автоматизированный способ диагностики, содержащий следующие шаги: ввод в компьютер списка заболеваний, каждое из которых связано с первым списком симптомов, а каждый симптом связан с первым списком вопросов, причм упомянутые симптомы и вопросы могут быть различными для каждого упомянутого заболевания; повторяющееся задание упомянутых вопросов из числа выбранных из списков вопросов для получения ответов, при этом упомянутые ответы устанавливают симптомы, каждый упомянутый установленный симптом вносит 50 сво значение в упомянутое накопленное общее значение для упомянутого заболевания, при этом дальнейшие вопросы задаются повторно для получения ответов спустя заданный промежуток времени, причм список упомянутых вопросов и список упомянутых симптомов, спустя заданный промежуток времени, могут быть иными, нежели упомянутый первый список вопросов и упомянутый первый список симптомов; регулирование последовательности задания вопросов из упомянутых выбранных списков вопросов для обеспечения последовательности вопросов, характеризующих медицинское состояние пациента; и определение того, достигает или превышает упомянутое накопленное общее значение порогового значения, принятого для соответствующего заболевания, с учтом которого устанавливается диагноз. 17. Способ по п.16, в котором упомянутый симптом устанавливается на основании наличия или отсутствия одного или более других симптомов. 18. Способ по п.16, в котором наличие упомянутого выбранного набора симптомов прибавляет дополнительное значение к упомянутому накопленному общему значению, по меньшей мере, одного из заболеваний. 19. Способ по п.16, в котором упомянутый симптом в первый выбранный момент диагностического процесса имеет иное значение, нежели тот же симптом во второй выбранный момент процесса. 20. Способ по п.16, в котором значение упомянутого симптома, сообщнного при первой степени тяжести, отличается от значения этого симптома, сообщнного при второй степени тяжести. 21. Способ по п.16, в котором выбранный упомянутый набор симптомов, появляющихся в определнной последовательности во времени,прибавляет к упомянутому общему значению иное накопленное значение, нежели накопления индивидуальных значений выбранного набора симптомов, не появляющихся в определнной последовательности. 22. Способ по п.16, в котором упомянутая последовательность начала или окончания выбранного набора симптомов прибавляет к упомянутому общему значению иное значение, нежели накопленные индивидуальные значения выбранных симптомов, взятых поодиночке. 23. Способ по п.16, в котором упомянутое заболевание принимается для дальнейшего диагностического исследования на основании упомянутого накопленного общего значения. 24. Способ по п.16, в котором упомянутое заболевание исключается из дальнейшего диагностического исследования на основании упомянутого накопленного общего значения. 51 25. Способ по п.16, в котором упомянутые вопросы по заболеваниям, считающимся неотложными, задаются раньше, чем вопросы по заболеваниям, не являющимися неотложными. 26. Способ по п.16, дополнительно содержащий шаг, определяющий меньше упомянутое накопленное общее значение для заболевания,чем установленное пороговое исключающее значение, чтобы исключить упомянутый возможный диагноз. 27. Способ по п.23, в котором устанавливается степень уверенности констатации заболевания. 28. Способ по п.24, в котором устанавливается степень уверенности исключения заболевания. 29. Способ по п.16, в котором упомянутое множество диагнозов накапливаются в дифференциальный диагностический список упомянутого конкретного пациента, при этом каждый упомянутый диагноз имеет свою степень уверенности. 52 30. Способ по п.16, в котором каждый упомянутый вопрос, заданный пациенту, вносит связанное с этим вопросом значение в упомянутое накопленное общее значение, по меньшей мере, для одного упомянутого заболевания. 31. Способ по п.16, в котором заданный промежуток времени определяется врачом.' 32. Способ по п.31, в котором врач определяет упомянутый набор промежутков времени для конкретного заболевания, при этом любой упомянутый промежуток времени может иметь иную продолжительность, чем другие промежутки времени. 33. Способ по п.32, в котором для каждого упомянутого определнного промежутка времени компьютер сохраняет упомянутые списки симптомов и упомянутые списки вопросов для каждого симптома. 34. Способ по п.32, в котором упомянутые вопросы составляются так, чтобы отслеживать развитие заболевания во времени. Структуры программного обеспечения Фиг. 1 а Фиг. 2 Автономная выработка основанного на списках ЗСВ сценария 53 Списки ЗСВ на временной основе
МПК / Метки
МПК: G06F 19/00
Метки: автоматизированный, диагностики, способ, варианты
Код ссылки
<a href="https://eas.patents.su/28-1835-avtomatizirovannyjj-sposob-diagnostiki-varianty.html" rel="bookmark" title="База патентов Евразийского Союза">Автоматизированный способ диагностики (варианты)</a>
Способ диагностики обострения или ремиссии приобретенных иммунодефицитных и аутоиммунных заболеваний
Номер патента: 1115
Опубликовано: 30.10.2000
Авторы: Рубенс Юрис, Селезнев Юрий, Рощин Виктор
МПК: G01N 33/70, A61K 35/78
Метки: иммунодефицитных, ремиссии, приобретенных, способ, аутоиммунных, диагностики, заболеваний, обострения
Формула / Реферат:
Способ диагностики обострения или ремиссии приобретенных иммунодефицитных и аутоиммунных заболеваний, включающий определение содержания долихола в моче по клиренсу креатинина и диагностирование обострения заболевания при определении долихола более 15 мкг/ммоль, отличающийся тем, что, с целью повышения достоверности диагностики, вводят ежедневно в дозе не менее 0,5 мг/кг соединение "Ропрен", состоящее из 50 и более атомов углерода, имеющее...
Способ диагностики энергетического состояния организма человека
Номер патента: 1355
Опубликовано: 26.02.2001
Авторы: Соломатова Анна Викторовна, Соломатов Виктор Геннадьевич, Соломатова Галина Владимировна, Соломатова Мария Викторовна
МПК: A61H 39/04, A61B 10/00
Метки: диагностики, энергетического, организма, состояния, человека, способ
Формула / Реферат:
1. Способ диагностики энергетического состояния организма человека, включающий определение местонахождения рефлекторных точек и/или зон на поверхности тела известными способами рефлексодиагностики и последующую идентификацию значимых точек и/или зон рефлексотерапиии, отличающийся тем, что в качестве значимых идентифицируются точки и/или зоны рефлексотерапии с недостатком энергии, характеризуемые проявляемой реакцией после, по крайней мере,...
Способ в.г.соломатова диагностики энергетического состояния человека.
Номер патента: 825
Опубликовано: 24.04.2000
Автор: Соломатов Виктор Геннадьевич
МПК: A61H 23/00, A61B 10/00, A61B 5/00...
Метки: в.г.соломатова, способ, энергетического, человека, диагностики, состояния
Формула / Реферат:
Способ В.Г. Соломатова диагностики энергетического состояния человека, заключающийся в комфортном переплетении пальцев рук исследуемого; при этом положение вышележащего большого пальца указывает на избыток энергии в БАТ и зонах акупунктуры в одноименной половине тела относительно передне- и заднесрединных меридианов, ограниченной снизу условной плоскостью, проходящей через пупок и верхнюю границу ягодиц, ушной раковине, голени со ступней; в...
Способ диагностики и лечения больных хроническими заболеваниями.
Номер патента: 50
Опубликовано: 30.04.1998
Автор: Ким Людмила Александровна
МПК: A61H 23/00, A61B 5/00
Метки: лечения, диагностики, заболеваниями, больных, хроническими, способ
Формула / Реферат:
Способ лечения больных хроническими заболеваниями, предполагающий диагностику общепатологических нарушений путем осмотра внешних признаков болезни и акупрессурного обследования и последующую коррекцию выявленных нарушений, отличающийся тем, что осуществляют акупрессурное обследование системы кровообращения, внутренних органов и центральной нервной системы, а коррекцию общепатологических нарушений организма осуществляют акупрессурным воздействием...
Способ диагностики шизофрении, комплект из двух праймеров для осуществления способа и набор, включающий комплект праймеров
Номер патента: 1037
Опубликовано: 28.08.2000
Авторы: Мелони Роландо, Малле Жак, Лорен Клодин
МПК: C12Q 1/68, C07H 21/04, C12P 19/34...
Метки: осуществления, двух, диагностики, способа, праймеров, комплект, способ, включающий, шизофрении, набор
Формула / Реферат:
1. Способ диагностики шизофрении, отличающийся тем, что определяют in vitro наличие аллеля Ер микросателлитной ДНК HUMTHО1 в гене тирозингидроксилазы. 2. Способ по п.1, отличающийся тем, что определение аллеля Ер осуществляют путем секвенирования ДНК, и/или путем разделения фрагментов ДНК в геле, и/или путем разделения фрагментов ДНК в геле в неденатурирующих условиях. 3. Способ по п.2, отличающийся тем, что аллель Ер определяют путем...
Предыдущий патент: Способ гидроформилирования с применением многоступенчатых реакторов
Следующий патент: Способ лечения половых дисфункций
Случайный патент: Печь для приготовления пищи и обогрева