Операция $merge (слияния) предназначена для объединения двух ресурсов Patient в один. Один из пациентов идентифицируется как источник (Source), а другой — как цель (Target). Данные из ресурса-источника интегрируются в ресурс-цель.

Цели слияния записей:

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

Операция применяется только к ресурсам Patient существующим в ЦИСЗ. невозможно использовать операцию к ресурсу Patient профиля Персональные дынные. Операция выполняется асинхронно. Получение статуса операции возможно по url предоставленной в ответе на запрос выполнения операции.

Если клиенту необходимо, чтобы сервер создал нового пациента, объединенного из двух ресурсов пациентов, клиент должен сначала создать новую запись пациента-цели (Target), а затем вызвать операцию слияния для объединения каждого ресурса пациента-источника в новый созданный ресурс пациента.

Пациент источник (Source) всегда деактивируется в результате операции - Patient.active = false

Идентификаторы Source и Target разрешается передавать только как GUID из регистра пациентов - “pa-1234567….”

Операция не является идемпотентной. Пациент источник деактивируется во время выполнения операции и при успешном ее завершение остается неактивным.

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

Изменение ресурсов, связанных с пациентом источником во время выполнения операции заблокировано. Получаемые в это время ресурсы пациента-источника, могут иметь устаревшую ссылку на пациента.

В ресурсах источнике и цели после выполнения операции появляется значение в элементе Patient.link. Если слияние с ресурсом целью происходит несколько раз, в Patient.link будет храниться массив с информацией о том, из каких ресурсов происходило слияние.

МИС должны правильно обрабатывать значение в элементе Patient.link и значение active=false предоставляя пользователю информацию об активности ресурса пациента и информацию о замене данных пациента в ЦИСЗ.

Перечень объединяющихся ресурсов, связанных с пациентом источником, может регулироваться в ЦИСЗ с уведомлением МИС по регламентированным каналам связи.

Важно: в электронных документах, хранящихся в ЦИСЗ, не изменяются ссылки на пациент-цель. Они остаются доступными для получения при выполнении операции $everything для пациента-цели, но будут иметь вид, в котором они были отправлены в ЦИСЗ изначально.

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

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

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

• Список назначенных рецептурных препаратов - информация будет содержать только данные пациента-цели

У Source:

Добавляется новый элемент Patient.link:

• type: “replaced-by”
• other: { “reference”: “Patient/«target-id»” } Все старые Patient.link (если были) сохраняются.

У Target:

Добавляется новый элемент Patient.link:

• type: “replaces”
• other: { “reference”: “Patient/«source-id»” }

Сценарии использования:

Слияние двух существующих записей разных профилей

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

• Предусловие: В системе созданы две записи пациента (Пациент и Пациент без ИН), которые, относятся к одному физическому лицу. Всегда считаем мастер записью (Target) ресурс Patient профиля Пациент.
• Действие: Пользователь с соответствующими правами инициирует операцию $merge, явно указывая Source и Target.
• Результат: Система объединяет данные, обновляет ссылки, деактивирует Source и перенаправляет все связанные ресурсы на Target.
• Постусловие: Target становится единственной активной записью для пациента. Source становиться деактивированной, доступ к этой записи возможно получить через элемент link.other содержащийся в мастер записи.

Слияние с созданием новой мастер-записи

Пациент не существует в системе, для него была создана запись Пациент без ИН, но в какой-то момент он был явно идентифицирован и требуется изменить его профиль на Пациент вместо Пациент без ИН

• Предусловие: В системе создана одна запись пациента (Пациент без ИН), НО есть необходимость создать ресурс Patient профиля Пациент.
• Действие: Пользователь создает новый, “чистый” ресурс Patient профиля Пациент с внесением нужного идентификатора, который будет служить мастер-записью. Затем он выполняет $merge, указывая старые записи как Source, а новую — как Target.
• Результт: Создается новая мастер-запись, которая содержит объединенную информацию.
• Постусловие: Target становится единственной активной записью для пациента. Source становиться деактивированной, доступ к этой записи возможно получить через элемент link.other содержащийся в мастер записи.

Дополнительный сценарий для одинаковых профилей

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

То же что и Основной сценарий с поправкой на профили

Слияние записи Анонимного обращения

Слияние двух существующих записей разных профилей (Пациент уже существует в системе, идентифицирован, имеет валидный ресурс профиля Пациент, но в момент оказания помощи, по каким-либо причинам для него создавалась запись Анонимное обращение). Сценарий является исключительным, объединение таких записей должно быть ограничено в ролевой модели на высоком уровне и необходим механизм регламентированного сопоставление таких записей. Потребность в раскрытии информации об анонимном обращении и связь с идентифицированным Пациентом может возникнуть в случаях, регламентированных в Законе о здравоохранении и других НПА МЗ РБ.

• Предусловие: В системе созданы две записи пациента (Пациент или Пациент без ИН, и запись Анонимное обращение), которые, относятся к одному физическому лицу. Всегда считаем мастер записью (Target) ресурс Patient профиля Пациент или Пациент без ИН.
• Действие: Пользователь с соответствующими правами инициирует операцию $merge, явно указывая Source и Target.
• Результат: Система объединяет данные, обновляет ссылки, деактивирует Source и перенаправляет все связанные ресурсы на Target.
• Постусловие: Target становится единственной активной записью для пациента. Source становиться деактивированной, доступ к этой записи возможно получить через элемент link.other содержащийся в мастер записи.

Предварительный просмотр (Preview)

• Действие: Пользователь выполняет операцию с параметром preview=true.
• Результат: Система возвращает Bundle содержащий ресурс Patient как результат слияния, и данные о том сколько ресурсов будут затронуты слиянием, но сами изменения не применяются.

Правила выбора Target и Source

Определения ролей

• Source (Источник): запись пациента, которая будет поглощена и деактивирована.
• Target (Цель): “Основная” или мастер-запись пациента, которая станет единственной активной записью после слияния

Правила выбора

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

Связанные ресурсы

По-умолчанию операция применяется ко всем ресурсам пациента.

Роли и права

Ограничение операции зависит от роли медработника

Особенности

• Деактивация Source (active = false) и установка link происходит всегда при успешном слиянии.
• Идентификаторы Source и Target разрешается передавать только как GUID регистра пациентов - “pa-1234567….”.

Вызов операции

Конечная точка: [FHIR_BASE]/Patient/$merge HTTP-метод: POST Формат тела запроса: Ресурс Parameters (JSON)

Пример тела запроса:

{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "source", "valueReference": { "reference": "pa-1234567...." } },
    { "name": "target", "valueReference": { "reference": "pa-6543210...." } },
    { "name": "preview", "valueBoolean": false }
  ]
}

Пример ответа при успешном принятии на выполнение:

Код состояния: 202 Accepted

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "ProcessingStatus",
      "valueString": "Pending"
    },
    {
      "name": "OperationStatusReference",
      "valueReference": {
        "reference": "http://staging.cisz.by/fhir/Patient/5d884255-1cf8-11ef-8fe6-232a0e90dedd/$merge/status"
      }
    },
    {
      "name": "ResourceId",
      "valueString": "5d884255-1cf8-11ef-8fe6-232a0e90dedd"
    }
  ]
}

Пример OperationOutcome при успешном слиянии:

Код состояния: 200 OK

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "information",
      "code": "informational",
      "diagnostics": "pa-1234567... успешно деактивирован."
    },
    {
      "severity": "information",
      "code": "informational",
      "diagnostics": "Обновлено 23 ресурса Observation, 4 Encounter."
    }
  ]
}

Пример OperationOutcome при ошибке валидации запроса

Код состояния: 400 Bad Request

{
  "resourceType": "OperationOutcome",
  "id": "8bc2465e-560f-4069-a51e-e76a32a21d3c",
  "meta": {
    "lastUpdated": "2026-05-29T09:17:36.9823861+00:00"
  },
  "issue": [
    {
      "severity": "error",
      "code": "invalid",
      "details": {
        "coding": [
          {
            "system": "http://hl7.org/fhir/dotnet-api-operation-outcome",
            "code": "1012"
          }
        ],
        "text": "id для параметра 'source' задан в неверном формате"
      }
    }
  ]
}

URL: [base]/$merge

Параметры

Ошибки валидации запроса

400 Bad Request

OperationOutcome с code=invalid

• Отсутствуют обязательные параметры.
• Некорректный формат параметров (например, preview – не boolean).
• Переданы неизвестные параметры.
• OperationOutcome с severity=error, code=invalid.

Ресурсы не найдены

404 Not Found

OperationOutcome с diagnostics «Пациент pa-1234567… не найден».

• source или target не существуют на сервере.

Конфликты состояния ресурсов

409 Conflict

OperationOutcome с code=conflict.

• Source уже деактивирован (active = false или присутствует link.type=replaced-by).
• Target ранее был слит с другой записью и не может быть целью (по бизнес-правилам).

Бизнес-правила нарушены

422 Unprocessable Entity

OperationOutcome с code=business-rule.

• Source и Target – один и тот же ресурс.
• Недопустимая комбинация профилей (например, попытка сделать Target’ом Анонимное обращение).

403 Forbidden 

OperationOutcome с code=forbidden

• Недостаточно прав для слияния анонимной записи.
• Недостаточно прав для выполнения слияния пациентов.

Превышение лимитов частоты запросов

429 Too Many Requests

• Сервер ограничивает количество операций слияния в единицу времени.