Прибыль:
- Понимание того, как работает Лабораторная информационная система (LIS), промежуточное программное обеспечение и поток данных HL7/ASTM и где в эту цепочку добавляется искусственный интеллект.
- Возможность разрабатывать правила автоматической проверки с поддержкой искусственного интеллекта и устанавливать безопасные ограничения и правила исключений.
- Способность понимать риск для безопасности пациента, связанный с ошибками интеграции (несоответствие единиц измерения, код LOINC, перепутывание каналов) и точками проверки положения.
Лабораторный результат совершает невидимое путешествие, пока не покинет устройство и не достигнет экрана врача: устройство генерирует данные, промежуточное программное обеспечение собирает их, Лабораторная информационная система (LIS) записывает и проверяет их, больничная информационная система (HIS) соединяет их с пациентом, и результат сообщается. На каждом звене этой цепочки данные переводятся из одного формата в другой, и каждый перевод — это возможность ошибки: не совпадает единица измерения, перепутан код теста, подменен канал на другой аналит. ИИ может создать большую ценность, добавив его в эту цепочку, особенно за счет более разумных правил автопроверки, но неуместный ИИ может ускорить и масштабировать ошибки.
В этом модуле вы узнаете, как работают LIS, промежуточное программное обеспечение и стандарты обмена данными (HL7, ASTM, LOINC); логика и безопасные пределы автоматической проверки; Мы покроем риск безопасности пациента, связанный с ошибками интеграции. Основной принцип: ИИ ускоряет управление и поток; Решение о том, какой результат будет выдан автоматически, а какой достанется человеку, принимает эксперт с учетом правил безопасности.
Кольца потока данных
LIS (Лабораторная информационная система) — это мозг лаборатории: она получает заказы на испытания, отслеживает образцы, записывает, проверяет и сообщает результаты. Промежуточное программное обеспечение — это промежуточное программное обеспечение, которое находится между устройствами и LIS; Он собирает данные с нескольких устройств, применяет правила (дельта-проверка, автоматическая проверка) и управляет запросами на повтор/разбавление. HIMS/HIS управляет идентификацией пациентов и запросами по всей больнице.
Эти системы говорят друг с другом на стандартных «языках»:
- HL7 (Уровень здоровья 7): Стандарт обмена сообщениями между системами здравоохранения. Тестовый запрос и его результат передаются в виде сообщений HL7.
- ASTM: стандарт обмена сообщениями, используемый в основном для связи между устройством и промежуточным программным обеспечением.
- LOINC: словарь, который универсально кодирует лабораторные тесты. Тест «глюкоза, сыворотка» имеет код LOINC; Благодаря этому коду разные системы понимают, что речь идет об одном и том же тесте.
Без этих стандартов каждое устройство и система неправильно понимали бы друг друга. ИИ может помочь сопоставить эти сообщения, сканировать ошибки и генерировать правила; но точность сопоставления должна быть проверена человеком.
слой
Миссия
Типичный риск ошибки
Устройство (анализатор)
делает измерения
Калибровка, перекрестные помехи каналов
промежуточное программное обеспечение
Собирает данные, применяет правила
Неправильное правило, совпадение единиц измерения
ЛИС
Записывает, проверяет, сообщает
Путаница LOINC/тестового кода
ЕГО/ЕГО
Идентификатор пациента, запрос
Неверное соответствие пациента
Что такое автоматическая проверка?
Автоматическая проверка — это автоматическая публикация результатов, соответствующих определенным безопасным условиям, без контроля со стороны человека. Например: результат, который находится в пределах эталонного диапазона, имеет действительный контроль качества, имеет чистую дельта-проверку, не имеет флажков помех и не является критическим, может быть автоматически одобрен. Это отвлекает от человека массу рутинных нормальных результатов и направляет внимание эксперта на результаты, которые действительно требуют исследования. Хорошо продуманная автоматизированная проверка может безопасно ускорить получение значительной части результатов в лаборатории.
Но суть автоматической проверки заключается в том, что вы НЕ автоматизируете. Из автоматизации следует исключить и адресовать человеку:
- Критические/панические значения
- Нарушения дельта-проверки
- Аналиты с нарушением контроля качества
- Признаки помех (гемолиз, липемия, желтуха)
- Результаты, в которых устройство ставит галочку
- Определенные результаты, выходящие за пределы референтного диапазона и требующие клинической интерпретации.
Внимание: «Автоматически освободить все» — самое опасное решение автоматизации. Хорошая автоматизация определяется правилами исключений; Важнее уточнить, какой исход точно достанется людям, чем какой пройдет.
Как добавить ИИ в интеграцию
ИИ очень полезен в качестве помощника при разработке правил автоматической проверки: он может просматривать существующие правила, указывать на лазейки, моделировать результаты, которые пройдет набор правил, проверять список исключений. Он также может сканировать ошибки сопоставления (несоответствие единиц измерения, неожиданный диапазон значений, путаница кода) в сообщениях HL7/ASTM. Но ни одно правило, предложенное ИИ, не внедряется в производство без проверки реальными данными пациентов и ретроспективного тестирования. Прежде чем запустить правило автоматизации, оно тестируется на исторических результатах и задается вопрос: «Сколько критических значений оно будет пропущено?» Это следует проверить с помощью вопроса.
Слабая подсказка / Сильная подсказка
Слабая подсказка:
Напишите правила автоматической проверки и быстро получайте результаты.
В этом подсказке не указаны пределы безопасности, исключения и лабораторный контекст. ИИ может предложить широкое и опасное правило «пропустить все», и существует риск автоматического освобождения критических значений.
Мощная подсказка:
Ваша роль: помощник эксперта лаборатории, который РАЗРАБОТКА правил автоматизированной валидации. Целью является безопасность; скорость вторична. Предложите проект правил для следующих аналитов: [список аналитов]. Напишите УСЛОВИЯ автоматического освобождения и случаи ИСКЛЮЧЕНИЯ (перейти к человеку) отдельно для каждого правила. Исключения должны включать как минимум следующее: критическое значение, нарушение дельта-проверки, нарушение контроля качества, флаг помех, флаг проверки устройства. Добавьте примечание рядом с каждым правилом: «Это правило позволяет избежать такого риска». Я буду тестировать правила ретроспективно, прежде чем запускать их в производство; Также напишите, какие исторические данные мне следует проверить для тестирования.
Строгие подсказки определяют приоритет безопасности, обеспечивают соблюдение исключений, подвергают сомнению риски и включают этап проверки.
три мини-кейса
Случай 1 — Хорошо спроектированная автоматизация. Лаборатория настраивает автоматическую проверку результатов обычного общего анализа крови: в референсном диапазоне, контроль качества чистый, дельта-чистый, без флага устройства. Критические значения, флаг взрыва, нарушение дельты переходят к человеку. Он имитирует набор правил ИИ и показывает, что за последние 10 000 результатов не ускользнуло ни одного критического значения. Эксперт проверяет и реализует правило; Примерно 70% результатов ускоряются безопасно, акцентируя внимание на критических.
Случай 2 — Ошибка сопоставления томов. После обновления интеграции устройство отправляет ммоль/л, в то время как промежуточное программное обеспечение ожидает мг/дл магния. Значения систематически масштабируются неправильно. ИИ отмечает внезапный и совершенно неожиданный сдвиг результатов в диапазон («все результаты по магнию примерно в 2,4 раза выше нормы»). Специалист находит и исправляет ошибку сопоставления единиц. Если бы автоматизация не обнаружила эту ошибку, тысячи результатов были бы неверными — яркий пример риска масштабирования ошибки, связанного с автоматизацией.
Случай 3 — Автоматический выход критического значения. Он открывает широкую автоматическую проверку без установки другого правила исключения для лаборатории. Уровень калия 6,4 ммоль/л, хотя и является критическим, автоматически выдается и уведомление пропускается. Пациенту причинен вред. Урок: безопасность автоматической валидации зависит от полноты правил исключений; критическое значение никогда не остается на усмотрение автоматизации.
Копируемые шаблоны подсказок
ШАБЛОН ПРОЕКТА ПРАВИЛА АВТОВАЛИДАЦИИ Аналит: [имя]. Перечислите условия автоматического сброса (опорный диапазон, статус контроля качества, дельта, помехи, флаг устройства). Затем отдельно перечислите исключения «ОБЯЗАТЕЛЬНО ИДТИ К ЛЮДЯМ». Укажите риск того, что каждое правило может быть пропущено. Правило представляет собой проект; Я не буду использовать его без ретроспективного тестирования.
ШАБЛОН МОДЕЛИРОВАНИЯ ПРАВИЛ Примените следующее правило автоматической проверки к анонимному списку исторических результатов, который я предоставлю. Покажите, какие результаты будут передаваться автоматически, а какие — людям. А конкретно: какие-то критические значения передавались автоматически? Прорыв в Дельту ускользнул? Правило: [правило]. Результаты: [список].
ШАБЛОН СКАНИРОВАНИЯ ОШИБКИ ИНТЕГРАЦИИ Следующие результаты аналита указывают на ошибку интеграции/сопоставления: внезапный и последовательный дрейф всех результатов (возможная ошибка единицы измерения), неожиданный диапазон, несоответствие от одного устройства/канала. Отметьте подозрительную картину и возможную причину; Я приму решение. Данные: [список].
ШАБЛОН ПРОВЕРКИ КОДА LOINC/ТЕСТА Проверьте соответствие следующего названия теста и представленного кода: относятся ли имя теста и тест, описанный кодом, к одному и тому же аналиту? Совместим ли объем? Если есть несовместимость, отметьте «[должно быть проверено совпадение]». Матчи: [список].
Распространенные ошибки
- Включите автоматическую проверку без исключения. Автоматизация без исключений критического значения, дельты, контроля качества и помех опасна.
- Ввод правила в производство без его проверки. Новое правило не вступит в силу без ретроспективного тестирования исторических данных.
- Не проверяется соответствие единиц измерения. Такая ошибка, как мг/дл ↔ ммоль/л, незаметно искажает все результаты.
- Не обращая внимания на путаницу тестового кода и LOINC. Несовпадающий код может превратить один отчет о тестировании в другой тест.
- Ошибочно принять предложение правил ИИ за доказательство. Предложение является проектом; Только моделирование и проверка показывают безопасность.
Совет: При разработке правила автоматической проверки сначала спросите себя: «Что бы я НИКОГДА не пропускал автоматически?» Начните с вопроса. После того как вы полностью создали список исключений, автоматизацию можно безопасно расширить. Безопасность измеряется не теми результатами, которые проходят, а тем, что вы не пропускаете.
В заключение
Лабораторные данные передаются по многозвенной цепочке от прибора к врачу; LIS, промежуточное программное обеспечение и стандарты HL7/ASTM/LOINC обеспечивают этот поток, и каждый звонок представляет собой возможность ошибки. Автоматическая проверка ускоряет получение результатов в безопасных условиях, но ее безопасность зависит от правил исключений (критическое значение, дельта, контроль качества, вмешательство должно достаться человеку). Искусственный интеллект — мощный помощник в разработке правил, их моделировании и сканировании ошибок интеграции; Однако ни одно правило не внедряется в производство без ретроспективного тестирования и экспертной проверки. Автоматизация также масштабирует ошибку; Вот почему контрольно-пропускные пункты незаменимы.
Задача приложения
Запросить у ИИ набор правил с помощью шаблона «Проект правила автоматической проверки» для аналита; В частности, убедитесь, что список исключений полон. Затем примените это правило к выборочному списку исторических результатов с помощью шаблона «Моделирование правил» и убедитесь, что не было исключено никаких критических нарушений значений/дельта. Наконец, создайте сценарий сопоставления томов и попробуйте шаблон «Сканирование ошибок интеграции».
контрольный список
- [ ] Я полностью определил список исключений (критические, дельта, контроль качества, помехи) для автоматической проверки.
- [ ] Я протестировал правило ретроспективно на исторических данных, прежде чем запустить его в производство.
- [ ] Я проверил, что никакие критические значения/нарушения дельты не пропускаются автоматически.
- [ ] Я проверил устройство и соответствие LOINC/тестового кода.
- [ ] Я просмотрел признаки сбоя интеграции (внезапный постоянный дрейф).
- [ ] Я подтвердил предложение ИИ о правилах посредством моделирования и проверки.