Моделирование сущностей "эпизод" и "случай" для составления профилей Encounter и EpisodeOfCare.

[Vrodvi]

Вводные сведения для начала моделирования

Encounter ("случай") - это конкретный случай взаимодействия пациента с поставщиком мед.услуг,
EpisodeOfCare ("эпизод") - это информация о контроле за пациентом некой мед. организацией (в рамках такого эпизода конкретных случаев может и не произойти).

<TODO - расширить вводную часть, обозначить необходимость логического моделирования и подробного текстового описания моделируемых сущностей>

Примеры выделения сущностей "эпизод" и "случай" для разных видов медицинской помощи представлены ниже.

См. также связанные обсуждения:

• Профилирование Encounter. #139
• Какие бывают номера карт пациента и где их хранить #150

См. сопровождающие материалы:

• Таблица "UseCases для обмена информацией о случаях оказания МП"
• Miro-доска для обсуждений в ходе встреч рабочей группы

Записи встреч:

• Выбор пилотного UseCase для представления эпизодов\случаев медицинской помощи
• Обсуждение Диспансерного наблюдения
• Обсуждение Амбулаторного наблюдения
• Обсуждение реализации MPI и прикрепления пациентов для получения амбулаторной медицинской помощи
• Обсуждение после-госпитального этапа и общего подхода к ведению "обобщенного случая"

1) Амбулаторное наблюдение.

С момента прикрепляется пациента за некоторой поликлиникой можно считать открытым амбулаторное ведение пациента в этой организации, в качестве его идентификатора можно указать номер амбулаторной карты (025/у).
Такое амбулаторное ведение может быть смоделировано в виде "эпизода - Амбулаторное ведение конкретной организацией" (EpisodeOfCare) или в виде "пациента - Амбулаторный пациент" (Patient).

Конкретные посещения пациентом поликлиники объединяются в "обращение" в виде "эпизода - Обращение за амбулаторной помощью" (EpisodeOfCare), в качестве его идентификатора можно указать номер талона (025-1/у).

Конкретные посещения пациентом поликлиники - это "случаи" (Encounter) в рамках "случай - Амбулаторное посещение".

• ??? [0..1] EpisodeOfCare "эпизод - Общее амбулаторное обслуживание пациента" ???
  • [1..*] EpisodeOfCare "эпизод - Амбулаторное ведение конкретной организацией" или Patient "пациент - Амбулаторный пациент" <= Тут указывается номер амбулаторной карты
    • [0..*] EpisodeOfCare "эпизод - Обращение за амбулаторной помощью" <= Тут указывается номер талона
      • [0..*] Encounter "случай - Амбулаторное посещение"

Вопросы к обсуждению:
нужно ли выделять сущность - "Общее амбулаторное обслуживание пациента", которое не зависит от конкретной организации, оказывающей амбулаторную помощь?
чем считать посещения врача на дому - также "случай" в рамках амбулаторного наблюдения?
можно ли использовать ресурс-пациент (Patient) для обозначения прикрепления пациента к поликлинике?

2) Госпитализация.

Госпитализация - это конкретный "случай" (Encounter) взаимодействие пациента со стационаром и на время этого взаимодействия заводится карта стационарного пациента.
Внутри госпитализации переводы пациента между отделения также являются "случаями".
"Эпизод" (EpisodeOfCare) также может быть оформлен. Например, для Дневных Стационаров, когда несколько отдельных госпитализаций в ДС объединяются вместе, поскольку являются продолжениями друг друга (например, несколько госпитализаций в ДС для проведения нескольких линий химиотерапевтического лечения по одному заболеванию).

• [0..1] EpisodeOfCare (объединение нескольких госпитализаций по одному заболеванию)
  • [1..*] Encounter (госпитализация) <= Тут указывается номер карты стационарного пациента
    • [1..*] Encounter (пребывание в отделении)

Вопросы к обсуждению:
консультации врачей во время пребывания пациента в стационаре - тоже "случаи"?

3) Диспансерное наблюдение.

С момента постановки пациента на диспансерное наблюдение можно считать открытым "эпизод - Диспансерное наблюдение по профилю" (EpisodeOfCare) (объект выделен сообществом, т.к. НПА его не регламентируют).
(альтернативно можно моделировать это как общий "План ведения - Диспансерное наблюдение по профилю" (CarePlan))
В качестве состояния, наблюдаемого в рамках этого эпизода, можно установить целый медицинский профиль соответствующего наблюдаемого состояния, например "онкология".
Кто должен быть установлен в качестве наблюдающей организации не регламентировано, границы ответственности примерно пересекаются с системами ВИМИС, например ВИМИС Онкология.

Диспансерное наблюдение по поводу конкретного состояния в рамках одного медицинского учреждения - это открытие "эпизода - Диспансерное наблюдение по состоянию конкретной организацией" (EpisodeOfCare) (регламентируется приказами N 548н, N 168н).
В качестве состояния, наблюдаемого в рамках этого эпизода, можно установить конкретное заболевание (или риск возникновения заболевания или иное состояние в соответствии с НПА).
В качестве наблюдающей организации устанавливается медицинская организация, где пациент получает первичную медико-санитарную помощь, в соответствии с НПА.

Конкретные посещения пациентом диспансера - это "случаи - Наблюдения" (Encounter) в рамках такого "эпизода - Диспансерное наблюдение по состоянию".

• [0..*] EpisodeOfCare "эпизод - Диспансерное наблюдение по профилю" или CarePlan "План ведения - Диспансерное наблюдение по профилю"
  • [1..*] EpisodeOfCare "эпизод - Диспансерное наблюдение по состоянию конкретной организацией" <= Тут указывается номер карты диспансерного наблюдения (например, N 030/у)
    • [0..*] Encounter "случай - Наблюдение"

4) Скорая медицинская помощь.

С момента принятия вызова от пациента можно считать открытым "эпизод" (EpisodeOfCare) скорой медицинской помощи, который завершится вместе с завершением вызова.
Взаимодействия пациента с бригадой СМП - "случай" (Encounter).

• [0..1] EpisodeOfCare (связь между пациентом и ответственной за него организацией скорой медицинской помощи на период от принятия заявки до завершения вызова)
  • [1..1] Encounter (выезд скорой медицинской помощи) <= Тут указывается номер карты скорой медицинской помощи

---

Дополнительные виды медицинской помощи, которые стоит дополнительно проанализировать для выделение "эпизодов" и "случаев" (обозначены в комментарии #150 (comment)):

• история развития ребенка (112/у)
• карта профилактических прививок (063/у)
• контрольная карта диспансерного наблюдения (030/у)
• медицинская карта ортодонтического пациента (043-1/у)
• медицинская карта пациента, получающего помощь в амбулаторных условиях (025/у)
• медицинская карта ребенка для образовательных учреждений (026/у)
• медицинская карта стоматологического больного (043/у)
• карта персонального учета пациента с ВИЧ-инфекцией (025-4/у)
• обменная карта беременной, роженицы и родильницы (113/у)

---

Сводка по подбору FHIR-ресурсов, необходимых для разобранных сценариев, представлена по [ссылке (google sheets)]:(https://docs.google.com/spreadsheets/d/1LAlptxGFQ5BdKe5vWGbNOHBOX1i4HXtVWpbAUhMq7_Q/edit?usp=sharing)

---

Для подобранных FHIR-ресурсов будут сформированы базовый (Ru Core) профили с минимальными ограничения структуры.
Базовые профили должны содержать только перевод на русский язык текстов и пояснений к полям, а также должны быть снабжены комментариями/рекомендациями по использованию этих ресурсов в разобранных сценариях.
На основании анализа сценариев выявлена необходимость в профилирования ресурсов CarePlan, EpisodeOfCare, Encounter.
Профилирование должно быть осуществлено в формате FSH.
Результаты профилирования будут приложен к данной карточке по мере их готовности:

• [временный вариант] общий FSH-файл с подготовленными заготовками - FSH discussions 221.zip
  • Файл сформирован со всеми необходимыми заготовками по обсуждённым артефактам CarePlan, EpisodeOfCare, Encounter и сопутствующим им ресурсам, чтобы проходила валидация по FSH\SUSHI
  • Файл сформирован с комментариями. Если убрать символы комментариев, то получится полноценный текст в формате Markdown (который можно просмотреть, например, через https://hackmd.io/). В том числе добавлена диаграмма классов для сформированных профилей в формате PlantUml Class Diagram.
    • 
    • 
    • 

[eugenekogan-spb]

В составе амбулаторного наблюдения обычно можно выделить элементы медицинского обслуживания двух уровней:

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

[eugenekogan-spb]

Для вызова скорой, на мой взгляд, EpisodeOfCare не требуется, поскольку нет понятия "ответственности организации за пациента" в течение периода времени.

[eugenekogan-spb]

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

[Vrodvi]

@eugenekogan-spb

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

Также описание ресурса в спецификации FHIR говорит о том, что ресурсов пациент может быть создано несколько - под каждую организацию http://hl7.org/fhir/patient.html#scope:

A Patient record is generally created and maintained by each organization providing care for a patient. A patient or animal receiving care at multiple organizations may therefore have its information present in multiple Patient Resources.

При этом в RU-Core дано лишь короткое описание ресурса Patient, в котором не обозначено предназначение ресурса - http://fhir-ru.zendoc.me/core.profile.Patient.

Хотелось бы услышать мнение административной группы по поводу:

• предназначения ресурса Patient
• возможности его использования для моделирования "Наблюдения за пациентом медицинской организацией"
• взаимосвязи между ресурсами Patient и Person

[eugenekogan-spb]

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

[Vrodvi]

Вопрос к обсуждению:
Использование ресурса Person, Patient, EpisodeOfCare для моделирования прикрепления\ведения пациента некой медицинской организацией.

Моё видение такое:

• ведение пациента организацией - это EpisodeOfCare
• если для ведения пациента организацией нужен фиксированный слепок персональных данных о пациенте, то дополнительно к нему создаётся отдельный ресурс Patient
  • в том числе, если одна организация ведёт одного пациента по нескольким причинам, то это несколько ресурсов EpisodeOfCare и несколько соответствующих им ресурсов Patient
• если стоит задача объединения записей о пациенте в рамках одной организации, то создаётся дополнительный ресурс Patient с последними актуальными данными по пациенту
• если стоит задача объединения записей о пациенте в рамках нескольких организаций, то создаётся дополнительный ресурс Person со ссылками на все известные записи о пациентах (Master-Patient-Index)

---

• Person_1 (Master-Patient-Index)
  • Patient_1 (организация 1, пациент на амбулаторном наблюдении)
    • Patient_2 (организация 1, пациент на амбулаторном наблюдении, слепок для амбулаторной карты 2022 года)
      • Patient_3 (организация 1, пациент на амбулаторном наблюдении, слепок для амбулаторного обращения 1)
      • Patient_4 (организация 1, пациент на амбулаторном наблюдении, слепок для амбулаторного обращения 2)
    • Patient_5 (организация 1, пациент на амбулаторном наблюдении, слепок для амбулаторной карты 2023 года)
      • Patient_6 (организация 1, пациент на амбулаторном наблюдении, слепок для амбулаторного обращения 3)
      • Patient_7 (организация 1, пациент на амбулаторном наблюдении, слепок для амбулаторного обращения 4)
  • Patient_8 (организация 2, пациент на диспансерном наблюдении)
  • Patient_9 (организация 3, пациент на диспансерном наблюдении)

---

• EpisodeOfCare_1 (организация 1, амбулаторное наблюдение) <- связан с Patient_1
  • EpisodeOfCare_2 (организация 1, амбулаторное наблюдение в 2022 году) <- связан с Patient_2
    • EpisodeOfCare_3 (организация 1, амбулаторное наблюдение в 2022 году, обращение 1) <- связан с Patient_3
      • Encouter_1 (организация 1, амбулаторное наблюдение в 2022 году, обращение 1, посещение 1) <- связан с Patient_3

[eugenekogan-spb]

Предложенная структура представляется крайне сложной, а решаемая задача - не нашей.

Полагаю, эти рассуждения являются следствием естественного противоречия между ведением данных и ведением документов. С одной стороны, данные (например, Patient) меняются сами по себе (например изменилась фамилия), а также вследствие исправления ошибок. С другой стороны, эти данные попадают в документы, которые после опубликования не меняются, и в документах остается старое значение.
Медицинские информационные системы решают эти проблемы по-разному, например, путем хранения истории изменения любых данных, или только ключевых данных. Например, дают возможность в картотеке найти пациента по фамилии, даже если поменял.
На мой взгляд, задачу "слепков" не следует включать в моделирование RuCore.

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

[Vrodvi]

14.04.2023 Обсуждение после-госпитального этапа и общего подхода к ведению "обобщенного случая".

Базовое представление о том, что госпитализация завершается выздоровлением (или смертью), - слишком упрощённое.
После госпитализации в большинстве случаев требуется долечивание в поликлинике или этап реабилитации.

Какой именно объём помощи\мед.услуг должен быть оказан пациенту после выписки - не регламентирован законодательно и остаётся на усмотрение участкового врача в поликлинике, несмотря на наличие рекомендаций в выписном эпикризе.

Госпитализация не всегда представлена одним случаем, зачастую требуется переводы в другие стационары для получения специализированной помощи (или перенаправления в связи с неправильно определённым профилем).

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

После завершения госпитализации могут следовать:

• этап долечивания в поликлинике с разной длительностью
• этап реабилитации (санаторий, поликлиника, на дому)
• постановка на диспансерное наблюдение
• направление на получение специализированной мед.помощи в другой стационар

Нужна проработка взаимосвязи между обобщённым случаем и фактической фиксацией случаев в виде мед.документации (в том числе связь с больничным листом, а также роль формы 57).

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

• догоспитальное обследование в ЦАОП -> онкологический консилиум в одном из специально выделенных центров -> оказание мед.помощи в одном или нескольких специализированных мед.учреждениях

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

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

Для определения "Обобщённого случая" могут быть рассмотрены различные подходы:

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

Желательно привлечь к анализу специалистов в предметной области ОНМК, предложены специалисты ФГБУ «НМИЦ им. В. А. Алмазова» Минздрава России.

Предварительная схема обсуждения со встречи клинической рабочей группы FHIR Ru:

Видеозапись встречи будет размещено тут - https://www.youtube.com/watch?v=2oIr5Y9BGbw&t=2590s.

[eugenekogan-spb]

Вопросы к обсуждению:
консультации врачей во время пребывания пациента в стационаре - тоже "случаи"?

Возможно, это зависит от задачи, которая ставится перед моделированием.

• Если смотреть "издалека", то мы необходимая нам информация содержит факт консультации, дату-время, место, исполнителя, и документ с результатами консультации.  Возможно, подойдет ресурс Procedure.
• Если смотреть "в реальном времени", например для МИС, то есть нечто, во время которого был заполнен QuestionnaireResponce, зафиксированы Observation, выставлены диагнозы, выполнены процедуры. Эта сущность хорошо ложится на Encounter.