Общие положения
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 указывается код значения из справочника |
Для корректной работы федеральных сервисов СЭМД, РЭМД при передаче врача должен передаваться СНИЛС. СНИЛС врача, должность врача, МО должны совпадать с соответствующими данными работника в ФРМР.
4.5.4. Обновление врача (PUT Practitioner)
В подсистеме ДЛИ должна быть возможность обновить информацию о враче. При обновлении данных должна передаваться полная информация о враче, т.е. для более корректной работы МИС должна запросить ресурс Practitioner (операция GET), а потом передать его со всеми параметрами, в том числе и неизменившимися (операция PUT). Обновление ресурса разрешено только отправителям данного ресурса. Методом PUT нельзя менять ключевые параметры — должность, специальность, идентификатор в МИС, организацию.
При обновлении врача в качестве адреса указывается URL в формате [base]/Practitioner/[GUID]?_format=json. В ответе сервис возвращает json с обновленным врачом и его идентификатором в сервисе ДЛИ.
Описание параметров
Параметры ресурса Practitioner приведены в таблице выше.
4.5.5. Передача заявки (POST Bundle заявки)
Для передачи заявки должен использоваться Bundle2 типа транзакция. В Bundle должна передаваться следующая информация:
- Сведения о пациенте (ФИО, пол, ДР, идентификаторы и т.п.).
- Сведения о враче (ФИО, пол, ДР, должность, специальность и т.п.).
- Общие сведения о заявке (идентификатор, дата, автор и т.п.).
- Информация о назначенных услугах и враче, сделавшем назначение.
- Данные о случае обслуживания, в рамках которого назначено исследование.
- Данные о состоянии пациента (диагнозы, информация о росте, весе пациента и т.п.).
- Информация о биоматериале (тип биоматериала, тип контейнера, штрихкод и др.)
Структура Bundle
Bundle используется для передачи набора ресурсов. Для каждого из ресурсов Bundle должна указываться операция (POST). Перечень ресурсов и их описание представлено в таблице ниже.
Таблица 5. Описание ресурсов, входящих в состав Bundle
| № п/п | Ресурс | Ссылки на другие ресурсы | Описание | |
| 1. | Order |
|
В ресурсе указывается общая информация о заявке на проведение исследования:
• информация о назначении |
|
| 2. | Patient | В ресурсе указывается информация о пациенте. | ||
| 3. | Practitioner | practitionerRole.managingOrganization — ссылка на Organization |
В ресурсе указывается информация о враче: для передачи данных об авторе заявки и врачах, которые сделали назначение пациенту. |
|
| 4. | Encounter |
|
В ресурсе указывается информация о случае обслуживания, в рамках которого назначено исследование, и информация о диагнозе пациента | |
| 5. | DiagnosticOrder |
• DiagnosticOrder.subject – ссылка на Patient • DiagnosticOrder.orderer – ссылка на Practitioner • DiagnosticOrder.specimen – ссылка на Specimen • DiagnosticOrder.encounter –ссылка на Encounter •DiagnosticOrder.supportingInformation – ссылка на Condition/Observation |
В ресурсе указывается следующая информация:
Если источник финансирования в заявке ОМС, то для пациента должен быть передан полис ОМС. Если в рамках одной заявки более одного врача назначили пациенту исследования, то по каждому врачу должен быть передан отдельный DiagnosticOrder. Если в заявке передается несколько услуг, которые были назначены разными врачами, то во всех ресурсах DiagnosticOrder необходимо указывать врача, дополнившего назначение на исследования последним. Несколько DiagnosticOrder могут ссылаться на один биоматериал (Specimen). |
|
| 6. | Specimen | Specimen.subject – ссылка на Patient | В ресурсе указывается информация о забранном биоматериале | |
| 7. | Observation |
В ресурсе указывается информация о состоянии пациента: рост, вес, неделя беременности, день цикла |
||
| 8. | Condition | Condition.subject – ссылка на Patient |
В ресурсе указывается информация о состоянии пациента: диагнозы, признак менопаузы |
|
Схема структуры Bundle приведена на рисунке ниже.
Рисунок 2 Структура Bundle
Допустимые операции над ресурсами Bundle
Список обязательных ресурсов и допустимые операции над ресурсами Bundle приведены в таблице ниже.
Таблица 6. Обязательность ресурсов внутри Bundle и допустимые операции
| № п/п | Ресурс | Кратность | Операции | Возможность использования ссылки на ресурс |
| 1 | Patient | 0..1 |
|
Ресурс может не передаваться, указывается ссылка на уже существующий |
| 2 | Practitioner | 0..* |
|
Ресурс может не передаваться, указывается ссылка на уже существующий |
| 3 | DiagnosticOrder | 1..* | Создание (POST) | Всегда должен передаваться ресурс |
| 4 | Encounter | 0..1 |
|
Ресурс может не передаваться, указывается ссылка на уже существующий |
| 5 | Specimen | 0..* |
Создание (POST) |
Может не передаваться. Нельзя указывать ссылку на уже существующий. Должен передаваться для корректной работы сервиса СЭМД |
| 6 | Observation | 0..* |
Создание (POST) |
Может не передаваться. Нельзя указывать ссылку на уже существующий |
| 7 | Condition | 0..* |
Создание (POST) |
Может не передаваться, если не передается Encounter. Нельзя указывать ссылку на уже существующий |
| 8 | Order | 1..1 |
Создание (POST) |
Всегда должен передаваться ресурс |
Структура запроса Bundle заявки
При добавлении заявки в качестве адреса указывается URL в формате [base]?_format=json. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ДЛИ.
Json-запрос для передачи заявки содержит следующие компоненты:
- Указание, что в запросе передается Bundle,
- Метаинформация (meta.profile — ссылка на ресурс StructureDefinition. Необходимо всегда указывать ссылку на ресурс StructureDefinition с
идентификаторомcd45a667-bde0-490f-b602-8d780acf4aa2.Ресурс
StructureDefinition описывает структуру JSON-запроса — набор определений элементов данных, и связанные с ними правила использования),
- Тип Bundle,
- Данные о передаваемых ресурсах:
- fullUrl ресурса,
- Сам ресурс,
- Операция над этим ресурсом.
Общее описание структуры запроса приведено на рисунке ниже.
Рисунок 3. Структура json-запроса для передачи Bundle заявки
Пример базовой структуры json-запроса для передачи заявки:
POST http://[hostname]/exlab/api/fhir?_format=json HTTP/1.1 authorization: N3[пробел][GUID передающей системы] content-type: application/json
{
«resourceType»: «Bundle»,
«type»: «transaction»,
«meta»: {
«profile»: [«StructureDefinition/cd45a667-bde0-490f-b602-8d780acf4aa2»]
},
«entry»: [
{
«fullUrl»: «urn:uuid:f8cd600f-f5b5-4b18-9662-18212c193555»,
//GUID ресурса в Bundle, который используется для связи ресурсов внутри Bundle «resource»: {
«resourceType»: «Specimen»,
//должны быть перечислены все параметры Specimen },
«request»: {
«method»: «POST»,
«url»: «Specimen»
}
},
{
«fullUrl»: «urn:uuid:f0ceca14-6847-4ea4-b128-7c86820da555»,
//GUID ресурса в Bundle, который используется для связи ресурсов внутри Bundle «resource»: {
«resourceType»: «Encounter»,
//должны быть перечислены все параметры Encounter },
«request»: {
«method»: «POST»,
«url»: «Encounter»
}
},
{
«fullUrl»: «urn:uuid:64d57862-f2c2-41ef-a5cf-27f2d5356555»,
//GUID ресурса в Bundle, который используется для связи ресурсов внутри Bundle «resource»: {
«resourceType»: «Condition»,
//должны быть перечислены все параметры Condition },
«request»: {
«method»: «POST»,
«url»: «Condition»
}
},
{
«fullUrl»: «urn:uuid:651f0cdc-2e7f-4e3a-99b1-da68d2b196c3»,
//GUID ресурса в Bundle, который используется для связи ресурсов внутри Bundle «resource»: {
«resourceType»: «Observation»,
//должны быть перечислены все параметры Observation },
«request»: {
«method»: «POST»,
«url»: «Observation»
}
},
{
«fullUrl»: «urn:uuid:116e99dc-2d39-4da0-8ca3-eda8844a6555»,
//GUID ресурса в Bundle, который используется для связи ресурсов внутри Bundle «resource»: {
«resourceType»: «Practitioner»,
//должны быть перечислены все параметры Practitioner },
«request»: {
«method»: «POST»,
«url»: «Practitioner»
}
},
{
«fullUrl»: «urn:uuid:2c98670c-3494-4c63-bb29-71acd486da1d»,
//GUID ресурса в Bundle, который используется для связи ресурсов внутри Bundle «resource»: {
«resourceType»: «DiagnosticOrder»,
//должны быть перечислены все параметры DiagnosticOrder },
«request»: {
«method»: «POST»,
«url»: «DiagnosticOrder»
}
},
{
«fullUrl»: «urn:uuid:6aee3e4e-6d66-4818-a9d3-96959f47cc04»,
//GUID ресурса в Bundle, который используется для связи ресурсов внутри Bundle «resource»: {
«resourceType»: «Order»,
//должны быть перечислены все параметры Order
},
«request»: {
«method»: «POST»,
«url»: «Order»
}
}
]
}
В Bundle заявки входят следующие ресурсы:
- Order
Ресурс Order предназначен для передачи общей информации о заявке. Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
Таблица 7. Параметры Order
|
№ п/п |
Параметр | Тип |
Кратность |
Описание |
|
1 |
identifier | Identifier |
1..1 |
Идентификатор заявки в МИС |
| 1.1 | identifier.system | uri | 1..1 | В качестве кодовой системы указывается OID передающей системы |
| 1.2 | identifier.value | string | 1..1 | Идентификатор заявки в МИС. Должен быть уникален для данной МО |
| 1.3 | identifier.assigner | Reference (Organization) | 1..1 | Ссылка. Соотнесение с кодом МО (или отделения). Должна указываться ссылка на существующую в БД Organization |
| 1.4 | identifier.use | code | 0..1 | Признак первичного / повторного направления. usual – первично secondary – повторно. Если параметр отсутствует, направление первичное |
| 2 | date | dateTime | 1..1 | Дата заявки (yyyy-MM-ddTHH:mm:sszzz) |
| 3 | subject | Reference (Patient) | 1..1 | Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient |
| 4 | source | Reference (Practitioner) | 1..1 | Ссылка. Соотнесение с автором заявки. Должен передаваться ресурс Practitioner в Bundle или указывается ссылка на существующий Practitioner |
| 5 | target | Reference (Organization) | 1..1 | Ссылка. Соотнесение с целевой лабораторией. Должна указываться ссылка на существующую в БД Organization |
| 6 | when | BackboneElement | 1..1 | Сведения о приоритете выполнения |
| 6.1 | when.code | CodeableConcept | 1..1 |
Приоритет выполнения (отметка срочности):
|
| 7 | detail | Reference (DiagnosticOrder) | 1..* | Ссылка. Соотнесение с клинической частью (DiagnosticOrder). Должен передаваться ресурс DiagnosticOrder в Bundle |
- Patient
Ресурс Patient предназначен для передачи информации о пациенте.
Перечень параметров и их описание представлены в разделе «Передача пациента».
- Practitioner
Ресурс Practitioner предназначен для передачи информации о враче. В этом ресурсе указывается:
- Врач, сделавший назначение;
- Врач-автор заявки.
Перечень параметров и их описание представлены в разделе «Передача врача».
- Encounter
Ресурс Encounter предназначен для передачи информации о случае обслуживания и ссылок на диагнозы пациента. Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
Таблица 8. Параметры Encounter
|
№ п/п |
Параметр | Тип |
Кратность |
Описание |
| 1. | identifier | Identifier | 1…1 | Идентификатор случая обслуживания в МИС и детальная информация по карте пациента |
| 1.1. | identifier.system | uri | 1…1 | Пространство имён идентификатора — указывается OID передающей системы |
| 1.2. | identifier.value | string | 1…1 | Идентификатор случая обслуживания в МИС |
| 1.3. | identifier.type | string | 1…1 | |
| 1.4. | identifier.period.start | string | 1…1 |
Тип карты (обязателен для ВИМИС):
сервисе Терминологии, • В параметре code указывается код значения из справочника |
| 1.4. | identifier.assigner.reference | datetime | 1…1 | Дата создания карты (обязательно для ВИМИС) |
| 1.5. | identifier.assigner.reference | string | 1…1 |
Ссылка на организацию, в которой открыта карта, в формате Organization/GUID, где GUID – идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64 (обязательно для ВИМИС) |
| 1.6. | identifier.assigner.display | string | 1…1 | Номер карты пациента (обязательно для ВИМИС) |
| 2. | Period | Period | 0..1 |
Дата начала и окончания случая (yyyy-MM-ddTHH:mm:sszzz). В параметре start указывается дата начала случая (должна быть указана), в параметре end указывается дата окончания случая (может быть не указана) |
| 3. | status | code | 1..1 |
Статус случая обслуживания (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.43) Передается in-progress для открытого случая обслуживания. Finished для закрытого (завершенного) случая обслуживания. |
| 4. | class | code | 1..1 |
Класс случая обслуживания (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.44). Передается в соответствии с Классификатором условий оказания медицинской помощи (UslMp) V006 ФФОМС РФ Стационарно — inpatient В дневном стационаре — outpatient Амбулаторно – ambulatory Вне медицинской организации – field |
| 5. | type | CodeableConcept | 1..* |
Тип случая обслуживания (региональный справочник типов случая обслуживания):
сервисе Терминологии (1.2.643.2.69.1.1.1.35),
сервисе Терминологии,
Дополнительно могут передаваться данные: характеристики случая обслуживания по справочникам ТФОМС, участок, по которому осуществляется обслуживание, код контингента, код вида поступления. Передача дополнительных данных (обязательность, используемые справочники) определяется на уровне региона. |
| 6. | patient | reference (Patient) | 1..1 |
Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient |
| 7. | reason | CodeableConcept | 0..1 | Ссылка. Соотнесение с пациентом. Должен передаваться |
| 8. | indication | Reference (Condition) | 1..* | Ссылка. Соотнесение с диагнозами пациента. Должен передаваться ресурс Condition в Bundle |
| 9. | serviceProvider | Reference (Organization) | 1..1 | Ссылка. Соотнесение с кодом МО (или отделения). Должна указываться ссылка на существующую в БД Organization |
- DiagnosticOrder
Ресурс DiagnosticOrder предназначен для передачи информации о назначении и об источнике финансирования, ссылки на биоматериал, случай обслуживания, и ссылок на состояние пациента.
Список услуг, передаваемых в конкретном DiagnosticOrder, должен быть логически обоснован (например, набор параметров биохимического анализа крови). Не допускается передавать в одном DiagnosticOrder услуги по разнородным исследованиям (например, клинику крови и мочи). В DiagnosticOrder указываются ссылки на те биоматериалы, из которых предполагается выполнение услуг, указанных в этом DiagnosticOrder.
Список используемых параметров и их описание приведены в таблице ниже.
Параметры, которые не используются в информационном обмене, в таблице не указаны.
Таблица 9. Параметры DiagnosticOrder
|
№ п/п |
Параметр | Тип |
Кратность |
Описание |
| 1. | Identifier | Identifier | 0..1 | Идентификатор исследования в МИС |
| 1.1. | identifier.system | uri | 1..1 |
В качестве кодовой системы указывается OID передающей системы |
| 1.2. | identifier.value | string | 1..1 | Идентификатор исследования в МИС. Должен быть уникален для данной МО |
| 1.3. | identifier.assigner | Reference (Organization) | 1..1 | Ссылка. Соотнесение с кодом МО (или отделения). Должна указываться ссылка на существующую в БД Organization |
| 2. | subject | Reference (Patient) | 1..1 | Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient |
| 3 | orderer | Reference (Practitioner) | 1..1 | Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Practitioner в Bundle или указывается ссылка на существующий Practitioner |
| 4 | encounter | Reference (Encounter) | 1..1 | Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Encounterв Bundle или указывается ссылка на существующий Encounter |
| 5 | reason | CodeableConcept | 0..1 |
Основание для направления на исследование:
Все параметры обязательны для передачи (1..1) |
| 6. | supportingInformation | Reference (Observation / Condition) | 0..* |
Ссылка. Соотнесение с описанием состояния пациента (неделя беременности, рост, вес, признак менопаузы и тп). Должен передаваться ресурс Observation/ Condition в Bundle Ссылка на печатную форму направления или иной документ в формате PDF, CDA и др., разрешенный в настройках сервиса. Должен передаваться ресурс Binary в Bundle (см. описание Binary результата) |
| 7. | specimen | Reference (specimen) | 0..* | Ссылка. Соотнесение с биоматериалом. Должен передаваться ресурс Specimen в Bundle |
| 8. | status | code | 1..1 |
Статус DiagnosticOrder (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.42). Всегда должен передаваться requested |
| 9. | item | BackboneElement | 1..* | Состав заявки |
| 9.1. | item.code | CodeableConcept | 1..1 | Сведения о запрашиваемой услуге |
| 9.1.1. | item.code.coding | CodeableConcept | 1..1 |
Код услуги заявки (Номенклатура медицинских услуг):
|
| 9.1.2. |
item.code.extension |
CodeableConcept | 1..1 |
Источник финансирования:
|
| 10. | note | Annotation | 0..1 | Примечание к заявке |
- Specimen
Ресурс Specimen предназначен для передачи информации о забранном биоматериале. Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
Таблица 10. Параметры Specimen
|
№ п/п |
Параметр |
Тип |
Кратно сть |
Описание |
|
1. |
identifier |
identifier |
0..1 |
Номер флакона (только для гистологических исследований). В параметре system указывается GUID направившего учреждения, в параметре value значение. Оба параметра обязательные |
|
2. |
collection |
Backbon eElement |
0..1 |
Сведения о биоматериале |
|
2.1. |
collection.comment |
string |
0..1 |
Комментарий к биоматериалу, в т.ч. комментарии о сохранности упаковки для гистологических препаратов, макроскопическое описание для цитологических препаратов |
|
2.2. |
collection.collectedD ateTime |
dateTime |
0..1 |
Дата-время сбора биоматериала (yyyy-MMddTHH:mm:sszzz) |
|
2.3. |
collection.method |
Codeable Concept |
0..1 |
Способ получения биоматериала: • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.99.2.33 для гистологических исследований, 1.2.643.2.69.1.1.1.152 для цитологических исследований), • В параметре version указывается версия справочника в сервисе Терминологии, В параметре code указывается код значения из справочника |
|
2.4. |
collection.bodySite |
Codeable Concept |
0..* |
Место забора биоматериала (локализация): • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.102 или 1.2.643.5.1.13.13.11.1477 в зависимости от настроек), • В параметре version указывается версия справочника в сервисе Терминологии, В параметре code указывается код значения из справочника |
|
2.5. |
collection.quantity |
SimpleQ uantity |
0..1 |
Количество образцов биоматериала для гистологических исследований, объем биоматериала для лабораторных и цитологических исследований. В параметре value указывается количество, в параметре code Код единицы измерения по справочнику 1.2.643.5.1.13.13.11.1358. Оба параметра обязательные |
|
3. |
container |
Backbon eElement |
0..1 |
Сведения о контейнере с биоматериалом (клиника, микробиология) Сведения о гистологических блоках (гистология) |
|
3.1. |
container.identifier |
Identifier |
0..1 |
Штрих-код контейнера с биоматериалом |
|
3.1.1. |
container.identifier.s ystem |
uri |
1..1 |
В качестве кодовой системы указывается код лаборатории |
|
3.1.2. |
container.identifier.v alue |
string |
1..1 |
Штрих-код. Должен быть уникален на протяжении как минимум срока жизни образца, рекомендуется – на протяжении как минимум трех месяцев. Штрихкод может содержать только цифры и буквы латинского алфавита, символы — _ . /. Не может содержать пробелы и спецсимволы. |
|
3.2. |
container.type |
Codeable Concept |
0..1 |
Тип контейнера: • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.34), • В параметре version указывается версия справочника в сервисе Терминологии, • В параметре code указывается код значения из справочника |
|
3.3. |
container.additiveCo deableConcept |
Codeable Concept |
0..1 |
Справочник реактивов и загрязнений в контейнере: • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.99), • В параметре version указывается версия справочника в сервисе Терминологии, В параметре code указывается код значения из справочника |
|
4. |
type |
Codeable Concept |
1..1 |
Тип биоматериала (характер патологического процесса для гистологических исследований): • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1081, для гистологических исследований 1.2.643.5.1.13.13.99.2.34), • В параметре version указывается версия справочника в сервисе Терминологии, • В параметре code указывается код значения из справочника |
|
5. |
receivedTime |
dateTime |
0..1 |
Дата-время поступления биоматериала в лабораторию (yyyy-MM-ddTHH:mm:sszzz) |
|
6. |
accessionIdentifier |
Identifier |
0..1 |
Идентификатор биоматериала, присвоенный лабораторией |
|
6.1. |
accessionIdentifier.sy stem |
uri |
1..1 |
В качестве кодовой системы указывается код лаборатории |
|
6.2. |
accessionIdentifier.va lue |
string |
1..1 |
Идентификатор биоматериала. |
|
7. |
subject |
Referenc e (Patient) |
1..1 |
Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient |
|
8. |
Extension |
Element
|
0..3 усл. |
Для передачи специализированной информации о биоматериале для гистологического исследования. |
|
8.1. |
extension.url |
uri |
|
Всегда указывается ссылка «https://www.hl7.org/fhir/extension-specimenspecialhandling.html» |
|
8.2. |
extension. valueCodeableConce pt |
Codeable Concept |
|
Информация передается в параметре coding. Вложенные параметры: • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.97), • В параметре version указывается версия справочника в сервисе Терминологии, • В параметре code указывается код значения из справочника: 1 — если биоматериал помещен в 10% раствор формалина, 2 — если биоматериал загрязнен, 3 – если упаковка биоматериала нарушена. В заявке может передаваться только code 1, в результате code 1-3. Если информации нет, Extension не передается. |
- Observation
Ресурс Observation предназначен для передачи информации о состоянии пациента. В этом ресурсе может указываться рост (в сантиметрах) и вес (в килограммах) пациента, неделя беременности, день цикла, а также передаваться дополнительная информация для направления на гистологическое исследование или для формирования СМС ВИМИС.
Список используемых параметров и их описание приведены в таблице ниже.
Параметры, которые не используются в информационном обмене, в таблице не указаны.
Таблица 11. Параметры Observation
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1. |
code |
CodeableCo ncept |
1..1 |
Указание типа Observation: • В параметре system указывается OID справочника в сервисе Терминологии, • В параметре version указывается версия справочника в сервисе Терминологии, • В параметре code указывается код значения из справочника Основной используемый справочник — 1.2.643.2.69.1.1.1.37, для передачи дополнительных параметров заявки ВИМИС может также использоваться справочник 1.2.643.2.69.1.1.1.127 |
|
2. |
status |
code |
1..1 |
Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.47). Всегда передается статус final |
|
3. |
valueQuantity или valueString |
Quantity или String |
1..1 |
Основные параметры: Количественные показатели передаются как valueQuantity. Вложенные параметры: value — значение, code – код единицы измерения по справочнику 1.2.643.5.1.13.13.11.1358. Оба параметра обязательны. Текстовые значения передаются как valueString Дополнительные параметры ВИМИС: могут передаваться показатели следующих типов: valueString, valueQuantity, valueCodeableConcept, valueDateTime, valueBoolean Тип valueCodeableConcept должен содержать вложенные параметры: в параметре system указывается OID справочника в сервисе Терминологии, version — указывается версия справочника, code — указывается код значения из справочника. Все параметры обязательные. |
Содержание ресурса Observation определяется по значению параметров system и code.
Список основных используемых параметров, передаваемых по справочнику 1.2.643.2.69.1.1.1.37, и их описание приведены в таблице ниже.
Таблица 12. Параметры Observation
|
№ п/п |
Значение параметра code |
Назначение ресурса |
Тип значения |
Единица измерения |
|
4. |
1 |
Рост пациента |
Quantity |
см |
|
5. |
2 |
Вес пациента |
Quantity |
кг |
|
6. |
3 |
Неделя беременности |
Quantity |
неделя |
|
7. |
4 |
День цикла |
Quantity |
день |
|
8. |
5 |
Задача исследования |
String |
нет |
|
9. |
6 |
Дополнительные клинические сведения |
String |
нет |
|
10. |
7 |
Результаты предыдущих исследований |
String |
нет |
|
11. |
8 |
Проведенное лечение |
String |
нет |
Использование параметров уточняется в организации, ответственной за передачу СМС ВИМИС и предоставляется данной организацией в виде таблицы, определяющей код значения из справочника, передаваемый параметр, тип, способ и обязательность заполнения данного параметра для определенного СМС.
Ресурс Condition предназначен для передачи информации о состоянии пациента. Содержание ресурса Condition определяется по значению параметра category:
- Для диагноза category = diagnosis.
- Для даты начала последней менструации category = symptom
- Для признака менопаузы category = finding.
Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене в таблице не указаны.
Таблица 13. Параметры Condition
|
№ п/п |
Параметр |
Тип |
Кратно сть |
Описание |
|
1. |
patient |
Referenc e (Patient) |
1..1 |
Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient |
|
2. |
category |
Codeable Concept |
1..1 |
Указание типа ресурса (диагноз или признака менопаузы): • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.36), • В параметре version указывается версия справочника в сервисе Терминологии, • В параметре code указывается код значения из справочника |
|
3. |
dateRecorde d |
date |
0..1 |
Дата установления диагноза или признака менопаузы, дата начала последней менструации |
|
4. |
code |
Codeable Concept |
1..1 |
Для диагноза указывается: • В параметре system указывается OID справочника МКБ-10 в сервисе Терминологии , • В параметре version указывается версия справочника в сервисе Терминологии, • В параметре code указывается код значения согласно МКБ-10 • В параметре display указывается клиническая формулировка диагноза (параметр не обязательный) Для даты начала последней менструации и признака менопаузы указывается: • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.39), • В параметре version указывается версия справочника в сервисе Терминологии, • В параметре code указывается код значения из справочника |
|
5. |
extension |
Codeable Concept |
0..1 |
Код вида нозологической единицы диагноза (указывается, если передается не основной диагноз): • В параметре url указывается OID расширения (http://api.n3med.ru/api/fhir/n3extensionnosologicalunitsofdiagnosis) • В параметре valueCodeableConcept.system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1077), • В параметре valueCodeableConcept.version указывается версия справочника в сервисе Терминологии, • В параметре valueCodeableConcept.code указывается код значения из справочника • В параметре valueCodeableConcept.display указывается текстовое представление значения |
|
6. |
clinicalStatus |
code |
0..1 |
Характер заболевания (справочник FHIR). Передается «active» для острого, «relapse» для обострения хронического, «remission» для хронического не в обострении |
|
7. |
verificationS tatus |
code |
1..1 |
Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.62). Передается «provisional» для предварительного диагноза, «confirmed» для окончательного |
|
8. |
notes |
string |
0..1 |
Комментарии |
4.5.6. Обновление биоматериала (PUT Specimen)
В случае, если в сервис сначала передается заявка, а затем передается информация по биоматериалу, в подсистеме ДЛИ должна быть возможность обновить информацию о биоматериале. В этом случае заявка изначально передается без детальной информации о биоматериале (в бандле заявки передается ресурс Specimen, в котором заполняется только параметры Specimen.subject.reference и Specimen.type). После забора биоматериала ранее переданный ресурс Specimen обновляется на основании фактических данных биоматериала (дата забора, штрих-код, контейнер). Обновление ресурса разрешено только отправителям данного ресурса.
При обновлении биоматериала в качестве адреса указывается URL в формате [base]/ Specimen/[GUID]?_format=json. GUID биоматериала в URL должен соответствовать id, указанному в запросе. В ответе сервис возвращает json с обновленным биоматериалом и его идентификатором в сервисе ДЛИ.
Параметры ресурса Specimen приведены в таблице выше.
4.5.7. Запрос заявки ($getorder)
Получение информации о конкретной заявке может осуществляться двумя способами: с помощью GET запроса ресурса Order по GUID или с помощью дополнительной операции (Custom Operation) getorder (POST).
При поиске заявки по второму способу используется POST запрос, в качестве адреса указывается URL в формате [base]/$getorder?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с массивом Order, найденных в сервисе ДЛИ.
Внутри полученных с помощью данного запроса массива ресурсов имеются ссылки на другие ресурсы. Информация по ним запрашивается с помощью функционала получения ресурса по GUID (GET с указанием ссылки на запрашиваемый ресурс), для чего запрашивающая система должна выполнить соответствующие запросы. Структура этих запросов описана в разделе «Запрос ресурсов»
Входные параметры операции getorder приведены в таблице ниже.
Таблица 14. Параметры операции $getorder
|
№ п/п |
Имя параметра |
Описание |
Кратность |
Тип |
|
1. |
SourceCode |
GUID направившей организации, подразделения по справочнику 1.2.643.2.69.1.1.1.64 |
0..1 |
string |
|
2. |
TargetCode |
GUID целевой организации, подразделения (КДЛ) по справочнику 1.2.643.2.69.1.1.1.64 |
1..1 |
string |
|
3. |
Barcode |
Штрих-код контейнера с биоматериалом* |
0..1 (обязателен Barcode или OrderMisID) |
string |
|
4. |
OrderMisID |
Идентификатор заявки в МИС |
string |
|
|
5. |
StartDate |
Диапазон поиска (начало). Если время не указано, поиск идет с 00:00:00 |
0..1 |
dateTime (yyyy-MMddTHH:mm:sszzz) |
|
6. |
EndDate |
Диапазон поиска (конец). Если время не указано, поиск идет по 23:59:59 |
0..1 |
dateTime (yyyy-MMddTHH:mm:sszzz) |
Выходным параметром является JSON вида {«resourceType»:»Parameters», «parameter»:[Х]}, где Х – это массив ресурсов Order, удовлетворяющих условиям запроса.
* Штрихкод может содержать только цифры и буквы латинского алфавита. Не может содержать пробелы и любые другие символы. Допускается перечисление нескольких штрихкодов в поле Barcode через запятую – в этом случае поиск будет вестись по всем перечисленным штрихкодам.
Под датой в данном методе подразумевается дата записи заявки в БД ДЛИ (служебное поле).
4.5.8. Запрос заявок ($getorders)
Получение информации о массиве заявок осуществляется с помощью дополнительной операции (Custom Operation) getorders (POST).
При поиске заявки используется POST запрос, в качестве адреса указывается URL в формате [base]/$getorders?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с массивом Order, найденных в сервисе ДЛИ.
Внутри полученных с помощью данного запроса массива ресурсов имеются ссылки на другие ресурсы. Информация по ним запрашивается с помощью функционала получения ресурса по GUID (GET с указанием ссылки на запрашиваемый ресурс), для чего запрашивающая система должна выполнить соответствующие запросы. Структура этих запросов описана в разделе «Запрос ресурсов»
Описание параметров
Входные параметры операции getorders приведены в таблице ниже.
Таблица 15. Параметры операции $getorders
|
№ п/п |
Имя параметра |
Описание |
Кратность |
Тип |
|
1. |
SourceCode |
GUID направившей организации, подразделения по справочнику 1.2.643.2.69.1.1.1.64 |
0..1 |
string |
|
2. |
TargetCode |
GUID целевой организации, подразделения (КДЛ) по справочнику 1.2.643.2.69.1.1.1.64 |
1..1 |
string |
|
3. |
StartDate |
Диапазон поиска (начало). Если время не указано, поиск идет с 00:00:00 |
1..1 |
dateTime (yyyy-MMddTHH:mm:sszzz) |
|
4. |
EndDate |
Диапазон поиска (конец). Если время не указано, поиск идет по 23:59:59 |
0..1 |
dateTime (yyyy-MMddTHH:mm:sszzz) |
Выходным параметром является JSON вида {«resourceType»:»Parameters», «parameter»:[Х]}, где Х – это массив ресурсов Order, удовлетворяющих условиям запроса.
Под датой в данном методе подразумевается дата записи заявки в БД ДЛИ (служебное поле).
4.5.9. Передача результата (POST Bundle результата)
Для передачи результата должен использоваться Bundle типа транзакция. В Bundle должна передаваться следующая информация:
- Ответ на заявку.
- Общие сведения о результате (идентификатор, дата и т.п.).
- Информация о пациенте
- Информация о враче, выполнившем исследование и утвердившем результат.
- Результаты тестов
- Сведения об использованном оборудовании
- Печатная форма протокола исследования в формате PDF
Структура Bundle
Bundle используется для передачи набора ресурсов. Для каждого из ресурсов Bundle должна указываться операция (POST, PUT). Перечень ресурсов и их описание представлено в таблице ниже.
Таблица 16. Описание ресурсов, входящих в состав Bundle
|
№ п/п |
Ресурс |
Ссылки на другие ресурсы |
Описание |
|
1. |
OrderRespon se |
• OrderResponse.request – ссылка на Order, • OrderResponse.fulfillment – ссылка на DiagnosticReport, • OrderResponse.who – ссылка на Organization |
В ресурсе указывается общая информация о результате, идентификатор заказа в ЛИС и дата результата, а также: • ссылка на заявку, • ссылка на результат, • ссылка на организацию, подразделение в формате Organization/GUID, где GUID – идентификатор организации, подразделения по справочнику 1.2.643.2.69.1.1.1.64 |
|
2. |
DiagnosticRe port |
• DiagnosticReport.subject – ссылка на Patient, • DiagnosticReport.performer– ссылка на Practitioner, • DiagnosticReport.request – ссылка на DiagnosticOrder, • DiagnosticReport.result – ссылка на Observation, • DiagnosticReport.presentedFor m.url – ссылка на Binary • DiagnosticReport.encounter – ссылка на Encounter • DiagnosticReport.specimen – ссылка на Specimen |
В ресурсе указывается следующая информация: • ссылка на пациента, • ссылка на врача, утвердившего результат, • ссылка на назначение, • ссылка на результат теста, • ссылка на протокол (PDF-документ) • ссылка на случай обслуживания (должна передаваться для корректной работы сервиса СЭМД) • ссылка на биоматериал (должна передаваться для корректной работы сервиса СЭМД) |
|
3. |
Observation |
• Observation.performer – ссылка на Practitioner • Observation.device – ссылка на Device • Observation.related.target – ссылка на ресурс Observation |
В ресурсе указывается следующая информация: • результат теста, • ссылка на врача, выполнившего тест • прибор исследования. |
|
4. |
Device |
• Device.owner – ссылка на Organization |
В ресурсе указывается информация о приборе исследования, которое использовалось для генерации наблюдения. |
|
5. |
Practitioner |
• managingorganisation – ссылка на Organization |
В ресурсе указывается информация о враче: для передачи данных о врачах, выполнивших исследование и утвердивших результат. |
|
6. |
Binary |
|
В ресурсе передается протокол исследования (PDF-документ) и (при необходимости) открепленная УКЭП для данного документа |
Схема структуры Bundle приведена на рисунке ниже.