VK
Youtube
Telegram
+7(812) 670-45-63

Сервис "Региональная ИЭМК"

Настоящее описание интеграционных профилей определяет механизмы информационного взаимодействия медицинских информационных систем и сервиса «Региональная ИЭМК», входящей в состав Интеграционной платформы N3.Здравоохранение

Общие сведения

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

Обмен данными между ЭМК МИС и сервисом «Региональная ИЭМК осуществляется в рамках следующих процессов:
  1. Передача информации о пациенте из ЭМК МИС в Модуль работы с пациентом (добавление пациента и/или изменение информации о нем).
  2. Передача данных об оказании медицинской помощи из ЭМК МИС в Модуль сбора статистики.
Функциональность Модуля работы с пациентами обеспечивается следующими методами:
  1. Добавление пациента (AddPatient).
  2. Обновление информации о пациенте (UpdatePatient).
  3. Получение данных о зарегистрированном пациенте (GetPatient).
Функциональность Модуля сбора статистики обеспечивается следующими методами:
  1. Добавление завершенного случая медицинского обслуживания (AddCase)
  2. Регистрация случая медицинского обслуживания (CreateCase).
  3. Добавление эпизода к незавершенному случаю медицинского обслуживания (AddStepToCase).
  4. Закрытие случая медицинского обслуживания (CloseCase).
  5. Добавление медицинских записей (AddMedRecord).
  6. Изменение закрытого случая медицинского обслуживания (UpdateCase).

Минимальный и рекомендуемый набор методов для реализации

Минимальный набор методов МИС определяет самостоятельно исходя из бизнес-процессов МО. Со стороны ЭлНетМед требования к набору методов, которые необходимо поддержать МИС следующие:
  • В рамках сервиса "ИЭМК. Модуль работы с пациентами" необходимы следующие обязательные методы:
  • Добавление пациента (AddPatient)
  • Обновление информации о пациенте (UpdatePatient)
  • Рекомендуемые к добавлению:
  • Получение данных о зарегистрированном пациенте (GetPatient)
  • В рамках сервиса "ИЭМК. Модуль сбора статистики" обеспечивается следующими обязательными методами:
  • Добавление завершенного случая медицинского обслуживания (AddCase)
  • Изменение закрытого случая медицинского обслуживания (UpdateCase)
  • Добавление медицинских записей (AddMedRecord)
  • Рекомендуемые к добавлению:
  • Добавление эпизода к незавершенному случаю медицинского обслуживания (AddStepToCase)
  • Регистрация случая медицинского обслуживания (CreateCase)
  • Закрытие случая медицинского обслуживания (CloseCase)

Для взаимодействия с сервисом «Региональная ИЭМК используется протокол SOAP 1.1 и 1.2.
При информационном взаимодействии используются следующие обязательные параметры:
  1. GUID – авторизационный токен. Выдается разработчику МИС администратором Интеграционной платформы;
  2. IdLPU – идентификатор МО, от имени которой передается\запрашивается информация в\из сервиса «Региональная ИЭМК». Используется значение поля code регионального справочника МО (urn:1.2.643.2.69.1.1.1.64).
Используемые при взаимодействии с сервисом «Региональная ИЭМК» справочники приведены в описании работы «Сервис Терминологии».
Для каждого используемого справочника в Настоящем документе указан его OID. Перечень присвоенных корней OID :
  • 1.2.643.5.1.13.2.1 – Корневой OID справочников, размещённых в реестре НСИ (http://nsi.rosminzdrav.ru/);
  • 1.2.643.5.1.13.2.7.1 – Корневой OID для "внутренних" справочников федерального сервиса ИЭМК;
  • 1.2.643.2.69.1.1.1 – Корневой OID для справочников подсистемы НСИ Регионального фрагмента.
В Модуле работы с пациентами ведется учет следующих объектов:
  1. Пациент. Содержит демографическую и идентифицирующую информацию о пациенте.
В Модуле сбора статистики ведется учет следующих объектов:
  1. Случай обслуживания. Совокупность обращений к врачу, либо взаимодействий с медицинским ресурсом (диагностическое оборудование, койка стационарного учреждения и пр.), выполненных при каждом обращении пациента с конкретной целью (примером может служить оказание медицинской помощи в рамках конкретного стационарного обращения);
  2. Обращение (эпизод случая обслуживания). Взаимодействие пациента с врачом, либо медицинским ресурсом. В рамках случая обслуживания может быть одно и более обращений.Примером амбулаторного обращения может служить очередное посещение врача поликлинического учреждения пациентом в рамках конкретного заболевания.
  3. Примером стационарного обращения можно выделить случай оказания медицинской помощи в стационарном отделении с учетом профиля койки. Смена профиля койки, занимаемой пациентом будет являться фактом появления нового обращения;
  4. Медицинская запись. Содержит информацию об оказанных услугах, назначенных препаратах и т.д.;
  5. Элемент медицинской записи. Детализирует информацию медицинской записи.
ИЭМК формируется на основании построенных и сохранённых в Системе логических связей между объектом-пациентом и описанными выше объектами сбора статистики.
Информация о перечисленных объектах передается из МО в сервис «Региональная ИЭМК» с помощью методов, приведенных в разделах "Модуль работы с пациентами" и "Модуль сбора статистики".

Формат даты
Значения параметров методов, имеющих тип Datetime, необходимо передавать в формате UTC или с указанием таймзоны. Если таймзона не указана, то в рамках сервиса считается, что передано локальное время (региональное), и сервис работает с переданным значением как с "датой, для которой не указана таймзона".
Пример времени по Москве: 2021-01-18T12:20:12.2508719+03:00

Описание типов объектов

Тип AllergyBase
Комплексный тип AllergyBase используется как базовый тип для передачи данных о патологических реакциях (аллергиях) и индивидуальной лекарственной непереносимости. Объекты типа AllergyBase отдельно не передаются, а расширяются дочерними типами AllergyDrug и AllergyNonDrug. Описание параметров объекта AllergyBase представлено в таблице.
Тип Activity
Комплексный тип Activity предназначен для передачи данных о произведенных медицинских воздействиях. Описание параметров типа Activity представлено в таблице.
Тип AssisNote
Комплексный тип AssisNote предназначен для передачи данных о произведенных медицинских воздействиях. Описание параметров типа AssisNote представлено в таблице.
Тип BirthCertificate
Комплексный тип BirthCertificate используется для передачи данных Медицинского свидетельства о рождении. Документы данного типа могут передаваться только в рамках стационарного случая обслуживания.
Параметры типа BirthCertificate полностью соответствуют параметрам родительского типа MedDocument .
Важно:
Свидетельство о рождении выдается на каждого ребенка отдельно. Поэтому, если роды были многоплодными, необходимо каждое свидетельство о рождении передавать в рамках отдельного объекта BirthCertificate.
Тип СaseBase
Комплексный тип СaseBase является базовым типом для передачи информации о случае медицинского обслуживания и наследуется дочерними типами, такими как:
  • Тип СaseAcps – используется для передачи карты вызова скорой помощи;
  • Тип СaseAmb – используется для передачи амбулаторного случая обслуживания;
  • Тип СaseTmc – используется для передачи случая обслуживания, в рамках которого была выполнена телемедицинская консультация;
  • Тип СaseStat – используется для передачи стационарного случая обслуживания.
Объекты CaseAmb и CaseStat используются в вызовах методов Модуля сбора статистики.
В зависимости от типа случая обслуживания для объекта caseDto должно указываться соответствующее значение атрибута xsi:type (используется для указания в явном виде типа наследуемого объекта; подробнее про xsi:type – см. http://www.w3.org/TR/xmlschema-1/#xsi_type).
Комплексный тип СaseBase содержит основные сведения по случаю, такие как информация по эпизодам обслуживания и медицинские записи, созданные в рамках случая. Описание типа CaseBase представлено в таблице.
Тип СaseAcps
Комплексный тип СaseAcps используется для передачи данных карты вызова скорой помощи. Тип наследуется от CaseBase и имеет дополнительные параметры, указанные в таблице.
Тип СaseTmc
Комплексный тип СaseTmc используется для передачи случая обслуживания, в рамках которого была выполнена телемедицинская консультация (передаётся только в РЭМД). Тип наследуется от CaseBase и имеет дополнительные параметры.
Тип СaseAmb
Комплексный тип СaseAmb используется для передачи данных амбулаторного случая обслуживания. Тип наследуется от CaseBase и имеет дополнительные параметры, описанные в таблице.
Тип СaseStat
Комплексный тип СaseStat используется для передачи данных стационарного обслуживания. Тип наследуется от CaseBase и имеет дополнительные атрибуты, описанные в таблице.
Тип DiagnosisInfo
Компдексный тип DiagnosisInfo предназначен для передачи сведений о диагнозе как сведений о состоянии пациента.
Внимание
  • Параметр DiagnosisStage остаётся необязательным при передаче СМО.
  • В случае, если параметр DiagnosisStage передаётся в рамках объекта ClinicMainDiagnosis, то он должен принимать значение "3". Использование других значений из справочника 1.2.643.2.69.1.1.1.10 недопустимо, и будет восприниматься системой, как ошибка.
  • В случае, если параметр DiagnosisStage передаётся в рамках объекта AnatomopathologicalClinicMainDiagnosis, то он должен принимать значение "4". Использование других значений из справочника 1.2.643.2.69.1.1.1.10 недопустимо, и будет восприниматься системой, как ошибка.
Тип DispensaryBase
Комплексный тип DispensaryBase используется для передачи данных диспансеризации. Тип полностью наследуется от комплексного типа MedDocument и содержит дополнительные параметры типа, представлены в таблице.
Тип DispensaryOne
Комплексный тип DispensaryOne используется для передачи данных первого этапа диспансеризации, наследуется от DispensaryBase. Дополнительные параметры типа DispensaryOne представлены в таблице.
Тип DispensaryTwo
Комплексный тип DispensaryTwo используется для передачи данных об итогах выполнения второго этапа диспансеризации. Тип DispensaryTwo передается в рамках типа случая обслуживания «Диспансеризация».
Параметры типа DispensaryTwo наследуются от родительского типа DispensaryBase и не имеет дополнительных элементов.
Тип DispensaryOnceByTwoYears
Комплексный тип DispensaryOnceByTwoYears используется для передачи данных об итогах выполнения профилактического медицинского осмотра раз в два года. Тип DispensaryOnceByTwoYears передается в рамках типа случая обслуживания «Диспансеризация».
Параметры типа DispensaryOnceByTwoYears наследуются от родительского типа DispensaryBase и не имеет дополнительных элементов.
Тип DeathCertificate
Комплексный тип DeathCertificate используется для передачи данных медицинского свидетельства о смерти.
Параметры типа DeathCertificate наследуются от родительского типа MedDocument и дополняются следующим элементом.
Тип Disability
Комплексный тип Disability служит для передачи сведений о наличии инвалидности у пациента. В таблице представлено описание комплексного типа Disability.
Тип DocumentAttachment
Комплексный тип DocumentAttachment используется для передачи неструктурированных вложений документов. В таблице представлено описание комплексного типа DocumentAttachment.
Важно:
  • Текстовые файл должен передаваться в формате UNICODE UTF-16 (aka UCS-2 LE);
  • Набор символов HTML-документа должен соответствовать utf-8 (charset="utf-8"), сам файл должен передаваться в формате UNICODE UTF-16.;
  • Файл документа в электронном виде должен иметь формат PDF/A-1, соответствующий международному стандарту ISO 19005-1:2005. Самостоятельно произвести проверку PDF-файла можно с помощью ресурсов Industry Supported PDF/A Validation или PDF/A online verification service.
Тип Initiator
Комплексный тип Initiator предназначен для передачи сведений об инициаторе телемедицинской консультации.
Тип Guardian
Комплексный тип Guardian служит для передачи сведений о законном представителе пациента. В таблице представлено описание комплексного типа Guardian.
Тип HealthGroup
Комплексный тип HealthGroup используется для передачи сведений о группе здоровья пациента (тип HealthGroupInfo) и информации о враче (тип MedicalStaff).В таблице представлено описание комплексного типа HealthGroup.
Тип HealthGroupInfo
Комплексный тип HealthGroupInfo используется для передачи группы здоровья, передаваемой в рамках объекта DispensaryOne. В таблице представлено описание комплексного типа HealthGroupInfo.
Тип HumanName
Комплексный тип HealthGroupInfo используется для передачи группы здоровья, передаваемой в рамках объекта DispensaryOne. В таблице представлено описание комплексного типа HealthGroupInfo.
Тип HumanName
Комплексный тип HumanName предназначен для передачи имени персоны. В таблице представлено описание комплексного типа HumanName.
Тип IdentityDocument
Комплексный тип IdentityDocument предназначен для передачи сведений о документах персоны. В таблице представлено описание комплексного типа IdentityDocument.
Тип MedicalStaff
Комплексный тип MedicalStaff предназначен для передачи данных о медицинском работнике. В таблице представлено описание комплексного типа MedicalStaff.
Тип MedRecord
Комплексный тип MedRecord является базовым для передачи медицинских записей. С помощью его дочерних типов формируются и передаются следующие данные:
  • AllergyDrug – данные об индивидуальной непереносимости лекарственных средств;
  • AllergyNonDrug – данные о патологических реакциях на не медикамент;
  • AppointedMedication – данные о медикаментозной терапии;
  • DeathInfo – причина смерти;
  • Diagnosis – диагнозы:
  1. ClinicMainDiagnosis – заключительный диагноз;
  2. AnatomopathologicalClinicMainDiagnosis – патологоанатомический диагноз;
  • Immunize – данные о проведенной вакцинации и иммунизации:
  1. Vaccination – данные о проведенной вакцинации;
  2. Reaction – данные о проведенной пробе;
  3. MedicalExemption – данные о медицинском отводе;
  4. ImmunizationPlan - данные о запланированных прививках/пробах;
  • Procedure – данные о выполненных медицинских процедурах;
  • Problem – сведения о подозрении на заболевание;
  • SocialAnamnesis – анамнез;
  • MedDocument – медицинские документы:
  1. AmbulanceInfo – данные карты вызова скорой помощи;
  2. BirthCertificate – данные медицинского свидетельства о рождении;
  3. ConsultNote – консультативное заключение;
  4. DeathCertificate - данные медицинского свидетельства о смерти;
  5. DischargeSummary – эпикриз;
  6. DispensaryOne – данные заключения первого этапа диспансеризации;
  7. DispensaryTwo – данные заключения второго этапа диспансеризации;
  8. DispensaryOnceByTwoYears - данные заключения о диспансеризации, проводящейся раз в два года;
  9. LaboratoryReport – результат лабораторного исследования;
  10. Referral – направление по форме №57;
  11. ReferralMSE – данные направления на медико-социальную экспертизу;
  12. SickList – данные о больничном листе;
  • NonDrugTreatment – данные о немедикаментозном лечение;
  • ResInstr – данные об инструментальных исследованиях;
  • Scores – результаты различных диагностических и прогностических шкал;
  • Service – данные об оказанных услугах;
  • TfomsInfo – данные о выполненных медицинских стандартах в разрезе учета ТФОМС;
Массив медицинских записей (MedRecords) может передаваться на уровне случая обслуживания (caseDto), на уровне эпизода случая обслуживания (StepDto) или на уровне «пациента» (без привязки к случаю обслуживания) в зависимости от типа передаваемой информации.
Тип MedRecord не имеет собственных параметров, а расширяется с помощью дочерних типов, описание которых приведено ниже в соответствующих разделах.

Тип AllergyDrug
Комплексный тип AllergyDrug предназначен для передачи данных об индивидуальной непереносимости лекарственных средств. Описание параметров типа AllergyDrug представлено в таблице.
Тип AllergyNonDrug
Комплексный тип AllergyNonDrug предназначен для передачи данных об индивидуальной непереносимости нелекарственных средств. Описание параметров типа AllergyNonDrug представлено в таблице.
Тип Immunize
Комплексный тип Immunize предназначен для передачи данных о проведенной вакцинации и иммунизации пациента.
Тип Immunize является родительским для передачи следующих данных:
  • Vaccination - о прививках пациента;
  • Reaction - о пробах пациента;
  • MedicalExemption - о медицинских отводах;
  • ImmunizationPlan - о запланированных прививках/пробах
Описание параметров типа Immunize представлено в таблице.
Тип Vaccination
Комплексный тип Vaccination предназначен для передачи данных о прививках пациента. Vaccination наследуется от родительского типа Immunize и имеет дополнительные элементы, указанные в таблице.
Тип Reaction
Комплексный тип Reaction предназначен для передачи данных о пробах пациента. Reaction наследуется от родительского типа Immunize и имеет дополнительные элементы, указанные в таблице.
Тип MedicalExemption
Комплексный тип MedicalExemption предназначен для передачи данных о мед.отводах пациента. MedicalExemption наследуется от родительского типа Immunize и имеет дополнительные элементы, указанные в таблице.
Тип ImmunizationPlan
Комплексный тип ImmunizationPlan предназначен для передачи данных запланированных мероприятиях по иммунизации и проведению проб пациента. ImmunizationPlan наследуется от родительского типа Immunize. Он состоит из двух базовых подтипов:
  • VaccinationType - о запланированных прививках;
  • ReactionType - о запланированных пробах;
Подтип VaccinationType
Подтип ReactionType
Тип NonDrugTreatment
Комплексный тип NonDrugTreatment предназначен для передачи данных о назначенном немедикаментозном лечении. Описание параметров типа NonDrugTreatment представлено в таблице.
Тип ResInstr
Комплексный тип ResInstr предназначен для передачи данных о проведенных инструментальных исследованиях. Описание параметров типа ResInstr представлено в таблице.
Тип Scores
Комплексный тип Scores предназначен для указания результатов различных диагностических и прогностических шкал. Описание параметров типа Scores представлено в таблице.
Тип Service
Комплексный тип Service предназначен для передачи данных о выполненных (оказанных) услугах в рамках эпизода случая обслуживания. Описание параметров типа Service представлено в таблице.
Тип TfomsInfo
Комплексный тип TfomsInfo предназначен для передачи данных о выполненных медицинских стандартах в разрезе учета ТФОМС. Описание параметров типа TfomsInfo представлено в таблице.
Тип AppointedMedication
Комплексный тип AppointedMedication предназначен для передачи данных о назначенных препаратах. Объекты типа AppointedMedication передаются в рамках эпизода случая обслуживания. Описание параметров объекта AppointedMedication представлено в таблице.
Тип DeathInfo
В объекте DeathInfo осуществляется передача данных о летальном исходе (причине смерти) в рамках стационарного случая обслуживания.

Структура объекта DeathInfo представлена на Рисунке 1.
Описание параметров
Описание параметров объекта DeathInfo представлено в таблице.
Тип Diagnosis
Комплексный тип Diagnosis используется для передачи информации о диагнозе и лице, его поставившем. Наследуемыми типами для Diagnosis являются:
  • ClinicMainDiagnosis – заключительный диагноз;
  • AnatomopathologicalClinicMainDiagnosis – патологоанатомический диагноз.

В таблице представлено описание комплексного типа Diagnosis.
Тип ClinicMainDiagnosis
Объект ClinicMainDiagnosis используется для передачи информации об основном диагнозе (при отсутствии летального исхода). Объект ClinicMainDiagnosis является наследуемым от объекта Diagnosis и имеет возможность передавать вложенные объекты типа Diagnosis (например, таким образом можно передать основной диагноз, а также его осложнение и сопутствующее заболевание).

Структура объекта ClinicMainDiagnosis представлена на Рисунке 4.
Описание параметров
Описание параметров объекта ClinicMainDiagnosis представлено в таблице.
Внимание
Не допускается передавать в параметре Complications диагнозы с типом "Основной диагноз" (IdDiagnosisType=1)
Тип AnatomopathologicalClinicMainDiagnosis
Объект AnatomopathologicalClinicMainDiagnosis предназначен для передачи информации о патологоанатомических диагнозах (основном диагнозе, его осложнении и сопутствующем заболевании). Тип AnatomopathologicalClinicMainDiagnosis является полным аналогом типа ClinicMainDiagnosis.
Тип MedDocument
Комплексный тип MedDocument наследуется от типа MedRecord и является базовым для передачи медицинских документов. Описание параметров типа MedDocument приведено в таблице.
Описание наследуемых от MedDocument типов приведено в соответствующих разделах ниже.
Подтип AmbulanceInfo
Комплексный тип AmbulanceInfo используется для передачи данных карты вызова скорой помощи. Тип AmbulanceInfo передается в рамках типа случая обслуживания Скорая помощь.

Параметры типа AmbulanceInfo наследуются от родительского типа MedDocument и дополняются элементами, приведенными в таблице.
Подтип Referral
Комплексный тип Referral предназначен для передачи данных направления на госпитализацию, обследование, консультацию по форме 057-У.

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

Параметры типа SickListInfo наследуются от родительского типа MedDocument и дополняются элементами, приведенными в таблице
Подтип DischargeSummary
Комплексный тип DischargeSummary используется для передачи информации и содержания выписных эпикризов, отражающих сводные медицинские сведения стационарного случая обслуживания.
Параметры типа DischargeSummary полностью соответствуют параметрам родительского типа MedDocument.
Подтип LaboratoryReport
Комплексный тип LaboratoryReport используется для передачи информации и содержания проведенных лабораторных исследований.
Параметры типа LaboratoryReport полностью соответствуют параметрам родительского типа MedDocument.
Подтип ConsultNote
Комплексный тип ConsultNote используется для передачи информации и содержания заключений по результатам консультации или диагностического исследования. Объекты данного типа могут передаваться как в рамках амбулаторного, так и в рамках стационарного случаев обслуживания.

Параметры типа ConsultNote полностью соответствуют параметрам родительского типа MedDocument.
Тип Observation
Комплексный тип Observation предназначен для передачи данных о клинически наблюдаемых показателях жизнедеятельности пациента.
Тип ValueQuantity
Комплексный тип ValueQuantity является базовым для передачи значений клинически наблюдаемых показателей жизнедеятельности пациента, которые могут передаваться следующими типами данных:
  • NumericalValue - числовое значение;
  • CodeableValue - код по справочнику;
  • StringValue - текстовая строка.
Тип NumericalValue
Комплексный тип NumericalValue предназначен для передачи значений целочисленного типа.
Тип CodeableValue
Комплексный тип CodeableValue предназначен для передачи значения показателя, которое регламентировано иным справочником
Тип StringValue
Комплексный тип StringValue предназначен для передачи значении текстового типа.
Тип ReferenceRange
Комплексный тип ReferenceRange предназначен для передачи данных о референтных значениях показателя, отражающих представление о нижней и верхней границах нормы показателя или возможных, статистически достоверных, пределах колебания (отклонения) его величины.
Тип Param
Комплексный тип Param предназначен для передачи различных медицинских показателей.
Тип Participant
Комплексный тип Participant предназначен для передачи данных о враче.
Тип PaymentInfo
Комплексный тип PaymentInfo предназначен для передачи сведений об оплате оказанных медицинских услуг. Описание параметров типа PaymentInfo приведено в таблице.
Тип Person
Комплексный тип Person предназначен для передачи данных о лице - участнике случая обслуживания.
Тип PersonalSign
Комплексеный тип PersonSign предназначен для передачи открепленной электронной подписи врача в формате CMS (Cryptographic Message Syntax) врача. Тип имеет параметры, описанные в таблице.
Важно:
Предполагается использование усиленной квалифицированной электронной подписи (УКЭП), сформированной по формату CMS (Cryptographic Message Syntax). Для формирования указанных УКЭП должны использоваться сертификаты, выданные аккредитованными УЦ. Сертификаты должны соответствовать требованиям ГОСТ Р 34.10−2012 (Согласно выписке из документа ФСБ России N 149/7/1/3−58 от 31.01.2014 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования» использование схемы подписи ГОСТ Р 34.10−2001 для формирования подписи после 31.12.2018 года не допускается).
Тип PersonWithIdentity
Комплексный тип PersonWithIdentity предназначен для передачи данных документов, удостоверяющих личность лица-участника случая обслуживания. Тип наследуется от Person и имеет дополнительные параметры, описанные в таблице.
Тип Procedure
Комплексный тип Procedure предназначен для передачи данных о выполненных медицинских процедурах. Описание параметров типа Procedure представлено в таблице
Тип Problem
Комплексный тип Problem предназначен для передачи сведений о подозрении на заболевание. Описание параметров типа Problem представлено в таблице
Тип SocialAnamnesis
Комплексный тип SocialAnamnesis является базовым для передачи важной анамнестической информации о пациенте. Описание параметров типа SocialAnamnesis представлено в таблице
Тип SocialGroup
Комплексный тип SocialGroup предназначен для передачи данных о занятости пациента.
Тип Quantity
Комплексный тип Quantity предназначен для передачи данных о дозировке лекарственных средств.
Тип Recommendation
Комплексный тип Recommendation предназначен для передачи данных о рекомендациях по лечению пациента.
Тип ReferralInfo
Комплексный тип ReferralInfo предназначен для передачи данных о направлении.
Тип ReferralMSE
Комплексный тип ReferralMSE предназначен для передачи данных направления на медико-социальную экспертизу (МСЭ) для последующей передачи в федеральный сервис РЭМД ЕГИСЗ. Параметры типа ReferralMSE наследуются от родительского типа MedDocument с некоторыми ограничениями, наложенными на объект комплексного типа DocumentAttachment.
  • Data - файл в формате CDA, сформированный согласно руководству по реализации СЭМД: Направление на медико-социальную экспертизу;
  • PersonSign - массив открепленных электронных подписей медицинских работников - участников комиссии;
  • MimeType - константа "text/xml".
Для регистрации в федеральном сервисе РЭМД ЕГИСЗ ЭМД типа "Направление на МСЭ" необходимо передать минимальный набор подписей:
  • Подпись МО - должна содержать ОГРН МО;
  • Подпись председателя ВК (роль CHAIRMAN) - возможно использование подписи без реквизитов организации;
  • 0-10 подписей членов ВК (роль COMMISSIONER) - возможно использование подписи без реквизитов организации;
Допустимые коды должностей для ролей CHAIRMAN и COMMISSIONER указаны в федеральном справочнике Правила подписи электронных медицинских документов
Следует помнить, что для передачи данных в ИЭМК берутся значения из справочника 1.2.643.5.1.13.13.11.1002, а для передачи данных в РЭМД - из 1.2.643.5.1.13.13.11.1102
В ФРМР указывается код должности по справочнику 1.2.643.5.1.13.13.11.1102. Для того, чтобы узнать, какой код должности (IdPosition) должен передаваться в сервис ИЭМК, необходимо, воспользоваться маппингом должностей работников организаций медицинского и фармацевтического профиля translate_post_2"
Тип SickListInfo
Комплексный тип SickListInfo предназначен для передачи информации о выданном листке временной нетрудоспособности (больничного листа). Параметры типа SickListInfo приведены в таблице.
Тип StepBase
Комплексный тип StepBase является базовым для передачи информации об эпизоде случая медицинского обслуживания и наследуется такими дочерними типами как:
  • Тип StepAmb – используемый для передачи эпизода амбулаторного случая обслуживания.
  • Тип StepStat – используемый для передачи эпизода стационарного случая обслуживания.

При передаче информации по эпизоду случая обслуживания вне объекта caseDto (см. метод AddStepToCase) указывается для объекта step соответствующее значение атрибута xsi:type (используется для указания в явном виде типа наследуемого объекта от базового объекта StepBase; подробнее про xsi:type – см. http://www.w3.org/TR/xmlschema-1/#xsi_type): StepAmb для амбулаторного эпизода случая обслуживания и StepStat для стационарного эпизода случая обслуживания соответственно.

Комплексный тип StepBase содержит базовую информацию об эпизодах случая медицинского обслуживания, таких как движения по отделениям, назначенные препараты, сведения об оказанных услугах или сформированных документах.
Описание типа StepBase представлено в таблице.
Тип StepAmb
Комплексный тип StepAmb используется для передачи данных эпизода амбулаторного случая обслуживания. Тип наследуется от StepBase и имеет дополнительные параметры. Параметры типа StepAmb приведены в таблице.
Тип StepStat
Комплексный тип StepStat используется для передачи данных эпизода стационарного случая обслуживания. Тип наследуется от StepBase и имеет дополнительные параметры. Параметры типа StepStat приведены в таблице.

Модуль работы с пациентами

Посредством Модуля работы с пациентами реализованы следующие сценарии информационного взаимодействия:
  • Передача данных о пациенте;
  • Получение данных о пациенте.

Передача данных о пациенте

Для передачи данных о пациенте в сервис ИЭМК используются следующие методы: AddPatient и UpdatePatient.
Для передачи данных о новом пациенте (регистрации нового пациента) используется метод AddPatient. Обновление данных о ранее зарегистрированном пациенте осуществляется посредством метода UpdatePatient.
Порядок вызова методов ИЭМК в рамках сценария «Передача данных о пациенте» представлен на Рисунке 6.

Получение данных о пациенте
Для получения данных по пациенту из сервиса ИЭМК используется метод GetPatient.
Порядок вызова метода ИЭМК в рамках «Передача данных о пациенте» представлен на Рисунке 7.

Модуль сбора статистики

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

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

Вызов метода CreateCase происходит в момент регистрации случая обслуживания в МО; далее следует внесение изменений в данные о случае обслуживания (методами AddStepToCase и AddMedRecord) на этапах движения пациентов по отделениям (для стационарного типа обслуживания) или посещений врача (для амбулаторного типа обслуживания); закрытие случая обслуживания осуществляется методом CloseCase. После закрытия случая возможно полное или частичное изменение в данных о случае обслуживания (методами UpdateCase или AddMedRecord соответственно).

Порядок вызова методов ИЭМК в рамках сценария «Передача данных по случаю обслуживания по факту завершения оказания медицинской помощи» представлен на Рисунке 8.
Передача данных по случаю обслуживания в ходе оказания медицинской помощи
При передаче данных о случае медицинского обслуживания по факту завершения оказания медицинской помощи используются следующие методы: AddCase, UpdateCase и AddMedRecord.
Регистрация законченного случая обслуживания осуществляется с помощью метода AddCase; после регистрации законченного случая возможно полное или частичное изменение в данных о случае обслуживания (методами UpdateCase или AddMedRecord соответственно).

Порядок вызова методов ИЭМК в рамках сценария «Передача данных по случаю обслуживания по факту завершения оказания медицинской помощи» представлен на Рисунке 9.
Добавление медицинских записей без привязки к случаю обслуживания
Для добавления медицинских записей по пациенту без привязки к случаю обслуживания используется метод AddMedRecord.

Порядок вызова метода ИЭМК в рамках сценария «Добавление медицинских записей без привязки к случаю обслуживания» представлен на Рисунке 10.
Получение данных по направлениям на госпитализацию, обследование или консультацию
Порядок вызова метода ИЭМК в рамках сценария «Получение данных по направлениям на госпитализацию, обследование или консультацию» представлен на Рисунке 11.

Порядок обработки ошибок

В случае успешного прохождения запроса в ответе методов сервиса «Региональная ИЭМК» (AddPatient, UpdatePatient, AddCase, CreateCase, AddStepToCase, CloseCase, AddMedRecord и UpdateCase) отсутствуют выходные параметры и код ответа http должен быть 2ХХ(в идеале 200), также ответная xml будет такая:
где XXXXXXXXXXXXXXXX=Имя метода(AddPatient, UpdatePatient, AddCase, CreateCase, AddStepToCase, CloseCase, AddMedRecord и UpdateCase).

В случае успешного прохождения запроса в ответе методов GetPatient, GetPatientByExternalMisId сервиса «Региональная ИЭМК» указываются выходные данные, приведенные в разделе "Получение данных о зарегистрированном пациенте (GetPatient)".В случае неуспешного прохождения запроса в ответе всех методов сервиса «Региональная ИЭМК» передаются выходные данные с перечнем возникших ошибок.

Например:
В таблице представлено описание параметров выходных данных методов сервиса «Региональная ИЭМК» в случае возникновения ошибок.

Модуль работы с пациентами

Добавление пациента (AddPatient)
Данный метод предназначен для добавления информации о пациенте.
При передаче информации о пациенте осуществляется добавление пациента в Модуль работы с пациентами.
При попытке повторного добавления пациента с помощь метода AddPatient осуществляется проверка наличия информации о пациенте в Модуле работы с пациентами. В случае получения идентичных данных добавление пациента не происходит. В случае получения измененных данных происходит обновление ранее полученной записи.

Описание параметров
В таблице представлено описание параметров запроса метода AddPatient.
Параметр «Кратность» означает количество возможных значений реквизита:
  • 0..1 означает, что реквизит необязательный, максимальное количество экземпляров 1;
  • 0..* – реквизит необязательный, максимальное количество экземпляров не ограничено;
  • 1..1 – реквизит обязательный, экземпляр один;
  • 1..* – реквизит обязательный, максимальное количество экземпляров не ограничено.
Обновление информации о пациенте (UpdatePatient)
Данный метод предназначен для обновления информации о пациенте, зарегистрированном ранее в Модуле работы с пациентами.

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

На уровне сервиса MPI запрещено:
Изменять дату рождения ранее переданного пациента. Исключение - разрешено добавлять недостающие сведения о дате рождения, например:Карточка 1, дата рождения 1999
Карточка 2, дата рождения 1999-01
Обновление возможно, так как год рождения совпал, а месяц был уточнен при обновлении. Аналогично, если добавляется дата рождения к ранее опубликованной записи.
Карточка 1, дата рождения 2000-04-02
Карточка 2, дата рождения 2000-03-02
Обновление невозможно, так как отличается месяц.
Карточка 1, дата рождения 2000-04-02
Карточка 2, дата рождения 2000-04

Обновление невозможно, так как были удалены ранее опубликованные данные по дате рождения.
На уровне сервиса запрещено передавать карточку пациента, в которой одновременно изменены все три параметра в ФИО пациента. А также, нельзя одновременно изменять 2 параметра ФИО, например Фамилия и Имя, или Имя и Отчество.
Получение данных о зарегистрированном пациенте (GetPatient)
Данный метод предназначен для получения информации о пациенте, ранее зарегистрированном в Модуле работы с пациентами сервиса «Региональная ИЭМК».

Описание параметров
В таблице представлено описание параметров запроса метода GetPatient при поиске данных на уровне региона.
Описание выходных данных
Параметры ответа метода GetPatient совпадают с параметрами запроса метода AddPatient и приведены в разделе "Добавление пациента (AddPatient)".

Модуль сбора статистики

Добавление завершенного случая медицинского обслуживания (AddCase)
Данный метод добавляет информацию по законченному случаю обслуживания (как амбулаторному, так и стационарному) в Модуль сбора статистики. При добавлении случая обслуживания осуществляется проверка на уникальность по следующим параметрам: Идентификатор передающей системы, Идентификатор пациента в передающей МИС, Идентификатор ЛПУ, Идентификатор случая обслуживания в передающей МИС.
Параметры метода AddCase можно разделить на 3 категории:
  1. Общие параметры. Передаются как для амбулаторных случаев обслуживания, так и для стационарных (например, исход заболевания, даты начала и окончания и т. д.).
  2. Дополнительные параметры для амбулаторных случаев обслуживания (например, цель обращения, результат обращения и т. д.).
  3. Дополнительные параметры для стационарных случаев обслуживания (например, информация о канале госпитализации, состоянии пациента при поступлении и т. д.).
Метод AddCase состоит из параметра guid (передается при подключении) и CaseBase. Ниже приведено описание амбулаторного и стационарного случаев обслуживания.
Примеры запросов метода AddCase приведены в разделе примеры запросов.
Описание параметров запроса (амбулаторный случай обслуживания)

Структура запроса для амбулаторного случая обслуживания представлена на Рисунке 14.
В таблице представлено описание параметров запроса метода AddCase, которые должны передаваться для амбулаторных случаев обслуживания.
Описание параметров запроса (стационарный случай обслуживания)
Структура запроса для стационарного случая обслуживания представлена на Рисунке 15.
В таблице представлено описание параметров запроса метода AddCase, которые должны передаваться для стационарных случаев обслуживания.
Кратность объектов MedRecord
В таблицах приведена обязательность MedRecord каждого типа для уровня случая обслуживания и эпизода для передачи с помощью метода AddCase.
Регистрация случая медицинского обслуживания (CreateCase)
Данный метод позволяет зарегистрировать (открыть) случай медицинского обслуживания (как амбулаторный, так и стационарный) в Модуле сбора статистики. При добавлении (открытии) случая обслуживания осуществляется проверка на уникальность по следующим параметрам: Идентификатор передающей системы, Идентификатор пациента в передающей МИС, Идентификатор ЛПУ, Идентификатор случая обслуживания в передающей МИС.

Параметры метода CreateCase можно разделить на 3 категории:
  1. Общие параметры. Передаются как для амбулаторных случаев обслуживания, так и для стационарных (например, идентификатор случая в передающей МИС, даты открытия случая и т.д.).
  2. Дополнительные параметры для амбулаторных случаев обслуживания (например, цель обращения, отметка о направленном пациенте и т.д.).
  3. Дополнительные параметры для стационарных случаев обслуживания (например, информация о канале госпитализации, состоянии пациента при поступлении и т.д.).

Структура запросов метода CreateCase аналогична структуре метода AddCase.
Примеры запросов метода CreateCase приведены в разделе примеры запросов.

Описание параметров запроса (амбулаторный случай обслуживания)

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

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

При вызове метода AddStepToCase осуществляется проверка уникальности эпизода случая обслуживания:
  • Если в случае обслуживания отсутствует эпизод случая обслуживания с указанным IdStepMis, то происходит добавление передаваемого эпизода к случаю обслуживания.
  • Если в случае обслуживания присутствует эпизод случая обслуживания с указанным IdStepMis, то происходит обновление данных по эпизоду случая обслуживания.

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

При передаче информации по эпизоду случая обслуживания указывается для объекта step соответствующее значение атрибута xsi:type (используется для указания в явном виде типа наследуемого объекта от базового объекта StepBase; подробнее про xsi:type – см. http://www.w3.org/TR/xmlschema-1/#xsi_type): StepAmb для амбулаторного эпизода случая обслуживания и StepStat для стационарного эпизода случая обслуживания.
На уровне эпизода случая обслуживания (StepAmb/StepStat) могут передаваться медицинские записи (MedRecords). Описание типов объекта MedRecord приведено в разделе "Тип MedRecord". Кратность объектов приведена в разделе ниже.

Примеры запросов метода AddStepToCase приведены в разделе примеры запросов.

Описание параметров запроса (амбулаторный случай обслуживания)
Структура запроса для амбулаторного случая обслуживания представлена на Рисунке 16.

Структура запроса для амбулаторного случая обслуживания представлена на Рисунке 16.

Описание параметров запроса (стационарный случай обслуживания)
Структура запроса для стационарного случая обслуживания представлена на Рисунке 17.
В таблице представлено описание параметров запроса метода AddStepToCase, которые должны передаваться для стационарных случаев обслуживания.
Кратность объектов MedRecord
В таблице приведена обязательность (кратность) MedRecord каждого типа для передачи в рамках метода AddStepToCase.
Закрытие случая медицинского обслуживания (CloseCase)
Данный метод позволяет передать информацию для закрытия случая обслуживания. При добавлении данных для закрытия случая поиск осуществляется по следующим параметрам: Идентификатор передающей системы, Идентификатор пациента в передающей МИС, Идентификатор ЛПУ, Идентификатор случая обслуживания в передающей МИС.

Параметры метода CloseCase можно разделить на 3 категории:
  1. Общие параметры. Передаются как для амбулаторных случаев обслуживания, так и для стационарных (например, исход заболевания, дата закрытия случая и т.д.).
  2. Дополнительный параметр для амбулаторных случаев обслуживания (результат обращения).
  3. Дополнительный параметр для стационарных случаев обслуживания (исход госпитализации).

Структура запросов метода CloseCase аналогична структуре метода AddCase.

Примеры запросов метода CloseCase приведены в разделе примеры запросов.
Описание параметров запроса (амбулаторный случай обслуживания)
В таблице представлено описание параметров запроса метода CloseCase, которые должны передаваться для амбулаторных случаев обслуживания.
Описание параметров запроса (стационарный случай обслуживания)
В таблице представлено описание параметров запроса метода CloseCase, которые должны передаваться для стационарных случаев обслуживания.
Кратность объектов MedRecord
В таблицах приведена обязательность MedRecord каждого типа для уровня случая обслуживания и эпизода для передачи в рамках метода CloseCase.
Добавление медицинских записей (AddMedRecord)
Данный метод используется для передачи в Модуль сбора статистики медицинской записи как в рамках случая обслуживания (в запросе метода требуется заполнение параметра Идентификатор случая обслуживания в передающей МИС), так и без привязки к нему (параметр Идентификатор случая обслуживания в передающей МИС не заполняется; привязка медицинской записи осуществляется напрямую «к пациенту»). Передачу медицинской записи на уровень случая обслуживания можно осуществлять как для открытых (незавершенных), так и для закрытых (завершенных) случаев обслуживания. Метод не позволяет передавать медицинские записи на уровень эпизода случая обслуживания.

Для передачи информации по медицинским записям используется объекты типа MedRecord (описание MedRecord и его наследуемых объектов приведено в разделе "Тип MedRecord"). Кратность объектов представлена ниже.

Структура запроса метода AddMedRecord представлена на Рисунке 18.
Пример запроса метода AddMedRecord приведен в разделе примеры запросов.

Описание параметров запроса
В таблице представлено описание параметров запроса метода AddMedRecord.
Кратность объектов MedRecord
В таблицах приведена обязательность (кратность) MedRecord каждого типа для передачи в рамках метода AddMedRecord.
Изменение закрытого случая медицинского обслуживания (UpdateCase)
Данный метод производит в Модуле сбора статистики полную замену информации о закрытом, ранее переданном случае обслуживания. При этом для ранее переданных данных выставляется статус «аннулировано» и происходит сохранение новых данных по законченному случаю медицинского обслуживания.
При изменении случая обслуживания осуществляется проверка наличия в Модуле сбора статистики случая обслуживания с указанными в запросе метода параметрами: Идентификатор передающей системы, Идентификатор пациента в передающей МИС, Идентификатор ЛПУ, Идентификатор случая обслуживания в передающей МИС.

Параметры метода UpdateCase, их обязательность, а также правила передачи контейнеров аналогичны методу AddCase (описание метода AddCase приведено в разделе "Добавление завершенного случая медицинского обслуживания (AddCase)").

Пример запроса метода UpdateCase приведен в разделе примеры запросов.
Важно!

При обновлении данных по СМО методом UpdateCase, запрещено изменять как по отдельности, так и одновременно в уже существующем СМО перечисленные ниже параметры.
При попытке передать данные с измененными вышеперечисленными параметрами, будут возвращаться сообщения со сведениями об ошибке:
Описание параметров запроса (амбулаторный случай обслуживания)
Параметры запроса метода UpdateCase для изменения информации по амбулаторному случаю обслуживания совпадают с параметрами запроса метода AddCase для добавления информации по амбулаторному случаю обслуживания (приведено в разделе "Добавление завершенного случая медицинского обслуживания (AddCase)").

Описание параметров запроса (стационарный случай обслуживания)
Параметры запроса метода UpdateCase для изменения информации по стационарному случаю обслуживания совпадают с параметрами запроса метода AddCase для добавления информации по стационарному случаю обслуживания (приведено в разделе "Добавление завершенного случая медицинского обслуживания (AddCase)").

Коды ошибок

Коды предупреждений

Взаимодействие с федеральными сервисами ЕГИСЗ

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

В ФИЭМК данные проходят две фазы обработки - Валидация I и Валидация II.

Валидация I (первичная валидация)
Включает в себя проверку СЭМД на соответствие содержания заголовка сообщения в соответствии с профилем IHE и содержания заголовка СЭМД. Т.е. на первом этапе производится валидация синтаксической корректности запроса. Данная проверка выполняется синхронно.В случае выявления расхождений/ошибок на адрес регионального сервиса ИЭМК поступает синхронный ответ с сообщением об ошибке.

Валидация II (вторичная валидация)
Включает в себя проверку структуры секций, значений атрибутов обязательных элементов, т.е. производится полная проверка предоставленных сведений:
проверка сертификатов электронных подписей, которыми был подписан ЭМД, с помощью сертифицированных СКЗИ;
проверка наличия сведений о медицинской организации в ФРМО;
проверка наличия сведений о медицинских работниках в ФРМР.
В случае неуспешной проверки на адрес регионального сервиса ИЭМК поступает асинхронный ответ с сообщением об ошибке.

Сервис ИЭМК логирует ответы, приходящие от федерального сервиса ЕГИСЗ. Ниже приведены коды ответов вместе с сообщениями федерального сервиса и их расшифровка:
Status=1, Message - "Данные добавлены успешно"- свидетельствует о том, что запрос прошел первичную валидацию ФИЭМК, но не получен асинхронный ответ, подтверждающий успешное прохождение второго этапа проверки;
Status=2, - свидетельствует о том, что не удалось сформировать запрос на передачу данных в ЕГИСЗ;
Status=3, - свидетельствует о том, что первый этап проверки не пройден;
Status=4, Message - "Валидация документа прошла успешно/СЭМД добавлен успешно" - свидетельствует о том, что данные успешно выгружены на Федеральный сервис ЕГИСЗ
Status=5, - свидетельствует о том, что не пройден 2-й этап валидации на стороне ЕГИСЗ.
Обычно Валидация II осуществляется в течении нескольких секунд,и статус 1 меняется на статус 1 или 4 практически мгновенно. Но иногда происходит задержка. В данном случае необходимо подождать некоторое время, пока не придет асинхронный ответ.
Данные считаются успешно выгруженными на Федеральный сервис ЕГИСЗ, если вторичная валидация пройдена успешно, и поступил асинхронный ответ (callback), соответственно Status=4.
В случае, если выгрузка не произошла, можно выявить проблему, изучив "Типовые ошибки при взаимодействии с сервисами СЭМД, РЭМД и ЕГИСЗ".
Структурированный электронный медицинский документ (СЭМД)
Структурированный электронный медицинский документ (СЭМД) – электронный документ, с помощью которого осуществляется передача информации (электронных персональных медицинских записей) из Электронной медицинской карты конкретной медицинской организации в Интегрированную электронную медицинскую карту.
СЭМД содержит информацию из конкретной Электронной персональной медицинской записи (ЭПМЗ) в конкретной медицинской организации, всю необходимую информацию для идентификации субъекта ИЭМК, а также для определения автора данной информации и медицинской организации, несущих ответственность за ее содержание.

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

Требования к составу передаваемых данных
СЭМД формируется из амбулаторного или стационарного случая обслуживания, переданного в региональный сервис ИЭМК (телемедицинские случаи обслуживания передаются только в РЭМД).
Для формирования СЭМД, случай обслуживания должен удовлетворять следующим требованиям:
Обязательно передаются данные СНИЛС медицинского работника во всех объектах, относящихся к типу MedicalStaff.

Обязательно передаются данные основного диагноза - см объект ClinicMainDiagnosis.

Федеральный реестр электронных медицинских документов (РЭМД)

Основные требования для взаимодействия с РЭМД
Для осуществления взаимодействия с подсистемой "Федеральный реестр электронных медицинских документов"(РЭМД) со стороны МИС должно быть обеспечено выполнение следующих условий:
Медицинская организация, от которой осуществляется отправка ЭМД в РЭМД, должна быть зарегистрирована в ФРМО;
Врач, подписавший ЭМД (передается в блоке Attachment.PersonalSigns.MedDocumentDto.PersonalSign.Doctor.Person) должeн быть зарегистрирован в ФРМР;
ЭМД должен быть подписан подписью врача и МО, сформированных по формату CMS (Cryptographic Message Syntax);
У врача, подписавшего ЭМД, должен быть передан СНИЛС;
У пациента должен быть передан СНИЛС;
Для формирования указанных УКЭП должны использоваться сертификаты, выданные аккредитованными УЦ. Сертификаты должны соответствовать требованиям ГОСТ Р 34.10-2012 (Согласно выписке из документа ФСБ России N 149/7/1/3-58 от 31.01.2014 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования» использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31.12.2018 года не допускается);
Файл ЭМД должен иметь формат PDF/A-1, соответствующий международному стандарту ISO 19005-1:2005.