Девід Ларо, президент і генеральний директор Medicomp Systems – Серія інтерв’ю

Девід Ларо, президент і генеральний директор Medicomp Systems, є виконавчим директором у сфері охорони здоров’я та підприємцем з кар’єрою, що охоплює майже п’ять десятиліть. Після початку своєї кар’єри в області комп’ютерної аудиту та управління він заснував Dexcom Systems у 1987 році, допомігши розгорнути деякі з перших корпоративних мереж зв’язку та великомасштабних середовищ LAN для організацій, таких як Світовий банк, DuPont та лікарня Синай. Він приєднався до Medicomp Systems у 1995 році як операційний директор і був призначений генеральним директором у 2012 році, очолюючи еволюцію компанії від піонерського постачальника клінічної знань до сучасної компанії з охорони здоров’я та штучного інтелекту та інтероперабельності. Під його керівництвом Medicomp розширив свій глобальний охоплення, просунув рішення клінічної інтелекту на основі доказів та зосередився на поліпшенні продуктивності клініцистів, зручності використання даних та догляду за пацієнтами завдяки розумнішій технології охорони здоров’я.

Medicomp Systems є компанією з технологій охорони здоров’я, найбільш відомою своїми клінічними знаннями та технологією знань, яка перетворює складні, фрагментовані дані охорони здоров’я на структуровані, клінічно значимі відомості. Заснована на патентованому клінічному двигуні знань MEDCIN, флагманська платформа Quippe компанії допомагає організаціям охорони здоров’я покращувати клінічну документацію, інтероперабельність, вимірювання якості, корекцію ризику та рішення, що підтримуються штучним інтелектом. Розроблена для відображення того, як клініцисти думають і працюють, рішення Medicomp використовуються лікарнями, системами охорони здоров’я, постачальниками ЕР та організаціями охорони здоров’я по всьому світу для оптимізації робочих процесів, зменшення адміністративного навантаження та надання більш значимих відомостей про пацієнтів на місці надання медичної допомоги. Компанія стала визнаним лідером у поєднанні клінічних графів знань, структурованих даних та штучного інтелекту для підтримки більш точного, ефективного та надійного прийняття рішень у сфері охорони здоров’я

Ви провели майже чотири десятиліття, працюючи в сфері інформаційних технологій охорони здоров’я, від перших корпоративних мереж зв’язку та медичних систем розрахунку до керівництва Medicomp Systems понад 30 років. Оглянувшись на цю еволюцію, яку фундаментальну проблему даних охорони здоров’я, на вашу думку, галузь ще не вирішила?

Галузь охорони здоров’я все ще не має інтегрованого стандарту клінічних даних. Термінологічні стандарти, на які ми спираємося, були створені для вирішення проблем кодування в рамках однієї області: ICD-10 для діагнозів, CPT і HCPCS для процедур і тестів, LOINC для результатів лабораторних досліджень та інших вимірювань, RxNorm для ліків, і SNOMED CT для клінічних висновків. Кожен з них був створений для кодування, класифікації або дослідження. Ніхто з них не був створений для організації догляду за пацієнтом.

Системи охорони здоров’я використовують ці стандарти для виконання конкретних транзакцій, більшість з яких пов’язані з відшкодуванням, а не для надання постачальникам інтегрованого огляду стану пацієнта. Розгляньте пацієнта з цукровим діабетом. Дані цього пацієнта розподілені по окремих вкладках у системі охорони здоров’я, без єдиного “виду діабету”, який би об’єднав все, що пов’язано з цим станом. Системи кодування не мають спільної схеми, що робить їх обчислювально неефективними, і ця неефективність стає ще більшим проблемою у світі клінічного штучного інтелекту. Штучний інтелект залежить від добрих даних, і нашій галузі ще не вистачає їх.

Представіть собі склад Amazon (AMZN ), який намагається працювати без одиниць зберігання товарів (SKU), спираючись замість цього на текстові описи кожного предмета, кожен опис пов’язаний з даними структури, які змінюються від одного типу предмета до іншого. Практично кожна галузь має якусь версію SKU. Охорона здоров’я не має, і тому її дані залишаються фрагментованими та несумісними.

Ви описали багато сучасних репозиторіїв охорони здоров’я як “болотисті дані” замість дієвої даних. Які найбільші архітектурні помилки, яких допустили системи охорони здоров’я під час поспішного централізації даних?

Основна помилка полягала в організації репозиторію так само, як і джерельні системи, навколо доменів і транзакцій, а не навколо пацієнта. Більшість систем охорони здоров’я все ще розділяють клінічну інформацію на окремі домени, такі як лабораторні дослідження, ліки, процедури та діагнози. Користувачі та програмне забезпечення, на яке вони спираються, повинні потім діставати інформацію з різних файлів і місць, щоб зібрати картину пацієнта, що робить кожний процес повільнішим і більш трудомістким.

Глибша проблема полягає в тому, що кожна транзакція, будь то рахунок, рецепт, замовлення тесту або лабораторний результат, зберігається як самодостатній елемент, а не як частина інтегрованого огляду стану пацієнта. Централізація цих даних в одному місці не вирішує проблему. Дані, які зберігаються в одному місці, стають “болотистими”, оскільки обсяг сам по собі, без клінічної організації, не дає розуміння.

Більша частина клінічно значимої інформації все ще міститься всередині лікарських нотаток, звітів зображень та підсумків виписки, а не структурованих полях. Чому галузь так сильно бореться з оперативним використанням некрокодованих клінічних даних у великому масштабі?

Ця ситуація змінюється, і швидко. Великі мовні моделі (LLM) тепер можуть генерувати текстові підсумки зустрічей, вільні від абревіатур і ідіоматичних скорочень, що робить клінічну обробку природної мови (NLP) значно легшою. У минулому захоплення структурованих даних означало, що клініцистам потрібно було працювати з переліком або формами, які вони вважали незручними та практично непридатними.

Сьогодні послідовність працює інакше. Амбієнтне прослуховування генерує досить чисту текстову нотатку, LLM підсумовує цю нотатку у напівструктуровану форму, а потім NLP працює над підсумком. Коли NLP спрямована на відповідну клінічну ціль даних, яка представляє клінічні концепції, а не плоский список кодів, вона може генерувати добре структуровані дані з нарративного тексту. Досягнення цього все ще потребує комбінації технологій, які працюють разом, і воно залежить повністю від наявності відповідної клінічної цільової інформації.

Ви стверджуєте, що основна проблема полягає не в “якості даних”, а в фрагментації даних. Чи можете ви пояснити різницю та чому це розрізнення має значення для систем охорони здоров’я, що підтримуються штучним інтелектом?

Ці два поняття тісно пов’язані, проте вони описують різні проблеми, і ця різниця має велике значення для штучного інтелекту. Якість даних полягає в тому, чи є окремий шматок інформації точним, повним та правильно зареєстрованим. Фрагментація даних є структурною. Фрагментація відбувається, коли клінічна інформація, незалежно від її якості, розділяється по окремим доменам і системам кодування та зберігається в різних форматах і місцях.

Ця фрагментація є поточною практикою, оскільки кожна система кодування була розроблена для окремої транзакційної справи. Підхід був достатнім для написання рецепта, генерації рахунку або обробки інших дискретних завдань. Загальне лікування пацієнта є іншою проблемою, яка вимагає інформації з кількох доменів, щоб бути об’єднаною, обробленою та відображеною як єдина, діагностично пов’язана картина пацієнта. Запис може бути повним окремих точних даних, але все одно не відповідати клініцисту, оскільки нічого не з’єднує ці точки в цю картину.

Ви виділили три основні прогалини в більшості даних охорони здоров’я: витягання нарративу через NLP, клінічні графи знань та примирення суперечливих записів. Яка з цих відсутніх можливостей зараз має найбільший вплив на догляд за пацієнтами?

Дві з трьох тісно пов’язані: примирення суперечливих записів та те, що клінічний граф знань є лише настільки добрим, наскільки добрі дані, на яких він працює. З трьох примирення зараз робить найбільшу шкоду вниз по течії, оскільки воно знаходиться вгору по течії від усього іншого.

Багато того, що існує в картці пацієнта, було введено шляхом копіювання та вставлення з попередніх зустрічей або шляхом консолідації інформації з кількох постачальників. Переміщення цієї інформації між системами з використанням Fast Healthcare Interoperability Resources (FHIR) робить її легше надсилати та отримувати, проте це нічого не робить для поліпшення якості даних. Виконання штучного інтелекту або клінічного графа знань на цій інформації, ймовірно, приведе до того, що несумісності будуть перенесені вперед.

Розгляньте пацієнта з діабетом, який оцінюється за ретинопатію або катаракту. Ця оцінка не означає, що пацієнт має діабетичну катаракту, оскільки катаракта може бути пов’язана з віком, а не з діабетом. LLM може пропустити цю відмінність, і хибна асоціація потім потрапляє в картку пацієнта і залишається там, коли вона переміщується між системами. Клінічний граф знань, який працює на поганих даних, поверне погані результати.

Стандарти, такі як SNOMED CT, LOINC, RxNorm, FHIR та C-CDA, часто обговорюються як рішення для інтероперабельності. На практиці чому багато організацій все ще борються з перетворенням стандартної відповідності в клінічно корисні системи?

Багато систем і організацій несуть погано закодовані дані, оскільки їхні інтерфейси роблять найлегшим вибір першого представленого елемента. Ці інтерфейси розроблені для руху коду якомога швидше для оплати, а не для забезпечення клінічного контексту, який би дозволив користувачеві точно записати стан.

Наприклад, ICD-10 містить код для “спадкової моторно-чутливої невропатії”, категорії, яка не розрізняє хворобу Шарко-Марі-Тута від синдрому Руссі-Леві, хоча обидва входять до неї. Якщо інтерфейс користувача поверхнево показує цю категорію і робить вибір конкретного стану більш складним, користувач, ймовірно, вибере категорію. Категорія може бути достатньою для оплати претензії, проте вона значно менш клінічно корисна, ніж конкретний стан. Усі транзакційні терміни мають певну версію цієї проблеми.

Запис найбільш конкретного стану залежить від системи та дизайнерів інтерфейсу користувача, і з часом він спускається вниз у їхньому списку пріоритетів. Поки транзакції продовжують виконуватися, а претензії оплачуються, стимул для дизайну клінічної специфіки зникає.

Medicomp провела роки, будуючи клінічно пов’язані термінології та двигуни актуальності навколо систем, таких як MEDCIN. Наскільки важливий клінічний граф знань для того, щоб штучний інтелект охорони здоров’я був надійним і контекстно-обізнаним?

Клінічний граф знань є необхідним, оскільки він робить дані корисними в момент, коли клініцист або рецензент їх потребує. Тест простий. Коли пацієнт має певний стан, який обробляється, чи може користувач побачити все, що пов’язано з цим станом, чи йому потрібно сортувати весь запис, вкладку за вкладкою, щоб відновити клінічний контекст? Клінічний граф знань, побудований на чистих клінічних даних, може поверхнево показати цей контекст за одну мить. Без нього пошук тієї ж інформації займає занадто багато часу.

Це пояснює, чому кожен раз, коли я відвідую свою мега-лікарню, мене просять заповнити чотиристорінковий, шестисекційний медичний історичний формуляр з тією ж інформацією, яку я надав місяць тому. Знаходження чогось у поточних системах охорони здоров’я просто занадто складно. Medicomp провела понад 45 років, будуючи MEDCIN і свій клінічний граф знань, щоб закрити саме цю прогалину, щоб штучний інтелект, який працює на чистих, пов’язаних даних, міг бути як надійним, так і обізнаним про клінічний контекст пацієнта.

Багато організацій охорони здоров’я зараз розгортають генеративні штучні інтелекти та амбієнтні системи документації. Які ризики виникають, коли ці системи штучного інтелекту тренуються або працюють на фрагментованих, погано контекстно-пов’язаних клінічних даних?

Галюцинація та неправильна категоризація інформації є двома найбільш поширеними ризиками, і обидва стають більш ймовірними, коли основні дані фрагментовані та погано контекстно-пов’язані.

Особистий приклад: мій батько помер від раку печінки у віці 78 років, проте під час недавнього візиту мене запитали, як довго я був у ремісії. Амбієнтна система документації записала особисту історію раку печінки в моєму власному картці. Колега зіткнувся з чимось подібним. У нього було записано хронічне обструктивне захворювання легень (ХОЗЛ) в його записі, оскільки його постачальник, який використовував амбієнтну документацію, замовив рентген легень, щоб виключити ХОЗЛ. Коли він пізніше подав заяву на страхування життя, йому було відмовлено, і причиною було вказано діагноз ХОЗЛ, який раніше був випадково сформований замовленням рентгену.

Помилки контексту можуть бути ще дивнішими. У одному недавньому випадку пацієнт-чоловік, який згадав, що їв яйця на сніданок, був перекласифікований як жінка, ймовірно, тому, що система асоціювала слово “яйця” з жіночною біологією. Кожна з цих помилок легко посміятися в ізоляції. Як тільки вони записуються в картку та обмінюються між системами, вони перестають бути смішними.

Є зростаючий інтерес до національного прогресу інтероперабельності, з сотнями мільйонів записів, які зараз обмінюються щороку. Що ще потрібно зробити, щоб клініцисти могли дійсно довіряти, що обмінювані дані є повними, точними та клінічно значимими на місці надання медичної допомоги?

Дві речі повинні статися. По-перше, постачальники, які підписують зустрічі, які все частіше генеруються інструментами амбієнтного прослуховування з підсумовуванням LLM, повинні мати швидкі та легкі в користуванні поручні перед підписанням, у моменті прямо перед тим, як ці дані потраплять до картки пацієнта. Як тільки неправильна інформація потрапляє до картки, кожне подальше використання її спадкоємно успадковує проблему “сміття в, сміттяออก”, і виправлення її після цього є складним.

По-друге, навіть якщо дані точні, клініцист повинен能够 знайти те, що йому потрібно, без сортування всього іншого в картці. Обмін сотнями мільйонів записів мало допомагає, якщо клініцист, який приймає дані, не може знайти відповідну інформацію або довіряти, що вона відображає справжню клінічну картину пацієнта. Валідация на місці надання медичної допомоги та легке відновлення є тим, що робить обмінювані дані тим, на що клініцист може дійсно розраховувати.

Оглянувшись вперед на п’ять років, як виглядатиме “активована” середовище даних охорони здоров’я, коли штучний інтелект, стандарти інтероперабельності, клінічний контекст та робочі процеси лікарів, нарешті, будуть виправдані значним чином?

Виравнивання буде залежати від того, щоб кожна сторона мала доступ до надійної клінічної бази даних, розробленої для ефективного управління кожним пацієнтом та, колективно, для того, щоб зробити справжнє управління здоров’ям населення реальністю. Використовуючи цю базу, виравнивання починається з окремого пацієнта.

Перед кожною зустріччю один агент штучного інтелекту збирає всі доступні дані про пацієнта з мереж охорони здоров’я, обмінів, платників та підприємств, тоді як інший агент видаляє дублікати та організовує дані. Через додаток, кіоск або розмовного агента пацієнт потім підтверджує діагнози, ліки, недавні результати лабораторних досліджень та будь-які нові питання, виправляючи помилки на ходу. Чернетка цих змін надсилається клініцисту на перегляд.

Під час зустрічі, віртуальної чи фізичної, клініцист переглядає цю інформацію з пацієнтом та звертається до станів, які потребують уваги. Агент поверхнево показує діагностично значимий контекст для кожного існуючого стану або нового скарги, а амбієнтне прослуховування захоплює розмову. Другий агент підсумовує її для клініциста на перегляд, виправлення та затвердження.

Відтоді агенти займаються подальшою роботою: забезпеченням необхідних авторизацій, надсиланням рецептів до аптеки, поданням претензій, плануванням подальшої допомоги та пакуванням інформації для затверджених сторін. На всьому протязі фонові агенти оцінюють клінічний ризик та спонукають до якості, корекції ризику та нормативної документації. Ця модель спочиває на чистих, надійних даних на кожному етапі, з клініцистами, які залишаються в циклі, створюючи інформацію, яка підтримує як індивідуальний догляд за пацієнтом, так і ефективне управління здоров’ям населення.

Дякуємо за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Medicomp Systems.