Общие положения
1.1. Настоящее описание интеграционных профилей модуля «Обмена данными лабораторных исследований» (далее – Описание) определяет механизмы информационного взаимодействия медицинских информационных систем (далее – МИС), лабораторных информационных систем (далее – ЛИС) и сервиса «Обмен данными лабораторных исследований» (далее – сервис ДЛИ), входящих в состав Единой государственной системы в сфере здравоохранения.
1.2. Описание предназначено для организаций-разработчиков, осуществляющих сопровождение эксплуатируемых информационных систем и разработку новых систем для медицинских учреждений и клинико-диагностических лабораторий.
1.3. В рамках информационного взаимодействия сервис ДЛИ поддерживает получение следующих сведений от сторонних информационных систем:
- Информация о пациенте (идентификатор в ИС, пол и дата рождения, ФИО и т.д.).
- Информация о враче (идентификатор в ИС, ФИО и т.д.).
- Информация о заявке на лабораторное исследование.
- Информация о результате лабораторного исследования.
- Информация об услугах, оказываемых целевой МО
1.4. Документ содержит описание методов сервиса ДЛИ, которые должны поддерживать сторонние информационные системы для обеспечения автоматизированного информационного взаимодействия.
Определения, обозначения и сокращения
|
Сокращение, обозначение |
Определение |
|
ДЛИ |
Данные лабораторных исследований |
|
КДЛ |
Клинико-диагностическая лаборатория |
|
ЛИС |
Лабораторная информационная система |
|
МИС |
Медицинская информационная система |
|
МЦКДЛ |
Межрайонная централизованная клинико-диагностическая лаборатория |
|
МО |
Медицинская организация |
|
ДУЛ |
Документ, удостоверяющий личность пациента |
|
ЕНП |
Единый номер полиса ОМС нового образца |
|
ОМС |
Обязательное медицинское страхование |
|
СНИЛС |
Страховой номер индивидуального лицевого счёта |
|
УКЭП |
Усиленная квалифицированная электронная подпись |
При описании ресурсов и используемых параметров используется понятие «Кратность». Кратность — это нижняя и верхняя граница того, сколько раз элементу разрешено появляться в ресурсе (см. описание параметров), или ресурсу в Bundle (см. структуру Bundle), при этом используются следующие обозначения:
0..1 — минимальное количество элементов ноль (параметр может не передаваться), максимальное один. Интерпретируется как необязательный параметр;
0..* — минимальное количество элементов ноль (параметр может не передаваться), максимальное количество элементов не ограничено. Интерпретируется как необязательный параметр;
1..1 — минимальное количество элементов один, максимальное один. Всегда передается один элемент. Интерпретируется как обязательный параметр;
1..2 — минимальное количество элементов один, максимальное два. Интерпретируется как обязательный параметр;
2..2 — минимальное количество элементов два, максимальное два. Всегда передается два элемента. Интерпретируется как обязательный параметр;
1..* – минимальное количество элементов один, максимальное количество элементов не ограничено. Интерпретируется как обязательный параметр.
Текстовая информация, передаваемая в запросах, должна передаваться в кодировке UTF8.
Описание решения
3.1. Краткое описание процесса
Процесс проведения лабораторных исследований согласно ГОСТ Р 53022.1-2008 состоит из трех этапов:
- Преаналитический. К преаналитическому этапу относятся процессы по подготовке заявки на выполнение исследования, передаче заявки и исследуемого материала в КДЛ, подготовке к выполнению исследования. Состоит из двух фаз:
1.1. Внелабораторная фаза. Включает в себя:
1.1.1. Формирование направления. Выполняется врачом МО в случае необходимости проведения исследования.
1.1.2. Сбор биоматериала. Осуществляет медицинская сестра процедурного кабинета в соответствии с данными направления.
1.1.3. Формирование заявки. К направлению добавляется необходимая дополнительная информация согласно требованиям лаборатории.
1.1.4. Передача заявки и биоматериала в лабораторию.
1.2. Внутрилабораторная фаза. Включает в себя:
1.2.1. Проверка корректности заявки. Выполняется регистратором.
1.2.2. Формирование/изменение заказа (заказ может быть передан в ЛИС из МИС автоматически или внесен в ЛИС сотрудником МО через удаленное рабочее место). Выполняется регистратором/врачом клинической лабораторной диагностики.
- Аналитический. К аналитическому этапу относится процесс выполнения исследования. Проведение исследования выполняется врачом клинической лабораторной диагностики вручную или с помощью оборудования.
- Постаналитический. К постаналитическому этапу относятся процессы по утверждению результата, передаче утвержденного результата в МО. Проверка корректности полученных результатов (анализ результатов) выполняется врачом клинической лабораторной диагностики. В случае необходимости производится корректировка заказа и выполнение дополнительных исследований. После подтверждения результаты передаются в МО.
Информационное обеспечение процесса осуществляют: МИС МО (как источник информации о назначении и получатель результатов исследования), ЛИС КДЛ (как получатель информации о назначении и источник результатов исследований) и сервис ДЛИ (как информационная шина, обеспечивающая информационный обмен и как хранилище информации по лабораторным исследованиям).
3.2. Описание взаимодействия с сервисом
Сервис ДЛИ предназначен для ведения, хранения, поиска и выдачи сведений по лабораторным исследованиям в рамках. Сервис обеспечивает:
- Централизованный учет заявок на лабораторное исследование.
- Централизованный учет результатов лабораторных исследований.
- Учет информации о пациентах, которым назначено лабораторное исследование.
- Учет информации о медперсонале
- Получение заявок на лабораторное исследование и передача их по запросу.
- Передача статуса заявки по запросу.
- Получение результатов лабораторных исследований и передача их по запросу.
- Передача всех результатов лабораторных исследований для МО по запросу. Базовая схема информационного взаимодействия приведена на рисунке ниже.
Рисунок 1. Базовая схема информационного взаимодействия
Обмен данными между МИС МО, ЛИС КДЛ и сервиса ДЛИ осуществляется в рамках следующих сценариев:
- Добавление заявки. Заявка из МИС передается в сервис ДЛИ.
- Запрос заявки. Заявки не передаются в ЛИС автоматически. ЛИС КДЛ запрашивает заявку у сервиса ДЛИ при поступлении исследуемого материала в лабораторию.
- Добавление результата. Результат передается из ЛИС. В сервис ДЛИ должны передаваться только утвержденные результаты исследований.
- Запрос статуса заявки. Информация об изменении статуса заявки не передается в МИС автоматически. МИС запрашивает статус заявки у сервиса ДЛИ
- Запрос результата. Результат не передается в МИС автоматически. МИС запрашивает заявку у сервиса ДЛИ.
- Описание протокола взаимодействия
Общая информация о сервисе
Информационный обмен осуществляется в соответствии со стандартом FHIR® (Fast Healthcare Interoperability Resources), разработанным организацией HL7. Используемая версия FHIR DSTU2, 1.0.2. Подробное описание стандарта доступно по следующим ссылкам:
- http://hl7.org/fhir/DSTU2/index.html
- http://fhir-ru.github.io/summary.html (перевод)
- качестве протокола взаимодействия используется RESTful AP (использование REST-
протокола в FHIR® – см. http://fhir-ru.github.io/http.html). Данные необходимо передавать
- формате JSON, должен присутствовать http заголовок content-type: application/json
Сервис поддерживает три основных метода:
- передача ресурса (Patient, Practitioner, etc.);
- передача бандла (заявки, результата, результата без заявки);
- запрос информации (заявок, результатов)
Требования к передаче данных
Для передачи данных в сервис ДЛИ необходимо передавать в заголовке сообщения авторизационный токен в формате:
Authorization: N3[пробел][GUID передающей системы]
GUID передающей системы выдается разработчику МИС администратором интеграционной платформы. GUID передающей системы должен соответствовать идентификатору информационной системы, указанному в идентификаторе ресурса, заявки или результата.
Для передачи данных в сервис необходимо передавать в заголовке сообщения заголовок вида content-type: application/json
Текстовая информация, передаваемая в запросах, должна передаваться в кодировке UTF8 (RFC 3629). Запрещается передача имени, отчества инициалами, а также записей вида «.», «нет», «нету» в случае, если отчество пациента отсутствует. Фамилия, имя, отчество должно начинаться с большой буквы, далее в нижнем регистре. Остальная текстовая информация передается регистром «Как в предложениях» или в нижнем регистре. Передача текста в верхнем регистре, за исключением аббревиатур, не допускается.
Все данные типа дата-время (кроме даты рождения пациента) следует передавать в сервис в формате YYYY-MM-DDThh:mm:ss[.SSS]±hh:mm (стандарт ISO8601). Допускается, но не рекомендуется передача данных в формате YYYY-MM-DD и YYYY-MM-DDThh:mm:ss[.SSS]Z. Дату рождения пациента следует передавать в формате YYYY-MM-DD
Ряд ключевых полей (например, DiagnosticReport.issued) сервис всегда возвращает
- формате YYYY-MM-DDThh:mm:ss±hh:mm, остальные поля не конвертируются и возвращаются в том формате, в котором были переданы в сервис
Идентификаторы, используемые для связки ресурсов в запросах, и ссылки на существующие ресурсы в БД должны соответствовать требованиям, предъявляемым к GUID (RFC 4122), буквенные символы должны передаваться в нижнем регистре. Идентификаторы для связки ресурсов в запросах должны начинаться с префикса urn:uuid:
Идентификаторы объектов (заявок, результатов, штрихкод) должны содержать только буквы и цифры, могут содержать символы двоеточия, запятой, тире, пробел, не могут содержать символы запятой, слеш любой, кавычки, спецсимволы.
OID справочников и OID передающей системы, передаваемые в параметрах “system”, должны начинаться с префикса urn:oid:
OID передающей системы, передаваемые в параметрах “display”, должны передаваться без префикса urn:oid:
Передача пустых значений вида parametrname: «» не допускается, за исключением Order.detail.reference в результате без заявки
Ресурсы и бандлы, передаваемые в сервис, должны корректно валидироваться как JSON (RFC 8259) и соответствовать правилам стандарта FHIR по структуре и содержанию.
Сервис возвращает ресурсы с автоматически присвоенными дополнительными идентификаторами, не описанными в ОИП. Интегрированные системы должны корректно обрабатывать идентификаторы, учитывая только те, что описаны в ОИП.
Порядок следования ресурсов в запросе, параметров в ресурсе не нормируется и может зависеть от способа передачи информации в сервис, поэтому нельзя ориентироваться на порядковый номер какого-либо элемента в структуре.
Ответы сервиса
Сервис осуществляет валидацию входных данных при вызовах любых методов. В ответ на запрос сервис возвращает HTTP код состояния и ответ. Основные коды и их значение указаны в таблице ниже.
Если валидация прошла успешно, то сервис возвращает успешный ответ (200, 201), включающий в себя определенные параметры (в зависимости от типа запроса):
если передавался отдельный ресурс, возвращается переданный ресурс, в котором также передаются:
- id — GUID созданного ресурса (присваивается при создании записи в БД, используется для формирования ссылки на ресурс),
- meta — мета данные,
- versionId — версия id ресурса в сервисе ОДЛИ,
- lastUpdated — дата-время последнего обновления ресурса
если передавался ресурс Bundle (заявка, результат, результат без заявки), возвращается Bundle, в котором передаются:
- id — GUID Bundle в сервисе (присваивается при создании записи в БД, используется в служебных целях)
- entry – массив переданных в запросе ресурсов в виде entry, содержащих для каждого ресурса параметры:
- fullUrl (переданный в запросе параметр fullUrl преобразуется в ссылку на ресурс для дальнейшего запроса его в сервисе — на новый ресурс или ссылка на найденный в БД ресурс),
- resource (непосредственно переданный ресурс),
- response (status (201-created), location –ссылка на ресурс)
- случае, если передавался запрос информации, возвращается ресурс parameter,
содержащий массив данных (ресурсы и другая информация) в соответствии с типом запроса.
Если валидация прошла неуспешно, то сервис возвращает ошибку (400-504), а также параметр issue, содержащий массив с данными по обнаруженным ошибкам:
- code — код ошибки
- diagnostics — текст ошибки
- location — массив параметров, в которых обнаружена данная ошибка.
Таблица 1. HTTP коды состояния
| № п/п | Код | Описание | Примечание |
| 1 | 200 | Успешный ответ | |
| 2 | 201 | Успешный ответ, ресурс создан | |
| 3 | 400 | Ресурс не может быть проанализирован или не прошел валидацию по базовым правилам проверки FHIR | Необходимо исправить ошибку в запросе |
| 4 | 403 | Ошибка авторизации (неверный токен) | Необходимо использовать токен, соответствующий OID передающей системы |
| 5 | 404 |
Тип ресурса не поддерживается / Метод не поддерживается |
Необходимо исправить ошибку в запросе |
| 6 | 405 | Неверно сформирован запрос к сервису | Необходимо исправить ошибку в запросе |
| 7 | 403 | Попытка создания дубля данных (конфликт) | Необходимо исправить ошибку в запросе |
| 8 | 415 | Неподдерживаемый тип данных | Необходимо передавать данные в формате JSON,должен присутствовать заголовок content-type:application/json |
| 9 | 413 | Тело запроса слишком велико | Необходимо уменьшить размер запроса |
| 10 | 422 | Ошибка валидации | Необходимо исправить ошибку в запросе |
| 11 | 500 | Сервис недоступен. Внутренняя ошибка сервиса | Необходимо обратиться в техническую поддержку |
| 12 | 502 | Сервис недоступен. Не включено серверное оборудование или не запущены программные компоненты модуля ИШ | Необходимо обратиться в техническую поддержку |
| 13 | 503 | Сервис недоступен. Не включено серверное оборудование или не запущены программные компоненты модуля ИШ | Необходимо обратиться в техническую поддержку |
| 14 | 504 | Сервис недоступен. Таймаут | Необходимо обратиться в техническую поддержку |
Использование справочников
Справочники, используемые в сервисе ДЛИ, опубликованы в «Сервисе Терминологии». Описание сервиса Терминологии и правила взаимодействия с ним приведены по ссылке: http://api.netrika.ru/docs.php?article=Terminology.
Для каждого справочника в Настоящем документе указан его OID (объектный идентификатор). Перечень присвоенных корневых OID:
- 2.643.5.1.13.2.1 — Корневой OID справочников, размещённых в Федеральном реестре НСИ (http://nsi.rosminzdrav.ru/);
Передача параметров, использующих значения справочников, не указанных в стандарте FHIR, осуществляется в следующей структуре:
"coding": [
{
"system": "urn:oid:[OID справочника в сервисе Терминологии]",
"version": "[версия справочника]",
"code": "[код значения]"
}
]
При передаче параметров, использующих значения внутренних справочников FHIR, указывается только код значения (справочники стандарта FHIR также опубликованы в сервисе Терминологии)
Особенности использования справочников
- При передаче любого значения с использованием справочника необходимо передавать в том числе используемую версию справочника. Допускается передача значений только по актуальной версии справочника. При валидации значений сервисом значения, передаваемые без указания версии справочника или с указанием неактуальной версии, не проходят валидацию и не принимаются сервисом. Передача значений, отсутствующих в актуальной версии справочника, невозможна.
- При использовании справочника медицинских организаций: в случае, если в справочнике для учреждения зарегистрированы подразделения, необходимо передавать информацию от имени соответствующего подразделения. Передача информации от имени головного учреждения в данном случае не допускается. При передаче заявки на исследование необходимо указывать в заявке
(Order.identifier.assigner), данных пациента (Patient.managingOrganization) и
случае обслуживания (Encounter.serviceProvider) то учреждение или подразделение (если зарегистрировано в справочнике), где проходит лечение пациент (открыт случай обслуживания и создана заявка). В качестве справочника медицинских организаций (включая подразделения) в сервисе используется справочник 1.2.643.2.69.1.1.1.64
Методы сервиса
Сервис ДЛИ поддерживает следующие методы:
- Передача пациента (POST Patient)
- Обновление пациента (PUT Patient)
- Передача врача (POST Practitioner)
- Обновление врача (PUT Practitioner)
- Передача заявки (POST Bundle заявки)
- Обновление биоматериала (PUT Specimen)
- Запрос заявки ($getorder)
- Запрос заявок ($getorders)
- Передача результата (POST Bundle результата)
- Передача результата без заявки (POST Bundle результата без заявки)
- Запрос статуса ($getstatus)
- Запрос результата ($getresult)
- Запрос результатов ($getresults)
- Запрос ресурсов (GET resource)
- Отмена заявки ($cancelorder)
- Отмена результата ($cancelresult)
- Обоснованность назначений ($validity)
- Передача услуги (POST HealthcareService)
- Запрос списка услуг для заданной МО
Для корректной работы с сервисом ОДЛИ информационная система также должна поддерживать методы работы с сервисом Терминологии. Минимально необходимо поддерживать метод «Запрос значений справочника». Описание данного метода в данном документе приведено в справочном порядке.
Передача пациента (POST Patient)
Для регистрации пациента в сервисе ДЛИ используется POST-запрос ресурса Patient.
- качестве адреса указывается URL в формате [base]/Patient?_format=json. В ответе сервис возвращает json с созданным пациентом и его идентификатором в сервисе ДЛИ.
При передаче данных анонимных пациентов следует в ресурсе Patient передавать параметр name.use = “anonimous”, не передавать никакие идентификаторы, кроме идентификатора в МИС/ЛИС, не передавать адрес пациента. Параметры name.given, name.family должны содержать произвольные значения, например «Анонимный»
Информация о представителе пациента (для новорожденных) передается ссылкой в параметре link, для этого следует сначала передать в сервис в полном объеме данные о представителе пациента, а затем использовать полученную ссылку на ресурс.
Уникальность пациента проверяется по совокупности параметров ID МИС и ИД пациента в МИС. Многократная передача одного и того же пациента из одной и той же МИС с разными идентификаторами МИС не допускается.
Описание параметров
Перечень параметров и их описание представлены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
Таблица 2. Параметры ресурса Patient
|
№ п/п |
Параметр | Тип | Кратность | Описание |
|
1 |
id | Identifier |
1..1 усл. Должен передаваться при обновлении методом PUT |
GUID ресурса Patient для обновления методом PUT |
| 2 | identifier | identifier |
1..* Должен передаваться хотя бы идентификатор в ИС (identifier.system 1.2.643.5.1.13.2.7.100.5 ) |
Идентификатор пациента. Указывает код пациента в МИС, ЛИС, ДУЛ, полисы, СНИЛС, информацию по прикреплению, дополнительные идентификаторы |
| 2.1 | Identifier.use | code | 0..1 |
Признак недостоверности данных. Значение “temp” присваивается сервисом в автоматическом режиме в случае, если идентификатор СНИЛС или ЕНП не прошел проверку на корректность |
| 2.2 | Identifier.type | CodeableConcept | 0..1 усл. |
Тип идентификатора. Обязателен при передаче дополнительного дентификатора.
|
| 2.3 | identifier.system | uri | 1.1 |
Пространство имён идентификатора. Указывается код:
|
| 2.4 | identifier.value | string | 1..1 |
Значение идентификатора или серия, номер документа
|
| 2.5 | identifier.period | Period | 0..1 |
Период действия документа.
|
| 2.6 | identifier.assigner.reference | Reference (Organization) | 0..1 усл. |
Передается только для дополнительного идентификатора. Ссылка на организацию прикрепления в формате Organization/GUID, где GUID – идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64 |
| 2.7 | identifier.assigner.display | string | 1..1 |
|
| 3 | managingOrganization | Reference (Organization) | 1..1 | Ссылка на организацию, зарегистрировавшую пациента в формате Organization/GUID, где GUID –идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64 |
| 4 | telecom | ContactPoint | 0..* |
Контактные данные пациента
|
| 5 | name | HumanName | 1..1 |
Информация о ФИО пациента |
| 5.1 | name.family | string | 1..2 |
Фамилия, Отчество. Сначала указывается фамилия. |
| 5.2 | name.given | string | 1..1 |
Имя |
| 5.3 | name.use | code | 0..1 |
Код типа имени (справочник FHIR). Передается значение “anonymous” при передаче данных по анонимному пациенту или “temp” при передаче заведомо некорректных данных пациента (инициалы, ФИО пациента неизвестны) |
| 6 | gender | code | 1..1 |
Код пола пациента (справочник FHIR. OID:1.2.643.2.69.1.1.1.40) |
| 7 | birthDate | date | 1..1 |
Дата рождения (yyyy-MM-dd) |
| 8 | extension | 0..1 |
Расширение формата для передачи места рождения пациента. В параметре url указывается ссылка на описание расширения http://hl7.org/fhir/StructureDefinition/birt hplace, в параметре valueAddress.text место рождения так, как указано в паспорте. |
|
| 9 | address | Address | 0..* |
Информация об адресе пациента |
| 9.1 | address.extension | 0..4 |
Расширение формата для передачи дополнительных данных адреса: — код вида места жительства пациента (город/село). В параметре url указывается ссылка на справочник http://api.n3med.ru/api/fhir/n3extension- residenceclasscode/ в параметре valueCode код места жительства по справочнику OID 1.2.643.5.1.13.13.11.1042; — код ФИАС адреса. В параметре url указывается ссылка http://api.n3med.ru/api/fhir/n3extension-aoguid/ , в параметре valueString AOGUID адресного объекта по ФИАС; — код ФИАС дома. В параметре url указывается ссылка http://api.n3med.ru/api/fhir/n3extension-houseguid/ , в параметре valueString HOUSEGUID здания по ФИАС; — номер квартиры. В параметре url указывается ссылка http://api.n3med.ru/api/fhir/n3extension-flatid, в параметре valueString номер квартиры |
|
| 9.2 | address.use | code | 1..1 |
Тип адреса (справочник FHIR. OID: 1.2.643.2.69.1.1.1.41) home — Адрес проживания, temp — Адрес регистрации |
| 9.3 | address.text | string | 1..1 |
Адрес строкой |
| 9.4 | address.line | string | 0..1 |
Улица, номер дома, номер квартиры |
| 9.5 | address.state | string | 0..1 |
Регион. Указывается двузначный код субъекта РФ по справочнику 1.2.643.5.1.13.13.99.2.206 |
| 9.6 | address.city | string | 0..1 |
Город |
| 9.7 | address.district | string | 0..1 |
Район |
| 9.8 | address.postalCode | string | 0…1 |
Почтовый индекс |
| 10 | contact |
BackboneElement |
0…1 |
Дополнительные данные по пациенту |
| 10.1 | contact.telecom |
ContactPoint |
1..* |
Контактные данные представителя пациента:
|
| 10.2 | contact.relationship | CodeableConcept | 0..1 |
Место работы, учебы. Тип указывается в параметре contact.relationship.coding, в параметре code по справочнику 1.2.643.5.1.13.13.11.1038 (в соответствии с занятостью, например 5 — место работы). Адрес места работы, учёбы указывается в параметре contact.address. Адрес строкой передается в параметре text. В параметре use всегда передается work |
| 11 | link | 0..1 |
Информация о представителе пациента |
|
| 11.1 | link.type | code | 1..1 |
Тип ссылки, всегда передается “refer” |
| 11.2 | link.other | Reference(Patient) | 1..1 |
Ссылка на ресурс Patient в БД, описывающий представителя пациента |
Для корректной работы федеральных сервисов СЭМД, РЭМД при передаче пациента обязательно должен передаваться СНИЛС
Для корректной работы смежных сервисов N3 (MPI, Портал врача, Личный кабинет пациента) при передаче пациента должны передаваться номер полиса и СНИЛС
При передаче заведомо некорректных данных пациента (неизвестные пациенты, новорожденные без имени и др.) к имени пациента необходимо добавлять параметр name.use == temp. В случае появления информации о корректных данных необходимо обновить данные пациента в сервисе методом PUT Patient, исключив указанный параметр.
СНИЛС и номер полиса пациента могут проверяться сервисом ОДЛИ на совпадение контрольной суммы. В случае, если проверка не пройдена, пациент будет добавлен в сервис, но к некорректному идентификатору будет добавлен параметр Identifier.use == temp. Данная информация должна анализироваться на стороне передающей системы и исправляться в ручном или автоматическом режиме.
При передаче данных анонимного пациента к имени пациента необходимо добавлять параметр name.use == anonymous. Для анонимного пациента запрещена передача персонализированных данных (адрес, номер полиса, паспорта, СНИЛС)
Помимо перечисленных выше параметров, в сервис может быть передан дополнительный идентификатор прикрепления. Особенности передачи идентификатора прикрепления описаны ниже.
Идентификатор является разновидностью уже имеющегося идентификатора Patient.identifier и имеет пространство имен 1.2.643.5.1.13.2.7.100.9. В ресурсе Patient допускается передавать несколько identifier из пространства имен 1.2.643.5.1.13.2.7.100.9.
Правила передачи идентификатора с OID 1.2.643.5.1.13.2.7.100.9:
- если Patient.identifier.value = 0, то идентификатор может передаваться только один
- запрещена передача нескольких идентификаторов с одинаковым Patient.identifier.value
Таблица 3 Параметры идентификатора прикрепления
| № п/п | Параметр | Тип | Кратность | Описание |
| 1.1. | identifier.system | uri | 1..1 | Пространство имён идентификатора. OID (1.2.643.5.1.13.2.7.100.9) |
| 1.2. | identifier.use | code | 0..1 | Способ прикрепления (справочник FHIR) usual – по территориально-участковому принципу official – по заявлению temp – на период первоначального прикрепления без заявления |
| 1.3. | identifier.value | string | 1..1 | Значение профиля прикрепления по справочнику 1.2.643.2.69.1.1.1.56. Прикрепление осуществляется по профилям: терапия, педиатрия, ВОП, стоматология, акушерство и гинекология. В случае прикрепления по всем профилям единовременно к одному участку передается код профиля 0 |
| 1.4. | identifier.period | Period | 0..1 |
Период прикрепления. Может быть указана одна или обе даты.
|
| 1.5. | identifier.assigner.reference | Reference | 0..1 усл |
Ссылка на организацию прикрепления в формате Organization/GUID, где guid — идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64. Не передается при откреплении пациента от МО |
| 1.6. | identifier.assigner.display | display | 0..1 усл | Текстовое наименование участка прикрепления. Не передается при откреплении пациента от МО |
4.5.2. Обновление пациента (PUT Patient)
В подсистеме ДЛИ должна быть возможность обновить информацию о пациенте. При обновлении данных должна передаваться полная информация о пациенте, т.е. для корректной работы МИС должна сначала запросить ресурс Patient (операция GET), а потом передать его со всеми параметрами, в том числе и неизменившимися (операция PUT). Обновление ресурса разрешено только отправителям данного ресурса. Методом PUT нельзя менять ключевые параметры — идентификатор в МИС, организацию.
При обновлении пациента в качестве адреса указывается URL в формате [base]/Patient/[GUID]?_format=json. GUID пациента в URL должен соответствовать id, указанному в запросе. В ответе сервис возвращает json с обновленным пациентом и его идентификатором в сервисе ДЛИ.
Описание параметров
Параметры ресурса Patient приведены в таблице выше.
4.5.3. Передача врача (POST Practitioner)
Для регистрации врача в сервисе ДЛИ используется POST-запрос ресурса Practitioner. В качестве адреса указывается URL в формате [base]/Practitioner?_format=json. В ответе сервис возвращает json с созданным врачом и его идентификатором в сервисе ДЛИ.
Данные СНИЛСа, идентификатор в ИС врача передаются в параметре identifier.
Описание параметров
Перечень параметров и их описание представлены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
Таблица 4. Параметры Practitioner
|
№ п/п |
Параметр | Тип | Кратность | Описание |
|
1. |
id | Identifier | 1..1 усл Должен передаваться при обновлении методом PUT | GUID ресурса Practitioner для обновления методом PUT |
| 2. | identifier | identifier | 1..2 Должен передаваться хотя бы идентификатор в ИС (identifier.system 1.2.643.5.1.13.2.7.100.5) | Идентификатор врача (идентификатор в МИС/ЛИС или СНИЛС) |
| 2.1. | identifier.system | uri | 1..1 |
Пространство имён идентификатора. Указывается код:
• OID ПФР для СНИЛСа (1.2.643.2.69.1.1.1.6.223) |
| 2.2. | identifier.value | string | 1..1 | Значение для идентификатора или для СНИЛСа |
| 2.3. | identifier.assigner.display | string | 1..1 |
|
| 3. | name | HumanName | 1..1 | ФИО врача |
| 3.1. | name.family | string | 1..2 | Фамилия, Отчество. Сначала указывается Фамилия |
| 3.2. | name.given | string | 1..1 | Имя |
| 4. | practitionerRole | BackboneElement | 1..1 | Сведения о враче |
| 4.1. | practitionerRole.managingOrganization | Reference(Organization) | 1..1 |
Ссылка на организацию, в которой работает врач, в формате Organization/GUID, где GUID – идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64 |
| 4.2. | practitionerRole.role | CodeableConcept | 1..1 |
Код должности врача (Номенклатура должностей медицинских работников и фармацевтических работников)
• В параметре code указывается код значения из справочника |
| 4.3. | practitionerRole.specialty | CodeableConcept | 1..1 |
Код специальности врача (Номенклатура специальностей специалистов с высшим и послевузовским медицинским и фармацевтическим образованием в сфере здравоохранения):
справочника в сервисе Терминологии, • В параметре code указывается код значения из справочника |
Для корректной работы федеральных сервисов СЭМД, РЭМД при передаче врача должен передаваться СНИЛС.