Способ генерирования описательных отчетов из исполнимых клинических протоколов - RU2733114C2

Чертежи

Описание

ОБЛАСТЬ ТЕХНИКИ

Настоящее изобретение в целом относится к формированию электронных медицинских карт, а также к областям составления отчетов и связанным областям.

УРОВЕНЬ ТЕХНИКИ

Система электронных медицинских карт (ЭМК) обеспечивает централизованный электронный репозиторий данных для хранения данных о пациенте. Как правило, данные о пациенте индексированы по пациенту и могут храниться в стандартном общем формате, таком как международный формат Health Level седьмого уровня (HL7) и/или в стандартных специфических для предметной области форматах для медицинских изображений, таких как DICOM. Кроме того, данные о пациенте в ЭМК могут храниться в менее структурированных форматах, таких как письменные медицинские отчеты, подготовленные врачами, которые могут обладать слабо определенной структурой данных или не обладать ею вовсе.

Другой областью, в которой все сильнее происходит автоматизация здравоохранения, является область клинической диагностики и мониторинга. Система поддержки принятия клинических важных решений (ППКВР) может использовать базу знаний наряду с экспертными правилами, разработанными опытными врачами, для выдачи диагноза или рекомендаций по лечению по конкретным пациентам. Еще в одном подходе с ППКВР для пациента сохраняют электронный клинический протокол, а поддержку принятия решений формируют доступными путями потока по клиническому протоколу. Использование системы ППКВР может улучшить диагностику и лечение, а также служит для обеспечения соответствия руководствам, введенным в действие организациями по аккредитации, а также ассоциациями и сообществами медицинских специалистов.

Далее раскрыты новые и улучшенные системы и способы.

РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

В одном раскрытом аспекте некратковременный носитель для хранения хранит модель процесса клинического протокола, содержащую шаблоны описательных клинических аннотаций, связанные с переходами между узлами в модели БП (бизнес-процесса) клинического протокола. Инструмент для управления бизнес-процессами (УБП) содержит вычислительное устройство, запрограммированное на выполнение операций, включающих: исполнение пути для пациента в модели БП клинического протокола задействованными узлами модели БП клинического протокола в соответствии со специфической для пациента информацией, хранящейся в электронной медицинской карте (ЭМК), и генерирование содержания описательного отчета на клиническом протоколе по пациенту посредством заполнения полей шаблонов описательных клинических аннотаций, связанных с переходами между узлами в пути пациента по модели БП, специфической для пациента информацией, хранящейся в ЭМК. Содержание описательного отчета для параллельных ветвей модели БП группируют в отдельный раздел для каждой ветви. Модель клинического протокола может представлять собой бизнес-процесс (БП), сохраненный на языке выполнения бизнес-процессов (BPEL) и/ил и в модели и нотации бизнес-процессов (BPMN). Кроме того, инструмент для УБП может быть запрограммирован на запуск графического редактора (42) модели БП для обеспечения пользователю возможности редактирования модели БП клинического протокола и аннотации переходов между узлами модели БП клинического протокола с шаблонами клинических аннотаций, связанных с аннотированными переходами между узлами. Может быть реализована другая модель или язык процесса с целью генерирования описательного медицинского отчета с контекстуальной информацией, включенной на основе редактируемой модели процесса.

Еще в одном раскрытом аспекте некратковременный носитель для хранения хранит модель БП клинического протокола, содержащую шаблоны описательных клинических аннотаций, связанные с переходами между узлами модели БП клинического протокола, и инструкции, исполнимые вычислительным устройством для выполнения способа формирования клинических отчетов, вместе с ЭМК, которая принимает и сохраняет специфическую для пациента информацию. Способ формирования клинических отчетов включает: исполнение пути для пациента в модели БП клинического протокола задействованными узлами модели БП клинического протокола в соответствии со специфической для пациента информацией, хранящейся в ЭМК, генерирование содержания описательного отчета на клиническом протоколе по пациенту посредством заполнения полей шаблонов описательных клинических аннотаций, связанных с переходами между узлами в пути пациента по модели БП клинического протокола, специфической для пациента информацией, хранящейся в ЭМК, и передачу содержания сгенерированного описательного отчета в ЭМК. В некоторых вариантах реализации некратковременный носитель для хранения хранит модель БП клинического протокола по меньшей мере в одном представлении из BPEL и графического BPMN.

Еще в одном раскрытом аспекте раскрыт способ, который функционирует вместе с моделью БП клинического протокола, содержащей шаблоны описательных клинических аннотаций, связанные с переходами между узлами в модели БП клинического протокола. Способ включает: взаимодействие с ЭМК для записи специфической для пациента информации в репозиторий данных в ЭМК; на компьютере: исполнение пути для пациента в модели БП клинического протокола задействованными узлами модели БП клинического протокола в соответствии со специфической для пациента информацией, хранящейся в ЭМК; и, используя компьютер, генерирование содержания описательного отчета на клиническом протоколе по пациенту посредством заполнения полей шаблонов описательных клинических аннотаций, связанных с переходами между узлами в пути пациента по модели БП клинического протокола, специфической для пациента информацией, извлеченной из ЭМК. В некоторых вариантах реализации взаимодействие включает прием специфической для пациента информации, содержащей медицинский отчет, через устройство интерфейса пациента, а способ дополнительно включает, во время приема медицинского отчета, отображение содержания сгенерированного описательного отчета в виде содержания, предлагаемого для включения в медицинский отчет.

Одно преимущество заключается в обеспечении автоматического генерирования содержания описательного медицинского отчета по конкретному пациенту.

Еще одно преимущество заключается в обеспечении электронной медицинской карты (ЭМК) с улучшенным интерфейсом пользователя для ввода описательного медицинского отчета.

Еще одно преимущество заключается в упрощении улучшенного формирования отчетов по соответствию медицинским протоколам, определенным стандартными клиническими протоколами.

Представленный вариант реализации может обеспечивать одно, два, более или все из указанных выше преимуществ, или же не обеспечивать их вовсе, и/или может обеспечивать другие преимущества, которые станут очевидны специалисту в данной области техники после прочтения и понимания настоящего раскрытия.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Настоящее изобретение может быть реализовано в виде различных компонентов и схем размещения компонентов, а также различных этапов и порядков выполнения этапов. Чертежи предназначены лишь для иллюстрации предпочтительных вариантов реализации и их не следует рассматривать в качестве ограничения настоящего изобретения.

На ФИГ. 1 схематически изображена электронная медицинская карта (ЭМК) с инструментом для управления бизнес-процессами (УБП), который исполняет путь по пациенту посредством модели бизнес-процесса (БП) клинического протокола и генерирует содержание описательного отчета.

На ФИГ. 2 схематически изображена часть иллюстративной модели БП протокола сепсиса с шаблонами описательных клинических аннотаций, связанных с некоторыми переходами между узлами.

На ФИГ. 3 схематически изображен автоматический способ генерирования содержания описательного отчета, подходящим образом выполняемый с использованием инструмента для УБП, изображенного на ФИГ. 1.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

Как описано выше в настоящем документе, два существующих аспекта информации о здравоохранении включают повышающееся использование систем электронных медицинских карт (ЭМК) и повышающееся использование систем поддержки принятия клинически важных решений (ППКВР). Несмотря на то что системы ЭМК и ППКВР обеспечивают существенные выгоды при хранении медицинских карт пациентов и диагностике/медицинском уходе за пациентом, они не направлены на проблемы, связанные с формированием медицинских отчетов.

В клинической практике подготовка медицинских отчетов по пациенту является важным аспектом здравоохранения. В таких отчетах охвачены и резюмированы клинические наблюдения, замеченные врачом пациента или медицинским специалистом, в отношении медицинского состояния пациента. В целом, природа медицинского отчета является описательной, поскольку описательность предоставляет врачу наивысший уровень свободы изложения и дает медицинский отчет, в достаточной степени понятный для других врачей или другого медицинского персонала.

При попытке даже частичной автоматизации, генерирование медицинских отчетов является затруднительным. В целом, ЭМК содержит специфическую по пациенту информацию для подготовки медицинского отчета, и врач, в действительности, вероятно, обратится к ЭМК пациента при подготовке медицинского отчета. Кроме того, ЭМК может содержать возможности интерфейса пользователя для формирования отчетов, с помощью которого врач может вводить медицинский отчет (например, вручную или посредством программного обеспечения для диктовки). Однако ЭМК не является эффективной для охвата контекста информации о пациенте, представляя контекст в более-менее описательной форме. Этот контекст может включать факторы, такие как причина назначенного медицинского исследования, время, в которое оно было назначено и/или проведено, медицинское состояние пациента в момент времени, в который были сгенерированы медицинские данные, любая другая информация, связанная с клинической процедурой, и так далее.

Система ППКВР на основе клинического протокола, в принципе, может обеспечивать клинический контекст. Однако система ППКВР функционирует на грубом уровне, который не является специфическим для пациента. Например, система ППКВР по онкологическим заболеваниям может выдавать клинический протокол с узлами, изображающими различные стадии или события в схеме лечения онкологического заболевания, такие как процедуры химиотерапии, процедуры медицинской визуализации или другое. Они являются событиями относительно высокого уровня. В отличие от этого, медицинский отчет, как правило, является более подробным и специфическим для пациента, например, резюмируя измерения показателей жизненно важных функций пациента в течение всего дня и представляя клинические заключения, выведенные из этих измерений, например, посредством иллюстрации заключения о том, что пациент хорошо (или не хорошо) переносит введенный лекарственный препарат. ППКВР на основе клинического протокола разработана для выдачи поддержки принятия клинически важных решений, а не формирования ретроспективных описательных медицинских отчетов. Например, некоторые системы ППКВР отображают графическую диаграмму потока выраженной части клинического протокола с различными узлами, аннотированными ограниченной информацией о пациенте.

В подходах, описанных в настоящем документе, устройство для формирования медицинских карт и отчетов функционирует совместно с ЭМК. Устройство содержит инструмент для управления бизнес-процессами (УБП), который исполняет путь для пациента по модели бизнес-процесса (БП) клинического протокола. Модель БП содержит шаблоны описательных клинических аннотаций, связанные с переходами между узлами клинического протокола. Для генерирования содержания описательного отчета, поля шаблонов описательных клинических аннотаций, связанных с переходами между узлами пути пациента в модели БП, заполняют специфической для пациента информацией, хранящейся в ЭМК. Модель БП может подробно представлять клинический протокол таким образом, что шаблоны описательных клинических аннотаций совместно охватывают подробный клинический контекст. Целью модели БП является поддержка формирования медицинских отчетов, а не обеспечение поддержки принятия клинических важных решений на более высоком уровне. Следовательно, в некоторых вариантах реализации, раскрытых в настоящем документе, пользователь не взаимодействует непосредственно с инструментом для УБП, поскольку он исполняет путь для пациента - вместо этого, пользователь взаимодействует с ЭМК, например, посредством интерфейса пользователя для формирования описательных отчетов, и получает доступ к инструменту для УБП непрямым образом, через ЭМК, с целью получения содержания для формирования описательных отчетов для возможного включения в отчет или для других целей.

Со ссылкой на ФИГ. 1 описан иллюстративный пример такой системы. Электронная медицинская карта (ЭМК) 10 хранится на серверном компьютере 12. Несмотря на то, что он схематически изображен в виде одного серверного компьютера, сервер 12, в более общем смысле, может представлять собой единый серверный компьютер или множество соединенных между собой компьютеров, например, распределенную вычислительную систему, облачный вычислительный ресурс или другое. ЭМК 10 содержит компоненты 14 для ввода и извлечения информации, а также репозиторий 16 данных ЭМК, в котором хранится специфическая для пациента информация, индексированная по пациенту, например, идентификационному номеру (ID) или идентификатору пациента. Специфическая для пациента информация содержит информацию, такую как демографическая информация о пациенте, информация об адресе проживания пациента и так далее, а также медицинские данные пациента, такие как результаты измерений показателей жизненно важных функций, результаты лабораторных исследований, данные медицинской визуализации (или, в некоторых конфигурациях, связи с данными медицинской визуализации, хранящимися в отдельной системе передачи и архивации изображений, СПАИ 18), описательные медицинские отчеты по пациенту, подготовленные врачами (возможно, также содержащие автоматически сгенерированное содержание описательного отчета, как описано в настоящем документе) или другое. Хранимая специфическая для пациента информация может содержать, например, медицинские данные, клинические отчеты, связи с медицинскими данными и связи с клиническими отчетами, и/или другое. Специфические для пациента данные, как правило, однако не обязательно, маркированы по времени (например, демографическая информация, такая как пол или этническая принадлежность, может быть неизменной посредством маркирования по времени) и, где приемлемо, специфическая для пациента информация, предпочтительно, хранится в структурированном формате, например, с разделенными по типу данных HL7-полями, хранящими конкретные типы данных. Компоненты 14 для ввода и извлечения информации содержат ряд компонентов (т.е. инструментов), обеспечивающих различные способы ввода данных о пациенте в ЭМК 10 и различные способы извлечения и представления данных о пациенте, содержащихся в ЭМК. Иллюстративные компоненты 14 для ввода и извлечения информации содержат схематически изображенные формы 20 для ввода данных (например, веб-ориентированные формы с разделенными по типу данных полями для ввода данных, упрощающими структурированный ввод данных), обработчики 22 запросов (например, язык структурированных запросов, SQL, обработчики запросов, если репозиторий 16 данных представляет собой систему управления реляционными данными, СУРД) и формы 24 для формирования клинических отчетов (например, интерфейс обработки текста и/или среда для более структурированного формирования отчетов с полями для ввода текста в свободной форме). Они являются лишь иллюстративными инструментами для взаимодействия, при этом предполагаются дополнительные или другие такие компоненты или инструменты. Компоненты 14 для ввода и извлечения информации взаимодействуют с различными внешними системами или компонентами для выполнения такого взаимодействия, например, взаимодействуя с вышеуказанной СПАИ 18 для извлечения медицинских изображений и связанных данных, и/или с одной или более лабораторных информационных систем 28, такими как те, что поддерживают лаборатории по гематологии, гистопатологии, цитопатологии, микроскопии или другие лаборатории специфических областей. При этом системы 18, 28 являются лишь иллюстративными примерами, а компоненты 14 для ввода и извлечения информации подобным образом могут взаимодействовать с многочисленными другими учреждениями, являющимися как внутренними, так и внешними, по отношению к больнице. Кроме того, компоненты 14 для ввода и извлечения информации, как правило, взаимодействуют с компьютерными рабочими станциями или другими терминалами для ввода данных, такими как репрезентативная компьютерная рабочая станция 30 ЭМК, содержащая дисплей 32 и одно или более устройств для ввода пользователя, таких как иллюстративная клавиатура 34 и мышь 36 или другое указательное устройство. Врач, медсестра, канцелярский персонал больницы или другие могут использовать рабочую станцию 30, например, для заполнения одной из электронных форм 20 для ввода данных или для ввода медицинского отчета через одну из форм 24 для медицинского отчета, и/или для извлечения хранимой информации о пациенте посредством ввода подходящего запроса через один из обработчиков 22 запросов.

Используемый в настоящем документе термин «электронная медицинская карта» или ЭМК следует понимать, как охватывающий интегрированные системы медицинской информации, обеспечивающие агрегацию и хранение данных о пациенте, независимо от того, называют ли такую систему электронной медицинской картой или электронной картой здоровья (ЭКЗ), или некоторой другой номенклатурой.

Как уже описано, ЭМК 10 обеспечивает хранение и извлечение данных о пациенте, однако не обеспечивает автоматическое генерирование содержания описательного медицинского отчета на естественном языке (например, английском, китайском, французском или другом), содержащего релевантную контекстуальную информацию и, в некоторых случаях, клинические заключения, которые могут быть надлежащим образом учтены. Вместо этого, для генерирования содержания описательного отчета предусмотрен инструмент 40 для управления бизнес-процессами (УБП). Инструмент 40 для УБП может функционировать на одном и том же компьютерном сервере 12, который хранит ЭМК 10, как показано, или инструмент для УБП может находиться на другом компьютере, который соединен с возможностью связи с компьютером (компьютерами) ЭМК. Инструмент 40 УБП может быть реализован с использованием по существу любого комплекса по разработке УБП, такого как «Bonita ВРМ» (доступного от компании «Bonitasoft, Inc.»), «Oracle Business Process Management Suite» (доступного от компании «Oracle Corp.») или другого. Комплекс для УБП обеспечивает или функционально соединен с графическим редактором 42 модели бизнес-процесса (БП), что обеспечивает конструирование или редактирование модели БП, например, в графическом представлении модели и нотации бизнес-процессов (BPMN). BPMN представляет модель БП с использованием формата диаграммы потока, содержащей объекты потока, представляющие события, действия, переходы (например, узлы решений) или другое; а также соединитель или соединяющие объекты, представляющие процесс и/или поток данных между объектами в потоке (см., например, ФИГ. 2, описанную подробно ниже в настоящем документе). В более общем смысле, термин «узел» используют в настоящем документе для общего обозначения события процесса, задачи или другой точки в модели БП (например, объекта в потоке в графической нотации BPMN); а термин «переход между узлами» используют в настоящем документе для обозначения потока процесса, входящего или выходящего из узла, как правило, в соответствии с соединительным объектом, который соединен с узлом в графической нотации BPMN.

Графический редактор 42 модели БП модифицирован так, как описано в настоящем документе, для включения редактора 44 шаблонов описательных клинических аннотаций, что обеспечивает возможность добавления шаблонов описательных клинических аннотаций, связанных с переходами между узлами модели БП. Врач или другой медицинский специалист подходящим образом использует графический редактор 42 модели БП для построения и/или редактирования модели БП клинического протокола с шаблонами описательных клинических аннотаций, связанных с выбранными переходами между узлами, с использованием редактора 44 шаблонов. В дополнение к редактору 44 шаблонов описательных клинических аннотаций, графический редактор 42 может содержать другие расширения, плагины или подобное (не показано), обеспечивая определения объектов в потоке для узлов (например, объекты в потоке), реализующие связи с ЭМК 10 - такие определения доступа к ЭМК могут быть созданы, например, посредством конфигурации имеющихся BPMN объектов данных для взаимодействия с ЭМК 10, с которой будет взаимодействовать модель БП.

Полученную сконструированную или отредактированную модель 46 БП клинического протокола с шаблонами описательных клинических аннотаций сохраняют в некратковременном носителе 48 для хранения, содержащимся в инструменте 40 для УБП или доступном ему. Носитель 48 для хранения может содержать, например, жесткий диск, RAID (избыточный массив независимых дисков) или другой магнитный носитель, оптический диск или другой оптический носитель для хранения, флеш-память или другой электронный носитель для хранения, различные их комбинации или другое. Модель 46 БП может храниться на некратковременном носителе 48 для хранения в BPMN и/или на скомпилированном исполняемом языке, таком как язык выполнения бизнес-процессов (BPEL). Обработчик 50 рабочего процесса УБП считывает и исполняет сохраненную модель 46 БП клинического протокола с шаблонами описательных клинических аннотаций. Это выполняют для конкретного пациента - таким образом, множество «случаев» исполнения модели 46 БП может дойти до любого заданного момента времени. При исполнении модели 46 БП для конкретного пациента, интерфейс 52 ЭМК реализует взаимодействие с ЭМК 10 для выполнения извлечения данных о пациенте или записи операций, таких как извлечение данных о пациенте для конкретного пациента, требуемых на конкретном узле.

По мере исполнения обработчиком 50 рабочего процесса БП модели 46 БП для конкретного пациента, собирают различные данные для различных пройденных узлов (например, объектов в потоке в BPMN) и/или данные могут быть сгенерированы в различных пройденных узлах. Фактический путь, пройденный по конкретному пациенту через модель 46 БП клинического протокола, как правило, также сохраняют. Кроме того, это может называться историей прохождения по пациенту. Данную специфическую для пациента информацию сохраняют в хранилище 54 путей пациента, например, индексируют по ID пациента. Как и некратковременный носитель 48 для хранения, хранилище 54 путей пациента представляет собой подходящий некратковременный носитель для хранения, такой как, например, жесткий диск, RAID (избыточный массив независимых дисков) или другой магнитный носитель для хранения, оптический диск или другой оптический носитель для хранения, флеш-память или другой электронный носитель, различные их комбинации или другое.

Вычислительные компоненты инструмента 40 для УБП, например, графический редактор 42 модели БП и обработчик 50 рабочего процесса БП и их составные компоненты, также подходящим образом хранятся на некратковременном носителе для хранения (не показан) в виде исполнимого кода (т.е. программы), считываемого и исполнимого компьютером 12. Кроме того, некратковременный носитель для хранения может содержать, например, жесткий диск, RAID (избыточный массив независимых дисков) или другой магнитный носитель для хранения, оптический диск или другой оптический носитель для хранения, флеш-память или другой электронный носитель для хранения, различные их комбинации или другое. Следует отметить, что в некоторых вариантах реализации модель 46 БП генерируют в отдельном редакторе модели (например, предоставленном коммерческим поставщиком, который выводит на рынок ЭМК 10 с интегрированным инструментом 40 для УБП), причем в этом случае инструмент 40 для УБП, который находится в функциональной связи с ЭМК 10, может, при необходимости, не содержать графический редактор 42 модели БП. Однако даже в случае генерирования модели БП в режиме оффлайн, при необходимости, все еще может быть предусмотрен графический редактор 42 модели БП для обеспечения возможности последующего редактирования или обновления модели 46 БП и/или ее шаблонов описательных клинических аннотаций.

Исполнение модели 46 БП по конкретному пациенту обеспечивает механизм для отслеживания прохождения пациента по моделированному клиническому протоколу. Модель 46 БП может быть сконструирована на очень детализированном уровне для того, чтобы охватить относительно «рутинные» события, такие как введение различных лекарственных препаратов несколько раз в сутки, измерение различных показателей жизненно важных функций несколько раз в сутки и другое; а также охватывая высокоуровневые детали, такие как в случае, когда пациенту проводят исследование МРТ или процедуру лучевой терапии, или другое. Кроме того, шаблоны описательных клинических аннотаций связаны с некоторыми переходами между узлами по пути пациента в модели 46 БП клинического протокола. Эти шаблоны описательных клинических аннотаций создают и связывают с переходами между узлами с использованием редактора 44 шаблонов клинических аннотаций во время создания или редактирования модели 46 БП клинического протокола. Эти шаблоны описательных клинических аннотаций используют для автоматического генерирования содержания описательного отчета в клиническом протоколе пациента. Это выполняют посредством заполнения полей шаблонов описательных клинических аннотаций, связанных с переходами между узлами в пути пациента по модели 46 БП клинического протокола, специфической для пациента информацией, хранящейся в ЭМК 10.

Содержание описательного отчета может быть сгенерировано (приблизительно) в режиме реального времени, то есть по мере исполнения модели 46 БП для пациента в каждом случае прохождения по переходу между узлами, имеющему связанный шаблон описательных клинических аннотаций, во время исполнения, компонент 60 генерирования содержания описательного клинического отчета, содержащийся в генераторе 50 содержания клинического отчета, (как показано, или, в качестве альтернативы, генератор 50 содержания описательного клинического отчета может быть отдельным от обработчика рабочего потока) заполняет поля шаблона описательных клинических аннотаций, связанного с исполняемым в данный момент переходом между узлами, и сохраняет содержание описательного отчета, сгенерированное посредством заполнения шаблона в карте пациента в хранилище 54 пройденных путей пациента. В данном случае, при подготовке врачом медицинского отчета по пациенту, например, с использованием иллюстративной компьютерной рабочей станции 30 ЭМК и одной из форм 24 медицинского отчета, пользователь может выбрать опцию извлечения содержания описательного клинического отчета из ЭМК. В ответ на данный выбор, взаимодействующие с инструментом ЭМК/УБП компоненты 14, 52 используются для извлечения содержания описательного отчета, хранящегося в карте пациента в хранилище 54 пройденных путей пациента.

В варианте реализации содержание описательного отчета генерируют ретроспективным образом. В данном случае шаблоны не заполняют в момент исполнения связанного перехода между узлами. Вместо этого, когда врач выбирает опцию извлечения содержания описательного клинического отчета из ЭМК, содержание описательного отчета генерируют в момент этого выбора (т.е. ретроспективным образом) посредством повторного трассирования ранее исполненного пути для пациента по модели 46 БП клинического протокола. Это возможно благодаря тому, что история прохождения сохранена в хранилище 54 пройденных путей пациента. По мере повторного трассирования пути для пациента по модели 46 БП, поля шаблонов описательных клинических аннотаций, связанных с переходами между узлами повторно трассированного пути, заполняют специфической для пациента информацией, хранящейся в ЭМК 10, для генерирования содержания описательного отчета.

В вариантах реализации с режимом реального времени или ретроспективным режимом, сгенерированное содержание описательного отчета передают в ЭМК 10 через компоненты 14, 52 взаимодействия и отображают врачу на дисплее 32. В одном подходе, подходящем для использования в описанном контексте, в котором врач составляет медицинский отчет по пациенту, сгенерированное содержание описательного отчета предлагают врачу посредством отображения сгенерированного содержания описательного отчета на дисплее 32, и предложенное описательное содержание копируют в составляемый (или иным образом хранящийся в репозиторий 16 данных ЭМК) медицинский отчет в ответ на согласие с предложением, полученное от врача через устройство (устройства) 34, 36 интерфейса пользователя. В таких вариантах реализации врач или другой пользователь не взаимодействует непосредственно с инструментом 40 для УБП, а инструмент 40 для УБП не запрограммирован на управление устройством 30 для взаимодействия с пользователем для отображения сгенерированного содержания описательного отчета; вместо этого, инструмент 40 для УБП запрограммирован на передачу сгенерированного содержания описательного отчета в ЭМК 10, а ЭМК управляет взаимодействием с пользователем для представления сгенерированного содержания описательного отчета врачу или другому пользователю. (В других альтернативных вариантах реализации предполагается, что врач непосредственно взаимодействует с инструментом для УБП).

Еще одной задачей, которая может возникнуть при генерировании содержания описательного отчета, описанном в настоящем документе, является то, каким образом охватить параллельные пути (ветви) модели 46 БП. Параллельные пути часто встречаются в клинических протоколах - например, после диагностирования у пациента конкретного типа рака, врач может провести: биопсию, предоставляя образцы ткани для исследования гистопатологии; медицинскую визуализацию для оценки наличия/характеристик опухоли(ей) и начальную химиотерапию или какую-либо другую начальную терапию (которая, вероятно, будет модифицирована после получения данных лабораторного исследования и визуализации). Таким образом, узел принятия решения, представляющий собой диагноз рака, имеет несколько выходящих переходов между узлами на параллельные ветви: одна ветвь, моделирующая биопсию/гистопатологию; одна ветвь, моделирующая медицинскую визуализацию; и одна ветвь, моделирующая исходное лечение.

В иллюстративных примерах, представленных в настоящем документе, такими параллельные путями или ветвями управляет генератор 50 содержания описательного клинического отчета следующим образом. Если путь для пациента по модели 46 БП клинического протокола содержит две или более ветви модели БП, представляющей действия в клиническом протоколе, предпринимаемые параллельно, содержание описательного отчета, сгенерированное посредством заполнения полей шаблонов описательных клинических аннотаций, связанных с переходами между узлами каждой ветви, группируют в раздел для этой ветви. Так генерируют раздел содержания описательного отдельного отчета для каждой ветви из двух или более параллельных ветвей. В данном подходе распознают, что каждая параллельная ветвь, как правило, представляет собой относительно независимый подпроцесс, который зачастую выполняется определенным набором исполнителей. Таким образом, группировка содержания описательного отчета каждой ветви в его собственный раздел, вероятно, приведет к семантически связанному словесному описанию подпроцесса, представленного ветвью.

Далее описаны некоторые дополнительные иллюстративные примеры. В целом, система содержит: ЭМК 10, содержащую клинические данные о пациенте, такие как возраст или другие демографические данные, результаты лабораторных исследований, информацию о диагностических и/ил и лечебных процедурах, выполненных для пациента, или другое; модель 46 БП, основанную на клиническом протоколе, которая описывает этапы, подлежащие выполнению для лечения некоторого состояния пациентов; редактор 42 модели БП, который взаимодействует с автором модели БП для добавления конкретных аннотаций в части (например, переходы между узлами) модели 46 БП (например, через редактор 44 шаблонов в иллюстративном примере); обработчик 50 рабочего потока БП, который исполняет модель 46 БП по конкретному пациенту и встроен в ЭМК 10; и модуль 60 генератора отчета, выполненный с возможностью считывания данных с обработчика 50 рабочего потока, которые, возможно, расширены дополнительными данными из ЭМК 10.

Модель 46 БП клинического протокола расширена аннотациями процесса (представленными шаблонами описательных клинических аннотаций), которые обеспечивают автору модели БП возможность включения частей предложения или другого описательного содержания, которое может быть использовано для генерирования отчета. Поля шаблонов описательных клинических аннотаций заполняют во время исполнения (или повторного трассирования) с целью включения в описание специфической для пациента информации из ЭМК 10 или других источников, таких как результаты измерения показателей жизненно важных функций, информация о дате, данные лабораторных исследований или другое. Как правило, наиболее важные единицы информации для включения в медицинский отчет относятся к выходящим переходам между узлами, поскольку они представляют собой сложное действие или решение, которое должно быть резюмировано в медицинском отчете. Входящие переходы между узлами также могут представлять важность, поскольку они представляют данные, приводящие к задаче, событию или подобному, представленному узлом (более того, в большинстве случаев выходящий из одного узла переход между узлами соответствует входящему в следующий узел переходу между узлами). Кроме того, следует понимать, что в настоящем документе информация в узлах принятия решения, как правило, представляет особую важность для включения в медицинский отчет, поскольку узлы принятия решения находятся там, где определен последующий набор действий.

В качестве примера, рассмотрим задачу, подлежащую выполнению медсестрой, такую как «Проверка кровяного давления». В данном случае задача представлена узлом (например, объектом потока в BPMN), а шаблон описательной клинической аннотации на выходном переходе между узлами подходящим образом представляет собой «Медсестра измерила кровяное давление с показателем <КД> в <время>», где <КД> и <время> представляют собой поля шаблона аннотации, которые заполняют фактическим результатом измерения кровяного давления и фактическим временем, соответственно. Данные, подлежащие заполнению, подходящим образом извлекают из репозитория 16 данных ЭМК через компоненты 14, 52 взаимодействия.

Шаблон описательных клинических аннотаций может иметь условную зависимость таким образом, что он генерирует содержимое описательного отчета только при соблюдении некоторого условия, указанного в шаблоне. Например, в предыдущем примере с измерением кровяного давления может быть необязательно включать кровяное давление в медицинский отчет, если результат измерения кровяного давления находится в нормальном диапазоне для пациента. Таким образом, для узла модели БП, который представляет собой точку принятия решения «Кровяное давление пациента является слишком высоким?», шаблон аннотации на выходящем переходе между узлами может быть сконструирован для генерирования: (1) содержания описательного отчета в форме «Результат измерения кровяного давления <КД> слишком высок», если результат измерения кровяного давления больше, чем некоторое пороговое значение, или (2) никакого содержания описательного отчета, если результат измерения кровяного давления не превышает пороговое значение.

По запросу, генератор 60 содержания описательного клинического отчета генерирует описательный отчет исполненных или находящихся на исполнении процессов. В ретроспективном варианте реализации это происходит следующим образом. Начиная со стартового узла модели 46 БП, следует (т.е. повторно трассируется) исполняемый путь по модели 46 БП. Для каждого шаблона описательных клинических аннотаций, с которыми сталкиваются, поля шаблона аннотации заполняют для генерирования содержания описательного отчета, предпочтительно, в форме одного или более предложений, определенных шаблоном. (Как было отмечено, если шаблон зависит от условия, то содержание описательного отчета генерируют только при соблюдении условия, например, кровяное давление выше порогового значения). Содержание описательного отчета, сгенерированное на каждом таком переходе между узлами, связывают вместе для генерирования текущего описания. Если пройденный узел имеет множество выходящих переходов между узлами (т.е. параллельных ветвей), то этот процесс выполняют для каждой ветви для генерирования отдельного раздела для этой ветви, и разделы комбинируют для формирования многораздельного описания параллельных ветвей, сгруппированных по ветви. В целом, это обеспечивает более целостное описание по сравнению с битами информации из каждой ветви, смешанными вместе. Сгенерированное содержание описательного отчета представляют врачу или другому конечному пользователю в иллюстративном варианте реализации посредством его направления в ЭМК 10, которая предлагает сгенерированное описательное содержание для включения в составляемый медицинский отчет и/или для включения в карту пациента в репозиторий 16 данных ЭМК.

Со ссылкой далее на ФИГ. 2 представлен пример, в котором используют модель БП клинического протокола, содержащего протокол сепсиса. На ФИГ. 2 изображена часть модели БП, показанная с использованием нотации BPMN, которую может видеть разработчик модели, взаимодействующий с графическим редактором 42 модели БП. Существует ряд выполняемых человеком задач, представленных на графическом представлении на ФИГ. 2 в виде прямоугольников со значком «человека», показанном в верхнем левом углу. Узел принятия решения представлен в виде «X», заключенного в ромбе. Таймер обозначен значком «часов», показанным на краю узла, и указывает на то, что переход между узлами инициируется по истечению указанного временного интервала. Узлы старта и конца процесса (или подпроцесса) обозначены узлами в виде небольших кругов.

Со ссылкой далее на ФИГ. 2, шаблоны описательных клинических аннотаций, связанные с переходами между узлами с использованием редактора 44 шаблонов клинических аннотаций, обозначены значками «документов», где значок «документа» представляет собой лист бумаги, обрезанный в нижней части искривленной линией. Для упрощения описания в настоящем документе, значок шаблона описательных клинических аннотаций пронумерован - на ФИГ. 2 представлено шесть шаблонов описательных клинических аннотаций, пронумерованных 1…6. (Такая нумерация необязательна в текущем BPMN-представлении модели БП, поскольку пользователь может выбирать просмотр/редактирование шаблона описательных клинических аннотаций посредством щелчка на этот значок с использованием указателя мыши или посредством некоторой другой операции выбора пользователя). Шесть иллюстративных шаблонов описательных клинических аннотаций, в свою очередь, описаны ниже.

Шаблон описательной клинической аннотации, пронумерованный «1», связан с переходом из узла начала процесса в самой левой части ФИГ. 2. Шаблон описательной клинической аннотации может подходящим образом называться «Отчет протокола сепсиса по пациенту <имя_пациента>, возраста <возраст_пациента>: \ВК\ВК Пациент вошел в протокол сепсиса в <местоположение> в <время> и у него было диагностировано <первичный_диагноз>.» Поля <имя_пациента> и <возраст_пациента> заполняют информацией об имени и возрасте пациента из ЭМК пациента. Нотация \ВК обозначает возврат каретки. Поля <местоположение> и <время> заполняют местоположением пациента с диагнозом и временем постановки диагноза, соответственно, а поле <первичный_диагноз> заполняют первичным диагнозом.

Шаблон описательной клинической аннотации, пронумерованный «2», связан с переходом из узла принятия решения, промаркированного «По меньшей мере 2 <симптома сепсиса>». Здесь подходящий шаблон описательной клинической аннотации может представлять собой «В <время> проверка медсестрой показателей жизненно важных функций выявила, что у пациента был риск серьезного сепсиса, исходя из следующих критериев: <перечень отклоненных от нормы значений>.» Поле <перечень отклоненных от нормы значений> может быть заполнено посредством проведения поиска данных о пациенте, полученных в узком временном окне около <время> для идентификации отклоненных от нормы значений.

Шаблон описательной клинической аннотации, пронумерованный «3», связан с переходом из узла принятия решения, промаркированного «Экстренная органная недостаточность?». Подходящий шаблон описательной клинической аннотации может представлять собой «Результат проведенного исследования крови подтвердил наличие экстренной органной недостаточности, исходя из следующих критериев: <перечень отклоненных от нормы значений>. <Врач_пациента> был проинформирован в <время_обнаружения>.»

Шаблон описательной клинической аннотации, пронумерованный «4», связан с переходом из объекта потока, промаркированного «[Дежурный врач] создал <план лечения>». Подходящий шаблон описательной клинической аннотации может представлять собой «<Врач_пациента> создал следующий план лечения в <время> : <перечень лекарственных препаратов>». Поле <перечень лекарственных препаратов> может быть заполнено из введенного в ЭМК 10 назначения приблизительно во время исполнения объекта потока «[Дежурный врач] создает <план лечения>».

Шаблон описательной клинической аннотации, пронумерованный «5», связан с переходом из объекта потока, промаркированного «[Медсестра] подтверждает завершение лечения». Подходящий шаблон описательной клинической аннотации может представлять собой «Медсестра ввела лекарственный препарат в <время_введения>». В данном случае <время_введения> заполняют временной меткой введения лекарственного препарата в ЭМК пациента.

Шаблон описательной клинической аннотации, пронумерованный «6», связан с переходом между узлами из управляемого таймером перехода из объекта потока, промаркированного «Лечение пациента в течение одного часа». Подходящий шаблон описательной клинической аннотации может представлять собой «Время между обнаружением острого сепсиса и введением антибиотиков превышало целевое время клинического протокола».

По мере прохождения каждого перехода между узлами, связанного с шаблонами описательных клинических аннотаций 1…6, генерируют соответствующее содержание описательного отчета. Таким образом, может быть сгенерировано следующее собирательное содержание описательного отчета:

Отчет протокола сепсиса по пациенту Джон До, возраст 48 лет: Пациент вошел в протокол сепсиса через общую палату в воскресенье, 26 марта в 6:24 РМ, с диагнозом операция на сердце. В понедельник, 27 марта в 10:36 AM проверка медсестрой показателей жизненно важных функций выявила, что у пациента был риск серьезного сепсиса, исходя из следующих критериев:

- Температура 39,9°С (выше порога в 36,6°С)

- Частота дыхания 35 движений в минуту (выше порога в 30) Результат проведенного исследования крови подтвердил наличие

экстренной органной недостаточности, исходя из следующих критериев:

- Лейкоциты: 36,540 (выше порога в 35,000)

Др. Смит был проинформирован в 10:45 AM. Др. Смит создал следующий план лечения в 10:56 AM:

- Антибиотик: Xanatex 35 мг

Медсестра ввела лекарственное средство в 11:55 AM. Время между обнаружением острого сепсиса и введением антибиотиков превышало целевое время клинического протокола.

Несмотря на отсутствие на схематически изображенных выше шаблонах описательных клинических аннотаций, пронумерованных 1…6, поля этих шаблонов, при необходимости, могут содержать разделители форматирования или подобное, например, конкретизируя выбор формата вывода времени (ЧЧ:ММ или ЧЧ:ММ:СС и так далее), форматирования данных о пациенте или другое. Шаблоны могут содержать другие признаки, такие как устойчивые выражения, например, для шаблона, пронумерованного 6, предполагается добавление выражения разницы для вычисления и количественного описания того, насколько большим является интервал между обнаружением острого сепсиса и введением антибиотиков по сравнению с контрольным значением клинического протокола сепсиса.

В качестве еще одного примера, шаблон описательной клинической аннотации может описывать контрольный перечень, в котором несколько задач подлежат выполнению перед выполнением следующих этапов. В таком случае содержание описательного отчета может включать задачи, которые были выполнены, с полями для заполнения при идентификации исполнителя, который выполнил каждую задачу, в какое время, а также, при необходимости, если задача была не выполнена, причину этого. Примером такого контрольного перечня является:

В <8:26 РМ> <врач W.> создал <план лечения> по завершению следующих задач:

- Измерение кровяного давления, выполненное <медсестрой Р.> в <8:13 РМ>.

- Получение результата лабораторного исследования, выполненное <медсестрой Т.> в <8:16 РМ>.

- Не завершено: Выдача лекарственного средства ингибитора АПФ. Отклонено <врачом W.> по причине <у пациента аллергия>.

где угловыми скобками (<…>) вновь обозначены поля.

Со ссылкой на ФИГ. 3 описан автоматический способ генерирования содержания описательного отчета, подходящим образом выполняемый системой по ФИГ. 1. При выполнении операции 70 обнаруживают инициирующее событие или генерирование инициирующих данных, инициирующих операцию 72, на которой для пациента начинают выполнение модели 46 БП клинического протокола. В представленном выше примере протокола сепсиса инициирующее событие представляет собой обнаружение показателей жизненно важных функций, являющихся показательными в отношении риска острого сепсиса, а при выполнении операции 72 начинают выполнение модели БП протокола сепсиса для пациента. Это влечет за собой создание пути карты пациента для пациента в хранилище 54 путей пациента для записи пути пациента по протоколу сепсиса. При выполнении операции 74 модель 46 БП исполняет обработчик 50 рабочего потока. Это влечет за собой обнаружения инициирующих событий или данных, вызывающих переходы от одного узла к другому, и запись истории прохождения в хранилище 54. При выполнении операции 76 обнаруживают событие или запрос, который запускает генерирование содержание описательного отчета. (Здесь используется ретроспективный подход, в котором путь повторно трассируют). Инициирующее событие или инициирующий запрос может представлять собой, например, открытие врачом одной из форм 24 медицинского отчета через интерфейс 30 пользователя, который выполнен с возможностью записи объекта клинического протокола, моделируемого моделью 46 БП. В качестве альтернативы, инициирующее событие или инициирующий запрос может представлять собой подтверждающее действие врача, такое как выбор опции на интерфейсе пользователя для ЭМК с целью предложения содержания описательного отчета. (Снова, в иллюстративном варианте реализации врач взаимодействует с ЭМК 10, а инструмент 40 для БП скрыт таким образом, что врач воспринимает ЭМК как генерирующую содержание описательного отчета).

При выполнении операции 80 историю прохождения пациента извлекают из хранилища 54 путей пациента и прохождение пациента повторно трассируют, начиная с входного узла модели 46 БП. Для каждого повторно трассированного узла при решении 82 выходящий переход (например, выходящий соединяющий BPMN-объект) исследуют для определения того, имеет ли он связанный шаблон описательной клинической аннотации. Если нет, то процесс переходит обратно на операцию 80 для повторного трассирования к следующему узлу вместе с посредством прохождения пациента. С другой стороны, если при решении 82 обнаружен шаблон описательной клинической аннотации, связанный с выходящим переходом между узлами, то при выполнении операции 84 поля (при их наличии) шаблона описательной клинической аннотации заполняют специфической для пациента информацией из ЭМК 10, а при выполнении операции 86 полученное в результате содержание описательного отчета добавляют в (собирательное) содержание описательного отчета.

Заданный узел может иметь два или более выходящих перехода - если это так, то каждый выходящий переход между узлами, в свою очередь, исследуют в решении 82 и обрабатывают согласно операциям 84, 86, если присутствует связанный шаблон описательной клинической аннотации. Если это приводит к идентификации параллельных ветвей, то каждую ветвь обрабатывают отдельно с использованием операций (замыкания) 80, 82, 84, 86 для генерирования отдельного раздела содержания описательного отчета для каждой ветви, и разделы собирают для генерирования собирательного содержания описательного отчета.

Когда история прохождения пациента до настоящего времени была полностью повторно трассирована, то при выполнении операции 90 полученное в результате собирательное содержание описательного отчета импортируют в составляемый медицинский отчет в ЭМК 10 или иным образом переносят в ЭМК 10 и используют (например, сохраняют в репозиторий 16 ЭМК).

В способе по на ФИГ. 3 используют ретроспективный подход с повторным трассированием для генерирования содержания описательного отчета. Если вместо этого используют подход в режиме реального времени, операции 80, 82, 84, 86 интегрируют в режиме реального времени в исполнение 74 модели БП, и в ответ на запрос 76, уже сгенерированное и сохраненное в хранилище 54 путей пациента содержание описательного отчета считывают и импортируют в ЭМК 10.

Настоящее изобретение было описано со ссылкой на предпочтительные варианты реализации. Специалистам в данной области техники могут быть ясны модификации и изменения после прочтения и понимания представленного выше подробного описания. Предполагается, что настоящее изобретение выполняют так, чтобы включить все такие модификации и изменения в такой мере, в какой они находятся в пределах объема прилагаемой формулы изобретения или ее эквивалентов.

Реферат

Изобретение относится к области информационных технологий, а именно к формированию электронных медицинских карт. Технический результат заключается в расширении арсенала средств того же назначения. Устройство для формирования медицинских записей и отчетов, включающее носитель для хранения, хранящий модель клинического протокола, содержащую шаблоны описательных клинических аннотаций, связанные с переходами между узлами в модели процесса клинического протокола, и инструмент управления процессом, выполненный с возможностью исполнения на вычислительном устройстве и имеющий: обработчик рабочего потока для исполнения пути пациента по модели процесса клинического протокола посредством прохождения узлов модели процесса клинического протокола в соответствии со специфической для пациента информацией, хранящейся в электронной медицинской карте (ЭМК), и генератор содержания для генерирования содержания описательного отчета по клиническому протоколу для пациента посредством заполнения полей шаблонов описательных клинических аннотаций. 3 н. и 12 з.п. ф-лы, 3 ил.

Формула