Автоматизований спосіб керування лікуванням (варіанти) та система керування лікуванням захворювань (варіанти) шляхом здійснення способів оптимізації лікування і медичної діагностики за допомогою вибору варіанті
Формула / Реферат
1. Автоматизований спосіб керування лікуванням, що містить оцінювання здоров'я пацієнта, що має захворювання, і оптимізацію лікування захворювання на підставі оцінювання здоров'я пацієнта, причому спосіб додатково містить крок призначення часу повторного відвідування для пацієнта.
2. Спосіб за п. 1, у якому час повторного відвідування є часом за регулярним розкладом.
3. Спосіб за п. 1, у якому час повторного відвідування відрізняється від часу за регулярним розкладом.
4. Спосіб за п. 1, у якому кроки виконують, повторюючи у часі.
5. Автоматизований спосіб керування лікуванням за допомогою кореляційної оцінки, що містить забезпечення суб'єктивного виміряння показників стану здоров'я в електронній медичній карті, що відповідає окремому пацієнту, забезпечення об'єктивного виміряння показників стану здоров'я в електронній медичній карті і розрахунок метрики на підставі суб'єктивного виміряння показників стану здоров'я й об'єктивного виміряння показників стану здоров'я.
6. Спосіб за п. 5, у якому кроки виконують, повторюючи у часі.
7. Спосіб за п. 6, у якому множину метрик аналізують статистично.
8. Спосіб за п. 6, що додатково містить регулювання лікування пацієнта на підставі метрики.
9. Спосіб за п. 7, у якому метрика є співвідношенням показників.
10. Автоматизований спосіб оцінювання критичної кривої для керування лікуванням, що містить забезпечення критичної кривої для конкретного захворювання, забезпечення множини показників стану здоров'я в електронній медичній карті, що відповідає конкретному пацієнту з конкретним захворюванням, і порівняння не менше ніж одного з показників стану здоров'я з критичної кривої для одержання інформації оцінювання показників стану здоров'я.
11. Спосіб за п. 10, у якому дають рекомендацію, якщо досягнутий поріг.
12. Спосіб за п. 10, у якому лікування захворювання регулюють, якщо досягнутий поріг.
13. Спосіб за п. 10, у якому показники стану здоров'я містять у собі об'єктивні параметри.
14. Спосіб за п. 10, у якому показники стану здоров'я містять у собі суб'єктивні параметри.
15. Система керування лікуванням захворювань, що містить модуль ведення захворювань, здатний автоматично забезпечувати оцінювання здоров'я і терапевтичну інформацію для пацієнта, що має захворювання, і базу даних по дозволах, що містить інформацію дозволів, що показує рівень доступу до оцінювання здоров'я і терапевтичної інформації.
16. Система за п. 15, у якій інформація дозволів відноситься до можливості доступу для певного агента, агентства або програмного об'єкта.
17. Система за п. 15, у якій інформація дозволів відноситься до можливості доступу на підставі юридичних норм.
18. Система за п. 15, у якій терапевтична інформація містить приписування лікування або регулювання лікування.
19. Автоматизована система медичних рекомендацій для керування лікуванням, що містить модуль медичних рекомендацій, здатний надавати медичну інформацію пацієнту, і рівень дозволу, зв'язаний із модулем медичних рекомендацій.
20. Система за п. 19, у якій рівень дозволу показує автономність модуля медичних рекомендацій при наданні медичної інформації пацієнту.
21. Система за п. 19, у якій рівень дозволу показує доступність медичної інформації, зв'язаної з модулем медичних рекомендацій.
22. Система за п. 19, у якій модуль медичних рекомендацій є діагностичним модулем.
23. Система за п. 19, у якій модуль медичних рекомендацій є модулем керування лікуванням захворювань.
24. Автоматизований спосіб оптимізації лікування, що містить визначення доступності об'єктивних показників стану здоров'я і суб'єктивних показників стану здоров'я для конкретного пацієнта з конкретним захворюванням, регулювання лікування для пацієнта на підставі доступних об'єктивних показників стану здоров'я або регулювання лікування для пацієнта на підставі недоступних об'єктивних показників стану здоров'я і доступних суб'єктивних показників стану здоров'я.
25. Спосіб за п. 24, який додатково містить збір об'єктивних показників стану здоров'я.
26. Спосіб за п. 24, який додатково містить збір суб’єктивних показників стану здоров'я.
27. Спосіб за п. 24, у якому суб’єктивні показники стану здоров’я містять показники стану побічних ефектів, що відносяться до лікування пацієнта.
28. Автоматизований спосіб вибору варіантів питань, що містить забезпечення множини груп питань, що стосуються оцінювання здоров’я пацієнта, причому кожна група зв’язана з лінгвістичним рівнем розуміння, ідентифікацію лінгвістичного рівня розуміння конкретного пацієнта, вибір однієї з груп питань на підставі ідентифікованого лінгвістичного рівня і задавання пацієнту питання з вибраної групи.
29. Спосіб за п. 28, що додатково містить відношення чутливості/вибірності на підставі ідентифікованого лінгвістичного рівня.
30. Автоматизований спосіб медичної діагностики, що містить кодування суб’єктивного відчуття болю пацієнтом у больовий код і індексування бази даних захворювань больовим кодом, завдяки чому діагностують захворювання.
31. Спосіб за п. 30, у якому больовий код містить підходи, що представляють збудника, якість, тяжкість, область і тривалість болю.
32. Автоматизований спосіб внесення терапевтичних змін, що містить забезпечення рівня дозволів терапевтичних змін, що відповідає конкретному пацієнту з конкретним захворюванням, автоматичне визначення регулювання лікування для пацієнта і рекомендацію регулювання лікування пацієнту, як дозволено рівнем дозволів терапевтичних змін.
33. Спосіб за п. 32, у якому регулювання лікування містить початок нового лікування.
34. Спосіб за п. 32, у якому регулювання лікування містить припинення поточного лікування.
35. Спосіб за п. 32, у якому регулювання лікування містить додавання нового лікування до поточного лікування.
36. Автоматизований спосіб встановлення режиму попереднього перегляду, що містить встановлення режиму попереднього перегляду для медичного сценарію, задавання питання щодо здоров’я пацієнта, дозвіл пацієнту одержати інформацію, що відноситься до наслідків відповіді на питання, і скидання медичного сценарію, так якби відповіді на питання не надійшло.
37. Автоматизований спосіб визначення відсутності відповіді, що містить зaбeзпeчeння множини параметрів, задавання вибраного питання з медичного сценарію, чекання протягом заданого часу відповіді на питання і виконання дії на підставі отриманих параметрів після того, як час чекання минув і відповіді не надійшло.
38. Спосіб за п. 37, у якому параметри містять у собі інформацію з історії хвороби пацієнта.
39. Автоматизований спосіб оцінювання здоров'я, що містить зіставлення будь-яких значимих симптомів хвороби конкретного пацієнта з конкретним захворюванням, одержання і зберігання початкових вимірів показників стану здоров'я пацієнта, якщо показники стану здоров'я пацієнта раніше не оцінювали, одержання і зберігання подальших вимірів показників стану здоров'я пацієнта, якщо показники стану здоров'я пацієнта раніше вже оцінювали.
40. Автоматизований спосіб визначення значущого симптому, що містить визначення тяжкості значущого симптому, отриманого від конкретного пацієнта з конкретним захворюванням, оцінювання показників стану здоров'я пацієнта, якщо рівень тяжкості досить низький і виконання заздалегідь заданої дії, якщо рівень тяжкості досить високий.
41. Спосіб за п. 40, у якому заздалегідь заданою дією є направлення до лікаря.
42. Спосіб за п. 40, у якому заздалегідь заданою дією є переведення у діагностичний процес.
43. Спосіб за п. 32, у якому визначення регулювання лікування обмежено рівнем дозволів терапевтичних змін.
Текст
Дійсний винахід у загальному випадку відноситься до систем медичних знань , а конкретніше, до систем автоматизованого довгострокового ведення захворювань пацієнта. Здоров'я - це основа, на якій ми проводимо наші життя. Медицина складається з діагностики і лікування. Діагностика означає знаходження причини проблеми пацієнта; лікування - це застосування найкращої доступної терапії. Однак не всі захворювання можуть цілком виліковуватися режимом лікування. Такі захворювання, як астма і діабет можуть вимагати регулярного графіка лікування, розписаної за часом терапії протягом життя пацієнта. У цьому випадку захворювання ведеться, а не лікується. Ведення захворювання може бути визначене як ведення пацієнта з відомим діагнозом із наміром забезпечити поінформованість пацієнта й слідкування для запобігання спалахів симптомів і загострень захворювання, щоб виключити дороге медичне втручання і сприяти гарному самопочуттю пацієнта. Терапевтична частина ведення захворювання повинна будуватися індивідуально відповідно до реакції конкретного пацієнта, оскільки захворілі пацієнти можуть по-різному реагувати на те саме лікування, наприклад, запропоновані дозування і препарати. Оскільки ведення захворювань створює для суспільства повторно виникаючі виграти, існує величезне бажання зменшити витрати. Варто зрозуміти, що таке система поголовної охорони здоров'я в граничному варіанті, щоб побачити, чому цієї мети варто домагатися. Захисники повністю поголовної системи говорять, що виграє кожний. У граничному варіанті ніхто ніколи не занедужає, і лікарям будуть платити за те, що вони ніколи не бачитимуть пацієнтів, оскільки ніяких пацієнтів не буде. У повністю поголовній системі кожна людина у світі платить заздалегідь задану суму на душу населення на місяць організаціям охорони здоров'я, єдиною метою яких є зберігання вашого здоров'я. Це прекрасна, але недосяжна мета Однак досяжною метою є автоматизація способу, яким ведуться захворювання Вся концепція ведення захворювання, доведена до крайності, полягає \ візуалізації лікаря, що невідступно спостерігає за пацієнтом 24 години на добу Звичайно, для значної більшості населення це неможливе рішення. Для зниження витрат знання лікаря повинні бути відкриті для суспільства, і один підхід може не вимагати фізичної присутності лікаря в місці розташування пацієнта. У медицині багато чого алгоритмично. Так, діагноз проходить послідовність кроків для відокремлення причини проблеми. Удосконалене кардіологічне життєзабезпечення (УКЖЗ) (ACLS) і удосконалене травматологічне життєзабезпечення (УТЖЗ) (ATLS) показали, наскільки може бути поліпшена охорона здоров'я шляхом прийняття стандартів. Деякі стандарти можуть бути переведені в медичні алгоритми, що можуть допомогти установити стандарт охорони здоров'я для терапевтів. Концепція медичного консультування по телефону була перевірена в національному масштабі токсикологічними центрами, а терапевти, зокрема, педіатри, займалися медичною практикою по телефону з тих пір, як він був винайдений. Дійсно, найпершими словами, сказаними по телефону, було кликання на допомогу, оскільки Олександер Грехем Белл пролив кислот) (для телефонних батарей), і сказав "Йдіть сюди, містер Уотсон, Ви мені потрібні", 7 березня 1876 р. Сьогоднішня так звана телемедицина залишається зв'язком один на один. Феномен телемедицини частково залежить від найкращих практичних рекомендацій, що допомагають зробити медичну практику змістовною. Ведення захворювання є не чим іншим, як перебудовою медичної практики Проблемою медицини була більшою частиною проблема інформації і систематизації цієї інформації. Внаслідок розвитку персонального комп'ютера ι стандартів тепер можна давати рекомендації по веденню захворювань. V минулому лікарі були як сховищем медичної інформації, так і тими, хто "систематизував" її, щоб вона мала клінічний зміст. Але тепер ці функції можуть виконуватися автоматично за допомогою "важеля" телекомунікацій і комп'ютерних те хнологій. Ведення захворювання може містити в собі координацію охорони здоров'я по всьому континуумі охорони здоров'я від народження до смерті. Ведення захворювання має програму, доступну для кожної частини життя будь-якої людини, у тому числі запобігання, діагностику, лікування і реабілітацію. Цей процес містить у собі ведення не тільки пацієнта з конкретним захворюванням, але ι здорового пацієнта. Дуже часто увага фокусується на забезпеченні інтенсивного і дорогого обслуговування для пацієнтів з загостреннями захворювання. Захисники ведення захворювань звертають більшу ува гу на превентивну всеосяжну охорону здоров'я для поліпшення здоров'я всієї популяції. У деякому змісті, ведення захворювань робить спробу передати медичну практик) -І рук терапевтів у р уки пацієнтів. Майже усі "засновані на знаннях" клінічні висновки можуть бути краще і з більшою надійністю виконані комп'ютерами. Техніка буде рушійною силою демократизації медицини. Система, що може автоматизувати медичну практик), особливо ведення захворювань, і яка заохочує й учить пацієнтів грати голови) роль у їхній медичній охороні здоров'я, найвищою мірою бажана. Така система повинна давати підтримуючу істотну і значну конкурентну перевагу на ринку поголовної охорони здоров'я. Така система повинна бути здатна автоматично ідентифікувати найкритичніші точки в процесі будь-якого захворювання, щоб утручання було максимально клінічним, економічним і гуманістичним. Розкриття винаходу Автоматизований спосіб ведення захворювання, що містить виймання із пам'яті медичної карти пацієнта, що відповідає конкретному пацієнту з відомим медичним захворюванням, оцінювання здоров'я пацієнта, що містить автоматичне опитування пацієнта, автоматичний приймання відповідей від пацієнта для одержання даних про здоров'я, автоматичне зберігання отриманих даних про здоров'я в медичній карті пацієнта, автоматичний вибір специфічного показника стану здоров'я, що відповідає частині медичної карти пацієнта, автоматичний розрахунок змін у стані здоров'я пацієнта, що відбулись із моменту попередніх сеансів ведення захворювання, як показує цей показник стану здоров'я, автоматичне порівняння цих змін у стані здоров'я зі специфічними змінами для даного медичного захворювання, і автоматичне виведення даних про регулювання терапії захворювання для конкретного пацієнта на основі отриманих даних про здоров'я і порівняння. Автоматизована система медичних рекомендацій, що містить модуль медичних рекомендацій, здатний автоматично надавати медичну інформацію конкретному пацієнту; і базу даних по дозволах, що містить інформацію дозволів, що вказує рівень доступності, дозволений для доступу до медичної інформації кожного з множини пацієнтів, причому ця інформація дозволів містить рівень дозволу для конкретного пацієнта. У однім виконанні дійсного винаходу поданий автоматизований спосіб ведення захворювання, що містить оцінювання здоров'я пацієнта з захворюванням; і оптимізацію терапії захворювання на основі цієї оцінки здоров'я пацієнта. У ще однім виконанні дійсного винаходу поданий автоматизований спосіб кореляційної оцінки, що містить: забезпечення суб'єктивного вимірення показників стану здоров'я в електронній медичній карті, що відповідає конкретному пацієнту; забезпечення об'єктивного вимірення показників стану здоров'я в електронній медичній карті; і розрахунок метрики на основі суб'єктивного вимірення показників стану здоров'я й об'єктивного вимірення показників стану здоров'я. У ще однім виконанні дійсного винаходу поданий автоматизований спосіб оцінки критичної кривої, що містить: побудову критичної кривої для конкретного захворювання; надання множини показників стану здоров'я в електронну медичну карту, що відповідає конкретному пацієнту з даним конкретним захворюванням; порівнювання щонайменше одного з показників стану здоров'я з критичної кривої для одержання інформації оцінки здоров'я. У ще однім виконанні дійсного винаходу подана система ведення захворювання, що містить: модуль ведення захворювання, здатний автоматично робити оцінювання здоров'я і давати інформацію про терапію для пацієнта з захворюванням; і базу даних по дозволах, що містить інформацію дозволів, що в казус рівень доступності, дозволений для доступу до інформації про оцінку здоров'я і терапії. У ще однім виконанні дійсного винаходу подана автоматизована система медичних рекомендацій, що містить модуль медичних рекомендацій, здатний давати пацієнту медичну інформацію; і рівень дозволу, зв'язаний із модулем медичних рекомендацій. У ще однім виконанні дійсного винаходу поданий автоматизований спосіб оптимізації лікування, що містить: визначення доступності об'єктивних вимірів показників стану здоров'я і суб'єктивних вимірів показників стану здоров'я для конкретного пацієнта з конкретним захворюванням; і регулювання лікування для цього пацієнта на основі доступних об'єктивних вимірів показників стану здоров'я; або регулювання лікування для цього пацієнта на основі недоступних об'єктивних вимірів показників стану здоров'я і доступних суб'єктивних вимірів показників стану здоров'я. У ще однім виконанні дійсного винаходу поданий автоматизований спосіб варіантів питань, що містить: надання множини груп питань, показових для оцінки здоров'я пацієнта, причому кожна група зв'язана з лінгвістичним рівнем розуміння; ідентифікацію лінгвістичного рівня розуміння конкретного пацієнта; вибір однієї з груп питань на основі ідентифікованого лінгвістичного рівня; і задавання пацієнту питання з обраної групи. У ще однім виконанні дійсного винаходу поданий автоматизований спосіб медичної діагностики, що містить: кодування суб'єктивного сприйняття болю пацієнтом у больовий код; і індексування бази даних захворювання за допомогою больового коду, завдяки чому діагностується захворювання. У ще однім виконанні дійсного винаходу поданий автоматизований спосіб терапевтичних змін, що містить: забезпечення рівня дозволу терапевтичних змін, що відповідає конкретному пацієнту з конкретним захворюванням; автоматичне визначення регулювання терапії для пацієнта, наскільки дозволяє рівень дозволу терапевтичних змін. У ще однім виконанні дійсного винаходу поданий автоматизований спосіб режиму попереднього перегляду, що містить; установлення режиму попереднього перегляду для медичного сценарію; задавання питання, зв'язаного зі здоров'ям пацієнта; дозвіл пацієнту одержати інформацію, зв'язаний із наслідками відповіді на питання; і скидання медичного сценарію, якщо на питання не було дано відповіді. У ще однім виконанні дійсного винаходу поданий автоматизований спосіб при відсутності відповіді, що містить: забезпечення множини показників стану; задавання обраного питання з медичного сценарію; чекання відповіді на питання протягом заданого часу; і виконання дій на основі цих показників стану після того, як заданий час минув при відсутності відповіді. У ще однім виконанні дійсного винаходу поданий автоматизований спосіб оцінювання здоров'я, що містить: зіставлення будь-яких значимих симптомів конкретного пацієнта з конкретним захворюванням; одержання і зберігання початкових вимірів показників стану здоров'я пацієнта, якщо пацієнт раніше не обстежувався; і одержання і зберігання наступних вимірів показників стану здоров'я пацієнта, якщо пацієнт раніше був обстежений. У останньому виконанні дійсного винаходу поданий автоматизований спосіб зіставлення значимого симптому, що містить: визначення тяжкості значимого симптому, отриманого від конкретного пацієнта з конкретним захворюванням; оцінювання здоров'я пацієнта, якщо рівень тяжкості занадто низький; і виконання заздалегідь заданої дії, якщо рівень тяжкості досить високий. Коротке описання креслень Фіг.1 є функціональною схемою автоматизованої системи медичного діагностування, лікування, ведення захворювання й інформації з дійсного винаходу. Фіг.2а є схемою конфігурації компонентів системи, показаної на фіг. 1. Фіг.2б є схемою конфігурації компонентів серверного комп'ютера, показаного на фіг 1 і 2а. Фіг.3 є функціональною схемою частини процесів і файлів бази даних, використовуваних системою на фіг.1. Фіг.4а, 4б, 4в і 4г є блок-схемою алгоритму' процесу верхнього рівня, виконуваного системою за фіг.1. Фіг.5 є блок-схемою алгоритму процесу Модуля ведення захворювання, показаного на фіг.4г і виконуваного системою за фіг.1. Фіг 6с блок-схемою алгоритму процесу Початку сеансу, показаного на фіг.5. Фіг.7 є блок-схемою алгоритму процесу Оцінювання здоров'я, показаного на фіг. 5. Фіг.8 є блок-схемою алгоритму процесу Зіставлення значимого симптому, показаного на фіг.7. Фіг.9 є блок-схемою алгоритму функції Оцінювання тяжкості, показаного на фіг. 8. Фіг.10 є блок-схемою алгоритму процесу Початкового оцінювання здоров'я, показаного на фіг.7. Фіг.11 є блок-схемою алгоритму процесу Поточного оцінювання здоров'я, показаного на фіг.7. Фіг.12 є блок-схемою алгоритму функції Оцінювання кореляції, показаного на фіг.11. Фіг.13 є блок-схемою алгоритму процесу Оцінювання критичної кривої, показаного на фіг.11. Фіг.14 є блок-схемою алгоритму процесу Оптимізації лікування, показаного на фіг.5. Фіг.15 є блок-схемою алгоритму процесу Регулювання лікування на основі суб'єктивних даних про здоров'я, показаного на фіг.14. Фіг.16 є блок-схемою алгоритму процесу Регулювання лікування на основі Об'єктивних Даних про Здоров'я, показаного на фіг. 14. Фіг 17 є блок-схемою алгоритму функції Рівня згоди пацієнта, показаного на фіг.15 і 16. Фіг.18 є блок-схемою алгоритму процесу Закінчення сеансу, показаного на фіг.5. Фіг.19а і 19б є блок-схемами алгоритму Ознаки варіантів питань, використовуваного процесом Модуля ведення захворювання, показаним на фіг.1 і 5. Фіг.20 є блок-схемою алгоритму Ознаки режиму попереднього перегляду, використовуваного процесом Модуля ведення захворювання, показаним на фіг.1 і 5. Фіг.21 є блок-схемою алгоритму Ознаки відсутності відповіді, використовуваного процесом Модуля ведення захворювання, показаним на фіг.1 і 5. Фіг.22а є блок-схемою алгоритму функції, використовуваної процесом Модуля ведення захворювання, показаним на фіг.4г і 5 і/або процесом Діагностики, показаним на фіг.4 г, при виробленні входу матриці PQRST (больового коду) для пацієнта. Фіг.22б є блок-схемою алгоритму функції, використовуваної процесом Діагностики, показаним на фіг.4г, при вимаганні діагнозу за допомогою входу матриці PQRST (больового коду), збереженого для пацієнта на фіг.22а. Фіг.23 є графіком приблизної критичної кривої, що окреслює вимірювання показників стану здоров'я з протягом часу для конкретного захворювання. Докладне описання кращого виконання Наступне докладне описання кращих виконань представляє описання деяких специфічних виконань, щоб допомогти зрозуміти формулу винаходу. Проте, дійсний винахід може бути реалізовано множиною різних способів, як це визначається і покривається формулою винаходу. Робиться посилання на креслення, на яких однакові цифрові позиції відносяться до однакових частин. Докладне описання розбите на такі розділи: Огляд системи Системні процеси і бази даних Хід системного процесу верхнього рівня Модуль ведення захворювання Початок сеансу Оцінювання здоров'я Зіставлення значимого симптому Оцінка тяжкості Початкове оцінювання здоров'я Поточне оцінювання здоров'я Оцінювання кореляції Оцінювання критичної кривої Оптимізація лікування Регулювання лікування (суб'єктивне) Регулювання лікування (об'єктивне) Рівень згоди пацієнта Закінчення сеансу Варіанти питань Ознака режиму попереднього перегляду Ознака відсутності відповіді Матриця PQRST Порядок ведення захворювання (ПВЗ) База даних по дозволах Організаційні дозволи Дозволи на спільне користування Дозволений рівень змін лікування (ДРЗЛ) Мета структури Мета функції Переваги ведення захворювання. Огляд системи За фіг.1 буде описана автоматизована, заснована на знаннях система 100 медичного ведення. Модуль ведення захворювань (МВЗ) 80 і декілька інших високорівневих обслуговуючих модулів 82 виконують автоматичне медичне обслуговування для користувачів системи 100 медичного ведення. Обслуговуючі модулі 82 можуть містити діагностику, таблицю лікування, автоматичне ведення запитів, аудіо/візуальну/образотворчу бібліотеку й авторський доступ. МВЗ 80 обробляє задачі, зв'язані з веденням захворювання (ВЗ); його головними цілями є сприяння гарному самопочуттю пацієнта, навчання пацієнтів і зменшення дорогих медичних утручань. Користувачем може бути пацієнт 114 або асистент пацієнта. У дійсному документі слова "користувач" і "пацієнт" використовуються взаємозамінно. Однак ясно, що користувач може діяти як представник пацієнта. Якщо це так, користувач реєстр ується як асистент пацієнта. Відповідні процеси реєстрації і входу, описані нижче, використовуються системою 100 як для пацієнта, так і для асистента. Модулі 80 і 82 підтримуються операційною системою і підтримуючим програмним забезпеченням 88, декількома базами даних 84 і обчислювальним середовищем 90 комп'ютерної апаратної платформи 110. Весь комп'ютерний апаратно-програмно-зв'язковий комплекс керується й обслуговується обслуговуючим персоналом. Всі додатки МВЗ 80 повністю автоматизовані Зовнішній контакт МВЗ із пацієнтами, терапевтами, клініками, аптеками, лабораторіями і т.д. (колективно позначені позицією 92) обслуговується автоматичними системами зв'язку за допомогою підхожих носіїв і методів обчислювального середовища 90, таких як інтерактивний мовний відгук (ІMB), прямий доступ від модема до модема або доступ через Інтернет 102. Для зв'язку з комп'ютерною платформою 110 системи пацієнт 114 використовує комп'ютер 116 і монітор 118, телефон 124 або інші компоненти, деякі з яких описані в зв'язку з фіг.2а нижче. За фіг.2а буде описана функціональна схема одного з виконань системи 100 медичного ведення. Система 100 містить мережу 102, що може являти собою локальну мережу (LAN), розширену територіальну мережу (WAN) або Інтернет, або іншу послугу зв'язку. Системні програми і бази даних можуть розташовуватися в групі серверів 108, що переважно зв'язані локальною мережею 106 і шлюзом 104 із мережею 102. Альтернативно системні програми і бази даних можуть знаходитися в однім сервері 110, що використовує апаратне і програмне забезпечення 112 мережного інтерфейсу. Системні сервери 108/110 зберігають модулі 80 і 82 (фіг.1). Мережа 102 може з'єднуватися з користувальним комп'ютером 116, приміром, за допомогою модему або мережної інтерфейсної карти. Користувач 114 може використовувати на комп'ютері 116 засіб 120 перегляду для доступ у до системних програм за допомогою клавіатури і/або вказівного пристрою і візуального дисплея, такого як монітор 118. Альтернативно засіб 120 перегляду не використовується, коли системні програми виконуються в комп'ютері 116 у локальному режимі. Відеокамера 122 може бути опційно з'єднана з комп'ютером 116 для забезпечення візуального введення, такого як візуальні симптоми або ознаки Крім того, відеокамера або окремий мікрофон (не показаний) можуть записувати клінічні звуки. Для зв'язку із системними серверами 108/110 можуть використовуватися різні піші пристрої. Якщо сервери обладнані апаратними засобами розпізнавання мови або тонального набору номера, користувач може зв'язуватися із системною програмою за допомогою телефону 124. Телефонне виконання описане в заявці дійсного заявника, озаглавленій "Автоматизована система медичної діагностики і рекомендацій по лікуванню", заявка США №08/176041, подана 29 грудня 1993 року, по якій виданий патент СЩА №5660176. Інші пристрої зв'язку для зв'язку із системними серверами 108/110 містять у собі переносний персональний комп'ютер із модемом або безпровідним інтерфейсом зв'язку, кабельний інтерфейсний пристрій 128, з'єднаний з візуальним дисплеєм 130, або супутникову антену 132, з'єднану із супутниковим приймачем 134 і телевізором 136. Можна представити й інші способи зв'язку між користувачем І 14 і системними серверами 108/110. На фіг.26 схема одного з виконань серверного комп'ютера 110 показує декілька можливих з'єднань із мережею. Для "програвання" сценарію використовується спеціальна програма, називана Ядро сценарію, що зчитує файл медичного діагностичного сценарію і використовує його коди для виконання дій інтерв'ю, таких як виведення питання пацієнту і уведення відповіді. Сценарії можуть також збирати відповіді пацієнта, оцінювати відповіді, ставити діагноз і модифікувати медичну карту пацієнта. Ядро сценарію може також знаходитися в користувальному комп'ютері 116 (фіг.2а). Ядро сценарію може зберігатися на жорсткому диску або на CD-ROM, і завантажується в основну пам'ять або в кеш-пам'ять для виконання. Компоненти кращого в дійсному винаході серверного комп'ютера ПО автоматизованої медичної системи 100 за дійсним винаходом показані на фіг.2б. Ссрверний комп'ютер 110 містить множину компонентів, показаних усередині пунктирного прямокутника. Телефонна лінія 156 з'єднує телефонну мережу 158 загального користування з комп'ютером 110 через модем 160. Телефонна мережа 158 може з'єднуватися з мережею 102, що має з'єднання із системним сервером (серверами) 108/110. Альтернативно комп'ютер і 10 може з'єднуватися з мережею 102 за допомогою мережної інтерфейсної карти 164. Апаратне забезпечення і системне програмне забезпечення зв'язані з двома основними концепціями: переносимість на інші операційні системи і використання стандартних промислових компонентів. Таким чином, система може бути більш гнучкою і забезпечить вільну ринкову конкуренцію з метою постійного поліпшення продукту, знижуючи в той самий час витрати. Хоча посилання може робитися на специфічне апаратне і програмне забезпечення, варто розуміти, що в дійсній системі може використовуватися множина різних компонентів. Комп'ютер 110 переважно є персональним комп'ютером π мікропроцесором 170 Intel Pentium. Можуть також використовуватися інші комп'ютери, такі як Apple Macintosh, Amiga, Digital Equipment Corporation VAX або універсальний комп'ютер IBM. Модем 160 або мережна інтерфейсна карта 164 приєднується до шини 162 стандартної промислової архітектури (ISA) або з'єднання периферійних компонентів (PCL). Шипа 162 з'єднує мікропроцесор 170 із множиною периферійних пристроїв через контролерні схеми (мікросхеми або плати). Комп'ютерна шина 162 має множину периферійних пристроїв, з'єднаних із нею через адаптери або контролери. Плата 172 відеоадаптера, переважно SVGA або кращого розрішення, з'єднується з відеомонітором 118. Послідовна схема 176 зв'язку взаємодіє з вказівним пристроєм, таким як миша 178. У іншому виконанні замість схеми 176 може використовуватися паралельна схема зв'язку. Схема 180 контролера клавіатури взаємодіє з клавіатурою 182. Дисковод !84 жорсткого диска ємністю 500Мбайт або більше і, опційно, дисковод 186 CD-ROM переважно з'єднані із шиною 162. Жорсткий диск 184 зберігає файли баз даних, такі як файли пацієнта, файли ВЗ, інші системні файли і бінарні файли підтримки. CD ROM 186 також зберігає файли баз даних і бінарні файли підтримки. Основна пам'ять 190 з'єднується з мікропроцесором 170. У однім виконанні комп'ютер 110 працює в операційній системі 92 Windows 95. Пам'ять 190 виконує ядро діагностичного сценарію (не показаний) і процес 220 модуля ведення захворювання (МВЗ). Частини програмного забезпечення процесу модуля контролювання захворювання можуть бути написані на Borland Delphi Pascal версії 2, а інші частини можуть бути написані на Microsoft С версії 7.0. Крім того, в однім із виконань база даних реалізована на Microsoft Foxpro або іншій програмі баз даних, такій як SQL-сумісні програми реляційних баз даних. Системні процеси і бази даних За фіг.3 буде описана частина процесів, файлів і баз даних, використовуваних системою 100 медичного ведення. За винятком процесу МВЗ, бази даних по дозволах, бази даних засобів візуалізації, бази даних лабораторних тестів, бази даних захворювань і інших специфічних баз даних ВЗ, що описані нижче, ці процеси, файли і бази даних були описані в патенті дійсного заявника, озаглавленому "Автоматизована система медичної діагностики і рекомендацій по лікуванню", патент США №5660176. Система 100 медичного ведення використовує декілька основних процесів і зв'язаних із ними баз даних. Набір процесів 200, 210 і 212 входу в систему пацієнта/асистента використовується системою 100 для ідентифікації раніше зареєстрованого системою пацієнта одним із трьох способів: 1) шляхом запитування ідентифікаційного номера пацієнта (ІНП) у процесі 200; 2) ідентифікація асистента, що раніше зареєструвався в системі, шляхом запитування ідентифікаційного номера асистента (ІНА) у процесі 210; або 3) ідентифікація пацієнта, що має асистента, що був раніше зареєстрований у системі, шляхом, запитування ідентифікаційного номера пацієнта в процесі 212. Один із процесів 202, 214 або 216 використовується для реєстрації пацієнта або асистента. Якщо користувач є пацієнтом, системою використовується процес реєстрації пацієнта для реєстрації нових або пацієнтів, що вперше звернулися, у процесі 200. Якщо користувач не є пацієнтом, система використовує процес реєстрації асистента для реєстрації нових або асистентів, що вперше звернулися, у процесі 214. Потім, якщо пацієнт ще не зареєстрований, система використовує процес реєстрації пацієнта, що асистується, для реєстрації пацієнта в процесі 216. Коли користувач ввійшов у систему або зареєструвався, система забезпечує вибір процесів. Первинним процесом у поточному виконанні є процес 220 МВЗ, що веде захворювання або стан пацієнта. Процес 220 МВЗ може звертатися до лабораторних тестів у вибірковій базі 260 даних або до засобів візуалізації у вибірковій базі 258 даних у ході ведення захворювання, і до таблиці 250 лікування для одержання інформації про поточне лікування для конкретного захворювання або діагнозу. З цими процесами зв'язана база 240 даних запису пацієнтів і асистентів, база 242 даних історії консультування, база 244 даних відповідей пацієнта, база 246 даних об'єктів медичної історії, база 248 даних медикаментозного лікування пацієнта, база 252 даних ситуацій, що підлягають розгляду, і база 254 даних медичної історії пацієнта. Ці бази даних містять електронну медичну карту для кожного пацієнта, зареєстрованого в медичній системі 100. Електронна медична карта містить всю інформацію про кожного пацієнта. База 256 даних по дозволах, база 262 даних захворювань і інші специфічні бази 264 даних ВЗ будуть описані нижче. У іншому виконанні додані інші можливості для доступу до інших інформаційних процесів. Хід процесу вер хнього рівня системи За фіг.4а, 4б, 4в і 4г буде описаний процес 300 верхнього рівня програмного забезпечення системи медичного ведення. Номер телефону, використовуваного для доступ у в систему 100 по телефону, може варіюватися в різних виконаннях системи. Якщо спонсуюче агентство або лікарня хочуть забезпечити доступ абонента до системи 100 медичного ведення безкоштовно, то може використовуватися безкоштовний номер служби (наприклад, 800, 888 або іншими номер). Якщо спонсуюче агентство або лікарня хочуть відшкодувати витрати на роботу системи 100 за рахунок того, хто дзвонить, вони можуть використовува ти номер з оплатою за дзвоник або номер з оплатою за пільговим тарифом (наприклад, службу 900). Для описання і виставляння рахунку третім особам-платникам за телефонні консультації існують коди "Поточної процедурної термінології" (СРТ-4). Вони є списком термінів і ідентифікаційних кодів для позначення медичних послуг і процедур. Коди СРТ-4 є найбільше загальноприйнятою номенклатурою для оповіщення страхових компаній про лікарські послуги. Якщо доступ у систему 100 забезпечується через Інтернет або іншу мережу, користувачу повідомляється відповідна мережна адреса (або адреси). Починаючи зі стартової операції 302, користувач 114 (фіг.1), що бажає одержати медичні рекомендації, набирає телефонний номер системи 100 на телефоні 124 (фіг.2а). Користувачем може бути пацієнт або "асистент", наприклад, батько, родич або друг, що допомагає пацієнту. Альтернативно, користувач може здійснювати доступ у систему 100 через користувальний комп'ютер 116, наприклад, через Інтернет, як було описано раніше. У операції 304 система 100 автоматично відповідає на дзвоник і вітає того, що дзвонить 114 вступним привітальним повідомленням шляхом відтворення мовного файла, що зберігається на жорсткому диску системи за допомогою плати обробки мови, такої як D/41D фірми Dialogic. Альтернативно, якщо користувач використовує засіб 120 перегляду (фіг.2а) або іншій користувальний .інтерфейс в Інтернеті 102, привітальне повідомлення відображається користувачу на візуальному дисплеї 118. Таким чином, система 100 зв'язується з користувачем 114 або по телефону, або шляхом відображення повідомлень на візуальному дисплеї. Наступні кроки в покрокових схемах процесів або функцій будуть описувати тільки одну форму зв'язку користувача з метою короткості. Переходячи до операції 306, система 100 задає кожному пацієнту, що дзвонить у систему, ряд "початкових відсіюючих питань". Ці питання складені для ідентифікації пацієнтів, що знаходяться в критичному стані: вони складені не для ідентифікації проблеми пацієнта. Початкові відсіюючі питання дозволяють системі відфільтровувати пацієнтів, що вимагають негайної медичної уваги. У операції 308 перевірки умови кожний пацієнт, стан якого знайдено критичним, інструктується набрати телефонний номер служби порятунку „911” в операції 309 або буде автоматично з'єднаний із найближчою службою швидкої допомоги в районі проживання пацієнта. Сеанс зв'язку завершується процесом 300 в операції 310. Наступні питання є прикладами початкових відсіюючи х питань: - Чи носить небезпека медичний характер? - У Вас утр уднене дихання? - Чи відчуваєте Ви сильний біль або тиск у гр удях? Якщо система визначає, що пацієнт знаходиться в медично небезпечному стані, вона може видати пацієнту меню термінових медичних процедур в операції 311 У ситуаціях, коли пацієнт або той, хто дзвонить від пацієнта, знаходиться далеко від найближчої служби швидкої допомоги, наприклад, у сільській місцевості, користувач може потребувати термінових процедур. Меню термінових медичних процедур дає користувачу декілька можливостей. Якщо користувач натискає клавішу "1" тонального набору або вимовляє слово "один" у телефонну тр убку, процес 300 відгалужується до операції 312, у якій викладається загальновідома інформація про реанімацію (непрямий масаж серця і вентиляція легень). Якщо користувач використовує наявну в телефоні 124 можливість голосного зв'язку, користувач може чути і виконувати інструкції, що даються системою 100, із вільними руками і знаходячись на відстані від телефону. Якщо той, що дзвонить натискає клавішу „2” тонального набору або вимовляє слово "два" у тр убку, процес 300 відгалужується до операції 313, у якій викладається загальновідома інформація Heimlich Hug для випадку ядухи. По завершенні операції 312 або операції 313 сеанс зв'язку закінчується в операції 314. Якщо в операції 308 визначено, що пацієнт не знаходиться в медичній небезпеці, тобто система 100 переконалася, що не існує безпосередньо загрози для життя, процес 300 переходить до операції 315 перевірки умови, щоб визначити, чи є користувач дійсним пацієнтом. Якщо так, то процес 300 переходить до операції З 16 перевірки умови, визначаючи, чи був пацієнт раніше зареєстрований або коли консультувався за допомогою системи 100, тобто не є тим, хто звернувся вперше. Якщо це так, то система 100 перевіряє ідентифікацію пацієнта і вимагає його медичну карту в процесі 200 входу пацієнта в систему. По завершенні процесу 200 процес 300 переходить через міжсторінковий з'єднувач С 317 до операції 344 (фіг.4г). Якщо пацієнт не зареєстрований, що визначається в операції 316 перевірки умови, система 100 переходить до процесу 202 реєстрації пацієнта для нового пацієнта. По завершенні процесу 202 процес 300 переходить через міжсторінковий з'єднувач С317 до операції 344 фіг.4г. Якщо користувач не є пацієнтом, що визначається в операції 315, процес 300 переходить через міжсторінковий з'єднувач А318 до операції 320 перевірки умови фіг.4б. Будуть виникати моменти, коли пацієнт може бути не в змозі використовувати систему 100 прямо, наприклад, через поранення, слабкість або рівень розуміння, що змінився. У цих випадках за дорученням пацієнта із системою може спілкуватися "асистент". Асистент реєструється в системі за допомогою процесу 214 реєстрації пацієнта. Реєстраційний запис асистента ідентичний за структурою реєстраційного запису пацієнта, але три поля мають особливе значення для пацієнта: ASST_PERM, ASST_EXP і RELATIONS. Поле ASST_PERM є логічною ознакою, що може бути встановленою у значення "істина" тільки автономно системним перевіряючим адміністратором за допомогою окремого засобу, що між пацієнтом і асистентом існує зв'язок. Зв'язки є відношеннями типу один до багатьох, тобто пацієнт може мати одного або декількох асистентів, а асистент може бути зв'язаний більш ніж з одним пацієнтом. Ознака ASST_PERM може бути обмежена полем ASST_EXP, що містить тимчасову відмітку терміну закінчення дії атрибута ASST_PERM. Якщо ознака PERM має значення "істина", то покажчики RELATIONS вкажуть на одну або декілька карт пацієнтів, для котрих цей асистент є "постійним асистентом"; у противному випадку поле RELATIONS буде порожнім. Медична інформація, зібрана в ході консультації за допомогою асистента, записується в медичну карту пацієнта, якщо дотримані наступні три умови: (а) ознака ASST_PERM асистента має значення "істина", (б) час ASST_PERM не наступив, (в) асистент має покажчик зв'язку на карту пацієнта. Якщо якесь з цих умов не виконується, то будь-яка нова медична інформація, зібрана про даного пацієнта, буде збережена у файлі 252 ситуацій, що підлягають розгляду, для автономної перевірки системним адміністратором. Система 100 встановлює в операції 315, чи є користувач пацієнтом або асистентом. Якщо користувач не є пацієнтом, то система робить висновок, що користувач є асистентом і в операції 320 перевірки умови визначає, чи зареєстрований асистент. Якщо асистент ще не зареєстрований у системі, система вводить асистента в процес 214 реєстрації асистента. Якщо асистент уже зареєстрований у системі 100, процес 300 виконує процес 210 входу асистента в систему. По завершенні процесу 214 або процесу 210 процес 300. просувається до операції 321 перевірки умови. Якщо пацієнт ще не зареєстрований у системі 100, як визначено в операції 321 перевірки умови, система дозволяє асистенту зареєструвати нового пацієнта в процесі 216 . реєстрації пацієнта, що асистується. Однак, якщо пацієнт уже зареєстрований у системі 100, як визначено в операції 321, процес 300 виконує процес 212 входу пацієнта, що асистується, в систему. По завершенні процесу 216 або процесу 212 процес 300 переходить через міжсторінковий з'єднувач В 327 до операції 334 перевірки умови фіг.4в. У операції 334 перевірки умови процес 300 визначає, чи присутня в медичній карті пацієнта дата народження пацієнта. Якщо так, те процес 300 переходить через міжсторінковий з'єднувач С 317 до операції 344 фіг.4 г. Якщо ні, система 100 намагається одержати дату народження пацієнта. Переходячи до операції 335, система 100 питає асистента, чи відома дата народження пацієнта. Якщо так, те процес 300 переходить до операції 336, запитуючи дату народження пацієнта. У операції 337 система 100 повідомляє дату народження пацієнта, отриману в операції 336. У операції 338 перевірки умови асистент визначає, чи правильно система 100 назвала дату народження пацієнта. Якщо ні, процес 300 повертається до операції 336, щоб наново запросити дату народження пацієнта. Якщо дата народження пацієнта названа правильно, як визначено в операції 338, процес 300 відзначає дату народження для зберігання в медичній карті пацієнта в операції 339 і переходить до операції 334 фіг.4г. Якщо дата народження пацієнта невідома, як визначено в операції 335, процес 300 переходить до операції 340, у якій система просить асистента зазначити приблизний вік пацієнта. Вік є важливим показником стану, використовуваним процесом 220 МВЗ, діагностичним модулем і таблицею 250 лікування. У операції 341 система повторює отриманий в операції 340 приблизний вік пацієнта. У операції 342 перевірки умови асистент визначає, чи правильно система 100 назвала вік. Якщо ні, процес 300 повертається до операції 340, щоб повторно запросити приблизний вік пацієнта. Якщо приблизний вік пацієнта названий правильно, як визначено в операції 342, система 100 радить асистенту в операції 343 узнати дату народження пацієнта до наступної консультації, і переходить до операції 344 фіг.4г. Система 100 використовує приблизний вік у сеансі зв'язку в діагностичному модулі і таблиці 250 лікування. У операції 344 фіг.4г система 100 дає користувачу меню вибору системи. Тут того, що дзвонить, просять вибрати із шести варіантів: діагностична система, таблиця лікування, ведення захворювання, аудіо/візуально/образотворча бібліотека, автоматичне ведення запиту або закінчення сеансу зв'язку, як описано нижче: А Діагностична система: Система починає процес 280 оцінювання в меню, де просить пацієнта почати ідентифікацію скарги. Б. Таблиця лікування: Система вводить пацієнта в процес 250 таблиці лікування в меню, де просить пацієнта вибрати спосіб вибору лікування. В. Ведення захворювання: Система починає процес 220 МВЗ, у якому вона спочатку визначає, чи використовував пацієнт раніше Модуль ведення захворювання. Цей процес докладно описаний нижче. Г. Аудіо/віз уальна/образотворча бібліотека: Система починає процес 282 Аудіо/візуальної/образотворчої бібліотеки, що дозволяє пацієнту чути медичні звуки, дивитись медичні відеозаписи або фотографії й інші зображення. Д. Автоматичне ведення запиту: Система починає процес 284 Автоматичного ведення запиту, щоб допомогти пацієнту визначити, чи варто сходити до лікаря, і якщо варто, то до яких лікарів і коли. Е. Кінець сеансу зв'язку: Система виконує декілька кроків, а потім перериває сеанс зв'язку. У точці виходу з процесу 280 оцінювання система 100 пропонує пацієнту опцію вибору іншої скарги. Наприкінці процесу 250 таблиці лікування система пропонує пацієнту опцію вибору іншого лікування. Наприкінці процесу 282 аудіо/візуальної/образотворчої бібліотеки система 100 пропонує пацієнту опцію вибору іншого аудіозапису, відео або зображення. Наприкінці процесу 284 автоматичного ведення запиту система 100 пропонує пацієнту опцію одержання рекомендації з іншої проблеми. По завершенні процесу 280 оцінювання, процесу 250 таблиці лікування, процесу 220 Модуля ведення захворювання, процесу 282 аудіо/візуальної/образотворчої бібліотеки або процесу 284 автоматизованого ведення запиту система 100 повертається до операції 344 і знову видає користувачу меню вибору системи. Якщо в операції 344 користувач вибирає Кінець сеансу зв'язку, система 100 переходить в операцію 345 перевірки умови. У операції 345 перевірки умови система 100 визначає, чи не відбувалися процес 280, процес 250, процес 200 або процес 284 в інформаційному режимі, тобто або в реальному режимі, або в режимі Розгляду, і вивчає таблицю символів, зв'язану з даним пацієнтом, щоб визначити, чи є які-небудь із перемінних пам'яті обставинами медичної історії, що потрібно зберегти у файлі медичної історії пацієнта. Якщо в операції 345 перевірки умови обидві умови істинні, система 100 переходить до операції 346 перевірки умови, визначаючи, чи проводилась консультація в реальному режимі. Якщо ні, то консультація проводилася в режимі розгляду, і система 100 потім в операції 347 записує будь-яку нову інформацію про пацієнта, отриману в ході консультації, у файл 252 потребуючих розгляду си туацій. Якщо в операції 346 умова виконується, тобто консультація проводилася в реальному режимі, то для кожної минулої медичної умови, що варто зберегти, система 100 просить пацієнта в операції 348 дати дозвіл на зберігання даних у файл медичної історії пацієнта і підтвердити, що ці дані вірні. Наприклад, у ході консультації з приводу кашлю система 100 могла з'ясувати, що пацієнту був поставлений діагноз позитивної ВІЛ-реакції. Система 100 запитає: "Можу я записати інформацію про ваш ВІЛ-діагноз у вашу медичну карту?". Якщо пацієнт відповідає "Так", то система 100 запитає: "Підтвердіть, будь ласка, що ваша ВІЛ-реакція була позитивною". Якщо пацієнт відповідає "Так", то система 100 пише діагноз і бал, що показує точність системи, у файл медичної історії пацієнта. Після підтвердження, кожна одиниця даних зберігається у файлі пацієнта в базі даних 254 медичної історії пацієнта (фіг.3). По завершенні обновлення бази даних 254 медичної історії пацієнта в операції 348, або якщо умова в операції 345 хибна, або по завершенні операції 347, процес 300 переходить до операції 349 перевірки умови. Перед тим, як система 100 закінчить консультування пацієнта, вона представляє зведення усіх виданих рекомендацій. У телефонному сеансі зв'язку пацієнта просять записати і повторити ключові моменти. Потім система 100 пропонує пацієнту можливість одержання зведення про консультаційний сеанс зв'язку і конкретні рекомендації системи по факсу, електронній пошті, або поштою, такою як поштові послуги першого класу. Якщо бажаний факс або електронна пошта, процес 300 переходить до операції 350 перевірки умови, визначаючи, чи доступна системі інформація, необхідна для відправлення зведення і рекомендацій. Якщо ні, процес 300 питає інформацію в пацієнта, наприклад, номер факсу, адресу електронної пошти або поштову адресу, в операції 352. Пацієнт має також можливість послати результати консультації своїй установі охорони здоров'я або фахівцю. У операції 351 процес 300 добавляє запис поточного телефонного сеансу зв'язку в чергу до факсу або електронної пошти, за бажанням, для наступної передачі. По завершенні операції 351 або якщо в операції 349 процес 300 визначає, що запис сеансу зв'язку посилати не потрібно, сеанс зв'язку переривається в операції 353. Огляд ведення захворювання Дійсний винахід містить комп'ютерну програму, називану Модулем ведення захворювання (МВЗ). Модуль ведення захворювання є одним із декількох високорівневих модулів обслуговування, що виконують автоматизоване медичне обслуговування для користувачів системи 100 медичного ведення. У цьому контексті ведення захворювання (ВЗ) означає тривале медичне обслуговування пацієнта, якому поставлений діагноз, зв'язаний із конкретною проблемою здоров'я, називаною захворюванням. МВЗ може продовжувати обслуговування протягом усього життя пацієнта. МВЗ виконує ведення захворювання цілком автоматично, використовуючи періодичні інтерактивні діалоги з пацієнтом для одержання від пацієнта вимірів показників стану здоров'я, для оцінювання прогресу захворювання пацієнта, для перегляду і регулювання терапії до оптимальних рівнів і для постачання пацієнта медичними рекомендаціями по веденню захворювання і діям під час спалахів симптомів і загостренні захворювання. Метою модуля ведення захворювання є сприяння здоров'ю пацієнта автоматичним способом, що знижує дороге медичне втр учання. Різні характеристики програмного забезпечення МВЗ спеціально розробляються для збору і використання специфічної для пацієнта інформації, так що ведення захворювання може бути в більшому ступені прилаштовано для кожного окремого випадку. Коли модуль веде в часі даного пацієнта, він будує профіль цього випадку у вигляді частоти і причин для контактів пацієнта з МВЗ, суб'єктивне розуміння захворювання пацієнтом, об'єктивну реакцію пацієнта на різні медичні впливи і те, чому віддає переваги пацієнт в лікувальному плані. Потім модуль використовує ці знання для настроювання своїх внутрішніх процедур так, щоб вони в більшому ступені були адаптовані до конкретного пацієнта. Коли пацієнт уперше звертається до ВЗ, МВЗ запускає процедуру реєстрації, що перевіряє медичну історію пацієнта, ініціює початкову терапію для захворювання пацієнта і встановлює розклад контактів із пацієнтом. Для кожного зареєстрованого пацієнта ВЗ МВЗ проводить періодичні автоматичні сеанси зв'язку з пацієнтом. У ході кожного сеансу зв'язку МВЗ одержує й обновляє медичну історію пацієнта останніми вимірами показників стану здоров'я, при необхідності аналізує й оцінює здоров'я пацієнта, при необхідності регулює терапію і дає пацієнту підхожі медичні рекомендації. Наприкінці кожного сеансу зв'язку МВЗ призначає час наступного сеансу зв'язку. Зрештою, МВЗ анулює пацієнта шляхом -переводу його зі стану ведення захворювання в інший стан, такий, як медобслуговування лікарем (людиною), обслуговування діагностичним модулем медичної системи, або в нормальний здоровий стан з регулярними перевірками здоров'я. Тут модуль МВЗ розглядається в термінах своїх загальних ознак, щоб привести ці ознаки в загальний контекст. Кожна ознака буде додатково описана нижче. При усіх своїх контактах із пацієнтами МВЗ повинний гарантува ти, що він відповідає величезному числу дозволів, згод і санкцій, що видаються численними агентами й агентствами. МВЗ використовує базу даних по. дозволах для керування цими даними. Для проведення оперативних інтерактивних діалогів із пацієнтами (або їхніми агентами) МВЗ використовує сценарії. Сценарії є спеціальними комп'ютерними програмами, здатними видавати пацієнту текст і питання, очікувати відповіді пацієнта, записувати відповідь і починати подальші дії на підставі цієї відповіді. Розробка і використання сценаріїв були описані в заявках РСТ із пріоритетом заявки США №08/893402, поданої 11 липня 1997р. і озаглавленої "Автоматизована система медичної діагностики і рекомендацій по лікуванню, що містить обробку на підставі списків", і заявки США №08/893912, поданої 11 липня 1997 р. і озаглавленої "Автоматизована система медичної діагностики і рекомендацій по лікуванню, що містить доступ до мережі". Звичайний оперативний діалог із пацієнтом має форму послідовності, що задається сценарієм питань і відповідей пацієнта. У ході виконання сценарію він розглядає поточний статус пацієнта, вибирає питання і ставить запитання пацієнту. Пацієнт відповідає, сценарій аналізує відповідь, вибирає ще одне питання і так далі доти, поки сеанс зв'язку не переривається звичайним способом. Режим попереднього перегляду сценарію для МВЗ дозволяє пацієнту відповідати на запитання в режимі "прогнозування", бачачи, що буде наслідком даної відповіді, не обираючи відповідь формально. Незвичайні завершення сценарію можуть оброблятися МВЗ розумним проактивним способом · "за допомогою функції Відсутності відповіді. Якщо пацієнт раптом не відповідає в середині діалогу, ця функція може використовувати усе, що відомо про пацієнта — месцезнаходження пацієнта і контрольоване захворювання, щоб негайно прореагувати, у тому числі, якщо необхідно, зв'язавшись із найближчою до пацієнта станцією швидкої допомоги або викликавши до пацієнта службу порятунку за теле фоном 911. МВЗ виконує усі свої контакти з пацієнтами у формі сеансів зв'язку Ведення захворювання, що регулярно призначаються оперативними діалогами з пацієнтом. Сеанс зв'язку ВЗ може ініціюватись або пацієнтом, що дзвонить у медичну систему (вхідний дзвоник), або системою, що дзвонить пацієнту (вихідний дзвоник). Кожний сеанс зв'язку ВЗ складається з чотирьох основних задач, виконуваних у такій послідовності: Відкриття сеансу зв'язку, Оцінювання здоров'я, Оптимізація лікування і Закриття сеансу зв'язку. Відкриття сеансу зв'язку ініціалізує дані і реєструє пацієнтів. Ця задача використовує історію здоров'я пацієнта і відоме захворювання для встановлення показника стану оцінювання здоров'я, що варто виміряти і простежити, у тому числі відповідні пороги, межі, діапазони і критичні значення. Вона також постачає пацієнта інструкціями щодо того, як спостерігати симптоми, виконувати вимірювання показників стану здоров'я, оцінювати своє здоров'я і розглядати тенденції розвитку свого захворювання. Задача Оцінювання здоров'я одержує від пацієнта вимірювання показників стану здоров'я за інтервал часу, починаючи з минулого сеансу зв'язку, кодує описання симптомів за допомогою Матриці PQRST і розраховує різні релевантні оцінки, графіки і тенденції здоров'я. Вона аналізує стан здоров'я за допомогою функції Оцінювання кореляції і функції Оцінювання критичної кривої. Функція Оцінювання кореляції використовує суб'єктивно-об'єктивний коефіцієнт кореляції (СОКК), статистичну міру того, наскільки добре даний пацієнт може оцінювати своє власне захворювання і його розвиток, для оцінювання здоров'я пацієнта на підставі суб'єктивних даних. Ма триця PQRST є кодуючою схемою, що використовується для переводу суб'єктивних описань больових синдромів у широкий оцифрований больовий код МВЗ. Критична крива є тимчасовим графіком визначених показників стану здоров'я, що МВЗ може порівнювати зі стандартними критичними кривими для виявлення або пророкування швидкого погіршення здоров'я пацієнта. Нарешті, задача Оцінювання здоров'я вирішує, яку дію почати стосовно пацієнта, як наприклад, відіслати пацієнта із системи для звертання до "людської" медичної допомоги; або відіслати до процесу діагностичного модуля для діагностування нового симптому; або перейти до наступної задачі для визначення наступного кроку терапії для пацієнта. Третьою задачею сеансу зв'язку ВЗ є Оптимізація лікування, основна мета якої полягає в регулюванні крок за кроком терапії, балансуючи між ризиками і вигодами, максимізуючи ефективність і мінімізуючи небажані побічні ефекти, і, через довгий час, приводить до оптимальної для даного пацієнта терапії. Ця задача вибирає одну з декількох можливих терапій із таблиці лікування, регулює дозування з маленьким кроком під керуванням функції Рівня згоди пацієнта, представляє пацієнту ризики і вигоди і дозволяє пацієнту приймати або відхиляти рекомендації. Якщо пацієнт відмовляється, задача розраховує кращу з терапій, що залишилися, і так доти, поки не досягне межі, що зберігається в базі даних по дозволах. У ході всієї цієї роботи задача консультується з Дозволеним рівнем змін лікування (ДРЗЛ), щоб визначити, які права по автоматичній модифікації терапії вона має. Якщо задача має занадто мало прав для рекомендацій терапії, або якщо пацієнт відмовляється від усіх терапевтичних порад, задача відправляє пацієнта до лікаря. Остання задача сеансу зв'язку ВЗ, Закриття сеансу зв'язку, зберігає всі оцінні виміри, показник стану і коефіцієнти рішень у базі даних медичної історії пацієнта. Ця задача також обробляє зміни в терапії, на які погодився пацієнт, видає пацієнту відповідні інструкції і, нарешті, призначає пацієнту наступний сеанс зв'язку. Потім ця задача ініціює процеси виводу різних журналів і звітів сеансу зв'язку, що викликались у ході сеансу зв'язку, і, нарешті, МВЗ зберігає відповідні дані і завершує поточний сеанс зв'язку ВЗ. На цьому МВЗ закінчує спілкування з цим пацієнтом, поки наступний сеанс зв'язку не повторить даний процес. Модуль ведення захворювання За фіг.5 буде описаний процес 220. Процес 220 містить виконувану частину Модуля ведення захворювання (МВЗ), що проводить оперативний інтерактивний діалог із пацієнтом із метою ведення відомого захворювання пацієнта. Процес 220 складається з чотирьох процесів 404, 406, 408 і 410. Сеанс зв'язку ВЗ починається, коли керування передається програмі 220 у стартовому вузлі 402. З стартового вузла 402 процес 220 викликає процес 404, що виконує ініціалізацію, відкривання файла і функції реєстрації, як описано в зв'язку з фіг.6 нижче. Коли процес 404 повертає керування процесу 220, процес 220 потім викликає процес 406, що вводить отримані від пацієнта вимірення показників стану здоров'я, аналізує їх і оцінює поточний стан здоров'я. Коли процес 406 повертає керування процесу 220, процес 220 потім викликає процес 408, що розраховує оптимальний наступний крок терапії, на який погоджується пацієнт. Коли процес 408 повертає керування процесу 220, процес 220 потім викликає процес 410, що виводить різні звіти, зберігає дані сеансу зв'язку і закриває робочі файли. Коли процес 410 передає керування процесу 220, процес 220 передає керування кроку 412. Крок 412 повертає керування процесу, що викликав процес 220 у вузлі 402. Відкриття сеансу зв'язку За фіг.6 буде описаний процес 404. Процес 404 встановлює дані, необхідні для проведення сеансу зв'язку ВЗ. Він реєструє пацієнтів, що є новими для МВЗ, і завантажує існуючі дані для пацієнтів, що вже проводили раніше сеанси зв'язку ВЗ. Нарешті, процес 404 створює запис Порядку ведення захворювання (ПВЗ), у якому накопичуються сукупні рішення, зроблені МВЗ у ході даного сеансу зв'язку ВЗ. ПВЗ додатково описаний у розділі "Порядок ведення захворювання". Процес 404 одержує керування в стартовому вузлі 430. Потім процес 220 передає керування операції 432 перевірки умови, що шукає ідентифікацію пацієнта в регістрі ВЗ, щоб визначити, чи зареєстрований пацієнт, тобто чи проводив він раніше сеанси зв'язку ВЗ. Якщо пацієнт не зареєстрований, процес 404 передає керування кроку 434, або кроку 452, що будуть описані пізніше в даному розділі. Крок 434 є першим кроком із семи послідовних кроків 434, 436, 438, 440, 442, 444, 446, що реєструють пацієнта для Ведення захворювання. Крок 434 виводить повідомлення, що вітають пацієнта й інформують його про те, що він приступає до реєстрації для ВЗ. Потім крок 436 уводить назву захворювання, що треба вести. Потім крок 438 интерв'ює пацієнта для введення даних, необхідних для здійснення Ведення захворювання, включаючи ім'я представника, що може виступати від імені пацієнта, ім'я і месцезнаходження лікаря пацієнта, назви і телефони служб швидкої допомоги, що знаходяться поруч із пацієнтом, і так далі. Потім крок 440 створює запис для нового пацієнта в реєстрі ВЗ. Потім крок 442 привласнює пацієнту статус зареєстрованого пацієнта ВЗ. Потім крок 444 створює новий запис даних для використання її МВЗ у базі даних пацієнтів. Потім крок 446 створює новий запис даних для даних сеансу зв'язку в базі даних сеансів зв'язку. Крок 446 завершує реєстрацію пацієнта як нового пацієнта ВЗ. Після кроку 446 керування переходить до кроку 448, що створює новий запис Порядку ведення захворювання (ПВЗ), у якому зберігаються сукупні рішення, прийняті N4B3 у ході даного сеансу зв'язку ВЗ. Крок 448 ініціалізує цей ПВЗ для указания того, що даний пацієнт є знову зареєстрованим пацієнтом ВЗ і потребує початкової оцінки здоров'я. Після кроку 448 процес 404 передає керування кроку 450, що повертає керування процесу, що викликав процес 404. Тепер продовжимо описання процесу 404 на кроці 452. Крок 452 вимагатиме медичну карту пацієнта з бази даних пацієнтів. Після кроку 452 керування передається кроку 454, що завантажує дані останнього сеансу зв'язку ВЗ для даного пацієнта з бази даних сеансів зв'язку. Після кроку 454 керування передасться кроку 456, що підтверджує, що останній сеанс зв'язку завершився нормально, і встановлює підхожі керуючі дані, якщо це не зроблено. Після кроку 456 керування передається кроку 458, що ініціалізує ПВЗ для указания того, що даний пацієнт при наступному обстеженні потребує поточної оцінки здоров'я Після кроку 458 керування передається на крок 450, що повертає керування процесу, що викликав процес 404. Оцінювання здоров'я За фіг.7 буде описаний процес 406. Процес 406 виконує оцінювання здоров'я для сеансу зв'язку ВЗ. Він є у своїй основі східчастим процесом, що викликає інші процеси, що виконують оцінювання здоров'я пацієнта. Процес 406 одержує керування в стартовому вузлі 480. Після вузла 480 процес 406 викликає процес 482, що називається Зіставлення значимих симптомів, і описаний нижче в зв'язку з фіг.8. Коли процес 482 повертає керування, процес 406 передає керування тесту 484, що перевіряє код запису ПВЗ, щоб визначити, чи є даний пацієнт знову зареєстрованим пацієнтом ВЗ або звернувся до ВЗ повторно. Для нових пацієнтів процес 406 викликає вузол 488, що оцінює здоров'я знову зареєстрованих пацієнтів і буде описаний нижче в зв'язку з фіг.10. Для інших процес 406 викликає вузол 490, що проводить оцінювання здоров'я пацієнтів ВЗ, що повторно звернулися, і буде описаний нижче в зв'язку з фіг.11. Після того, як оцінювання здоров'я нових або тих пацієнтів, що повторно звернулися, завершено, процес 406 повертає керування у вузлі 492. Зіставлення значимих симптомів За фіг.8 буде описаний процес 482. Процес 482 застосовує декілька тестів до поточних симптомів пацієнта для класифікації поточного стану здоров'я пацієнта, виносу рішень за конкретними потребами оцінювання та їхніх причин, і відправлення цього оцінювання наступним процесам ВЗ. Ці потреби зберігаються в ПВЗ пацієнта, що потім обробляється наступними процедурами МВЗ. Запис ПВЗ описується пізніше у розділі "Порядок ведення захворювання". Процес 482 одержує керування в стартовому вузлі 510. Звідти він передає керування тестовому вузлу 512, що являє собою перший фільтр, питаючи пацієнта, чи є в нього які-небудь значимі симптоми. Якщо в пацієнта немає значимих симптомів, він може бути оцінений за допомогою автоматичних засобів, і тому процес 482 передає керування на крок 544. Крок 544 установлює код запису ПВЗ для указання того, що здоров'я даного пацієнта варто оцінювати за допомогою таких процедур. Керування повертається через вузол 526. Якщо у вузлі 512 пацієнт має поточні значимі симптоми, то процесу 482 необхідно визначити, чи має пацієнт симптом, зв'язаний із контрольованим захворюванням, або не має Щоб зробити це, процес 482 передає керування спочатку на крок 514, що вводить симптом від пацієнта і шукає його в таблиці зв'язаних симптомів, а потім у тест 516, що відгалужується до вузла 520, якщо симптом зв'язаний із контрольованим захворюванням, або до вузла 530 у противному випадку. Це складає другий фільтр, що тепер визначив пацієнтів із значимими зв'язаними симптомами і без них. Якщо у вузлі 516 пацієнт має зв'язаний симптом, процес 482 викликає функцію 520 Оцінювання тяжкості, щоб додатково класифікувати зв'язаний симптом як легкий або важкий. Для пацієнтів із важкими зв'язаними симптомами процес 482 передає керування на крок 522, що відбиває виявлене в записі ПВЗ. З кроку 522 керування повертається через вузол 526. Однак якщо в тесті 520 симптом був розцінений як легкий, процес 482 передає керування вузлу 524, що відбиває в записі ПВЗ потребу в звичайному оцінюванні здоров'я. З вузла 524 процес 482 повертає керування через вузол 526. Якщо у вузлі 516 у пацієнта нема зв'язаного симптому, процесу 482 потрібно визначити, чи є в пацієнта побічний ефект, зв'язаний із поточним лікуванням пацієнта. Щоб зробити це, процес 482 передає керування спочатку на крок 530, що шукає симптом пацієнта в таблиці побічних ефектів поточного лікування. Потім процес 482 передає керування тесту 532, що є фільтром, що визначає симптоми побічних ефектів. Якщо симптом пацієнта є побічним ефектом, процес 482 викликає функцію 520 Оцінювання тяжкості для класифікації побічного ефекту як легкого або важкого. Для легких побічних ефектів процес 482 передає керування вузлу 536, що відбиває в запису ПВЗ необхідність оцінювання наступними процедурами. Для важких побічних ефектів процес 482 передає керування спочатку на крок 534, що маркірує запис ПВЗ, відсилаючи пацієнта із системи до лікаря, а потім повертається в процес, що викликає, через вузол 526. Якщо по тесту 532 симптом пацієнта не є побічним ефектом, цей симптом є значимим симптомом, не зв'язаним ні з контрольованим захворюванням, ні з застосовуваним лікуванням. Процес 482 викликає функцію 520 Оцінювання Тяжкості для класифікації симптому як легкого або важкого. Для легких симптомів процес 482 передає керування вузлу 542, що встановлює ознаку запису ПВЗ, щоб викликати спеціальну дискусію з пацієнтом після того, як будуть виконані всі процеси ВЗ, і відзначає причини цієї дискусії. Потім процес 482 передає керування спочатку вузлу 544, що встановлює запис ПВЗ, щоб викликати наступне оцінювання здоров'я, а потім вузлу 526, що повертається до процесу, що викликав процес 482. Для важких незв'язаних симптомів процес 482 передає керування спочатку на крок 540, що маркірує запис ПВЗ для відсилання пацієнта із системи до лікаря, а потім повертається до процесу, що викликає, через вузол 526. Оцінювання тяжкості За фіг.9 буде описана функція 520 Оцінювання тяжкості. Ця функція використовує декілька критеріїв, щоб вирішити, чи варто вважати даний симптом легким або важким для цілей оцінювання ВЗ. Функція 520 одержує керування в стартовому вузлі 560, де вона починає послідовність із 6 послідовних кроків, а потім повертає розрахований результат. Спочатку функція 520 передає керування вузлу 562, що просить пацієнта визначити вагу симптому по шкалі від 0 до 10. Потім функція 520 передає керування вузлу 564, що одержує з бази даних симптомів шкалу абсолютної тяжкості для самого цього симптому. Різні симптоми мають різні шкали тяжкості, і оцінка пацієнта тепер сполучається зі шкалою даного симптому. Для цього функція 520 потім передає керування вузлу 566, що нормує оцінку пацієнта так, щоб вона виражалася в розмірах шкали тяжкості симптому. Потім функція 520 передає керування вузлу 568, що використовує Установку коефіцієнта чутливості для регулювання нормованої оцінки тяжкості у більшу або меншу сторони в залежності від поточної чутливості, установленої для МВЗ. Таким чином, чим вище чутливість, тим більше консервативна система у своєму оцінюванні. При самій низькій чутливості всі симптоми будуть оцінюватися як легкі. Потім функція 520 передає керування вузлу 570, що переводить остаточну відрегульовану оцінку в одну з двох категорій - легку і важку. Важливо зауважити, що цей кінцевий крок в інших контекстах може класифікувати остаточн у оцінку по будь-якому числу градацій; однак для оцінювання симптому, що описується в даний момент, повинний класифікуватися як легкий або важкий. Потім функція 520 передає керування вузлу 572, що повертає в процес, що викликав, код або для "легкого", або для "важкого". Початкове оцінювання здоров'я За фіг.10 буде описаний процес 488. Цей процес виконує оцінювання здоров'я пацієнтів, що вперше роблять сеанс зв'язку Ведення захворювання. Процес 488 приймає керування у вузлі 600. Потім процес 488 передає керування вузлу 602, що завантажує описання оцінювання здоров'я для контрольованого захворювання з бази даних захворювань. Ці описання містять різні показники стану, що повинні використовува тися в сеансах зв'язку ведення захворювання, такі як інструкції для пацієнта, вибори лікування, необхідні дозволи і так далі. Після того, як ці значення отримані, процес 488 передає керування вузлу 604, що ініціалізує сегмент сеансу зв'язку ВЗ у медичній історії пацієнта і базу даних сеансів зв'язку. Потім процес 488 передає керування вузлу 606, що проводить початкове інтерв'ювання про здоров'я, запитуючи в пацієнта суб'єктивну оцінку поточного стану здоров'я, будь-які об'єктивні виміри показників стану здоров'я, що можуть бути у пацієнта, будь-які терапевтичні або побічні ефекти , що існували раніше, і так далі. Потім процес 488 передає керування вузлу 608, що повертає керування процесу , що викликає. Поточне оцінювання здоров'я За фіг.11 буде описаний процес 490. Цей процес одержує від пацієнта поточні дані про здоров'я в трьох формах: суб'єктивній (тобто як представляється пацієнту або як він почуває), об'єктивній (тобто на підставі проведених пацієнтом вимірів, звичайно за допомогою інструмента), і у формі побічних ефектів, замічених пацієнтом. Ці виміри показників стану здоров'я потім використовуються для аналізу поточного стану здоров'я. Процес 490 приймає керування у вузлі 620. З вузла 620 процес 490 передає керування тесту 622, що перевіряє поточний запис ПВЗ пацієнта, щоб визначити, яке обслуговування було проведено і що потрібно зробити. Якщо код запису ПВЗ не вказує на потребу в оцінюванні здоров'я, процес 490 передає керування вузлу 634, що повертає керування процесу, що викликає, послідовності з п'ятьох кроків, що приходить і різним оцінкам здоров'я. Спочатку процес 490 передає керування на крок 624, що запитує в пацієнта суб'єктивну оцінку поточного стану здоров'я пацієнта. Потім процес 490 передає керування на крок 626, що запитує в пацієнта об'єктивні виміри показників поточного стану здоров'я пацієнта. Потім процес 490 викликає функцію 630 Оцінювання кореляції. Ця функція описана в зв'язку з фіг.12. Потім процес 490 викликає функцію 640 Оцінювання критичної кривої. Ця функція описана в зв'язку з фіг.13. Потім процес 490 передає керування на крок 632, що повертає керування процесу, що викликає. Оцінювання кореляції За фіг.12 буде описаний процес 630. Ця функція розраховує і стандартизує СОКК для недавно отриманих даних, обчислює інші показники стану і статистику оцінювання й обновляє медичну історію пацієнта. Нарешті, вона викликає знову функцію оцінювання здоров'я для заповнення пробілів у даних за інтервал часу, що пройшов із минулого сеансу зв'язку. Процес 630 приймає керування в стартовому вузлі 650. Потім процес 630 передає керування на крок 652, що одержує будь-які нові дані, що варто додати до медичної історії пацієнта, за час, що минув з останнього сеансу зв'язку ВЗ. Потім процес 630 передає керування на крок 654, що розраховує нові точки на грубому тимчасовому гра фіку СОКК шляхом обчислення співвідношення суб'єктивного й об'єктивного вимірення за той самий час і відновлення грубого тимчасового графіка СОКК за допомогою цих нових точок. Потім процес 630 передає керування на крок 656, що застосовує стандартні методи статистичного нормування й апроксимації кривих для нормування грубих точок СОКК і одержання єдиного поточного СОКК, що є високим у пацієнтів, суб'єктивна оцінка яких має тенденцію збігатися з їхніми об'єктивними вимірами показників стану здоров'я, і низьким у пацієнтів, суб'єктивні оцінки яких мають тенденцію бути неточними в порівнянні з їхніми об'єктивними вимірами показників стану здоров'я. Крок 656 також обчислює інші показники стану, використовувані в іншій частині сеансу зв'язку ВЗ, такі як крутизна і зміна крутизни для трьох самих останніх точок даних і різниця між вимірами пацієнта і нормальними вимірами. Крок 656 визначає також, чи існують у даних про здоров'я пацієнта великі пробіли, що необхідно ретроактивно заповнити шляхом інтервального оцінювання. Крок 656 відповідним чином установлює код ПВЗ, щоб викликати ще одне оцінювання. Потім процес 630 передає керування кроку 658, що обновляє медичну історію пацієнта за допомогою розрахованих оцінних показників стану. Потім процес 630 передає керування тесту 660, що визначає, чи варто знову оцінювати здоров'я пацієнта для одержання відсутніх інтервальних даних. Якщо тест 660 визначає, що додаткового оцінювання не потрібно, процес 630 передає керування завершальному вузлу 662, що повертає керування процесу, що викликає. Якщо тест 660 визначає, що потрібний ще один тур оцінювання здоров'я, процес 630 передає керування тесту 664. Тест 664 визначає тип даних, що варто повторно оцінювати для даного інтервалу. Якщо тест 664 визначає, що доступні об'єктивні дані, процес 630 викликає процес 490 Оцінювання здоров'я, передаючи показник стану, що вимагає оцінки як суб'єктивних, так і об'єктивних даних про здоров'я пацієнта для даного інтервалу. Потім процес 630 передає керування завершальному вузлу 674, що повертає керування процесу, що викликає. Якщо тест 664 визначає, що об'єктивні дані недоступні, процес 630 викликає процес 490 Оцінювання здоров'я, передаючи показник стану, що вимагає одержання тільки суб'єктивних оцінок здоров'я пацієнта для даного інтервалу. Потім процес 630 передає керування завершальному вузлу 672, що повертає керування процесу, що викликає. Оцінювання ритичної кривої Оцінювання критичної кривої є процесом МВЗ для відстежування значних погіршень здоров'я пацієнта. Критична крива визначається у вигляді графіка вимірів показників стану здоров'я в часі, що використовується для ідентифікації значних змін у стані здоров'я. Процес Оцінювання критичної кривої вибирає специфічний для захворювання і пацієнта показник стану здоров'я, вичерчує його у вигляді критичної кривої, обновляє цю критичну криву як звичайну частину повторюваних сеансів зв'язку ВЗ, і починає певну дію, якщо критична крива пацієнта виявляє специфічні критичні точки, нахили, і зміни крутизни. Процес заснований на порівнянні критичної кривої пацієнта зі стандартними, специфічними для захворювання, критичними кривими. Постійне значення з великою ординатою означає гарне здоров'я, крива, що знижується, означає здоров'я, що погіршується; різке "падіння" кривої показує кризовий стан здоров'я. "Критичною точкою" на кривій є точка, що пророкує значне погіршення здоров'я. Приклад типової критичної кривої показаний на фіг.23, де крива містить точку, позначену як "критична точка". З фіг.23 можна зробити висновок, що в критичній точці крутизна кривої (тобто тангенс кута нахилу дотичної в критичній точці) різко негативна, що пророкує, що наступний вимір показників стану здоров'я буде нижче критичної точки. Більш того, у критичній точці швидкість зміни крутизни може також бути негативною, показуючи, що крутизна кривої усе більш зменшується, що пророкує стан здоров'я, що погіршується швидко. Для стислості ці три критичні тестові розміри звичайно називаються в процесах МВЗ критична точка, крутизна і тренд. Вони обчислюються за допомогою трьох останніх точок вимірення показників стану здоров'я. Для критичних кривих із значимими точками даних можуть також використовува тися методи апроксимації кривих. МВЗ має базу 262 даних захворювань (фіг.3), що містить стандартні критичні криві для різних захворювань, популяцій пацієнтів і показників стану здоров'я. Процес Оцінювання критичної кривої дістає підхожий набір даних про захворювання, вибирає підхожий для використання показник стану здоров'я, адаптує його до конкретного пацієнта і зберігає його у вигляді стандартної кривої для поточного пацієнта в медичній історії 254 пацієнта (фіг.3). Оскільки МВЗ періодично спілкується з пацієнтом, процес Оцінювання критичної кривої одержує від пацієнта поточні дані, вичерчує їх на критичній кривій пацієнта і використовує методи апроксимації кривих і узгодження моделей для порівняння поточної КК пацієнта зі стандартної КК пацієнта. Це порівняння дозволяє МВЗ виявляти ключові точки і тренди на кривій пацієнта, такі як "критична точка", що пророкує значне погіршення здоров'я. Коли крива досягає цієї критичної точки, метод Оцінювання критичної кривої дає вказівки внести зміни в лікування, що запобігатимуть погіршенню, або виставляє ознаку, що означає, що пацієнт відсилається до організації охорони здоров'я. Для креслення КК використовуються як об'єктивні, так і суб'єктивні дані про здоров'я, особливо, якщо Суб'єктивно-об'єктивний коефіцієнт кореляції (СОКК) високий (що означає, що пацієнт добре уявляє собі процес свого захворювання, і МВЗ може покладатися на відповіді пацієнта усе більше і більше). Гомеостаз Концепція гомеостазу, описана Клодом Бернаром, корисна для розуміння концепцій, що стоять за критичною кривою і її аналізом. Коротко кажучи, гомеостаз — це стан динамічної рівноваги тіла. Ця рівновага підтримується різними внутрішніми керуючими механізмами, що змушують певні системні показники стану залишатися в бажаному діапазоні. За допомогою цих гомеостатичних механізмів тіло здатне переносити хворобу до певного моменту, у який тимчасове прогресування хвороби починає прискорюватися. Хорошими прикладами є: — бікарбонатна буферна система підтримки рН крові, — крива поділу оксигемоглобіну, і — погіршення стану пацієнта з захворюванням на хронічну закупорку легень. Критична крива Критична крива (КК) описує стан здоров'я пацієнта в ході захворювання. Крива відображає стан здоров'я пацієнта в часі, починаючи звичайно з (високого) нормального стану здоров'я і неспадній — по мірі прогресування захворювання — до більш низького стану здоров'я. Нормальний, що не має захворювання пацієнт буде мати практично горизонтальний графік на високому рівні здоров'я. Початкова частина кривої асимптотично прямує до нормального здоров'я, оскільки здорове тіло часто може якийсь час чинити опір захворюванню, використовуючи резервні можливості і механізми внутрішнього захисту. Після початкової фази крива здоров'я починає знижуватися усе більш круто в міру того, як витрачаються резерви, установлюється захворювання і виробляються вторинні ефекти. У деякій критичній точці крива знижується так сильно, що стан пацієнта може швидко погіршуватися. Багато фізіологічних показників стану характерно реагують на зміну, будучи здатними компенсувати його до деякого моменту, а потім відповідаючи дуже сильними змінами сигнальних даних на малі зміни в розвитку хвороби. Дуже важливо знати, де на Критичній кривій знаходиться пацієнт, оскільки якщо вираженість захворювання в цього пацієнта близька до прискорення, потрібно значне втручання. Коли існують показання або хоча б підозра, що стан пацієнта досягає крутої ділянки кривої здоров'я, МВЗ може рекомендувати зміну лікування або консультацію з тими, хто підтримує здоров'я пацієнта. Якщо потрібно підтвердження про зміни стану здоров'я, характеристики повторного входу МВЗ дозволяє системі МВЗ підтвердити свою гіпотезу до того, як давати рекомендації. Аналіз Критичної кривої Для пацієнта з відомим захворюванням, що здійснює ведення захворювання вдома, за допомогою підхожого профілактичного лікування, МВЗ відслідковує періодичні контакти пацієнта і звіти про стан здоров'я. Коли лінія зміни показує, що крива здоров'я пацієнта досягає критичної точки, МВЗ може змінити лікування і/або повідомити лікаря пацієнта. Оскільки пацієнти можуть місяцями успішно здійснювати ведення захворювання, даний аналіз кривої може усун ути декілька необов'язкових візитів до лікаря, відразу ж інформуючи лікаря і пацієнта, якщо зміна стану здоров'я показує наближення до критичної точки. Очевидно, найкраще використовувати показник стану, що легко виражається кількісно, як маркера прогресування захворювання, коли мова йде про втілення даної кривої, але якщо суб'єктивно-об'єктивна кореляція в даного.пацієнта висока, те ж саме можна виконувати за допомогою його суб'єктивної оцінки. Система вимірює об'єм збільшення і зниження в часі і пікові швидкості ходу. Якщо виявлено, що невеликі зміни в об'ємі збільшення і зниження приводять до великих відмінностей в уявленні пацієнта про вагу його захворювання (у порівнянні зі змінами, що раніше відбулися в пацієнта), пацієнт знаходиться на крутій частині кривої. Встановлюється ознака, і необхідно значне втручання. Якщо дозволений рівень терапевтичних змін установлений низьким, то пацієнт відсилається до свого лікаря, а лікар пацієнта одержує звіт, часті ше усього по факсу або електронній пошті, про нові результати. Якщо дозволений рівень терапевтичних змін установлений високим, то оптимізація лікування може робитися до того, як пацієнт піде до свого лікаря. Лікарю посилається звіт, і пацієнт може йти до лікаря, а може і не йти. У цьому полягає аналіз і розпізнавання даної залежності, що складає аналіз стану здоров'я "за кривою". Приклад: хронічна закупорка легень Як приклад обговоримо хронічну закупорку легень. Хронічна закупорка легень повільно руйнує легеневу тканину. Як було відзначено, багато фізіологічних показників стану мають однакову реакцію на зміни, будучи здатними до деякого моменту компенсувати їх, а потім, після того як закінчилися резервні можливості, дуже невеликі зміни в стані захворювання дають дуже великі зміни виразності прогресування захворювання в пацієнта в ранній фазі, пацієнт із хронічною закупоркою легень втрачає тільки резервну ємність легких, так що немає ніяких значних змін в іншому стані здоров'я. Після того, як резервна тканина зруйнована, досягається межа, за якою усе менші відрізки часу (і весь менший розвиток процесу захворювання) будуть приводити до усе більшого погіршення здатності пацієнта видихати вуглекислий газ і насичувати кров киснем. Нарешті, навіть дуже маленька зміна в хронічній закупорці легень приводить до респіраторної недостатності. Коли ми починаємо бачити усе більші убування легеневої функції, побудованої в часі, пацієнт досягає критичної частини кривої. Необхідно значне втручання, що варто почати якомога швидше. Процес Оцінювання критичної кривої особливо ефективний у МВЗ, оскільки МВЗ: - цілком автоматичне, - простежує здоров'я пацієнта в часі, - має різні модулі, що простежують і корелюють контакти пацієнта, - знає пацієнта (історію, Суб'єктивно-об'єктивний коефіцієнт кореляції), - має доступ до баз даних медичних знань, - може аналізувати розвиток захворювання за допомогою математичного аналізу, і - може вибирати альтернативні терапії, якщо цього вимагають умови, що змінились. За фіг.13 буде описана функція 640 Оцінювання критичної кривої. Ця функція має дві фази. Перша фаза (що починається у вузлі 702) обновляє критичну криву пацієнта за допомогою вимірів показників стану здоров'я, доданих до медичної історії пацієнта з моменту останнього оцінювання критичної кривої. Друга фаза - (що починається у вузлі 712) порівнює поточну критичну криву пацієнта зі стандартною критичною кривою, використовуваною для даного пацієнта. Якщо пацієнт знаходиться в критичній частині кривої (або наближається до неї), це припускає можливість швидкого загострення контрольованого захворювання, і пацієнт відсилається для консультації до лікаря. Процес 640 приймає керування в стартовому вузлі 700. Потім процес 640 передає керування на крок 702, що обновляє поточну критичну криву пацієнта за допомогою нових вимірів показників стану здоров'я. Потім процес 640 передає керування на крок 704, що аналізує обновлену критичну криву пацієнта для одержання точки, крутизни і тренда за трьома точками останньої критичної кривої. Потім процес 640 передає керування на крок 706, що зберігає дані критичної кривої пацієнта в медичній історії пацієнта. Потім процес 640 передає керування тесту 708, що вивчає код запису ПВЗ, щоб визначити, чи варто оцінювати критичні точки пацієнта. Якщо критичні точки пацієнта оцінювати не потрібно, процес 640 передає керування завершальному вузлу 710, що передає керування процесу, що викликає. Якщо тест 708 показує, що необхідна оцінка здоров'я, процес 640 передає керування на крок 712. Крок 712 починає фазу оцінювання процесу 640. Крок 712 вимагає або обчислює робочі дані, необхідні для використання критичної кривої для оцінювання здоров'я пацієнта. Робочі дані містять точку і крутизну останнього поточного графіка здоров'я пацієнта, що відповідають точці і крутизні стандартної критичної кривої пацієнта, і межі для кожного набору, що використовуються для того, щоб установити пацієнта як критичного. Коли крок 712 обчислив ці робочі дані, процес 640 передає керування тесту 714. Тест 714 починає послідовність кроків, що перевіряють критичну точку пацієнта. Якщо тест 714 знаходить, що остання точка здоров'я пацієнта недоступна або не може бути зіставлена з точкою на стандартній кривій, процес 640 передає керування завершальному вузлу 716, що передає керування процесу, що викликає. Якщо тест 714 визначає, що остання точка здоров'я доступна,*то процес 640 передає керування кроку 718, що порівнює різницю між поточною точкою здоров'я і стандартною критичною точкою. Потім процес 640 передає керування тесту 720. Якщо тест 720 виявляє, що пацієнт досяг або перевищив межу критичної точки, процес 640 передає керування на крок 722, що відбиває в записі ПВЗ, що пацієнт відсилається до лікаря для консультації. Потім процес 640 передає керування завершальному вузлу 724, що повертає керування процесу, що викликає. Якщо тест 720 виявляє, що пацієнт не досяг межі критичної точки, процес 640 передає керування тесту 726. Тест 726 починає послідовність кроків, що досліджують критичну крутизну. Якщо тест 726 визначає, що критична крутизна недоступна, процес 640 передає керування завершальному вузлу 724, що повертає керування процесу , що викликає. Якщо тест 726 визначає, що поточна крутизна доступна, процес 640 передає керування на крок 728, що порівнює різницю між поточною і стандартною критичною крутизною. Потім процес 640 передає керування тесту 730. Якщо тест 730 визначає,·що пацієнт знаходиться нижче межі критичної крутизни, процес 640 передає керування вузлу 724, що повертає керування процесу, що викликає. Якщо тест 730 визначає, що пацієнт досяг або. перевищив межу критичної крутизни, процес 640 передає керування вузлу 732, що відбиває в записі ПВЗ, що пацієнт відісланий для консультації з лікарем. Потім процес 640 передає керування вузлу 724, що повертає керування процесу, що викликає. Оптимізація лікування Оптимізація лікування складається з набору процесів, що переглядають і регулюють лікування пацієнта від одного сеансу зв'язку до іншого,» із довгостроковою метою збільшення ефективності, зменшення шкідливих побічних ефектів і підтримки сприянню пацієнту і його згоди з рекомендованим лікуванням. Процеси Оптимізації лікування вибирають показники стану лікування з таблиць медичних лікувань і відслідковують специфічну для пацієнта ефективність шляхом розгляду суб'єктивних і об'єктивни х даних про здоров'я пацієнта від одного сеансу зв'язку до іншого. Процес Оптимізації лікування вибирає з множини лікувань. Він намагається мінімізувати побічні ефекти пропонуючи пацієнту різні лікування на вибір і регулюючи рівні дозування доти' поки пацієнт не знайде підхожий комфортний рівень. Незгоди пацієнта з МВЗ дозволяються направленням пацієнта до лікаря для особистої консультації і рекомендації. Оптимізація лікування управляється Дозволеним рівнем зміни лікування (ДРЗЛ), глобальної перемінної МВЗ, що конкретизує ступінь автономії, що вигляділяється МВЗ для зміни терапії. ДРЗЛ описаний в окремому розділі нижче. Після того, як був оцінений стан здоров'я пацієнта, процес Оптимізації лікуванні переглядає і регулює (у тій мірі, у якій це дозволяє ДРЗЛ) лікування пацієнта для досягнення найкращої комбінації декількох підцілей загальної мети відновлення нормального здоров'я. Процес Оптимізації лікування прагне також зменшити побічні ефекти лікування. У межах, дозволених поточною установкою ДРЗЛ, МВЗ буде поступово титрувати дозу медикаменту доти, поки не буде максимізоване співвідношення, переваги/побічні ефекти. Загальною ідеєю є досягнення бажаних фізіологічних змін із найменшими побічними ефектами. Початкове лікування вибирається з таблиці лікувань на підставі захворювання, віку і cтатті. Через широкий діапазон реакцій на лікування в різних пацієнтів, як тільки ліки було вибрано як лікування для даного захворювання, інше формулювання, дозування, способи прийманя і час приймання визначаються, по суті, методом проб і помилок для конкретного пацієнта. Для перегляду лікування задача Оптимізації лікування порівнює поточне лікування пацієнта з таблицею лікувань для виявлення й аналізу відмінностей. Якщо доступно нове лікування, пацієнт і лікар повідомляються про це, і лікування може бути змінено, у залежності від ДРЗЛ. Для максимізації терапевтичного результату і мінімізації побічних ефектів ця функція може вибирати початкове лікування, переглядати поточне лікування пацієнта, регулювати різні показники стану лікування і контролювати ефект цих змін. Показники стану лікування, що можуть бути змінені, містять у собі клас ліків, тип, марку, дозування, спосіб застосування, режим введення ліків, формулювання, час приймання і частоту приймання. Коли будьякий із них змінюється, дані про здоров'я пацієнта і побічні ефекти перевіряються, щоб переконатися, що поточна зміна лікування йде на користь пацієнту, і т.д. Кожний показник стану лікування послідовно змінюється методом проб і помилок, щоб знайти найкращу комбінацію показників стану лікування. Коли МВЗ регулює лікування пацієнта, він підхожим способом регулює розклад сеансів зв'язку ВЗ, звичайно інструктуючи пацієнта наново ввійти в систему через невелику кількість ітерацій лікування або дозування. Мінімізація побічних ефектів є спеціальною метою процесу Оптимізащї лікування, що покликана зменшити небажані побічні ефекти лікування. Ця задача ілюструє складні методи проб і помилок, використовувані МВЗ для реалізації Оптимізації лікування. Приклад 1: У ракових хворих існує момент, коли пацієнти, то одержують хіміотерапію, вирішують, що побічні ефекти не коштують уповільнення розвитку захворювання. У цей момент дозування знижують, знаючи, що подальше підвищення буде марним. Процес стає більш складним, якщо використовується багато ліків, але залежність залишається тією ж. Приклад 2: Альбутеролові дозуючі інгалятори допомагають зняти задишку в пацієнтів з астмою, але певна, специфічна Для пацієнта доза приводить до настільки сильних побічних ефектів, що пацієнт не може їх переносити. У·цей момент дозування знижується малими кроками для досягнення найкращого співвідношення ефективності і побічних ефектів. За фіг.14 буде описаний процес 408 Оптимізації лікування. Процес 408 виконує терапевтичну фазу сеансу зв'язку ВЗ. Ця фаза розраховує наступний найкращий терапевтичний крок, що приймається пацієнтом, за допомогою двох головних підпорядкованих процесів і циклу, що пробує різні лікування доти, поки пацієнт не вибере один з них. Загальною метою процесу 408 є вибір кроків лікування так, щоб оптимізувати лікування на довгий термін, шляхом максимізації ефективності, мінімізації побічних ефектів і регулювання типів і засобів візуалізації лікування так, щоб вони збігалися з рівнем комфорту пацієнта. Процес 408 приймає керування в стартовому вузлі 760, що перевіряє, чи забезпечив пацієнт поточні об'єктивні виміри показників стану здоров'я в ході більш ранньої стадії даного сеансу зв'язку ВЗ. Якщо тест 762 визначає, що пацієнт не забезпечив поточних об'єктивних даних про здоров'я, процес 408 передає керування тесту 782, що перевіряє, чи ввів пацієнт суб'єктивну оцінку свого здоров'я в ході більш ранньої стадії сеансу зв'язку ВЗ. Якщо тест 782 визначає, що пацієнт забезпечив суб'єктивну оцінку здоров'я, процес 408 викликає процес 790. Процес 790 регулює лікування на підставі поточних суб'єктивних даних про здоров'я. Докладніше процес 790 описаний нижче в зв'язку з фіг.15. Коли процес 790 повертає керування, процес 480 передає керування завершальному вузлу 792, що повертає керування процесу, що викликає. Якщо тест 782 виявляє, що пацієнт не дав поточної суб'єктивної оцінки здоров'я, процес 408 передає керування на крок 784, що відбиває в записі ПВЗ, що пацієнт відсилається для консультації до лікаря. Потім процес 408 передає керування завершальному вузлу 786, що повертає керування процесу , що викликає. Якщо тест 762 визначив, що пацієнт дав поточні об'єктивні дані про здоров'я, процес 408 передає керування на крок 764, що ініціалізує цикл, що пропонує різні лікування доти, поки пацієнт не погодиться на один з них, або поки кількість спроб не буде вичерпано, у залежності від того, що відбуде ться раніш. Крок 764 одержує максимальну кількість лікувань, дозволених для даного пацієнта базою даних по Дозволах. Потім процес 408 викликає процес 770. Процес 770 вибирає наступне найкраще лікування з таблиці лікувань для даного пацієнта і пропонує її пацієнту, що може або погодитися з нею, або модифікувати її, або відмовитися від неї. Процес 770 додатково описується нижче в зв'язку з фіг. 16. Коли процес 770 повертає керування, процес 408 передає керування тесту 772. Якщо тест 772 визначає, що пацієнт погодився з рекомендованою терапією, процес 408 передає керування завершальному вузлу 780, що повертає керування процесу, що викликає. Якщо тест 772 визначає, що пацієнт відмовився від рекомендованої терапії, процес 408 передає керування тесту 774. Якщо тест 774 визначає, що підрахунок повторів циклу більше одиниці, процес 408 передає керування на крок 776. Крок 776 зменшує підрахунок повторів циклу на одиницю, а потім процес 408 знову викликає процес 770 для ще однієї ітерації циклу. Якщо тест 774 визначає, що підрахунок повторів дорівнює одиниці, то процес 408 передає керування на крок 778. Крок 778 відбиває в записі ПВЗ, що пацієнт відсилається для консультації до лікаря. Потім процес 408 передає керування завершальному вузлу 780, що повертає керування процесу , що викликає. Регулювання лікування (Суб'єктивне) За фіг.15 буде описаний процес 790. Процес 790 розраховує наступне найкраще лікування для даного пацієнта, базуючись тільки на суб'єктивних оцінках пацієнтом свого здоров'я. Процес 790 використовує Суб'єктивно-об'єктивний коефіцієнт кореляції (СОКК), що описується нижче в розділі " Суб'єктивнооб'єктивний коефіцієнт кореляції". СОКК показує, наскільки вірно пацієнт суб'єктивно оцінює своє захворювання, і процес 790 обпирається на СОКК при розрахунку наступного кроку терапії. Процес 790 приймає керування в стартовому вузлі 810. Потім процес 790 передає керування тесту 812. Якщо тест 812 визначає, що пацієнт не потребує регулювання лікування, тобто запис ПВЗ даного пацієнта вже заповнений схваленим лікуванням, процес 790 передає керування завершальному вузлу 814, що повертає керування процесу, що викликає. Якщо тест 812 визначає, що даний пацієнт потребує оптимізації лікування, процес 790 передає керування тесту 816. Тест 816 визначає (опитуючи пацієнта або одержуючи збережену відповідь пацієнта, якщо пацієнт уже був опитаний), чи є в пацієнта які-небудь поточні симптоми Якщо тест 816 виявляє, що в пацієнта немає симптомів, процес 790 передає керування тесту 818. Якщо тест 818 визначає, що поточна установка ДРЗЛ для МВЗ не дозволяє регулювати лікування, процес 790 передає керування вузлу 826, що відбиває в записі ПВЗ, що варто підтримувати те ж саме лікування, наприклад, те ж дозування у випадку терапії, заснованої на ліках. Потім процес 790 передає керування завершальному вузлу 824, що повертає керування процесу, що викликає. Якщо тест 818 визначає, що поточна установка ДРЗЛ дозволяє регулювати лікування, процес 790 передає керування тесту 820. Якщо тест 820 визначає, що пацієнт не хоче зменшувати дозування, процес 790 передає керування на крок 826, що записує підтримку того ж лікування в карту ПВЗ. Потім процес 790 передає керування завершальному вузлу 824, що повертає керування процесу, що викликає. Якщо тест 820 визначає, що пацієнт хоче зменшити дозування, процес 790 передає керування на крок 822, що шукає наступний більш низький рівень дозування в таблиці лікувань і відбиває зменшення дозування в карті ПВЗ. Потім процес 790 передає керування завершальному вузлу 824, що повертає керування процесу, що викликає. Якщо тест 816 виявляє, що в пацієнта є поточні симптоми, процес 790 передає керування тесту 830. Якщо тест 830 виявляє, що ДРЗЛ не дозволяє змінювати лікування, процес 790 передає керування на крок 832. Крок 832 відзначає в карті ПВЗ, що пацієнт відсилається для консультації до лікаря. Потім процес 790 передає керування завершальному вузлу 833, що повертає керування процесу , що викликає. Якщо тест 830 виявляє, що ДРЗЛ дозволяє змінювати лікування, процес 790 передає керування на крок 834. Крок 834 починає фазу процесу 790, що розраховує наступний крок лікування для пацієнта, що має симптоми, але повідомив тільки суб'єктивні оцінки здоров'я. Крок 834 використовує поточний СОКК із медичної історії пацієнта, модифікує його за допомогою поточної установки Коефіцієнта чутливості для регулювання відповідно до використовуваної для даного пацієнта чутливості, а потім класифікує поточний СОКК пацієнта як "високий" або "низький". Якщо тест 834 класифікує СОКК пацієнта як високий, то суб'єктивна оцінка здоров'я пацієнта надійна, і процес 790 передає керування на крок 838, що дивиться на таблицю лікувань, наскільки терапія (тобто дозування в даному прикладі) може бути збільшена для пацієнта з високим СОКК, і що є зв'язаними з цим вигодами і ризиками. Потім процес 790 викликає функцію 840. Навпаки, якщо тест 834 розцінює СОКК як низький, процес 790 передає керування кроку 836, що одержує дозування і коефіцієнти ризику/вигоди для ненадійних пацієнтів. У будь-якому випадку процес 790 продовжується викликом функції 840. Функція 840 Рівня згоди пацієнта представляє пацієнту рекомендоване лікування і питає згоду пацієнта на рекомендоване лікування або його варіант; пацієнт може також цілком відмовитися від рекомендованої терапії. Функція 840 описується нижче в зв'язку з фіг.17. Коли функція 840 повертає керування, якщо функція 840 повертає як результат те, що пацієнт погоджується зі збільшенням дозування, процес 790 передає керування на крок 842. Крок 842 відбиває в карті ПВЗ наступне лікування зі збільшеним дозуванням і відповідною зміною в розкладі, щоб наступний сеанс зв'язку МВЗ відбувся раніш. Потім процес 790 передає керування завершальному вузлу 844, що повертає керування процесу, що викликає. Коли функція 840 повертає керування, якщо функція 840 повертає у вигляді результату те, що пацієнт погодився продовжувати терапію з тим же дозуванням, процес 790 передає керування на крок 846. Крок 846 відбиває в карті ПВЗ, що варто продовжувати те ж саме лікування. Потім процес 790 передає керування завершальному вузлу 844, що передає керування процесу, що викликає. Коли функція 840 повертає керування, якщо функція 840 повертає у вигляді результату те, що пацієнт погоджується зі зменшеним дозуванням, процес 790 передає керування на крок 848. Крок 848 відбиває в карті ПВЗ наступне лікування зі зменшеним дозуванням. Потім процес 790 передає керування завершальному вузлу 844, що повертає керування процесу, що викликає. Коли функція 840 повертає керування, якщо функція 840 повертає у вигляді результату те, що пацієнт відмовився від будь-якого рівня рекомендованого лікування, процес 790 передає керування тесту 850. Тест 850 консультується з поточною Установкою Коефіцієнта чутливості, щоб визначити, чи потрібно процесу 790 намагатися запропонувати наступне лікування або ж варто відіслати пацієнта до лікаря. Якщо тест 850 визначає, що можна спробувати інші лікування, процес 790 передає керування вузлу 852, що відбиває в карті ПВЗ, що пацієнт відмовився від рекомендованого лікування. Потім процес 790 передає керування завершальному вузлу 844, що повертає керування процесу , що викликає. Якщо тест 850 визначає, що пацієнта варто відіслати до лікаря, процес 790 передає керування вузлу 854, що відбиває в карті ПВЗ, що пацієнт відсилається до лікаря. Потім процес 790 передає керування завершальному вузлу 844, що повертає керування процесу, що викликає. Регулювання лікування (об'єктивне). За фіг.16 буде описаний процес 770. Процес 770 розраховує наступне найкраще лікування для даного пацієнта на підставі поточних об'єктивних вимірів показників стану здоров'я пацієнта. Процес приймає керування в стартовому вузлі 870. Потім процес 770 передає керування тесту 872. Тест 872 порівнює показники стану оцінювання здоров'я, щоб визначити, чи досягають об'єктивні дані здоров'я пацієнта різних меж або перевершують їх. Спочатку тест 872 порівнює поточне вимірення показників стану здоров'я пацієнта з абсолютною межею для цього вимірення, щоб переконатися, чи знаходиться саме вимірення у прийнятному діапазоні. Потім тест 872 порівнює крутизну двох останніх вимірів показників стану здоров'я, щоб зрозуміти, чи перевищується межа швидкістю погіршення здоров'я пацієнта. Потім тест 872 порівнює зміни крутизни для трьох останніх вимірів, щоб зрозуміти, чи стає зміна здоров'я пацієнта в гіршу сторону усе більш і більш швидким. Якщо якась із цих меж досягнута або перевищена, процес 770 передає керування на крок 874, що відбиває в карті ПВЗ, що пацієнт відсилається до лікаря. Потім процес 770 передає керування завершальному вузлу 876, що повертає керування процесу, що викликає. Якщо тест 872 визначає, що вся поточна статистика здоров'я пацієнта не досягає межі, процес 770 передає керування тесту 878. Тест 878 починає фазу процесу 770, що розраховує наступне рекомендоване лікування для даного пацієнта. Тест 878 порівнює поточні виміри показників стану здоров'я пацієнта з вимірами, зробленими в ході попереднього сеансу зв'язку МВЗ, щоб класифікувати зміну стану здоров'я пацієнта як "краще", "так само" або "гірше" із метою розрахунку кроку наступного лікування. Якщо тест 878 визначає, що пацієнту стало гірше, чим було востаннє, процес 770 передає керування тесту 880. Тест 880 визначає (із таблиці лікувань), чи може бути збільшене поточне лікувальне дозування. Якщо тест 880 визначає, що дозування може бути збільшене, процес 770 передає керування вузлу 882, що відбиває в ПВЗ збільшення дози. Потім процес 770 передає керування тесту 896. Якщо тест 880 визначає, що дозування не може бути збільшене, процес 770 передає керування вузлу 884, що відбиває в ПВЗ продовження лікування з тим же дозуванням. Потім процес 770 передає керування тесту 896. Якщо тест 878 визначає, що здоров'я пацієнта не змінилося з останнього разу, процес 770 передає керування тесту 892. Тест 892 визначає, чи знаходяться поточні виміри показників стану здоров'я пацієнта в нормальних межах. Якщо тест 892 визначає, що поточні дані про здоров'я пацієнта нормальні, процес 770 передає керування на крок 890. Крок 890 відбиває в ПВЗ зменшення дозування. Потім процес 770 передає керування тесту 896. Якщо тест 892 визначає, що поточні дані про здоров'я пацієнта виходять за рамки нормальних меле, процес 770 передає керування тесту 880. Тест 880 був описаний вище для процесу 770. Якщо тест 878 визначає, що пацієнту стало краще, чим було в минулий раз, процес 770 передає керування тесту 886. Якщо тест 886 визначає (проконсультувавшись із таблицею лікувань), що поточне дозування може бути зменшене, процес 770 передає керування на крок 890. Крок 890 був описаний вище для процесу 770. Якщо тест 886 визначає, що поточне дозування не може бути зменшене, процес 770 передає керування на крок 888, що відбиває в ПВЗ продовження лікування з тим же дозуванням. Потім процес 770 передає керування тесту 896. Тест 896 визначає, чи дозволяє установка ДРЗЛ для даного пацієнта виконувати ПВЗ, розрахований до цього моменту процесом 770. Якщо тест 896 визначає, що ДРЗЛ дозволяє виконати ПВЗ так, як він записаний, процес 770 викликає функцію 840 Рівня згоди пацієнта, що представляє пацієнту рекомендоване лікування й одержує від пацієнта згоду на рекомендоване лікування або його варіант; пацієнт може також цілком відмовитися від рекомендованого лікування. Функція 840 описується нижче в зв'язку з фіг.17. Якщо функція 840 повертає у вигляді результату згоду пацієнта на рекомендоване лікування (можливо, на декілька видозміненому рівні), процес 770 передає керування завершальному вузлу 898, що повертає керування процесу, що викликає. Якщо функція 840 повертає у вигляді результату повну відмову пацієнта від рекомендованого лікування, процес 770 передає керування тесту 900. Тест 900 з'ясовує в поточній Установці коефіцієнта чутливості, чи потрібно процесу 770 пропонувати наступне найкраще лікування або варто відіслати пацієнта до лікаря. Якщо тест 900 визначає, що можна пропонувати інші лікування, процес 7^0 передає керування вузлу 902, що відбиває в карті ПВЗ відмову пацієнта від рекомендованого лікування. Потім процес 770 передає керування завершальному вузлу 904, що повертає керування процесу, що викликає. Якщо тест 904 визначає, що пацієнту варто проконсультуватися в лікаря, процес 770 передає керування вузлу 906, що відбиває в карті ПВЗ, що пацієнт відсилається до лікаря. Потім процес 770 передає керування завершальному вузлу 904, що повертає керування процесу, що викликає. Якщо тест 896 визначає, що ДРЗЛ не дозволяє рекомендоване лікування, процес 770 передає керування на крок 908, що відбиває в карті ПВЗ, що пацієнт відсилається до лікаря. Потім процес 770 передає керування завершальному вузлу 904, що повертає керування процесу , що викликає. Рівень згоди пацієнта За фіг.17 описується функція 840 Рівня згоди пацієнта. Функція 840 представляє пацієнту рекомендоване лікування і дістає згоду пацієнта на це лікування або точно в тому вигляді, як рекомендовано МВЗ, або у вигляді його відрегульованого варіанта на підставі відповідей пацієнта. Пацієнт може також цілком відмовитися від рекомендованого лікування. Функція 840 приймає керування в стартовому вузлі 920. Потім процес 840 передає керування на крок 922, що виводить лікування, як рекомендовано в ПВЗ пацієнту Потім процес 840 передає керування на крок 924, що представляє пацієнту ризики і переваги. Потім процес 840 передає керування на крок 926, що представляє пацієнту інші варіанти лікування. Потім процес 840 передає керування на крок 928, що просить пацієнта погодитися з рекомендованим лікуванням або яким-небудь варіантом цього лікування. Потім процес 840 передає керування на крок 930, що обновляє ПВЗ, щоб записати запропоновані варіанти, зроблені попередження й отриманий рівень згоди разом із відповідними оцінками про дату і час. Потім процес 840 передає керування на крок 932, що розраховує результат функції, що потрібно повернути в процес, що викликає. Рівень згоди пацієнта може мати декілька значень. Використовувані в блок-схемах чотири значення припускають лікарську терапію; (1) згоду збільшити дозування; (2) згоду залишити дозування на тому ж рівні; (3) згоду зменшити дозування; і (4) відмову від даного лікування Потім процес 840 передає керування завершальному вузлу 934, що повертає керування процесу , що викликає. Закриття сеансу зв'язку За фіг.18 буде описаний процес 410 Закриття сеансу зв'язку. Процес 410 є останнім процесом, виконуваним у кожному сеансі зв'язку ВЗ. Він відповідає за опрацювання Порядку ведення захворювання (ПВЗ), що містить повний набір зроблених тестів і їхні х причин, наступний рекомендований крок лікування, дана пацієнтом згода і різні зв'язані з цим вказівки, такі як відправлення по факсу рецептів в аптеку пацієнта, запит тестів із лабораторії, підготовка звіту для лікаря пацієнта, відправлення пацієнту роздрукованих інструкцій і т.д. Крім реалізації подробиць ПВЗ процес 410 також у цілому відповідає за запис усіх подій, що відбулися у ході сеансу зв'язку ВЗ, збереження всіх релевантних даних, закриття всіх застосовуваних файлів, призначення наступного сеансу зв'язку ВЗ і, нарешті, відправлення пацієнту прощального повідомлення, щоб показати, що поточний сеанс зв'язку ВЗ припиняється. Процес 410 приймає керування в стартовому вузлі 950. Потім процес 410 передає керування тесту 952, що вносить у медичну історію пацієнта лікування, призначене ПВЗ. Потім процес 410 передає керування тесту 954, що визначає, чи містить ПВЗ спеціальні вказівки, що підлягають опрацюванню. Якщо тест 954 визначає, що ПВЗ не містить спеціальних терапевтичних указівок, процес 410 передає керування кроку 972, що призначає наступний сеанс зв'язку ВЗ, як визначено в поточному терапевтичному розкладі пацієнта. Потім процес 410 передає керування вузлу 962. Обробка від вузла 962 для процесу 410 описана нижче. Якщо тест 954 визначає, що ПВЗ містить спеціальні вказівки, процес 410 передає керування на крок 956, що призначає наступний сеанс зв'язку ВЗ, як зазначено в ПВЗ. Потім процес 410 передає керування на крок 958, що підготовляє і розсилає різні інструкції і звіти в різні місця. Ці повідомлення і місця, де їх приймають, управляються полями Організацій, Спільного користування й інших полів підтримуваних в базі даних по Дозволах. Потім процес 410 передає керування на крок 960, що інформує пацієнта про наступний крок лікування і дає пацієнту інструкції, як визначається в ПВЗ і дозволено базою даних по Дозволах. Потім процес 410 передає керування на крок 962. Крок 962 інформує лікаря пацієнта про сеанс зв'язку ВЗ і про призначене МВЗ лікування. Хоча лікар пацієнта завжди інформований про всю інформацію, що виробляється для цього пацієнта, він може уточнити інструкції, що відсилаються, і подробиці, що повідомляються. Поточні вимоги й обмеження лікаря на освідомлення зберігаються в базі даних по Дозволах і можуть змінюватися лікарем за допомогою процесів поза МВЗ. Потім процес 410 передає керування на крок 964, що інформує пацієнта про дії, початі програмним забезпеченням МВЗ у межах, дозволених базою даних по Дозволах. Цей крок дозволяє системі розповісти пацієнту, що вона робить і чому, що може підняти довіру пацієнта і допомогти пацієнту робити кращі висновки в майбутніх сеансах зв'язку. Цей зворотний зв'язок є важливим елементом довгострокової оптимізації лікування, що є однією з ознак дійсного винаходу. Крок 964 також переглядає усі виставлені спеціальні ознаки, щоб обговорити з пацієнтом нові симптоми. Потім процес 430 передає керування на крок 966, що зберігає всі релевантні дані в різних підхожих ділянках основної і резервної пам'яті. Потім процес 410 передає керування на крок 968, що закриває усі файли даних, що застосовувалися, і звільняє всі тимчасові ресурси комп'ютерної системи, вигляділені для даного сеансу зв'язку ВЗ. Потім процес 410 передає керування завершальному вузлу 970, що повертає керування процесу, що викликає. Варіанти питань Ознака Варіантів питань МВЗ дозволяє записати в сценарій декілька різних варіантів того самого питання і вирішувати, який варіант використовувати. Ця ознака використовує глобальну одиницю даних, називану Покажчик варіантів питань (ПВП) для вибору бажаних варіантів питань із сценарію під час виконання програми. Ознака Варіанти питань може бути поданий як "Ролик питань": розділений на багато сегментів циліндр із різними варіантами питання, по одному на кожному сегменті. Щоб поставити запитання, циліндр обертається для показу сегмента, що містить бажаний текст питання. Якщо кожне питання з набору питань написане на окремому циліндрі, і циліндри обертаються в унісон, показуючи однаковий сегмент, як визначається глобальним керуючим елементом, весь набір питань сценарію може бути відрегульований або "прокручений" як один блок, так що сценарій у цілому може бути відрегульований або точно настроєний для задання різних варіантів питань на різних рівнях. Одне використання ознаки Варіанти питань складається в спроможності глобально регулювати чутливість і вибірність мови, використовуваної всім МВЗ, за допомогою загального для МВЗ ПВП, що управляє лінгвістичною чутливістю. Таким чином, коли чутливість або вибірність питань необхідно змінити, Ролик Питань обертається або пошагово переміщається в одну сторону для збільшення чутливості, і в протилежну сторону для збільшення вибірності. Для такого використання кожний варіант питання лише злегка відрізняється від інших у словесному вираженні і чутливості. У деяких випадках єдиною відмінністю є кома (пауза) або інтонація голосу, як, наприклад: - Це абсолютно найсильніший головний біль, що Ви можете собі в кого-небудь представити? - Це найсильніший головний біль, що Ви можете собі в кого-небудь представити? - Це найсильніший головний біль, що був коли-небудь у Вас? - Це один з найсильніший Ваших головних болів? Інше використання ознаки Варіанти питань полягає в написанні питань сценарію, призначених для різних рівнів освіти пацієнта, його розумових здатностей, розуміння захворювання або медичної експертизи. Приміром, МВЗ може в різних формах задати те саме питання учню третього класу, студенту університету, випускнику коледжу або медичному працівнику. Таким чином, МВЗ може адаптувати виведення до комунікаційних потреб пацієнта, ще може містити в собі діапазон рішень на основі того, що відомо про пацієнта, як наприклад, яку використовувати природну мову, який рівень розуміння, яку граматику використовувати (наприклад, звертаємося ми до пацієнта, родича пацієнта або лікаря пацієнта?), і які медичні подробиці обговорювати. МВЗ може звернутися до медичної історії пацієнта, щоб визначити рівень мови, освіти й інтелектуальності, що зможе зрозуміти пацієнт. Якщо такий індикатор відсутній, можна дати мовний міні-тест на Коефіцієнт інтелектуальності (IQ) як частини Початкового оцінювання здоров'я, щоб установити ПВП для використання з цим пацієнтом. Ще одне використання ознаки Варіанти питань полягає в тому, що МВЗ може регулювати рівень питання динамічно, базуючись на відповідях або запитах пацієнта. Таким чином зніяковілий або розгублений пацієнт може попросити МСВЗ дати більш докладні інструкції для відповіді на питання. МВЗ може реагувати шля хом зміни ПВП для вибору більш підхожих варіантів питань. З іншого боку, оскільки пацієнт навчається в ході сеансу зв'язку, він може згодом запитувати менше інструкцій і більш швидкий режим спілкування. Знову ж, МВЗ може реагувати шляхом регулювання ПВП. Таким чином, МВЗ упізнає про поточне" і минуле використання МВЗ пацієнтом і може видозмінюватися для пристосування до природної мови, освіти, медичних знань пацієнта і необхідної медичної чутливості. Ознака Варіанти питань реалізована програмно шляхом дозволу авторам сценарію збирати різні варіанти питань у гр упу варіантів , у якій кожний варіант питання зв'язаний із відмінним ПВП. Під час виконання МВЗ використовує Установку коефіцієнта чутли вості для установки глобального ПВП, щоб визначити варіант поточного питання, що підлягає використанню для поточного пацієнта всіма сценаріями. Коли процес МВЗ (такий, як ядро сценарію) повинний видати питання, він використовує глобальний ПВП, щоб знайти і вимагати бажане питання з групи питань сценарію. Питання, що не вимагають різних варіантів, пишуться у вигляді групи варіантів, що містить тільки одне питання, що діє по умовчанню. Це питання використовується також тоді, коли в групі варіантів немає питання для поточного глобального ПВП. Структура ознаки Варіанти питань дозволяє писати варіанти питань для широкого діапазону ПВП без написання варіантів для кожного ПВП. Простий сценарій може мати лише один варіант питання; при удосконаленні сценарію добавляються додаткові варіанти питань. Приміром, перший сценарій може бути написаний англійською мовою, а потім удосконалений додаванням іспанської версії для кожного питання. Ознака Варіанти питань реалізована у вигляді Покажчика варіантів питань і двох окремих функцій Установки ПВП і Вибору питання. На фіг. 19а і 19б ці елементи показані так: - Глобальний покажчик варіантів (ПВП) є групою 1020 даних; - Установка ПВП являє собою процес 1000; - Процес Вибору питання показаний як процес 1001. Поточне значення Глобального покажчика 1020 варіантів визначає, які з декількох різних варіантів питань вибираються і виводяться пацієнту. Група 1020 даних зберігається у вигляді керуючого поля в базі 256 даних по Дозволах (фіг.3), змінюється процесом 1000 і використовується процесом 1001. Процес 1000 є глобальною для МВЗ системною обслуговуючою процедурою, що встановлює і періодично обновляє групу 1020 даних. Процес 1000 приймає керування в стартовому вузлі 1002. Потім процес 1000 передає керування на крок 1004, що ідентифікує пацієнта, група 1020 даних якого повинна бути встановлена. Потім процес 1000 передає керування на крок 1006, що шукає поточне значення групи 1020 даних пацієнта. Потім процес 1000 передає керування на крок 1008, що розраховує нове значення групи 1020 даних. Цей крок одержує бажаний рівень чутливості з поточної Установки коефіцієнта чутливості, і одержує інші показники стану з медичної історії пацієнта, такі як рівень освіти пацієнта, рівень розуміння мови й установки ПВП, використані в минулих сеансах зв'язку ВЗ. Після того, як крок 1008 розрахує нове значення ПВП, процес 1000 передає керування на крок 1010, що зберігає нове значення в групі 1020 даних пацієнта, це завершує відновлення групи 1020 даних пацієнта. Потім процес 1000 передає керування завершальному вузлу 1012, що повертає керування процесу, що викликає. Процес 1001 є глобальною для МВЗ процедурою, що використовує Глобальний покажчик 1020 Варіантів для вибору одного питання з набору питань. Процес 1001 приймає керування в стартовому вузлі 1022. Потім процес 1001 передає керування на крок 1024, що завантажує застосовний набір питань із поточної області даних сценарію. Потім процес 1001 передає керування на крок 1026, що одержує поточне значення Покажчика 1020 Варіантів питань із файла дозволів пацієнта. Потім процес 1001 передає керування тесту 1028. Тест 1028 визначає, чи знаходиться варіант питання, обраний ПВП, у наборі питань, отриманому на кроці 1024. Якщо тест 1028 визначає, що бажаний варіант знаходиться в наборі питань, процес 1001 передає керування на крок 1030, що шукає в наборі питання з бажаним рівнем питання. Потім процес 1001 передає керування на крок 1034, що повертає тому, що запитує, обране із набору питання як результат функції. Потім процес 1001 передає керування завершальному вузлу 1036, що повертає керування процесу, що викликає. Якщо тест 1028 визначає, що бажаного варіанта немає в наборі питань, процес 1001 передає керування на крок 1032, що шукає в наборі питання по умовчанню. Потім процес 1001 передає керування на крок 1034, що повертає тому, що запитує, обране із набору питання як результат функції. Потім процес 1001 передає керування завершальному вузлу 1036, що повертає керування процесу, що викликає. Режим Попереднього перегляду Режим Попереднього перегляду є режимом виконання сценарію МВЗ, що дозволяє пацієнту "прогнозувати", тобто розглядати наслідки відповіді перед тим, як "офіційно" дати цю відповідь. Насправді пацієнт може сказати - у будь-який момент сценарію: - "Поясніть мені, до чого привела б ця відповідь". Одне використання Режиму Попереднього перегляду полягає в тому, щоб дозволити пацієнту тимчасово припиняти діалог, що відбувається, щоб упізнати, що означає задане питання. Знання наслідків відповіді допомагає в роз'ясненні наслідків або спрямованості питання. Таким чином, у надрукованій блок-схемі або процедурі один із вірних способів знайти найкращий шлях полягає в тому, щоб заглянути вперед із метою визначити, які наслідки (або рекомендації) буде мати визначена відповідь на питання. Інші використання Режиму Попереднього перегляду полягають у дозволі сценарію відверто попереджати пацієнта, що конкретне питання веде до серйозних наслідків, і використовува ти Режим Попереднього перегляду так, щоб пацієнт міг представляти ефект від кожної відповіді. Наприклад, одна відповідь може почати дію для забезпечення контакту з лікарем пацієнта або для передачі пацієнта службі швидкої допомоги. Якщо сценами може застерегти пацієнта на предмет цих наслідків, то пацієнт може попередньо переглядати ці відповіді без їхньої активізації, і може змінювати напрямок діалогу сценарію. За фіг.20 буде описаний процес 1060. Цей процес показує тільки ті кроки сеансу зв'язку ВЗ, що мають справу з ознакою Режим Попереднього перегляду, що з'являється в кроках, що задають пацієнту питання й обробляють відповідь. Інші кроки сеансу зв'язку В3,:не зв'язані з Режимом Попереднього перегляду, опущені для ясності. Процес 1060 приймає керування в стартовому вузлі 1062. Потім процес 1060 передає керування тесту 1064. Якщо тест 1064 визначає, що більше немає питань, що варто задати, процес 1060 передає керування завершальному вузлу 1066, що перериває Режим Попереднього перегляду. Якщо тест 1064 визначає, що існує питання, що варто задати, процес 1060 передає керування на крок 1068, що виводить питання пацієнту. Потім процес 1060 передає керування на крок 1070, що виводить пацієнту набір відповідей. Потім процес 1060 передає керування на крок 1072, що вводить відповідь пацієнта разом з індикатором, Що показує, хоче або не хоче пацієнт попередньо переглянути дії сценарію для даної відповіді. Потім процес 1060 передає керування тесту 1074. Якщо тест 1074 визначає, що пацієнт відповів, установивши індикатор попереднього перегляду, процес 1060 передає керування на крок 1076. Крок 1076 шукає інформацію попереднього перегляду, що закодована в сценарії (у вигляді частини звичайних текстів питання і відповіді), і видає її пацієнту так, щоб пацієнт бачив або чув описання того, що обрана відповідь спричинить у "реальному" режимі. Наприклад, текст попереднього перегляду може повідомити пацієнту, що "Відповідь ТАК збільшить вашу щоденну дозу медикаменту на наступні 2 тижні". Після того, як текст попереднього перегляду виведений пацієнт), процес 1060 передає керування на крок 1068, що наново задає те ж питання, як описано вище для кроку 1068. Але якщо тест 1074 визначає, що пацієнт відповів, не виставивши індикатора попереднього перегляду, процес 1060 передає керування на крок 1078. Крок 1078 виконує дії, запропоновані для даної відповіді. Потім процес 1060 передає керування тесту 1064, що визначає, чи існує наступне питання, що треба задати, як описано вище для теста 1064. Ознака Відсутності відповіді Кожний діалог МВЗ із пацієнтом управляється сценарієм. У ході звичайного сеансу зв'язку сценарій вибирає питання, виводить його пацієнту, а пацієнт вводить відповідь. Сценарій аналізує відповідь, вибирає ще одне питання, і виводить його пацієнту. Цей діалог, що складається із питань і відповідей, продовжується доти, поки сеанс зв'язку не завершиться нормальним способом. Однак, коли пацієнт раптом ле відповідає в середині діалогу, усі сценарії розраховані на виклик ознаки Відсутності відповіді (ВВ), що відповідає за підхожу дію для продовження для даного сценарію. Ознака ВВ є програмним механізмом МВЗ, що запускається, коли операційна система сигналізує про стан блокування. Механізм ВВ може починати будь-яку кількість дій, що були передбачені сценарієм і можуть змінюватися в ході виконання сценарію. Дії ВВ можуть охоплювати від мовчазного входження в журнал сеансів зв'язку В 3 для використання даних про здоров'я з медичної історії пацієнта і даних про медикаменти і симптоми з таблиці лікувань, до контакту із сусідою пацієнта або найближчою службою швидкої допомоги. Одне використання ознаки ВВ полягає в тому, щоб виконати медичну, специфічну для захворювання і пацієнта, оцінку відсутності відповіді пацієнта. Очевидно, для певних пацієнтів із визначеними захворюваннями (наприклад, проблеми із серцем, травми голови, діабет) несподівана відсутність відповіді пацієнта посеред звичайного діалогу може означати декілька можливостей. Ознака ВВ має спеціальне значення в контексті МВЗ, що деталізує медичну інформацію про пацієнта з попередніх сеансів зв'язку, і в контексті Оптоволоконної підтримуючої системи, що має розширені релевантні бази даних, зазначені географічним розташуванням в усьому світі (наприклад, кабінети швидкої допомоги, служби 911, лікарі, що стрибають на парашуті). По тому, що система знає про пацієнта, ознака ВВ може робити дії, що залежать від ситуації. Дуже простим прикладом є 60-літній пацієнт, що консультується з приводу болі у гр удя х: несподівана відсутність відповіді на питання дає підстави підозрювати зупинку серця і може ініціювати термінові дії, у тому числі виклик місцевої служби порятунку 911. За фіг.21 описується процес 1100. Зауважимо, що процес 1100 показує тільки ті частини кроків сценарію, що характерні для Ознаки відсутності відповіді. Інші кроки сценаріїв опущені для ясності. Процес 1100 приймає керування в стартовому вузлі 1102, що являє собою типовий стартовий вузол будь-якого сценарію. Потім процес 1100 передає керування групі 1104 кроків. Група 1104 кроків являє собою всі дії сценарію, що не звертаються до Ознаки ВВ. Якщо сценарій завершується як частина одного з цих кроків, процес 1100 передає керування завершальному вузлу 1106, що завершує сценарій. Коли один із кроків у групі 1104 кроків хоче задати пацієнту питання, процес 1100 передає керування на крок 1108. Крок 1108 установлює потрібні пізніше показники стану ВВ, якщо пацієнт не зможе відповісти. Джерелом цих показників стану є медична історія 254 пацієнтів, що містить релевантну інформацію для використання в тому випадку, якщо пацієнт не відповість, таку як захворювання пацієнта, стан його здоров'я, прийняті медикаменти, лікар, найближча служба швидкої допомоги, і т.д. Крок 1108 зберігає показники стану ВВ у вигляді множини 264 даних. Потім процес 1100 передає керування тесту 1114. Подробиці кроку 1114 варіюються в залежності від операційної системи й апаратної платформи, але типовою дією є установка ознаки блокування на певний час чекання, передача керування операційній системі і повторне приймання керування, коли операційна система повертає відповідь, або коли минає цей час чекання. Якщо тест 1114 одержує відповідь, процес 1110 передає керування групі 1104 кроків, де продовжуються звичайні дії сценарію. Якщо тест 1114 приймає блокування, процес 1100 передає керування на крок 1116. Крок 1116 шукає дані ВВ, специфічні для пацієнта, захворювання і місця розташування, із множин 264 і 254 даних і виконує запитувані дії ВВ. Коли крок 1116 виконав дії ВВ, процес 1100 передає керування завершальному вузлу 1106, що являє собою типове переривання сценарію через блокування. Матриця PQRST Сер Томас Льюіс сказав, що біль "відомий нам із досвіду й описується ілюстрацією". Здатність кодувати суб'єктивне сприйняття болю в стандартний і повторюваний формат є обов'язковою рисою будь-якої системи автоматичної медицини. Багато діагностичних сеансів зв'язку починаються з того, що пацієнт повідомляє лікарю про деякий вид болю як основної скарги; доскональне описання болю дозволяє швидко поставити або виключити багато діагнозів, використовуючи механізм перегляду таблиці або доступ до бази даних. Ознака Матриці PQRST описує набір програмних процесів і даних, що спільно працюють для кодування опису болю пацієнтом у "больовий код", що є спеціальним способом відформатованою матрицею цілих чисел. Кодування робиться способом, що зберігає суб'єктивну інформацію, так що можна декодувати больовий код за допомогою цілих чисел матриці для відновлення вихідних слів, використаних для описання болю. Больовий код складається з підкодів; кожний підкод ідентифікує один добре визначений приватний аспект сприйняття болю, такий як місце розташування, відчуття, часто та, і т.д. Больові підкоди організовані в специфічну послідовність або формат, відомий усім програмним процесам, що маніпулює больовим кодом. Послідовність, використовувана для кодування аспектів, сама має префікс у вигляді номера послідовності, так що перший аспект матриці завжди ідентифікує схему кодування, використовувану для цієї матриці. Це робить Матрицю PQRST гнучкою і розтяжною, оскільки для задоволення різних потреб можуть використовуватися різні схеми кодування. Будь-який програмний процес, що вимагає декодування PQRST у майбутньому, просто вивчає код першого аспекту і з його значення впізнає схему декодування для інших аспектів. Ознака Матриці PQRST забезпечує кодування описання болю пацієнтів у цифрову форму, придатну для програмних процесів. Приміром, скарга пацієнта на те, що "коли я згинаю праву руку або повертаю зап'ястя, навіть злегка, сильно болить область ліктя, із скриплячими або скреготливими звуками, але без кровотечі", може бути закодована шляхом дозволу пацієнту вибрати слова зі стандартних слів, що описують, (наприклад, "скрип", "щільно", "оніміти") і перетворення обраних слів у масив цілих чисел, подібний (7, 2, 3, 8, 5, 970612, 2, 13). Цей масив представляє числове значення різних аспектів болю, таких як місце розташування, повторювальність, якість, або дату, як 970612. Для будь-якого з даних аспектів число представляє деякий ступінь або описання болю. Таким чином, якщо четвертий аспект представляє Зв'язані-з-рухом-звуки, то значення підкоду "8" може означати "скрип/скрегот, зв'язаний із рухом суглоба". Мітка "PQRST" пристосована з класичного мнемонічного правила, використовуваного студентамимедиками для основних аспектів болю: Р=дратуюча / знесилююча (до чого приводить - до погіршення або до поліпшення); Q = якість (гостра або тупа); R = район (голова, груди і т.д.); S = ступінь тяжкості (від легкої до болючої); і Τ = час (коли почався біль). Ці аспекти представляють стартову точку для Матриці PQRST, що може розширюватися, щоб містити в собі інші корисні суб'єктивні дескриптори захворювання, із багатьма додатковими аспектами, зв'язаними з болем, такими як Причина (інфекція, травма); Маса (дробова, ціла); Розмір (пучка, .м'яч для гольфа); Відчуття (текуча, п ульсуюча) і об'єктивні асоціації (колір, запах, вигляд). Щоб закодувати описання в больовий код, процес: - використовує набір заздалегідь визначених аспектів (тобто граней, елементів, вимірів) болю, - використовує набір заздалегідь визначених аспектних слів, визначених для кожного аспекту, - одержує підхоже аспектне слово від пацієнта, - кодує всі аспектні слова в підкоди, - форматує ці підкоди у вигляді фізичної групи даних (Матриця PQRST), - зберігає Матрицю PQRST у пам'яті або на диску, - використовує адресу місця розташування в пам'яті у вигляді покажчика. Для маніпуляції больовим кодом у цілому програма - передає покажчик Матриці PQRST, - використовує, якщо необхідно, покажчик для доступу до Матриці PQRST. Щоб декодувати больовий код, програма обертає процес кодування: - використовує покажчик для розміщення Матриці PQRST у пам'яті або сховищі, - виймає Матрицю PQRST із пам'яті або з диска, - виймає кожний підкод, - декодує кожний підкод у суб'єктивне аспектне слово, - видає аспектні слова як суб'єктивні описання. За фіг.22 буде описаний процес 1140. Процес 1140 містить кроки, необхідні для створення Матриці PQRST, що представляє оцифровану форму суб'єктивного описання болю пацієнтом. Процес 1140 описується тут для ситуації, коли пацієнт знаходиться в діалоговому режимі і може інтерактивно вводити подробиці суб'єктивного описання болю, коли їх запитує процес 1140. Процес 1140 приймає керування від процесу, що викликає, на стартовому кроці 1142. Крок 1142 є початком циклу, що кодує аспекти болю, уведеш пацієнтом, у погоджений набір больових підкодів. Крок 1142 виділяє простір для Матриці PQRST, що буде містити підкоди. Потім процес 1140 передає керування до кроку 1144, що встановлює наступний аспект болю для кодування. Потім процес 1140 передає керування до кроку 1146, що виймає список стандартних аспектних слів із бази даних 1150 і виводить їх пацієнту у форматі списка для вибору, тобто списка, який пацієнт може вивчити і з якого пацієнт може вибрати одне з аспектних слів. Потім процес 1140 передає керування до кроку 1152, що просить пацієнта вибрати зі списку для вибору аспектне слово, що щонайкраще підходить для суб'єктивного описання пацієнтом больового аспекту, що кодується. Потім процес 1150 передає керування до кроку 1154, що перетворить аспектне слово, обране пацієнтом, у ціле число, що іденти фікує це аспектне слово. Це ціле число є підкодом для поточного аспекту. Це може бути просто індекс обраного аспектного слова в списку для вибору. Потім процес 1140 передає керування до кроку 1156, що вставляє ціле число підкода в Матрицю PQRST на індексну позицію, що представляє аспект, що кодується. Потім процес 1140 передає керування тесту 1158, що визначає, чи є ще які-небудь аспекти для кодування. Якщо тест 1158 визначає, що існують ще аспекти для кодування, процес 1140 передає керування до кроку 1144, щоб почати ще одн у ітерацію тільки що описаного циклу. Якщо тест 1158 виявляє, що більше не залишилося аспектів для кодування, процес 1140 передає керування до кроку 1160, що зберігає або копіює Матрицю PQRST у підхожий набір даних, такий як медична історія 254 пацієнта. Потім процес 1140 передає керування до кроку 1162. Крок 1162 повертає керування процесу, що викликає. За фіг.22б буде описаний процес 1170. Процес 1170 являє приклад кроків, необхідних для використання Матриці PQRST як покажчика для виймання конкретного діагнозу з таблиці захворювань. Цей приклад припускає, що список захворювань (або наборів захворювань, у якому для даного больового коду існує більше одного захворювання) проіндексований за больовим кодом і збережений у базі даних 262 захворювань. Даний приклад також припускає, що існує програмний процес для доступу до бази даних, що може виймати елементи бази даних, коли задано ключ доступу. Одним очевидним прикладом такого механізму доступу до бази даних є відповідним способом відформатоване вираження Структурованої мови запитів (SQL); іншим прикладом є простий масив назв захворювань або покажчик, доступ до якого здійснюється за допомогою покажчика положення кожного елемента. Процес 1170 приймає керування в стартовому вузлі 1172. Потім процес 1170 передає керування до кроку 1174, що завантажує копію Матриці PQRST для використання у виборі діагнозу з бази даних 262. Потім процес 1170 передає керування до кроку 1176, що перетворить больовий код МВЗ у ключ доступу, що відформатований, як потрібно процесу/що здійснює доступ до бази даних 262. Потім процес 1170 передає керування до кроку 1178, що використовує ключ доступу для виймання запису, що відповідає больовому коду, із бази даних 262. Потім процес 1170 передає керування завершальному вузлу 1180, що повертає керування процесу, що викликає. Порядок Ведення захворювання (ПВЗ) Порядок Ведення захворювання є записом даних, що закріплюється за пацієнтом на початку сеансів зв'язку ВЗ, подорожує з пацієнтом із процесу в процес і використовується наприкінці сеансу зв'язку (процесом Закриття сеансу зв'язку) для реалізації рішень і вказівок, прийнятих різними процесами в ході сеансу зв'язку. Запис ПВЗ містить численні поля і зберігається в ділянках сеансів зв'язку баз 264 даних, специфічних для ВЗ (фіг.3). Одне ключове поле ПВЗ, що називається Код, звичайно містить наступний процес, що підлягає виконанню для пацієнта. Одне використання ПВЗ полягає в сигналізації про спеціальну обробку, що необхідна для пацієнта. Приміром, щоб виставити ознаку одноразової вимоги для проведення початкового інтерв'ю з новим пацієнтом, процес Відкриття сеансу зв'язку привласнює полю Код ПВЗ значення "оцінити початкове здоров'я" (фіг.6, вузол 448). Потім процес сеансу зв'язку ВЗ продовжується процесом Оцінювання здоров'я, що перевіряє Код ПВЗ і переводить пацієнта в процес 488 Початкового оцінювання здоров'я (фіг.7). Ще одне використання ПВЗ полягає в повторенні процесів, якщо це необхідно. Приміром, якщо процес Оцінювання кореляції вимагає додаткових даних про здоров'я за інтервал часу між сеансами зв'язку, він може викликати знову Оцінювання здоров'я для одержання відсутніх даних (фіг.12, вузол 660). Коли процес має достатню кількість даних, він привласнює полю Код ПВЗ значення "оптимізувати лікування", і пацієнт виводиться з циклу оцінювання. Ще одне використання ПВЗ полягає в відсліджуванні різних причин для винесених рішень, що може використовува тися процесом Закриття сеансу зв'язку для видання докладних звітів про те, що процеси ВЗ узнали про пацієнта. Наприклад, процес Регулювання лікування може відсилати пацієнта до лікаря з різних причин (фіг. 14, вузли 778 і 784; фіг. 15, вузли 832, 854). У кожному випадку полю Код ПВЗ привласнюється значення "відіслати до лікаря", але полю Причина ПВЗ привласнюються різні значення, що вказують на різні причини. Нарешті, ключовим використанням ПВЗ є представлення вказівок лікаря, тобто збір усіх вказівок, даних у ході сеансу зв'язку, так, щоб вони могли бути реалізовані, коли сеанс зв'язку завершений (фіг. 18, вузол 956). База даних по дозволах База 256 Даних по дозволах (фіг.3) є набором всіх елементів програмного забезпечення, що управляють доступом до даних МВЗ. Ця база даних підтримує ознаки цілості, безпеки, надійності, керування й адміністрування МВЗ у вигляді паролів, прав доступу, необхідних для знання і дозволених для знання роз'яснень, санкцій на перегляд, згод, обмежень, меж і т.д. База Даних по дозволах є інтерфейсом, за допомогою якого обслуговуючий персонал із медичних експертів і програмістів може конкретизувати й управляти тим, які автоматичні дії може, а які не може виконувати МВЗ. Оскільки дозволи управляють діями всіх процесів МВЗ, База Даних по дозволах може використовуватися для динамічного конфігурування системи для запуску в різних режимах, від цілком автоматичного до цілком неавтоматичного, у якому МВЗ повинна питати дозвіл на кожний крок, що робиться. Останній режим особливо корисний при експериментальних, тестови х використаннях, відсліджуванні проблем і перевірці системи. Діям вищеописаних процесів МВЗ відповідають три таблиці Бази даних по Дозволах; вони описуються нижче кожний у своєму розділі: Організаційні Дозволи, Дозволи на спільне користування і Дозволений рівень змін лікування (ДРЗЛ). Організаційні дозволи Організаційні дозволи є наборами даних, гарантуючи х узгодженість МВЗ із всіма організаційними, ліцензійними і правовими вимогами й обмеженнями в тих сферах повноважень, де діє МВЗ. Набори даних Організаційних дозволів організовані по сферах повноважень, і для кожної сфери повноважень визначають, які поля даних можуть бути розкриті якому агентству. Ознака Організаційних дозволів звертається до дуже складного питання, що звичайно інтегрується іншими автоматичними медичними системами, як-от до того, що такі системи можуть вважатися практичною медициною в керуючих сферах повноважень і з проникненням з однієї сфери в іншу, навіть через державні межі, а тому повинні підкорятися великому числу різних обмежень і ліцензій на медичну практику. Ця ознака дозволяє МВЗ погоджуватися з законом у своїх діях і у своїх контактах із пацієнтами, лікарями, організаціями охорони здоров'я, урядовими агентствами і т.д. Організаційні дозволи загальні для МВЗ і можуть використовуватися завжди, коли вони застосовні. Одним прикладом є процес Закриття сеансу зв'язку (фіг.18, вузли 958-964), що повинний розглянути законні вимоги і заборони, що стосуються розкриття конфіденційних медичних даних, перед поширенням зауважень, інструкцій і звітів про сеанс зв'язку ВЗ або про пацієнта. Дозволи на спільне користування Дозволи на спільне користування застосовуються для керування розглядом окремих груп медичних даних. Кожне поле даних у медичній історії пацієнта зв'язано з полем керування доступом, що визначає, чи може ця група медичних даних бути розкрита пацієнту, різним агентам або агентствам і іншим програмним об'єктам з особливими санкціями допуску. Дозволи на спільне користування використовуються процесом Закриття сеансу зв'язку МВЗ (фіг.18, вузли 958, 960), щоб вирішити, які одиниці медичних даних можуть бути розкриті (тобто "спільно використовуватися") у повідомленнях і звітах для пацієнтів, агентів пацієнтів, лікарів, лабораторій, аптек, організацій охорони здоров'я або урядових агентств. Ще одним використанням Дозволів на спільне користування є запобігання розкриттю діагнозу пацієнта в умовах, коли це неприйнятно (фіг.18, вузол 964). Дозволений рівень змін лікування (ДРЗЛ) Дозволений рівень змін лікування (ДРЗЛ) є набором даних, що визначає різні рівні повноважень, що має МВЗ для зміни лікування пацієнта. ДРЗЛ визначає ступінь автономії, що має МВЗ для ведення захворювання пацієнта без попереднього схвалення людиною. Щораз, коли група даних медичної історії пацієнта запитується, скажемо, урядовим агентством або страховою компанією, МВЗ переглядає поле керування доступом цієї групи даних, щоб зрозуміти, який рівень дозволу на спільне користування потрібно для неї. Потім МВЗ консультується з базою даних по Дозволах, щоб перевірити, що агентство, що запитує, має дозвіл на доступ на зазначеному рівні. На найбільш обмежувальному рівні ДРЗЛ вимагає від МВЗ повідомляти лікарю про кожний випадок, коли МВЗ визначає, що пацієнт може виграти від зміни лікування, і одержувати дозвіл, перед тим, як якимсь чином змінити лікування. На найменш обмежувальному рівні ДРЗЛ дозволяє МВЗ автоматично змінювати лікування пацієнта без утручання людини. Значення ДРЗЛ між цими крайніми випадками вимагають різного ступеня попереднього повідомлення і дозволу для різних терапевтичних утр учань. ДРЗЛ використовується усіма функціями МВЗ, що змінюють лікування пацієнта або дають рекомендації зробити це (фіг.15, вузол 830; фіг.16, вузол 896). Метастр уктури Матриця Метадапих З метою обговорення Метафункцій системи медичного ведення структура даних системи, використовувана для запису, відсліджування, аналізу і звітів про медичні проблеми може бути найкращим способом подана у вигляді сітки або матриці, називаної Матриця Метаданих. Ця матриця перераховує по одному виміру (абсциса, або вісь X) причини захворювання (наприклад, травма, інфекція, алергія), позначені як Причина, а по другому виміру (ордината, або вісь Y) перераховує анатомічні системи або органи, що піддаються дії захворювання (наприклад, серцево-судинна, дихальна, нервова), позначені як Анатомія. Потім дане захворювання може розглядатися як комірка Матриці Метаданих, що є перетином відповідних значень Причини й Анатомії. При реалізації як вісь Причини, так і вісь Анатомії, зрозуміло, у сильній мірі підрозділяються. Так, наприклад, інфекційна причина підрозділяється на бактеріальну і вірусну; бактеріальна розбивається на грампозитивну і грамнегативну; грампозитивна додатково розбивається на стрептокок і т.д. до моменту, коли система може ідентифікувати остаточні причини, такі як "менінгококова грамнегативна бактеріальна інфекція". Вісь Анатомії, мабуть, також може підрозділятися на структури органів, органи, тканини, клітини і так далі. Куб Метаданих Оскільки система медичного ведення має багато контактів із даним пацієнтом, додаткові дані про пацієнта розширюють Матрицю Метаданих уздовж третього вимірення, формуючи Куб Метаданих. Вісь часу позначається також як вісь Z. Куб Метаданих є внутрішньою структурою даних, що підтримує різні Метафункції. Подробиці, у залежності від яких модуль медичної системи виконує той або інший тип Метааналізу, змінюються, але всі наступні приклади застосовують: - Декілька епізодів однієї і тієї ж скарги (частотна Метафункція), - Декілька інфекцій у різних анатомічних системах (причинна Метафункція), - Різні скарги в одній і тій же анатомічній системі (анатомічна Метафункція), - Довгострокова історія пацієнта, наприклад, звичка до паління протягом 35 років (волюметрична Мета функція), - Історія хронічного захворювання, наприклад п'ять років спалахів астми або малярії, - Короткострокове прогресування захворювання, наприклад, три дні шлунково-кишкових болів, головних болів, нежиті. Мета функції Мета функції є медично орієнтованими програмними об'єктами, що діють на глобальному рівні всієї системи медичного ведення і різних її модулів. Вони контролюють, записують, відслідковують і аналізують "взаємодію пацієнта із системою" для того, щоб: - оцінювати використання пацієнтом системи, - переглядати комбінації або залежності, що можуть указувати на проблему, - "відходити назад" із метою повністю розглянути взаємодію пацієнта із системою, - аналізувати поточний сеанс зв'язку пацієнта в контексті минулих сеансів зв'язку. Мета функції автоматизують той аспект лікаря, у якому пацієнт розглядається як сукупний складний біомеханізм, дія якого порушена і вимагає коригування протягом деякого часу. Ці функції дають МВЗ потужну можливість аналізувати здоров'я пацієнта в цілому, розробляючи довгострокові медичні діагнози, терапії, рекомендації і стратегії ведення. Частотна Метафункція використовує Ме тафункцію послідовного підсумовування для аналізу частоти консультацій із приводу того самого захворювання. Анатомічна Мета функція аналізує скарги пацієнта на підставі порушених анатомічних систем органів. Причиннонаслідкова ланцюгова Метафункція відслідковує захворювання в зворотному порядку аж до його причини (причин), а потім до інших захворювань (захворювання). Метафункція ділянки і волюметрична Метафункція аналізують зміну в часі показників стану захворювання. Метафункція критичної кривої відслідковує здоров'я пацієнта на наявність значного погіршення шляхом порівняння зі стандартною кривою для контрольованого захворювання. Інтервальна Метафункція оцінює тимчасові інтервали між консультаціями для того самого захворювання. Метафункція надійності оцінює імовірність надійності і цілісності даних. Мета функції, описані для ведення захворювань, використовують ту ж структур у даних "Куб Метаданих", що описана в патенті заявника, озаглавленому "Автоматизована система медичної діагностики і рекомендацій по лікуванню", патент США №5660176. Однак, оскільки ВЗ має іншу спрямованість, воно досліджує інші елементи даних куба, що знаходяться на інших осях. Слово "Мета" указує на загальну природу цих функцій, що сфокусовані на маніпуляції даними про здоров'я не на рівні подробиць, а на рівні довгострокових тенденцій, глобальних схем, статистичних розподілів і інших загальних залежностей. Слово "функція" означає тут різні використовувані обчислювальні й аналітичні методи, що використовують класичну і нечітку логіку, арифметику, геометрію, тригонометрію, аналітичну геометрію, диференціальне числення, статистику, теорію імовірностей, відображення областей значень, перетворення (Фур'є, Лапласа), евристику, рекурсію і т.д. Мета функції реалізовані і втілені у вигляді підхожих структур даних і процесів, таких як бази даних, таблиці, матриці, модулі, об'єкти, сценарії, списки, підпрограми, процедури, функції і т.д. Мета функція послідовного підсумовування Мета функція послідовного підсумовування (ПП) виявляє і підсумовує дії одного пацієнта, що здійснює доступ до окремих модулів усієї системи медичного ведення, таким як діагностичний модуль і МВЗ, оскільки окремі сеанси зв'язку в комбінації можуть представляти значну зміну або погіршення стану пацієнта. Мета функція ПП аналізує комбіновану дію окремих модулів і може дати рекомендацію на підставі цього глобального аналізу. Мета функція ПП використовує заздалегідь установлені пороги для різних комбінацій системних модулів, що підсумовуються. Ці пороги містяться у внутрішній таблиці, що перераховує всі комбінації модулів, такі як медична діагностика + ведення захворювання, медична діагностика + медична аудіо/відео/образотворча бібліотека, медична діагностика + консультація по таблиці лікувань і т.д. Приміром, якщо модуль Медичної діагностики був викликаний для консультації по задишці і продіагностував астму, а модуль ВЗ був пізніше використаний для ведення астми і модуль Медичної аудю/відео/образотворчої бібліотеки був декілька разів викликаний для консультації по записаних повідомленнях щодо астми, Мета функція ПП використовує значення з таблиці по ' комбінації медична діагностика+ведення захворювання+медична аудіо/відео/ образотворча бібліотека для астми для розрахунку порога для запуску спеціальних рекомендацій. Таким чином, навіть хоча в жодному з модулів поріг не був досягнутий, поріг досягається, коли консультації з приводу астми в діагностичному модулі, модулі ведення захворювання й аудіо/відео/образотворчій бібліотеці комбінуються і розглядаються разом. Частотна Мета функція Частотна Мета функція переглядає число випадків, коли пацієнт звертався за консультацією до системи, і дає рекомендації на підставі цієї частоти консультацій. Ця функція обчислює, скільки разів пацієнт взаємодіяв із системою на предмет того самого захворювання або скарги, для консультації за допомогою медичного аудіо тексту або консультації за допомогою таблиці лікувань, використовує Мета функцію послідовного підсумовування для аналізу комбінованого ефекту цих консультацій і може дати рекомендацію на підставі цього глобального аналізу. Коли пацієнт допущений до системи медичного ведення, для кожного контрольованого захворювання встановлюється граничне значення кількості консультацій (вхідних і ви хідних) за одиницю часу. Це граничне значення різне для кожного захворювання і змінюється за допомогою установки коефіцієнта чутливості. Якщо це граничне значення досягнуте, частотна Мета функція дає рекомендацію. Тобто самий факт того, що пацієнт мав певну кількість проявів симптому даного типу, може спричинити за собою рекомендацію від частотних Мета функцій. Інтервальна Мета функція Інтервальна Метафункція аналізує інтервали часу між кожними взаємодіями для того ж самого захворювання для виявлення тенденцій, то можуть указувати на проблему. Приміром, якщо ця функція виявила, що взаємодії пацієнта із системою стали відбуватися усе часті ше і частіше, функція може дати рекомендацію, базуючись тільки на цьому факті. Використовується спосіб серій послідовного підсумовування. Вичерчується інтервал між консультаціями, і рекомендація робиться тоді, коли інтервали стають коротшими. Причинна Метафункція Причинна Метафункція є фоновою задачею ВЗ, що шукає захворювання або комбінацію причин, що можуть допомогти ідентифікувати основні причини. Ця функція відслідковує й аналізує використання пацієнтом різних системних модулів. Причинна Метафункція ідентифікує серії послідовного підсумовування з інтервалами часу, що зменшуються, між медичною діагностикою, веденням захворювання, бібліотекою медичних аудіотекстів, консультаціями за допомогою таблиці лікувань і всіх їхні х комбінацій. Наприклад, припустимо, що пацієнт консультувався із системою по декількох випадках, із скаргами на різні частини тіла, і що в ході кожного сеансу зв'язку модуль медичної діагностики (належним способом) визначав, що кожна окрема проблема викликана інфекцією. Причинна Метафункція виявляє такі серії консультацій і - якщо їхня кількість досягає встановленого граничного значення за одиницю часу - сигналізує системі, що основна причина може лежати в області імунної системи пацієнта. Якщо система обслуговує пацієнта з численними травматичними епізодами, причинна Метафункція допоможе системі припустити можливість зловживання пацієнтом наркотиками або алкоголем. Анатомічна Метафункція Анатомічна Метафункція аналізує контакти пацієнта з медичною системою з точки зору одного органа або анатомічної системи тіла. Ця функція шукає різні контрольовані захворювання, що можуть уражати ту саму анатомічну систему. Ця функція автоматизує той аспект ВЗ, що найчастіше, коли різні захворювання впливають на той самий орган, необхідно відслідковувати і часто вимірювати функціонування цього органа. Приміром, якщо пацієнт консультується в модулі медичної діагностики з приводу трьох різних випадків хвороб в області живота, блювоти і поносу, анатомічна Метафункція розпізнає, що всі ці проблеми торкаються шлунково-кишкового тракту, і може змусити систему відрегулювати свої рекомендації на підставі цієї додаткової інформації. Наприклад, і цукровий діабет, і гіпертонія викликають повільне і прогресуюче погіршення функції нирки. Анатомічна Метафункція виявляє потребу в такому спеціальному відслідковуванні. Базуючись на деяких внутрішніх установлених заздалегідь граничних значеннях, аналіз анатомічної Метафункції може змусити систему ведення захворювань рекомендувати оцінювання функцій ураженого органа. У вищенаведеному прикладі, для пацієнта з веденням діабету і гіпертонії, аналіз анатомічної Метафункції може змусити систему медичного ведення рекомендувати з підхожими інтервалами креатининову сироватку, перевірку функції нирок. Причинно-анатомічна Метафункція Причинно-анатомічна Метафункція координує взаємодію між причинною й анатомічною Мета функціями. Оскільки причинна й анатомічна Метафункції взаємодіють тісніше, їхня взаємодія описується тут. Коли пацієнт використовує систему медичного ведення в часі, комірки причини/анатомії накопичуються по осі часу, або осі Z, що відслідковує момент часу, коли в пацієнта виявляється перетин причинної й анатомічної систем, тобто створення діагнозу. Куб Метаданих представляє суму взаємодії пацієнта із системою в часі. Хоча багато чого з минулої історії пацієнта зберігається за допомогою кодів ICD-9-CM а також загальноприйнятих текстових рядків у полях медичного запису пацієнта,' цей метод дозволяє виконувати дуже корисні аналізи. Важливо зауважити, що система може бути здатна приписати проблемі причину, не знаючи порушеної анатомічної системи, і що система може зазначити, який орган або система органів порушена, не знаючи причини проблеми пацієнта. Наприклад, шестирічна дитина, що скаржиться на м'язові болі, головну біль, нежить і болі в суглобах із найбільшою імовірністю має вірусну інфекцію, але складно вказати на конкретну систему органів, у яких вона виявляється. Цікаво, що при веденні захворювання в діагностичному модулі і при пошуку декількох проблем, що з'являються в тому самому модулі, виробляються різні комбінації. Приміром, діабет може бути представлений при перетині ендокринної і судинної систем. Іншим же способом візуалізувати процес захворювання при діабеті є наступний додатковий крок. Щораз, коли система медичного ведення представляє, що інший процес захворювання (подібний діабету) впливає на судинну систему, "судинний" шукається як Причина додаткового захворювання. Мета функція причинного ланцюга Мета функція причинного ланцюга автоматизує аналіз того медичного факту, що певні захворювання роблять патологічні зміни в інших органах тіла, що означає, що захворювання може бути причиною інших захворювань або визиватися іншими захворюваннями. Наприклад, Метафункція причинного ланцюга розглядає захворювання і як причину, і як слідство, і виконує три аналізи для даного захворювання D: 1. Знайти основну причину D. 2. Знайти інші захворювання, викликані D. 3. Рекурсивно повторювати кроки 1 і 2 для знаходження інших основних причин і інших захворювань, викликаних D. У такий спосіб аналіз ланцюгової Мета функції відслідковує загальний вплив. У такий спосіб аналіз ланцюгової Метафункції відслідковує загальний вплив захворювання на організм. Він використовує причинну Ме тафункцію (яка використовується для виявлення безпосередньої єдиної причини скарги або захворювання) для рекурсивного пошуку віддалених причин і захворювань. При заданому початковому захворюванні аналіз ланцюгової Метафункції використовує Куб Ме таданих для виявлення комбінацій, що дозволяють аналізу йти обернено по причинному ланцюжку для виявлення інших можливих проблем у пацієнта. Таким способом виконується аналіз, необхідний для виявлення зв'язаних проблем, що до цього часу були замасковані або ще не були розкриті. Внутрішня причинно-наслідкова таблиця, використовувана причинно-наслідковою Метафункцією, містить фундаментальні медичні знання про анатомічні системи, їх зв'язки, їх захворювання, і причинні ланцюжки захворювань. Ця таблиця ідентифікує комбінації, що необхідно вивчити на наявність основних причин і вторинного захворювання. Друга таблиця, використовувана в керуванні опрацюванням причинних ланцюжків, містить інші дані, такі як імовірність виникнення, серйозність вторинних захворювань, і можливі терапевтичні вікна. Результатом обчислення Метафункції причинного ланцюга є список захворювань, що варто шукати і контролювати в поточного пацієнта. Ці результати корисні для того, щоб: - гарантувати, що побічні ефекти захворювання не упущені, - не пропустити головне лікування захворювання, необхідне для стабілізації пацієнта, - підтвердити причини шляхом перевірки інших наслідків (головний біль значимий при апендициті), - заперечити причину при невиявленні необхідних наслідків (відсутність плазмодіїв у крові виключає малярію). Мета функція ділянки Приклад Метафункції ділянки може бути описаний у вигляді гра фіка болю або нездужання в часі, а потім інтегрування ділянки під кривою для одержання загального розміру страждання або нездужання. Це важливо, оскільки багато пацієнтів, зокрема, із невиліковними захворюваннями, такі як пацієнти з кінцевою стадією раку, постійно відчувають біль, але вони ізольовані, не ходять до лікаря регулярно, або їхній лікар не розуміє, наскільки страждає пацієнт. Вони прагнуть "упіймати біль", але ніколи не доганяють її. І як тільки межа страждань досягнута, пацієнт може прийняти наркотичний анальгетик або збільшити дозування. Волюметрична Метафункція Волюметрична Метафункція виконує аналіз на підставі (тривимірного) добутку захворювання ´ анатомія ´ час і дає рекомендації на підставі заздалегідь установлених порогів. Слово "волюметрична" указує на використовуваний спосіб аналізу Куба Метаданих, при якому історія паління представляється у вигляді об'єму, укладеного між трьома осями Ρ (отрута), R (дихальна система) і Ζ (час). Приміром, пацієнт, що палив протягом 30 років по дві пачки щодня, вважається тим, що має 60 пачко-років впливу на дихальну систему. Волюметричний аналіз важливий для багатьох процесів захворювань. Так, пацієнт з об'ємом паління 60 пачко-років нагромадив значну руйнацію дихальної системи. Чим довше це продовжувалося, тим більше об'єм, тим більше кількість отрути впливає на функціонування дихальної системи, і тим більше ймовірні будуть визначені діагнози або лікування. Іншим прикладом волюметричного аналізу є довгострокова руйнація, що викликається діабетом у мікросудинному кровообігу. Програмна реалізації волюметричної Метафункції містить у собі різні внутрішні таблиці ведення захворювань, що містять волюметричні добутки для різних захворювань, а також граничні показники стану. Ці пороги (динамічно змінені установкою коефіцієнта чутливості) управляють спеціальними діями й аналізами системи. Коли досягнутий поріг, система виконує спеціальні аналізи, а потім подає внутрішні сигнали тривоги для пошуку можливих свідчень руйнації, зроблених стосовно системи (систем) органів, і для повідомлення пацієнту спеціальних рекомендацій. Мета функція надійності Мета функція надійності розглядає надійність усіх даних пацієнта, щоб зрозуміти, чи є обслуговування пацієнта неадекватним. Ця функція може рекомендувати повторне оцінювання пацієнта, якщо вона виявляє, що (окремі або комбіновані) імовірності діагнозу нижче порога надійності (зміненого установкою коефіцієнта чутливості). Ця функція використовує внутрішні Індикатори надійності, зв'язані з кожною групою даних, що відслідковують імовірність того, що гр упа даних відбиває реальний стан здоров'я пацієнта на момент часу, коли вона була записана. Ці Індикатори надійності встановлюються в системі медичного ведення для кожної групи даних, коли вона установлюється вперше, і залишаються зв'язаними з ній протягом всього існування цієї групи в системі. Приміром, якщо пацієнт повідомляє системі, що в нього головний біль через мігрень, система може запитати пацієнта: - Хто поставив діагноз "мігрень" (сам пацієнт, друг, медсестра, лікар, невропатолог)? - Які тести були проведені, ким, на яких тканинах, із якими результатами? - Хто підтверджував тести, як, у якому контексті? Ідея, звичайно, полягає в тому, що якщо фахівець по головним болям поставив діагноз після повного обстеження, у тому числі обстеження мозку, пункції поясничного відділу хребта, електроенцефалограмі і т.д., то імовірність того, що діагноз поставлений, правильно, дуже висока. Це буде записано в Індикаторі надійності і зв'язано з діагностичною групою даних. Якщо надійність занадто низька, пацієнту буде призначене повторне оцінювання на більш високому рівні, що викликає більш точне і ретельне опитування. Переваги Ведення захворювань Система медичного ведення і модуль Ведення захворювань мають такі переваги; Переваги для пацієнтів - більш швидкі, прості, дешеві медичні послуги, - медичне обслуговування, доступне в години, коли всі установи закриті, із дому, коли потрібно, - медичне обслуговування, доступне у віддалених місцях, бідних співтовариства х, - новітні, найкращі, перевірені, модернізовані медичні послуги, - пацієнти можуть мати у своєму розпорядженні свій час, повторювати сеанси зв'язку, вести перегляд, - пацієнти мають повну медичну історію у файлі. Переваги для тих, що надають медичні послуги - зменшення тривіальних, невідповідних, марних контактів із пацієнтами, - відточування діагностичної майстерності/досвіду лікаря, - лікар може порівнювати свою думку з іншими, - повторні пацієнти пропонують більш якісні, безупинні медичні записи, - провайдери мають доступ до більшої кількості ресурсів медичних даних, - комп'ютер підтримує доступ до статистики, баз даних, прийняття рішень, призначення, прийому, - доступна історія сеансів зв'язку і захворювань, - провайдери можуть підтверджувати рекомендації/дії на підставі зафіксованих відповідей, - можна порівнювати пацієнтів у популяціях, - є великі бази даних випадків. Переваги для медичних менеджерів - заощаджуються витрати на тривіальні контакти, - відслідковуються контакти, - статистична інформація і планування, - уявлення практики лікаря/лікарні, - журнали сеансів зв'язку знижують правову відповідальність і незахищенвсть, - забезпечується узгодження зі страховими полісами, - стандартизація рекомендацій і лікувань. Переваги для регуляторів охорони здоров'я - дії організацій охорони здоров'я і лікарів можуть проглядатися й оцінюватися, - медичні записи доступні для критики, - можна перевіряти відповідність нормам. Переваги для викладачів охорони здоров'я - медична практика може моделюватися на великих популяціях пацієнтів, - допомога у вивченні медицини, - можна порівнювати вивчення випадків, - розгляд випадку можна повторити, вносячи зміни. Хоча вищенаведений опис показав, розглянув і відзначив фундаментальні . нові ознаки винаходу в застосуванні до різних виконань, варто розуміти, що фа хівцями можуть бути зроблені різні опущення, заміни і зміни у формі і подробицях проілюстрованої системи без відходу від духу й об'єм у винаходу.
ДивитисяДодаткова інформація
Назва патенту англійськоюSystem for managing disease process
Назва патенту російськоюСистема для контроля течения болезни
МПК / Мітки
МПК: G06Q 50/00
Мітки: вибору, допомогою, діагностики, автоматизований, керування, варіанти, оптимізації, шляхом, лікування, спосіб, захворювань, медичної, здійснення, способів, система, лікуванням
Код посилання
<a href="https://ua.patents.su/49-64743-avtomatizovanijj-sposib-keruvannya-likuvannyam-varianti-ta-sistema-keruvannya-likuvannyam-zakhvoryuvan-varianti-shlyakhom-zdijjsnennya-sposobiv-optimizaci-likuvannya-i-medichno-dia.html" target="_blank" rel="follow" title="База патентів України">Автоматизований спосіб керування лікуванням (варіанти) та система керування лікуванням захворювань (варіанти) шляхом здійснення способів оптимізації лікування і медичної діагностики за допомогою вибору варіанті</a>
Спосіб діагностики хвороб, що передаються статевим шляхом (сифіліс, снід, гепатит в та інші) та автоматизований пристрій для його виконання
Номер патенту: 23350
Опубліковано: 31.08.1998
Автори: Клімов Сергій Анатольович, Мавров Іван Іванович, Тацька Лариса Семенівна
МПК: A61B 10/00, A61B 5/15, G01N 33/49
Мітки: статевим, автоматизований, діагностики, снід, сифіліс, інші, пристрій, шляхом, спосіб, виконання, хвороб, гепатит, передаються
Формула / Реферат:
1. Способ диагностики болезней, передающихся половым путем (сифилис, СПИД, гепатит В и др.) путем иммунологического и биофизического исследований сыворотки крови, отличающийся тем, что для повышения стабильности, точности, надежности, специфичности соединяют испытуемую сыворотку (антитела) с соответствующим антигеном (антигенами), например сухой трепонемный и кардиолипиновый антигены при сифилисе, и комплементом без индикаторной системы...
Спосіб керування потужністю в замкненій системі керування потужністю системи зв’язку з режимом паралельного доступу з кодовим розподілом каналів (пдкр) (варіанти) та замкнена система керування потужністю систем
Номер патенту: 57747
Опубліковано: 15.07.2003
Автор: Сеінтс Кіт В.
МПК: H04B 7/00
Мітки: режимом, системі, систем, керування, розподілом, спосіб, кодовим, паралельного, замкнений, пдкр, зв'язку, замкнена, потужністю, система, каналів, доступу, варіанти
Формула / Реферат:
1. Спосіб керування потужністю в замкненій системі керування потужністю системи зв'язку з режимом паралельного доступу з кодовим розподілом каналів (ПДКР), який полягає в:вимірюванні значення енергії у смузі частот,вимірюванні енергії пілот-каналу,перерахунку зазначеної енергії пілот-каналу відповідно до значення пілотної складової для одержання значення неперешкоджаючої енергії.відніманні зазначеного значення...
Система приведення до руху за допомогою рідкого середовища для прискорення, а також керування спрямуванням рідкого середовища (варіанти)
Номер патенту: 44788
Опубліковано: 15.03.2002
Автор: Джесвайн Уілльям В.
МПК: B64C 23/00, B63H 25/06
Мітки: варіанти, керування, також, середовища, рідкого, приведення, допомогою, система, прискорення, руху, спрямуванням
Формула / Реферат:
1. Система приведення до руху за допомогою рідкого середовища для прискорення, а також керування спрямуванням рідкого середовища, що містить:безперервну динамічну поверхню для циркуляції через рідке середовище від зони забору, де рідке середовище підводять до динамічної поверхні, після чого рідке середовище поблизу від поверхні прискорюється так, щоб створити шар прискореного рідкого середовища через зону тяги, де прискорене рідке...
Спосіб зниження рівнів ліпідів та лікування хвороб, пов’язаних з ними, за допомогою аналогів сибутраміну (варіанти) та фармацевтичний препарат (варіанти)
Номер патенту: 63916
Опубліковано: 16.02.2004
Автори: Джонс Стефен Поль, Келлі Петер Фініан
МПК: A61P 3/10, A61P 3/06, A61K 31/135
Мітки: фармацевтичний, ліпідів, допомогою, аналогів, спосіб, пов'язаних, варіанти, сибутраміну, препарат, зниження, ними, рівнів, хвороб, лікування
Формула / Реферат:
1. Спосіб профілактики і/або лікування гіперліпідемії, гіперхолестеринемії або гіпертригліцеридемії, який полягає у введенні людині, яка цього потребує, терапевтично ефективної кількості сполуки формули (І): (I)або її енантіомерів і фармацевтичнo прийнятних солей, в яких R1 і R2 є незалежно Н або метилом, у поєднанні з фармацевтичнo прийнятним розчинником або носієм.2. Спосіб згідно з п. 1, в якому сполукою формули (І) є...
Спосіб обміну даними, драйвер пристрою (варіанти), система обробки даних і приймач/декодер (варіанти) для його здійснення
Номер патенту: 63965
Опубліковано: 16.02.2004
Автори: Мерік Жером, Деклерк Крістоф
МПК: G06F 13/38, G06F 13/14, H04L 29/02, G06F 13/10, H04N 5/44
Мітки: даними, здійснення, обробки, спосіб, варіанти, система, пристрою, драйвер, обміну, даних
Формула / Реферат:
1. Спосіб обміну даними через драйвер пристрою між прикладною програмою і інтерфейсом, що має щонайменше один засіб, якому присвоюється відповідний інтерфейсний ідентифікатор, причому присвоєний згаданому засобу інтерфейсний ідентифікатор може бути змінений після щонайменше однієї події, який включає: для щонайменше одного згаданого засобу, збереження відповідного логічного ідентифікатора; передавання згаданого логічного ідентифікатора в...
Попередній патент: Спосіб одержання екстрактів із рослинної сировини та мобільна установка для його здійснення
Наступний патент: Лікарський препарат, що містить ліпофільний інертний газ
Випадковий патент: Інтерференційний фільтр авсва-123r456т