Прибуток:
- Розуміння того, як працює Лабораторна інформаційна система (LIS), проміжне програмне забезпечення та потік даних HL7/ASTM і де до цього ланцюжка додається штучний інтелект.
- Можливість розробляти правила автоматичної перевірки з підтримкою штучного інтелекту та встановлювати безпечні обмеження та правила винятків
- Здатність розуміти ризики безпеки пацієнта через помилки інтеграції (невідповідність одиниць, код LOINC, змішування каналів) і точки перевірки позиції
Лабораторний результат робить невидиму подорож, поки не покине пристрій і не досягне екрана лікаря: пристрій генерує дані, проміжне програмне забезпечення збирає їх, Лабораторна інформаційна система (LIS) записує та перевіряє їх, інформаційна система лікарні (HIS) з’єднує його з пацієнтом, і результат повідомляється. У кожній ланці цього ланцюга дані перекладаються з одного формату в інший, і кожен переклад є можливістю помилки: одиниця не відповідає, тестовий код переплутається, канал замінюється на інший аналіт. Штучний інтелект може створити велику цінність, додавши його до цього ланцюжка — особливо зробивши правила автоматичної перевірки інтелектуальнішими — але неправильно розміщений ШІ може прискорити та масштабувати помилки.
У цьому розділі ви дізнаєтесь, як працюють LIS, проміжне програмне забезпечення та стандарти обміну даними (HL7, ASTM, LOINC); логіка та безпечні межі автоматичної перевірки; Ми покриваємо ризики безпеки пацієнтів через помилки інтеграції. Основний принцип: AI прискорює правило та потік; Рішення про те, який результат буде опубліковано автоматично, а який – людині, визначає експерт із правилами безпеки.
Кільця потоку даних
LIS (лабораторна інформаційна система) — це мозок лабораторії: вона отримує замовлення на тестування, відстежує зразки, записує, перевіряє та звітує про результати. Проміжне програмне забезпечення — це проміжне програмне забезпечення, яке знаходиться між пристроями та LIS; Він збирає дані з кількох пристроїв, застосовує правила (дельта-перевірка, автоматична перевірка) і керує запитами на повторення/розведення. HIMS/HIS керує ідентифікацією пацієнтів і запитами в усій лікарні.
Ці системи говорять між собою стандартними «мовами»:
- HL7 (7 рівень здоров’я): стандарт обміну повідомленнями між системами охорони здоров’я. Тестовий запит і його результат переносяться як повідомлення HL7.
- ASTM: стандарт обміну повідомленнями, який використовується переважно для зв’язку між пристроєм і проміжним програмним забезпеченням.
- LOINC: словник, який універсально кодує лабораторні тести. Тест «глюкоза, сироватка» має код LOINC; Завдяки цьому коду різні системи розуміють, що мова йде про один і той же тест.
Без цих стандартів усі пристрої та системи не розумітимуть один одного. AI може допомогти зіставити ці повідомлення, перевірити помилки та створити правила; але точність відповідності повинна бути перевірена людиною.
шар
Місія
Типовий ризик помилки
Прилад (аналізатор)
робить вимірювання
Калібрування, канал перехресних перешкод
проміжне програмне забезпечення
Збирає дані, застосовує правила
Неправильне правило, збіг одиниць
ЛІС
Записує, перевіряє, звітує
Плутанина LOINC/тестовий код
ЙОГО/ЙОГО
ID пацієнта, запит
Неправильний збіг пацієнта
Що таке автоматична перевірка?
Автоматизована перевірка — це автоматичне оприлюднення результатів, які відповідають певним безпечним умовам, без контролю людини. Наприклад: результат, який знаходиться в межах еталонного діапазону, має дійсний КЯ, має чисту дельта-перевірку, не має позначок перешкод і не є критичним, може бути автоматично затверджений. Це забирає масу звичайних звичайних результатів від людини та спрямовує увагу експерта на результати, які насправді потребують дослідження. Добре розроблена автоматизована перевірка може безпечно пришвидшити значну частину результатів у лабораторії.
Але суть автоматизованої перевірки полягає в тому, що ви НЕ автоматизуєте. Слід виключити з автоматизації та направити на людей:
- Критичні/панічні значення
- Порушення перевірки Delta
- Аналіти з порушенням КЯ
- Інтерференційні ознаки (гемоліз, ліпемія, жовтяниця)
- Результати, де пристрій ставить знак «галочка».
- Певні результати, які виходять за межі референтного діапазону та потребують клінічної інтерпретації
Застереження: «Автоматично звільняти все» є найнебезпечнішим рішенням автоматизації. Гарна автоматизація визначається винятковими правилами; Важливіше з’ясувати, який результат обов’язково дістанеться людям, аніж який пройде.
Як додати ШІ до інтеграції
ШІ дуже корисний як помічник при розробці правил автоматичної перевірки: він може переглядати існуючі правила, вказувати на лазівки, симулювати, які результати буде виконувати набір правил, перевіряти список винятків. Він також може шукати помилки збігу (невідповідність одиниць вимірювання, неочікуваний діапазон значень, плутанину коду) у повідомленнях HL7/ASTM. Але жодне правило, запропоноване штучним інтелектом, не впроваджується у виробництво без перевірки реальними даними пацієнтів і ретроспективного тестування. Перед запуском правило автоматизації перевіряється на історичних результатах і запитується «скільки критичних значень воно пропустить?» Це слід перевірити за допомогою запитання.
Слабка підказка / Сильна підказка
Слабка підказка:
Напишіть правила автоматичної перевірки та швидко отримуйте результати.
Ця підказка не включає обмеження безпеки, винятки та лабораторний контекст. ШІ може запропонувати широке, небезпечне правило «пропуску всіх», і існує ризик автоматичного вивільнення критичних значень.
Потужна підказка:
Ваша роль: помічник експерта лабораторії, який розробляє правила автоматизованої перевірки. Мета – безпека; швидкість другорядна. Запропонуйте проект правил для таких аналітів: [список аналітів]. Напишіть випадки автоматичного випуску УМОВИ та ВИНЯТКИ (перейдіть до людини) окремо для кожного правила. Винятки повинні включати принаймні таке: критичне значення, порушення перевірки дельти, порушення контролю якості, прапор перешкод, прапор перевірки пристрою. Біля кожного правила додайте примітку «це правило може уникнути цього ризику». Я буду тестувати правила ретроспективно перед тим, як запустити їх у виробництво; Також напишіть, які історичні дані мені слід перевірити для тестування.
Сильна підказка надає пріоритет безпеці, забезпечує винятки, ставить під сумнів ризики та включає етап перевірки.
три міні-чохла
Випадок 1 — Добре розроблена автоматизація. Лабораторія встановлює автоматичну перевірку для рутинних результатів повного аналізу крові: у референсному діапазоні, КЯ чистий, дельта-чистий, без позначки пристрою. Критичні значення, прапор вибуху, порушення дельти переходять до людини. Він імітує набір правил AI і показує, що жодне критичне значення не вийшло за останні 10 000 результатів. Експерт підтверджує та впроваджує правило; Приблизно 70% результатів прискорюється безпечно, зосереджуючи увагу на критичних.
Випадок 2 — Помилка відповідності обсягу. Після оновлення інтеграції пристрій надсилає ммоль/л, а проміжне програмне забезпечення очікує магнію мг/дл. Значення систематично неправильно масштабуються. ШІ відзначає раптовий і абсолютно несподіваний зсув результатів у діапазон («усі результати магнію ~2,4 рази від норми»). Спеціаліст знаходить і виправляє помилку підбору одиниць. Якби автоматизація не вловила цю помилку, тисячі результатів були б неправильними — яскравий приклад ризику автоматизації масштабування помилки.
Випадок 3 — автоматичний вихід критичного значення. Він відкриває широку автоматичну перевірку без встановлення іншого правила винятку для лабораторії. Рівень калію 6,4 ммоль/л, хоч і критичний, автоматично вивільняється, а сповіщення пропускається. Пацієнту завдано шкоди. Урок: безпека автоматичної перевірки залежить від повноти правил винятків; критичне значення ніколи не залишається на розсуд автоматизації.
Шаблони підказок, які можна копіювати
ПРОЕКТ ШАБЛОНУ ПРАВИЛА АВТОМАТИЧНОЇ ПЕРЕВІРКИ Аналіт: [ім’я]. Список умов для автоматичного випуску (референсний діапазон, стан контролю якості, дельта, перешкоди, прапор пристрою). Потім окремо перелічіть винятки «МАЄ ЙТИ ДО ЛЮДЕЙ». Вкажіть ризик, що кожне правило може бути пропущено. Правило є чернеткою; Я не буду використовувати його без ретроспективного тестування.
ШАБЛОН МОДЕЛЮВАННЯ ПРАВИЛА Застосуйте наведене нижче правило автоматичної перевірки до списку анонімних історичних результатів, який я надам. Покажіть, які результати будуть прийняті автоматично, а які – людям. Зокрема: чи проходили якісь критичні значення автоматично? Дельта-прорив втік? Правило: [правило]. Результати: [список].
ШАБЛОН СКАНУВАННЯ ПОМИЛОК ІНТЕГРАЦІЇ. Наступні результати аналіту вказують на помилку інтеграції/відповідності: раптовий і послідовний дрейф усіх результатів (можлива одинична помилка), неочікуваний діапазон, невідповідність від одного пристрою/каналу. Позначте підозрілий шаблон і можливу причину; Я прийму рішення. Дані: [список].
ШАБЛОН ПЕРЕВІРКИ КОДУ LOINC/ТЕСТУ. Перевірте відповідність наступної назви тесту та поданого коду: чи назва тесту та тест, описаний кодом, стосуються одного аналіту? Чи сумісний том? Якщо є несумісність, позначте «[збіг має бути перевірено]». Збіги: [список].
Поширені помилки
- Увімкніть без винятку автоматичну перевірку. Автоматизація без винятків критичного значення, дельта, контролю якості та перешкод є небезпечною.
- Введення правила у виробництво без його перевірки. Нове правило не запрацює без ретроспективного тестування на історичних даних.
- Не перевіряється відповідність одиниць. Така помилка, як мг/дл ↔ ммоль/л, спотворює всі результати.
- Недогляд тестового коду/Плутанина LOINC. Невідповідний код може зробити один тестовий звіт іншим тестом.
- Приймаючи пропозицію правила ШІ як доказ. Пропозиція є чернеткою; Тільки симуляція та перевірка показують безпеку.
Порада. Розробляючи правило автоматичної перевірки, спершу запитайте: "Що б я НІКОЛИ не проходив автоматично?" Почніть із запитання. Після того, як ви повністю створили список винятків, автоматизацію можна безпечно розширити. Безпека вимірюється не результатами, які проходять, а тим, що ви не пропускаєте.
Підсумовуючи
Лабораторні дані надходять у багатоланковий ланцюг від пристрою до лікаря; Стандарти LIS, проміжне програмне забезпечення та HL7/ASTM/LOINC забезпечують цей потік, і кожен дзвінок є можливістю для помилки. Автоматична перевірка прискорює результати в безпечних умовах, але її безпека залежить від правил винятків (критичне значення, дельта, контроль якості, перешкоди мають отримувати люди). Штучний інтелект є потужним помічником у розробці правил, їх моделюванні та пошуку помилок інтеграції; Однак жодне правило не вводиться у виробництво без ретроспективного тестування та експертної перевірки. Автоматика також масштабує похибку; Тому без блокпостів не обійтися.
Аплікаційне завдання
Запитуйте набір правил від ШІ за допомогою шаблону «Проект правила автоматизованої перевірки» для аналіту; Зокрема, перевірте, чи повний список винятків. Потім застосуйте це правило до зразка історичного списку результатів за допомогою шаблону «Імітація правила» та переконайтеся, що критичне значення/дельта-порушення не попереджені. Нарешті створіть сценарій зіставлення томів і спробуйте шаблон «Сканування помилок інтеграції».
контрольний список
- [ ] Я повністю визначив список винятків (критичні, дельта, контроль якості, перешкоди) для автоматичної перевірки.
- [ ] Я перевірив правило ретроспективно з історичними даними, перш ніж запустити його у виробництво.
- [ ] Я переконався, що критичні значення/порушення дельти не передаються автоматично.
- [ ] Я перевірив відповідність одиниці та LOINC/тестового коду.
- [ ] Я перевірив ознаки збою інтеграції (раптовий послідовний дрейф).
- [ ] Я підтвердив пропозицію правила ШІ за допомогою моделювання та перевірки.