Clinical ReasoningWork Group Clinical Decision Support  | Maturity Level: 2 | Standards Status: Trial Use |
В этом разделе модуля клинического обоснования обсуждается пример использования оценки для поддержки принятия клинических решений и то, как различные артефакты знаний могут быть интегрированы в клинический рабочий процесс. Тема посвящена двум основным сценариям:
Обратите внимание, что эта тема представляет собой очень высокоуровневый подход к использованию ловушек CDS для поддержки этих двух вариантов использования. Это не нормативное описание какого-либо содержимого CDS Hooks. Пожалуйста, обратитесь к самой спецификации CDS Hooks для получения более подробной информации. На момент публикации спецификация CDS Hooks была проголосована, но все еще находится в процессе публикации. Поскольку ссылки на этой странице ссылаются на спецификацию хуков CDS, они все еще ссылаются на исходную спецификацию хуков CDS. Когда он будет опубликован, спецификация CDS Hooks будет находиться по адресу http://cds-hooks.hl7.org .
CDS Hooks - это спецификация с открытым исходным кодом, ориентированная на поддержку удаленных клинических решений с участием пользователей. CDS Hooks может использовать FHIR для представления информации и рекомендаций пациента, но это архитектурно независимая спецификация. Основные компоненты CDS Hooks:
| Service | Служба поддержки принятия решений, которая принимает запросы, содержащие информацию о пациентах, и предоставляет ответы |
| Hook | Определенная точка в рабочем процессе клиентской системы с хорошо известной контекстной информацией, предоставляемой как часть запроса |
| EHR | Электронная медицинская карта или другая клиническая информационная система, которая использует поддержку принятия решений в виде услуг |
| Card | Рекомендации служб поддержки принятия решений возвращаются в виде карточек, представляющих дискретные рекомендации или предложения, которые представляются пользователю в EHR |
Первым этапом использования службы CDS с использованием ловушек CDS является настройка интеграции из EHR. Служба CDS публикует набор конечных точек для рекламы доступных функций с помощью конечной точки обнаружение . Для каждой конечной точки служба объявляет ловушку , во время которой она ожидает вызова, и, необязательно, любую информацию предварительной выборки , которая может быть предоставлена службе.
Каждый hook идентифицирует контекстную информацию, доступную в EHR. Например, хук medication-identify указывает пациента в контексте, а также назначаемые лекарства. Ожидается, что при вызове службы из этого перехвата EHR предоставит эту контекстную информацию как часть запроса.
Кроме того, служба CDS может указывать дополнительную информацию, используя prefetch шаблоны. Каждый шаблон предварительной выборки представляет собой URL-адрес запроса FHIR, параметризованный данными, доступными в контексте, и описывающий информацию, необходимую службе CDS для выполнения своей обработки. Предоставляя эту информацию как часть запроса, EHR устраняет необходимость для службы CDS запрашивать дополнительную информацию.
В следующем примере показан типичный ответ на обнаружение службы:
{
"services": [
{
"hook": "medication-prescribe",
"prefetch": {
"medication": "MedicationOrder?patient\u003d{{context.patientId}}\u0026status\u003dactive"
},
"title": "Opioid Morphine Milligram Equivalence (MME) Guidance Service",
"description": "CDS Service that finds the MME of an opioid medication and provides guidance to the prescriber if the MME exceeds the recommended range.",
"id": "cdc-opioid-guidance"
},
{
"hook": "patient-view",
"prefetch": {
"patient": "Patient/{{context.patientId}}"
},
"title": "Zika Virus Intervention",
"description": "Identifies possible Zika exposure and offers suggestions for suggested actions for pregnant patients",
"id": "zika-virus-intervention"
},
} Второй этап - это фактический запрос / ответ службы CDS. После того, как интеграция была настроена с использованием вышеуказанной информации, EHR может делать запросы к службам поддержки принятия решений в соответствующее время на основе поддерживаемых им ловушек . Чтобы сделать запрос, EHR подготавливает объект request , содержащий контекстный информация, необходимая для ловушки, а также любая дополнительная информация о предварительной выборке.
Например, следующий запрос иллюстрирует вызов службы cdc-opioid -idance :
{
"hookInstance": "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
"fhirServer": "https://example.org/fhir",
"hook": "medication-prescribe",
"context":
{
"medications": [
{
"resourceType": "MedicationOrder",
"id": "medrx001",
... <FHIR Resource - snipped for brevity>
}
],
"patientId": "Patient/Patient-12214",
"userId": "Practitioner/example"
},
"patient": "Patient/Patient-12214",
"prefetch": {
"medication": {
"resource": {
"resourceType": "Bundle",
"entry": [
{
"fullUrl": "https://example.org/fhir/open/MedicationOrder/medrx002",
"resource": {
"resourceType": "MedicationOrder",
"id": "medrx002",
... <FHIR Resource - snipped for brevity>
}
]
}
}
}
}Этот запрос идентифицирует:
лекарство-прописать . MedicationOrder . MedicationOrder для пациента Служба отвечает набором карточек с описанием любых рекомендаций или предложения, которые следует представить пользователю:
{
"cards":[
{
"summary":"High risk for opioid overdose - taper now",
"detail":"Total morphine milligram equivalent (MME) is 110 mg/d. Taper to less than 50.",
"indicator":"warning",
"source": {
"label": "Centers for Comprehensive Disease Control (CDC)",
"url": "http://cdc.gov"
},
"suggestions":[
{
"label": "Total morphine milligram equivalent (MME) is 110 mg/d. Taper to less than 50.",
"actions":[
{
"type": "update",
"description":"Total morphine milligram equivalent (MME) is 110 mg/d. Taper to less than 50.",
"resource": { ... <Updated FHIR Resource - snipped for brevity> ... }
}
]
}
],
"links":[
{
"label":"CDC guideline for prescribing opioids for chronic pain",
"type": "absolute",
"url":"https://www.cdc.gov/mmwr/volumes/65/rr/rr6501e1.htm"
},
{
"label":"MME Conversion Tables",
"type": "absolute",
"url":"https://www.cdc.gov/drugoverdose/pdf/calculating_total_daily_dose-a.pdf"
}
]
}
]
}Каждая карточка содержит:
информация , предупреждение или жесткая остановка На этом этапе EHR обрабатывает ответ и определяет наиболее подходящий механизм для отображения результатов конечному пользователю. Однако часто бывает так, что результаты взаимодействия по поддержке принятия решений необходимо сохранить для использования в будущем. Ресурсы GuidanceResponse и RequestGroup предоставляют общий механизм, поддерживающий этот вариант использования.
Как правило, ответ на перехватчики CDS может быть записан как один ответ GuidanceResponse, представляющий общий ответ от службы CDS, и отдельная группа RequestGroup, содержащая карточки и предложения, как показано на следующих сопоставлениях на уровне объектов:
| Объект перехватчиков CDS | Сопоставление ресурсов FHIR | Описание |
|---|---|---|
| Response | GuidanceResponse и RequestGroup | Ответ ловушек CDS составляет 1 к 1 с GuidanceResponse и связанной RequestGroup |
| Card | RequestGroup.action | Каждая карта в ответе представлена как действие верхнего уровня в RequestGroup. SelectionBehavior действия (т.е. среди предложений на карточке) определяется элементом selectionBehavior карточки. |
| Suggestion | RequestGroup.action.action | Каждое предложение на карточке представлено как вложенное действие внутри действия для карточки. SelectionBehavior действия (то есть среди действий, описанных в предложении) - all , поскольку ловушки CDS указывают, что когда предложение принято, выполняются все действия по предложению. |
| Action | RequestGroup.action.action.action | Каждое действие перехватчиков CDS на карточке представлено как вложенное действие внутри действия RequestGroup для предложения, и ресурс в действии перехватчиков CDS заполняет элемент ресурса действия RequestGroup. |
В следующей таблице перечислены сопоставления на уровне элементов:
| Элемент перехватчиков CDS | Сопоставление ресурсов FHIR |
|---|---|
| Request.hookInstance | GuidanceResponse.requestId & RequestGroup.identifier |
| URL-адрес запроса | GuidanceResponse.moduleUri & RequestGroup.instantiatesUri |
| Статус ответа | GuidanceResponse.status |
| Запросить пациента | GuidanceResponse.subject & RequestGroup.subject |
| Время запроса | GuidanceResponse.occurrenceDateTime & RequestGroup.authoredOn |
| Запросить услугу | GuidanceResponse.performer & RequestGroup.author (как устройство) |
| Response.card | RequestGroup.action |
| Response.card.summary | RequestGroup.action.title |
| Response.card.detail | RequestGroup.action.description |
| Response.card.indicator | RequestGroup.priority | RequestGroup.action.resource.priority, используя сопоставление, указанное здесь |
| Response.card.source | RequestGroup.action.relatedArtifact.where (type = 'documentation') |
| Response.card.selectionBehavior | RequestGroup.action.selectionBehavior |
| Response.card.suggestion | RequestGroup.action.action |
| Response.card.suggestion.label | RequestGroup.action.action.title |
| Response.card.suggestion.uuid | RequestGroup.action.action.id |
| Response.card.suggestion.action | RequestGroup.action.action.action |
| Response.card.suggestion.action.type | RequestGroup.action.action.action.type |
| Response.card.suggestion.action.description | RequestGroup.action.action.action.description |
| Response.card.suggestion.action.resource | RequestGroup.action.action.action.resource |
Обратите внимание: все эти примеры предполагают использование службы FHIR DSTU2.
Для поддержки этих сценариев в этом модуле определены ответы на хуки CDS, GuidanceResponse и Группа запросов хуков CDS профили.
Помимо поддержки варианта использования удаленной поддержки принятия решений, ориентированного на пользователя, ловушки CDS могут использоваться для выявления поведения поддержки принятия клинических решений, представленного артефактами знаний в модуле Clinical Reasoning. В этом случае сервер FHIR, функционирующий как поставщик знаний, предоставляет сервисы перехватчиков CDS с помощью конечной точки обнаружения и предоставляет руководство с помощью конечной точки службы CDS. Для поддержки этого используется несколько сопоставлений функциональности Clinical Reasoning с сервисами CDS Hooks:
Hooks в CDS Hooks - это заранее определенная точка в рабочем процессе клинической информационной системы, такой как EHR. Каждая ловушка определяет context , который представляет собой информацию, доступную как часть текущей активности в системе. Каждая ловушка представляет собой точку в рабочем процессе, которая может быть дополнена поддержкой принятия решений от внешней системы. Внутри ловушек CDS каждая ловушка определяет набор доступных значений контекста, а также то, может ли это значение контекста использоваться в качестве токена предварительной выборки.
Например, обработчик Patient-view определяет PatientId и expectId как значения контекста и указывает, что они оба доступны для использования в качестве предварительной выборки. токены (то есть их можно использовать для параметризации шаблонов предварительной выборки).
В FHIR концепция ловушки может быть представлена с помощью комбинации TriggerDefinition и ParameterDefinition:
| Элемент перехватчиков CDS | Отображение FHIR |
|---|---|
| Hook.name | TriggerDefinition.where (type = 'named-event'). name |
| Hook.context.field | ParameterDefinition.name |
| Hook.context.priority | ParameterDefinition.min & ParameterDefinition.max |
| Hook.context.description | ParameterDefinition.documentation & ParameterDefinition.type & ParameterDefinition.profile |
Обратите внимание, что использование TriggerDefinition для представления информации о ловушке требует, чтобы детали ловушки дублировались везде, где они используются. Другой подход - использовать ресурс EventDefinition для однократного захвата информации о ловушке, а затем повторно использовать ее по ссылке везде, где это необходимо.
Служба в CDS Hooks - это служба поддержки принятия клинических решений, которую можно использовать для предоставления рекомендаций пользователям в заранее определенных точках рабочего процесса. Ресурс PlanDefinition можно использовать для описания поведения функций поддержки принятия решений, которые затем могут быть представлены через службу CDS Hooks. В простейшем случае существует взаимно однозначное соответствие между PlanDefinition и службой CDS:
| Элемент перехватчиков CDS | Отображение FHIR |
|---|---|
| Service.id | PlanDefinition.url (без базы) |
| Service.title | PlanDefinition.title |
| Service.description | PlanDefinition.description |
| Service.hook | PlanDefinition.action.trigger |
| Service.prefetch | PlanDefinition.data-requirement |
Для поддержки этого представления этот модуль определяет профиль CDS Hooks Service PlanDefinition , который также поддерживает указание конечной точки CDS Hooks, на которой должно быть установлено определение PlanDefinition. разоблачены.
Операция PlanDefinition / $ apply затем может использоваться для обеспечения поведения службы перехватчиков CDS, как описано в разделе «Обработка запросов перехватчиков CDS» ниже.
В дополнение к контекстной информации, определенной с помощью hook , службы в CDS Hooks могут запрашивать, чтобы дополнительная информация предоставлялась с каждым запросом в форме шаблонов предварительной выборки . Эти шаблоны представляют собой параметризованные URL-адреса запросов FHIR, которые могут быть выполнены EHR как часть запроса, что сокращает количество циклов обмена между службой CDS и сервером FHIR EHR.
Концепция предварительной выборки данных представлена в Clinical Reasoning как DataRequirement, который можно преобразовать во взаимодействие чтения или поиска на уровне экземпляра следующим образом:
| Элемент DataRequirement | Сопоставление с URL-адресом FHIR |
|---|---|
| type | [тип] {[id] | ? [параметры]} |
| subject | subject={{patientId}} |
| codeFilter | [path visible{=|:in}[code|valueSet ] |
| dateFilter | [path visible{eq|lt|gt|ge|le}[valueDateTime|valuePeriod|valueDuration ] |
| sort | _sort=[сортировка ] |
| limit | _limit=[limitght |
Эти данные предварительной выборки могут быть автоматически определены из требований к данным PlanDefinition и предоставлены как часть определения службы в ответ на обнаружение ловушек CDS.
После того, как доступные ресурсы PlanDefinition объявлены через конечную точку обнаружения, конечную точку CDS Hooks можно использовать для выполнения фактической оценки, как показано на следующей диаграмме:
Как показано на приведенной выше диаграмме, EHR вызывает запрос CDS Hooks в соответствующей точке рабочего процесса, предоставляя запрошенный контекст и данные. Служба CDS отвечает, выполняя операцию $ apply для указанного PlanDefinition и преобразуя полученный RequestGroup в ответ CDS Hooks.
Поскольку PlanDefinitions может использоваться в широком диапазоне вариантов использования, этот модуль определяет библиотеку CQL и Computable PlanDefinition , чтобы описать особый случай использования PlanDefinition в качестве правила событие-условие-действие с условиями и другим динамическим поведением, указанным в библиотеке CQL. Эта схема обеспечивает общий и последовательный шаблон для описания поддержки принятия решений, который можно легко интегрировать с помощью спецификации CDS Hooks.
®© HL7.org 2011+. FHIR Release 4 (Technical Correction #1) (v4.0.1) generated on Thu, Jan 21, 2021 15:39+0000. QA Page
Links: Search |
Version History |
Table of Contents |
Credits |
Compare to R3 |
|
Propose a change