0.9.0 - ci-build

RuCoreIG, published by HL7 FHIR Россия. This guide is not an authorized publication; it is the continuous build for version 0.9.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/fhir-ru/RuCoreIG/ and changes regularly. See the Directory of published versions

Gost Appendix B

Приложение Б. Пример применения стандарта при описании информационного взаимодействия для направления пациента на ВМП

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

Пример носит справочный характер и показывает ход аналитического решения: от прикладного требования к выбору ресурсов FHIR, определению профилей и описанию отличий от базовых ресурсов и профилей RuCore.

Б.1 Исходное прикладное требование

В рассматриваемом примере информационная система управления потоками пациентов должна обмениваться с медицинскими информационными системами сведениями о заявке на оказание ВМП. При передаче заявки должны передаваться:

  • сведения о пациенте, включая идентификаторы, ФИО, пол, дату рождения, контактные данные, адрес, сведения о прикреплении к медицинской организации, социальную группу, льготную категорию и при необходимости сведения об инвалидности или смерти пациента;
  • сведения о заявке на оказание ВМП, включая номер заявки, статус, этап обработки, дату создания, направляющую сторону, принимающую организацию, признак необходимости оформления талона N 2, вид ВМП, профиль ВМП, модель пациента, метод лечения и группу ВМП;
  • сведения о заболевании, являющемся причиной направления пациента на ВМП;
  • сведения об источнике финансирования и программе финансирования ВМП;
  • сведения о документах, на основании которых создана или изменяется заявка, включая направление, протоколы врачебной комиссии, талон N 2 и выписной эпикриз;
  • сведения о событиях рассмотрения заявки, врачебных комиссиях, планируемой и фактической госпитализации.

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

Б.2 Выбор ресурсов

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

Информационный объект предметной области Выбранный ресурс Обоснование
Пациент, по которому создается заявка Patient Ресурс предназначен для идентификации пациента и хранения демографических сведений. Для российских сценариев используется профиль Core_Patient.
Заявка на оказание ВМП ServiceRequest Заявка является запросом на оказание медицинской помощи и соответствует назначению или направлению. Для российских сценариев используется профиль Core_ServiceRequest.
Заболевание, являющееся причиной направления Condition Диагноз и состояние пациента не включаются непосредственно в заявку, а представляются отдельным клиническим ресурсом.
Источник финансирования Coverage Сведения о финансировании выделяются в отдельный ресурс и связываются с заявкой через ServiceRequest.insurance.
Направление, протокол ВК, талон N 2, выписной эпикриз DocumentReference Документы передаются как отдельные информационные объекты, связанные с заявкой и, при необходимости, с событием оказания помощи.
Врачебная комиссия, плановая или фактическая госпитализация Encounter Событие рассмотрения или оказания помощи описывается как отдельное взаимодействие пациента с медицинской организацией.

В примере используются условные имена прикладных профилей: VMP_Patient, VMP_ServiceRequest, VMP_Condition, VMP_Coverage, VMP_DocumentReference, VMP_Encounter. Профили VMP_Patient, VMP_ServiceRequest, VMP_Coverage и VMP_Encounter уточняют соответствующие профили RuCore. Для ресурсов, для которых в настоящем стандарте базовый профиль RuCore не установлен, прикладный профиль строится от базового ресурса FHIR R5 с применением общих правил профилирования.

Б.3 Решения по уточнению модели

При уточнении ресурсов применяются следующие механизмы:

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

Решения по разбиению информации принимаются с учетом повторного использования ресурсов. Например, сведения о пациенте не дублируются в заявке, а передаются через ссылку ServiceRequest.subject. Сведения о диагнозе передаются через Condition, сведения о финансировании через Coverage, сведения о документах через DocumentReference, а события врачебной комиссии и госпитализации через Encounter.

Б.4 Профиль пациента VMP_Patient

Профиль VMP_Patient уточняет профиль Core_Patient. Основные идентификаторы, ФИО, пол, дата рождения, адрес и полис ОМС уже представлены в Core_Patient; поэтому прикладное уточнение пациента ограничивается небольшим набором дополнительных требований.

Элемент Механизм уточнения Требование
identifier:localId Добавлен срез Идентификатор пациента в МИС-источнике должен передаваться отдельным срезом Identifier.
identifier:localId.system Установлен шаблон Значение формируется по правилу идентификации экземпляра МИС медицинской организации.
identifier:localId.value Ограничена кратность Значение локального идентификатора пациента обязательно.
managingOrganization Ограничен тип Ссылка должна указывать на организацию прикрепления пациента, представленную национальным или прикладным профилем организации.
extension:socialGroup Добавлено расширение Социальная группа пациента кодируется по справочнику НСИ МЗ РФ.
extension:privilege Добавлено расширение Льготная категория пациента кодируется по справочнику НСИ МЗ РФ; допускается несколько значений.
extension:disability Добавлено расширение Признак или тип инвалидности кодируется по справочнику НСИ МЗ РФ.
deceasedBoolean, deceasedDateTime Уточнено заполнение При наличии сведений о смерти пациента заполняется один из элементов в зависимости от доступности точной даты смерти.
extension:deathAttester Добавлено расширение При необходимости указывается медицинский работник или роль, подтвердившие сведения о смерти.
extension:supportingDocument Добавлено расширение При необходимости указываются документы, подтверждающие сведения о смерти пациента.

Правило профиля: в экземпляре пациента должен быть указан identifier:localId и не менее одного идентификатора, пригодного для межсистемной идентификации пациента: СНИЛС, документ, удостоверяющий личность, или полис ОМС.

Б.5 Профиль заявки VMP_ServiceRequest

Профиль VMP_ServiceRequest уточняет профиль Core_ServiceRequest и является основным профилем примера. В нем сосредоточена большая часть прикладной специфики процесса ВМП.

Элемент Механизм уточнения Требование
subject Ограничен тип Ссылка должна указывать на пациента, соответствующего профилю VMP_Patient.
status Добавлена привязка Используются значения, соответствующие состоянию заявки: активна, приостановлена, отозвана, завершена.
extension:stage Добавлено расширение Этап обработки заявки кодируется по справочнику этапов процесса ВМП.
intent Установлен шаблон Значение фиксируется как order.
identifier:localId Добавлен срез Уникальный идентификатор заявки в системе управления потоками пациентов.
identifier:localNumber Добавлен срез Номер заявки в системе управления потоками пациентов.
identifier:misNumber Добавлен срез Идентификатор документа направления в передающей МИС, если заявка создана на основании электронного медицинского документа.
authoredOn Ограничена кратность Дата создания заявки обязательна.
requester Ограничен тип Ссылка должна указывать на роль медицинского работника, сформировавшего направление.
performer Ограничен тип Ссылка должна указывать на организацию, в которой предполагается оказание ВМП.
reason:condition Добавлен срез Причина направления указывается ссылкой на VMP_Condition.
reason:document Добавлен срез Документ, на основании которого создана заявка, указывается ссылкой на VMP_DocumentReference.
extension:talon2required Добавлено расширение Указывается, требуется ли оформление талона N 2.
extension:partialCode Добавлено расширение Используется, когда вид ВМП определен неполностью и описан через профиль, модель пациента, метод лечения и группу ВМП.
extension:partialCode.profile Добавлена привязка Профиль ВМП кодируется по справочнику НСИ МЗ РФ.
extension:partialCode.model Добавлена привязка Модель пациента кодируется по справочнику НСИ МЗ РФ.
extension:partialCode.method Добавлена привязка Метод лечения кодируется по справочнику НСИ МЗ РФ.
extension:partialCode.group Уточнено заполнение Группа ВМП передается как прикладная характеристика требуемой помощи.
code:vmp Добавлен срез Вид ВМП передается как срез элемента code с кодированием по справочнику видов ВМП.
insurance Ограничен тип Источник финансирования указывается ссылкой на VMP_Coverage; допускается несколько записей при изменении программы финансирования.
note Уточнено заполнение В элементе допускается фиксировать историю значимых действий с заявкой: получение документов, направление уведомлений, изменение этапа.
supportingInfo:relatedRequest Добавлен срез Связанные заявки, созданные в результате оказания ВМП, передаются ссылками на другие экземпляры ServiceRequest.
supportingInfo:supportingDocument Добавлен срез Медицинские документы, приложенные к заявке, передаются ссылками на VMP_DocumentReference.

Правило профиля: если вид ВМП определен полностью, должен быть заполнен code:vmp; если вид ВМП определен только частично, должен быть заполнен extension:partialCode. Одновременное отсутствие обоих элементов не допускается.

Б.6 Профиль заболевания VMP_Condition

Профиль VMP_Condition описывает заболевание, являющееся причиной направления пациента на ВМП.

Элемент Механизм уточнения Требование
subject Ограничен тип Ссылка должна указывать на пациента VMP_Patient.
code Ограничена кратность Диагноз, являющийся причиной направления, обязателен.
code.coding Добавлена привязка Диагноз кодируется по Международной классификации болезней, используемой в НСИ МЗ РФ.
code.text Ограничена кратность Текстовая формулировка диагноза обязательна.
clinicalStatus Установлен шаблон Для активного заболевания используется значение active из системы condition-clinical.

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

Б.7 Профиль источника финансирования VMP_Coverage

Профиль VMP_Coverage уточняет профиль Core_Coverage и описывает источник финансирования ВМП.

Элемент Механизм уточнения Требование
kind Установлен шаблон Для прикладного источника финансирования используется значение other.
status Установлен шаблон Для действующего источника финансирования используется значение active.
beneficiary Ограничен тип Ссылка должна указывать на пациента VMP_Patient.
class:paymentType Добавлен срез Вид финансирования ВМП передается отдельным срезом Coverage.class.
class:paymentType.type Установлен шаблон Тип класса указывает, что значение описывает вид финансирования.
class:paymentType.value Добавлена привязка Код вида финансирования выбирается из справочника НСИ МЗ РФ.
class:paymentProgram Добавлен срез Программа финансирования ВМП передается отдельным срезом Coverage.class.
class:paymentProgram.type Установлен шаблон Тип класса указывает, что значение описывает программу финансирования.
class:paymentProgram.value Добавлена привязка Код программы финансирования выбирается из прикладного или ведомственного справочника.
period.start Уточнено заполнение При изменении программы финансирования указывается дата начала действия новой программы.

Б.8 Профиль документа VMP_DocumentReference

Профиль VMP_DocumentReference описывает документы, связанные с заявкой: направление, протокол врачебной комиссии, талон N 2, выписной эпикриз и иные медицинские документы.

Элемент Механизм уточнения Требование
status Добавлена привязка При получении актуального документа используется current; при замещении предыдущей версии используется superseded.
identifier:misNumber Добавлен срез Идентификатор документа в передающей МИС указывается, если документ получен из МИС.
identifier:remd Добавлен срез Идентификатор документа в РЭМД обязателен, если документ получен из РЭМД.
version Уточнено заполнение При наличии версии документа она передается в DocumentReference.version.
basedOn:serviceRequest Добавлен срез Документ связывается с заявкой VMP_ServiceRequest.
basedOn:encounter Добавлен срез Протокол ВК или выписной эпикриз может быть связан с соответствующим VMP_Encounter.
type Ограничена кратность Тип документа обязателен.
type.coding Добавлена привязка Тип документа кодируется по справочнику видов медицинской документации.
author Ограничен тип Автором документа указывается организация, сформировавшая документ.
content.attachment Ограничена кратность Для передаваемого документа обязательно описание вложения или ссылки на него в соответствии с выбранным способом обмена.

Б.9 Профиль события оказания помощи VMP_Encounter

В примере профиль VMP_Encounter используется для двух близких видов событий: врачебной комиссии и плановой или фактической госпитализации. При необходимости они могут быть оформлены как два отдельных профиля VMP_Encounter_VK и VMP_Encounter_Hospitalization.

Элемент Механизм уточнения Требование
status Добавлена привязка Для врачебной комиссии используется завершенное состояние; для госпитализации используются состояния планирования, выполнения, завершения или отмены.
basedOn Ограничен тип Ссылка должна указывать на заявку VMP_ServiceRequest.
serviceProvider Ограничен тип Указывается организация, проводящая врачебную комиссию или оказывающая ВМП.
diagnosis.condition Ограничен тип Диагноз указывается ссылкой на VMP_Condition.
actualPeriod Уточнено заполнение Для врачебной комиссии указывается дата проведения; для госпитализации фактический период лечения.
extension:decision Добавлено расширение Для врачебной комиссии передаются сведения о решении.
extension:decision.type Добавлена привязка Тип решения кодируется справочником решений ВК: положительное, отрицательное, требуются уточнения.
extension:decision.refuseReason Добавлена привязка Причина отказа указывается при отрицательном решении ВК.
extension:decision.text Уточнено заполнение Допускается текст решения или указания о необходимых уточнениях заявки.
extension:plannedPeriod Добавлено расширение Для планируемой госпитализации передается преслот или планируемый период начала.
plannedStartDate Уточнено заполнение Указывается планируемая дата госпитализации, если она определена.
extension:startAttester Добавлено расширение Указывается медицинский работник или роль, подтвердившие начало госпитализации.
extension:endAttester Добавлено расширение Указывается медицинский работник или роль, подтвердившие завершение госпитализации.
extension:dischargeDocument Добавлено расширение Выписной эпикриз связывается с госпитализацией через VMP_DocumentReference.

Б.10 Пример изменения ресурсов при наступлении события

При получении электронного медицинского документа "Направление на госпитализацию для оказания ВМП" прикладная система выполняет следующие действия:

  1. Создает или обновляет экземпляр VMP_Patient.
  2. Создает экземпляр VMP_Condition с диагнозом, являющимся причиной направления.
  3. Создает экземпляр VMP_ServiceRequest с указанием пациента, диагноза, вида ВМП или частичного описания вида ВМП, направляющей организации и даты создания заявки.
  4. Создает экземпляр VMP_DocumentReference для полученного документа направления.
  5. Связывает документ с заявкой через VMP_ServiceRequest.reason:document или VMP_DocumentReference.basedOn:serviceRequest.
  6. Устанавливает начальный этап обработки заявки в VMP_ServiceRequest.extension:stage.

При получении протокола врачебной комиссии создается или обновляется VMP_Encounter, связанный с заявкой. В зависимости от решения ВК изменяются VMP_ServiceRequest.status и VMP_ServiceRequest.extension:stage, а документ протокола ВК регистрируется как VMP_DocumentReference.

При получении сведений о начале или завершении госпитализации обновляется VMP_Encounter, описывающий госпитализацию. При завершении оказания помощи заявка переводится в состояние завершенной, а выписной эпикриз регистрируется как VMP_DocumentReference.

Б.11 Выводы по примеру

Рассмотренный пример показывает различную степень прикладного уточнения ресурсов.

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

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

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