Сервис интеграционной платформы N3 «Подсистемы Управление потоками» обеспечивает механизмы взаимодействия и обмена медицинскими данными между различными информационными системами, обслуживающими процесс передачи сведений о заявках в рамках конкретной бизнес-логики.
Ниже представлено описание регламента работы с сервисом. В состав описания включены схемы процессов, описание используемых технологий, методов, входных и выходных данных.
Описание решения
Описание процесса обмена данными о заявках
Подсистема УП предназначена для обмена информацией по заявкам в рамках указанного процесса. Для разных типов заявок МО может выступать как в роли направляющей МО, так и в роли целевой (консультирующей) МО.
Процесс обмена данными о заявках в рамках типового решения, реализуемый в УП, поддерживает выполнение следующих действий:
- Получение маршрутов прохождения заявок и описания операций, в рамках которых доступно право создавать заявки.
- Создание заявки по выбранному маршруту.
- Получение списка заявок, которые имеют операции доступные данному получателю.
- Получение списка заявок в статусах, которые доступны для просмотра и действия.
- Получение сведений заявки по её идентификатору.
- Получение набора данных (объекта контекста) собранного при работе с заявкой.
- Получение перечня переходов (операций), которые доступных в текущем состоянии заявки.
- Получение условий перехода (выполнения операций) к новому состоянию (статусу) заявки.
- Получение схемы данных (объекта контекста), необходимого для осуществления перехода к новому состоянию (статусу) заявки.
- Запрос перехода заявки в новое состояние согласно указанному правилу перехода.
УП предоставляет возможность реализации различных сценариев работы с заявками. Сценарии зависят от набора операций, доступных для заявки в рамках указанного процесса. Под операциями понимаются различные действия над заявкой, такие как распределение заявки врачу-консультанту, возврат заявки запрашивающему врачу на дополнение, отказ в консультации по заявке, дополнение заявки сведениями, формирование заключения по заявке и т.д.
Описание базового сценария обмена
Подсистема Управление потоками предназначена для получения, ведения, хранения, поиска и выдачи сведений о заявках согласно контексту бизнес-процесса.
Обмен данными между МИС МО и подсистемой Управление потоками осуществляется в результате выполнения шагов следующего базового сценария:
- Получить из подсистемы список маршрутов и операций, доступных для создания и продвижения заявки.
- Получить из системы по выбранному маршруту описания условий перехода к новому состоянию заявки.
- На основе полученных данных выполнить запрос схем передачи данных, необходимых для осуществления операции создания заявки: формат структуры данных передаваемых в заявку, используемых при описании характеристик пользователя.
- Создать заявку по указанному маршруту.
- Запросить список заявок, доступных для осуществления операций согласно их текущему состоянию. МИС МО запрашивает наличие заявок у подсистемы Управление потоками для последующих действий.
- Получить из системы контекст по заявке для принятия решения о последующем действии. МИС МО запрашивает объект контекста с содержанием заявки по ее идентификатору.
- Выполнить запрос на изменение заявки для перевода её в следующее состояние в рамках указанного процесса. Передача информации из МИС МО в подсистему УП об изменении состояния заявки и переходе к новому статусу. Выполнение производится до тех пор, пока заявка не будет приведена к конечному состоянию.
- Запросить список заявок доступных для просмотра. МИС МО запрашивает список заявок у подсистемы УП для просмотра изменений по заявкам.
- Получить из системы контекст по закрытой заявке для получения консультативного заключения.
Описание протокола взаимодействия
Общая информация о сервисе
В качестве протокола взаимодействия используется RESTful API. Данные необходимо передавать в формате JSON, должен присутствовать http заголовок content-type: application/json.
Информационный обмен может осуществляется в соответствии со стандартом FHIR® (Fast Healthcare Interoperability Resources), разработанным организацией HL7. Требуемая версия FHIR R4, 4.0.0. Подробное описание стандарта — http://hl7.org/FHIR/. Использование REST- протокола в FHIR® – см. http://FHIR-ru.github.io/http.html.
Использование справочников
Справочники, используемые в сервисе, опубликованы в «Сервисе Терминологии». Описание сервиса Терминологии и правила взаимодействия с ним приведены по ссылке: http://api.netrika.ru/docs.php?article=Terminology.
Для каждого использованного в обмене справочника в схеме данных указан OID (объектный идентификатор).
Параметры схемы, указывающие на значения справочников, представляются в следующей виде:
Раскрыть
{
"type": "string",
"title": "<Текстовое значение параметра>",
"description": "<Инструкции по заполнению с указанием источника - oid справочника>"
}
Роли пользователей передаются согласно справочнику НСИ: 1.2.643.5.1.13.2.1.1.734
Медицинские организации передаются согласно справочнику НСИ: 1.2.643.2.69.1.1.1.64
Полный перечень используемых сервисом справочников перечислен в описании параметров объектов.
Внутренняя логика сервиса
Описание данных
Структуры данных, которыми системы обмениваются в ходе работы с заявками, описываются с помощью json-схем. Идентификаторы схем содержатся в описании операций (переходов между статусами) над заявками.
Предметная область – сущность, объединяющая под собой описания данных и маршруты бизнес-процессов.
Общий набор данных - json-схема, описывающая все возможные поля и структуры данных, используемых в документообороте. Схемы, описанные ниже, должны быть сконструированы на основе общего набора данных. Это обеспечивает автоматизацию сбора, поиска и агрегации данных. Хранится одна схема на предметную область.
Метаданные маршрутов бизнес-процессов - json-схема описывающая краткий набор ключевых характеристик маршрута бизнес процесса в рамках предметной области. Позволяет выводить контекстную информацию о маршрутах в списке, строить по маршрутам форму фильтрации. Заявки также можно фильтровать по метаданным маршрутов. Хранится одна схема на предметную область.
Метаданные заявок - json-схема, описывающая краткий набор ключевых характеристик заявки. Позволяет выводить контекстную информацию о заявках в списке, строить по заявкам форму фильтрации. Хранится одна схема на предметную область.
Данные, используемые при операциях с заявками - json-схема, описывающая набор и структуру данных необходимых для передачи со стороны пользователя при совершении операции с заявкой. Можно создать в рамках предметной области столько, сколько требуется.
Роли - json-схема, описывающая набор и структуру данных необходимых для передачи информации о пользователе при проверке доступа к функциям системы. Можно создать в рамках предметной области столько, сколько требуется. Пользователь может на входе передавать несколько наборов присвоенных ему ролей. Например, пользователь может быть одновременно врачом в одной организации и административным руководителем в другой. Соответственно заявки и маршруты ему будут подбираться с учетом обеих его ролей.
Маршрут и его описание
Маршрут - описание порядка выполнения операций в ходе исполнения работ по заявкам.
Рисунок 2 Схема состояний и операций над заявкой
Маршрут описывается с помощью названия, описания и структуры метаданных. Суть маршрута заключается в наборе состояний и операций с заявками.
Состояния или статусы (1, 2, 3 на рисунке) - это контрольные точки в бизнес-процессе. Они создаются в рамках маршрута с указанием имени и правил доступа. Правило доступа описывает, какому пользователю может быть доступна заявка для просмотра в данном статусе.
Переходы (а, б, в, г, д, е на рисунке) - это операции над заявкой по данному маршруту.
Если стартовое состояние перехода не указано (а, б на рисунке), то он используется для создания заявки в том статусе, который указан как конечный. Операций создания заявки по маршруту может быть сколько угодно с любой логикой. Например, можно настроить создание заявки со статусом доступным исполнителю. Можно создать заявку в статусе “черновик”, доступным заявителю.
Если стартовое состояние указано тоже, что и конечное (е на рисунке), то операция не изменит статус заявки. Решает задачу редактирования данных заявки без необходимости изменения статуса.
При указании конечного состояния отличного от стартового - заявка меняет состояние (в, г, д на рисунке).
Для типового маршрута в подсистеме Управление потоками определен следующий набор состояний заявки:
- Черновик
- Направлено в МО
- Отклонено
- Передано врачу
- В листе ожидания
- Запрашивается дополнительная информация
- Подготовка заключения
- Заключение готово
- Организация консилиума
- Подготовка заключения консилиумом
- Подпись заключения участниками консилиума
- На подписи у председателя консилиума
- Заключение консилиума готово
Каждое из состояний заявки имеет свой уникальный идентификатор в системе.
Переходы и ролевой доступ к просмотру
Содержание правил перехода в рамках маршрута:
- Название операции или перехода.
- Начальное состояние. Не указывается, если операция предназначена для создания заявки.
- Итоговое состояние. Указывается обязательно.
- Набор данных, необходимых для осуществления операции.
- Проверки. Осуществляют проверки доступа к выполнению операции и другую бизнес-логику, необходимую для поддержки бизнес-процесса. Текстовое описание каждой проверки содержится в описаниях операций.
- Отклики. Уведомление внешнего сервиса о факте перехода конкретной заявки в определенный статус. Текстовое описание каждого отклика содержится в описаниях операций.
Для определения ролевого доступа к просмотру и работе с заявками используется «ролевой контекст». Например, для предметной области «Тестовая область» ролевой контекст определён набором json-схем. Основной ролевой схемой для работы пользователей МИС является данная схема:
Раскрыть
{
"type": "object",
"$schema": "http://json-schema.org/draft-04/schema#",
"required": [
"organization",],
"properties": {
"organization": {
"type": "string",
"title": "Организация пользователя",
"examples": [
"Organization/a7ad714e-7c68-4950-ac7d-408bb68e23e9"
],
"description": "Заполняется согласно справочнику НСИ 1.2.643.2.69.1.1.1.64"
},
"SNILS": {
"type": "string",
"title": "СНИЛС",
"examples": [
"89322342342"
],
"description": "СНИЛС сотрудника заполняется без пробелов и тире"
}
}
}
Пример ролевого контекста согласно данной схеме:
Раскрыть
"roleContext": {
"5ff16ba7-9edd-41a4-bd06-2ee33cfd4597": {
"organization": "910bbc2e-e8c3-489d-aee4-5810797b212b",
"SNILS": "11122233344"
}
}
Так же идентификатор схемы ролевого контекста возможно получить при получении сведений о маршруте (getWorkflow) и операции над заявкой (getTransition). Саму схему в последствии можно запросить методом «getSchema».
"5ff16ba7-9edd-41a4-bd06-2ee33cfd4597" – в примере ролевого контекста должно являться идентификатором ролевой схемы соответствующей настройкам доступа на маршруте, смотрите приложение к регламенту.
Описание методов
Состав методов сервиса
Функциональность подсистемы Управление потоками обеспечивается следующими методами:
- Получение списка переходов доступных для создания заявки (GetAvailableTransitions)
- Получение маршрута обработки заявки по идентификатору (GetWorkflow)
- Получение схемы данных передаваемых при осуществлении перехода (GetSchema)
- Создание заявки (POST StartNewProcess)
- Редактирование/обновление заявки (POST MoveToStage)
- Получение списка доступных для действия заявок (POST //GetTransitionAvailableProcesses)
- Получение списка доступных для просмотра заявок (POST //GetReadAvailableProcesses)
- Получение описания правил перехода по его идентификатору (GetTransition)
- Получение объекта контекста заявки (POST //GetProcessContext)
- Передача файла вложения заявки (POST //api/Commands/xds)
- Вызов метода преобразования контекста заявки processContext (/api/debug/convertSimpleJsonToFHIRJson?FHIRType=QuestionnaireResponse) и сохранение результата.
- Вызов метода преобразования ролевого контекста roleContext (/api/debug/convertSimpleJsonToFHIRJson?FHIRType=Parameters) и сохранение результата.
- Описание метода создания заявки по стандарту FHIR (POST //api/FHIR/StartNewProcess)
- Описание метода редактирования/обновления заявки по стандарту FHIR (POST //api/FHIR/MoveToStage)
- Описание метода получения объекта контекста заявки по стандарту FHIR (POST //api/FHIR/ProcessContext)
Структура данных заявки
В методах сервиса для передачи набора данных заявки используется параметр типа «Object» - processContext.
В обмене для структуры данных о заявке используется несколько объектов. Перечень объектов и описание их назначения представлено в таблице ниже.
Данные в параметре типа «Object» - processContext могут быть описаны в формате стандарту FHIR.
Таблица 2 Описание объектов, входящих в состав типовой заявки
|
№ п/п |
Объект |
Назначение объекта по бизнес-логике |
Описание |
|
1 |
patient |
Пациент |
В объекте указывается информация о пациенте. |
|
2 |
requesterPractitioner |
Врач направляющей МО |
В объекте указывается информация о медицинском специалисте направляющей МО |
|
3 |
serviceRequest |
Параметры заявки |
В объекте указывается информация об общих параметрах заявки |
|
4 |
requesterCondition |
Состояние пациента от направляющей МО |
В объекте указывается информация о состоянии пациента со стороны направляющей МО |
|
5 |
diagnosticResults |
Результаты диагностических исследований |
В объекте указывается информация о результатах диагностических исследований пациента со стороны направляющей МО |
|
6 |
medication |
Лекарственные препараты |
В объекте указывается информация о принимаемых пациентом лекарственных препаратах |
|
7 |
observation |
Объективные данные осмотра |
В объекте указывается информация о состоянии пациента, объективные данные о состоянии пациента при осмотре |
|
8 |
attachedfiles |
Прикрепленные файлы |
В объекте указывается информация о прикрепленных файлах, в том числе откреплённых подписях к файлам |
|
9 |
communication |
Комментарий при отказе обработки заявки |
В объекте указывается информация комментарии при отказе обработки заявки |
|
10 |
appointment |
Бронирование времени обслуживания |
В объекте указывается информация о времени (фактическом, желаемом) обработки заявки |
|
11 |
performerPractitioner |
Врач целевой МО |
В объекте указывается информация о медицинском специалисте целевой МО, отвечающем за консультацию |
|
12 |
performerCondition |
Диагноз |
В объекте указывается информация об анамнезе и диагнозах установленных при осмотре пациента со стороны целевой МО. |
|
13 |
diagnosticReport |
Заключение |
В объекте указывается информация о параметрах заключения целевой организации |
|
14 |
presentedForm |
Консультативное заключение |
В объекте указывается информация о ссылке на файлы документа и подписи документа заключения |
|
15 |
council |
Состав консилиума |
В объекте указывается информация о составе консилиума и председателе консилиума |
Структура метаданных заявки
Использование метаданных заявок применяется для вывода контекстной информацию о заявках в списке, для построения форм фильтрации по заявкам. Это общая логика для всех заявок вне зависимости от методов работы с заявками.
В приведенном ниже примере описания структуры метаданных заявки описывается набор и структура формируемых параметров заявки и пути их нахождения в её контексте (наборе структурированных данных агрегированных по ходу заявки по маршруту).
Раскрыть
"schema":
{
"type": "object",
"$schema": "http://json-schema.org/draft-04/schema#",
"properties": {
"patient": {
"selector": "$.patient.idMPI"
},
"performer": {
"selector": "$.serviceRequest.performerOrganization"
},
"requester": {
"selector": "$.serviceRequest.requesterOrganization"
},
"resultMedicalCare": {
"selector": "$.serviceRequest.resultMedicalCare"
},
"resultAmbulanceDepartureType": {
"selector": "$.serviceRequest.resultAmbulanceDepartureType"
}
}
}
Пример структуры метаданных конкретной заявки по схеме, приведенной выше:
"metadata":
{
"patient": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3",
"performer": "fc2c38ce-6599-4ff3-ae82-915b91a07db9",
"resultMedicalCare": "5",
"resultAmbulanceDepartureType": "3"
},
- Name - имя процесса или значение человек ориентированного идентификатора (поиск по неполному совпадению).
- Workflow - название маршрута или его идентификатор (точное совпадение).
- Metadata - фильтр по объекту метаданных процесса (правила сопоставления Json-объектов см ниже).
- Created - дата (или период) создания процесса (описание передачи дат см. ниже).
- Updated - дата (или период) обновления процесса (описание передачи дат см. ниже).
Описание принципа сопоставления Json-объектов при использовании в качестве фильтров метаданных маршрута или заявки:
В качестве фильтра принимается Json-объект, в котором путь к искомому значению будет таким же как в объекте, где производится поиск. Например, в метаданных процесса есть следующие данные в формате обмена:
Раскрыть
{
"patientName": "Alexander",
"diagnosis": {
"name": "some name",
"code": 315
},
"participant": {
"name": "Ivan",
"cpecialityCodes": [
103,
203,
304
]
}
}
В таком случае, для доступа к полю "code" в объекте "diagnosis" нужно повторить путь к полю:
Раскрыть
{
"diagnosis": {
"code": 315
}
}
Все выбранные данные в объекте в любом случае будут приведены к строке, и выбор сопоставление производится с помощью SQL-конструкции LIKE (поиск вхождения подстроки). То следующее выражение будет эквивалентно предыдущему:
Раскрыть
{
"diagnosis": {
"code": "315"
}
}
Для выбора нескольких значений, одного и того же поля можно использовать перечисление значений в массиве, однако в таком случае будет использовано полное совпадение:
Раскрыть
{
"diagnosis": {
"code": [
314,
315,
317
]
}
}
В случае, если в объекте фильтра будет несколько полей — итоговое выражение будет собираться с учётом того, что все выражения должны быть истиной.
Раскрыть
{
"patientName": [
"Alex",
"Sam"
],
"diagnosis": {
"name": "some name",
"code": [
314,
315,
317
]
}
}
Передача дат фильтрации:
Для передачи периода дат ожидается структура, представляющая собой массив дат, сериализованный в JSON:
Раскрыть
"created": [ "2020-12-17T11:58:30+03:00", "2020-12-18T13:58:30+03:00" ] или "updated": [ "2020-12-17T11:58:30+03:00", "2020-12-18T13:58:30+03:00" ]
В случае если в массиве одна дата, будут выбраны все данные, в которых искомая дата будет больше чем, переданная в дата массиве. В случае, если передано больше 2х дат — все кроме первых двух будут проигнорированы.
Параметры сортировки:
Для передачи сортировки необходимо передать имя из ответа в поле запроса orderingField. Поля доступные для передачи «Created», «Updated».
Для сортировки по убыванию в поле запроса descendingOrder нужно передать true.
Получение списка переходов доступных для создания заявки (GetAvailableTransitions)
Метод предоставляет перечень маршрутов и описания операций, в рамках которых возможно создавать заявки.
Описание параметров запроса и ответа
Описание параметров запроса метода в таблице ниже.
Таблица 3 Входные параметры метода POST GetAvailableTransitions
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
roleContext |
object |
1..1 |
Значение ролевого контекста пользователя |
|
2 |
WorkflowFilter |
object |
1..1 |
Значение фильтра (описание принципа работы фильтра в тексте ниже) |
|
3 |
Skip |
number |
0..1 |
Количество пропущенных элементов в выборке |
|
4 |
Take |
number |
0..1 |
Количество элементов в списке |
Фильтр
Объект для фильтрации по маршруту. Все поля являются опциональными (не обязательными). Пример конструкции фильтра:
"WorkflowFilter": {
"name": "",
"metadata": {},
}
-
Name - название маршрута (точное совпадение);
-
Metadata - фильтр по объекту метаданных маршрута (правила сопоставления Json-объектов описаны выше).
Метаданные маршрута описываются по соответствующей схеме и указываются при его создании или редактировании администратором системы.
Описание структуры ответа:
Таблица 4 Выходные параметры метода POST GetAvailableTransitions
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
roleContext |
object |
1..1 |
Значение ролевого контекста пользователя |
|
2 |
WorkflowFilter |
object |
1..1 |
Значение фильтра |
|
3 |
Skip |
number |
0..1 |
Количество пропущенных элементов в выборке |
|
4 |
Take |
number |
0..1 |
Количество элементов в списке |
|
5 |
roleContext |
object |
1..1 |
Значение ролевого контекста пользователя |
Пример запроса
Пример запроса
POST {{url}}/api/Queries/GetAvailableTransitions
authorization: N3[пробел][GUID передающей системы]
content-type: application/json
{
"RoleContext": {},
"WorkflowFilter":
{
"Organization": "dfe3eec2-8a79-4921-9b58-0ce03a5e6c10"
},
"Skip": 0,
"Take": 10 }
Получение маршрута обработки заявки по идентификатору (GetWorkflow)
Метод возвращает данные о статусах и операциях на маршруте по идентификатору. С помощью возвращаемых данных можно узнать все возможные состояния заявки, перечень возможных операций и переходов между статусами, выполняемые проверки при попытках выполнения переходов и условия доступности заявок на каждом из статусов.
Описание параметров запроса и ответа
В таблице ниже представлено описание параметров запроса метода.
Таблица 5 Входные параметры метода GET GetWorkflow
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
workflowId |
String |
1..1 |
Идентификатор маршрута |
Описание структуры ответа
Таблица 6 Выходные параметры метода GET GetWorkflow
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
ErrorCode |
string |
1..1 |
Код результата операции |
|
2 |
Message |
string |
1..1 |
Описание результата операции |
|
3 |
result.Id |
string |
1..1 |
Системный идентификатор маршрута |
|
4 |
result.Name |
string |
1…* |
Название маршрута |
|
5 |
result.Description |
string |
1..1 |
Описание маршрута |
|
6 |
result.IsContruction |
string |
1..1 |
Статус отладки. Если передано True, то маршрут является пилотным |
|
7 |
result.AreaId |
string |
1..1 |
Идентификатор предметной области, в рамках которой существует маршрут |
|
8 |
result.AreaName |
string |
1..1 |
Имя предметной области, в рамках которой существует маршрут |
|
9 |
result.MetadataID |
Array |
0..1 |
Идентификатор метаданных маршрута |
|
10 |
result.Metadata |
object |
0..1 |
Структура метаданных маршрута |
|
11 |
result.Stages |
Array |
0..* |
Статусы |
|
12 |
result.Stages.StageId |
object |
0..1 |
Статус |
|
13 |
result.Stages.StageId.Id |
string |
1..1 |
Идентификатор статуса |
|
14 |
result.Stages.StageId.Name |
string |
1..1 |
Название статуса |
|
15 |
result.Stages.StageId.Description |
string |
0..1 |
Описание статуса |
|
16 |
result.Stages.StageId.Validators |
Array |
0..1 |
Проверки, выполняемые для доступа к данным по заявке, когда она находится в данном статусе |
|
17 |
result.Stages.StageId.Validators.Id |
String |
1..1 |
Идентификатор проверки |
|
18 |
result.Stages.StageId.Validators.Name |
String |
1..1 |
Название проверки |
|
19 |
result.Stages.StageId.IsDisabled |
boolean |
1..1 |
Статус блокировки |
|
20 |
result.Stages.StageId.BusinessStatus |
Object |
0..1 |
Статус согласно справочнику НСИ |
|
21 |
result.Stages.StageId.BusinessStatus.System |
string |
0..1 |
OID справочника статусов |
|
22 |
result.Stages.StageId.BusinessStatus.Code |
string |
0..1 |
Код статуса |
|
23 |
result.Transitions |
Array |
0..1 |
Операции |
|
24 |
result.Transitions.TransitionId |
Object |
1..1 |
Операция (переход) |
|
25 |
result.Transitions.TransitionId.Id |
String |
1..1 |
Идентификатор операции (перехода) |
|
26 |
result.Transitions.TransitionId.Name |
String |
1..1 |
Название операции (перехода) |
|
27 |
result.Transitions.TransitionId.FromStageId |
String |
0..1 |
Идентификатор статуса заявки, в котором можно совершить операцию. Если передаётся «null», то операция используется для создания заявки |
|
28 |
result.Transitions.TransitionId.ToStageId |
String |
1..1 |
Идентификатор статуса заявки, в котором она окажется после осуществления операции (перехода) |
|
29 |
result.Transitions.TransitionId.SchemaId |
String |
0..1 |
Идентификатор схемы данных необходимых для выполнения операции |
|
30 |
result.Transitions.TransitionId.Validators |
Object |
1..* |
Проверки,выполняемые при попытке выполнении операции (перехода) |
|
31 |
result.Transitions.TransitionId.Validators.Id |
String |
1..1 |
Идентификатор проверки |
|
32 |
result.Transitions.TransitionId.Validators.Name |
String |
1..1 |
Описание проверки |
|
33 |
result.Transitions.TransitionId.Callbacks |
Object |
0..* |
Уведомления внешних систем |
|
34 |
result.Transitions.TransitionId.Callbacks.Id |
string |
1..1 |
Идентификатор уведомления |
|
35 |
result.Transitions.TransitionId.Callbacks.Name |
string |
1..1 |
Описание уведомления, которое уходит при успешном выполнении операции (перехода) |
|
36 |
result.IsDisabled |
boolean |
0..1 |
Свойство блокировки маршрута. Если маршрут заблокирован, то по нему будет невозможно создать новую заявку. |
Пример запроса
GET {{url}}/api/Queries/GetWorkflow/[id маршрута]
GET http://[hostname]/api/Queries/GetWorkflow/b3393395-06f7-4261-b403-5dc0dab1296b authorization: N3[пробел][GUID передающей системы]
content-type: application/json
Получение схемы данных передаваемых при осуществлении перехода (GetSchema)
Метод предназначен для получения схемы данных (объекта контекста), необходимого для осуществления перехода к новому состоянию заявки.
Описание параметров запроса и ответа
В таблице ниже представлено описание параметров запроса метода.
Таблица 7 Входные параметры для метода POST GetSchema
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
id |
String |
1..1 |
Идентификатор схемы |
Описание структуры ответа
В описании структур, передаваемых в ответе данных в формате json-схемы, содержится описания типов передаваемых данных, кратности и обязательности. Справочные материалы в обмене данными в заявках используются в рамках справочников НСИ. В случае использования справочника, в описании структуры данных "description" указывается код справочника.
Если в рамках заявки требуется передать информацию о пациенте, зарегистрированном в ГИС, случае ИЭМК, результатах лабораторных или инструментальных исследований, направлении на оказание медицинской помощи, то согласно схеме описания данных для осуществления операции над заявкой потребуется указать идентификаторы данных объектов из соответствующих сервисов: Индекс пациента, ИЭМК, ОДЛИ, ОДИИ, УО.
Пример запроса
GET {{url}}/api/Commands/GetSchema/[id схемы]
GET http://[hostname]/api/Queries/GetSchema/e57a49c0-717c-4d25-a045-114157567088
authorization: N3[пробел][GUID передающей системы]
content-type: application/json
Создание заявки (POST StartNewProcess)
Для создания заявки в сервисе используется метод POST StartNewProcess. Метод создаёт заявку по маршруту согласно переданному переходу.
Описание параметров запроса
В таблице ниже представлено описание параметров запроса метода.
Таблица 8 Входные параметры для метода POST StartNewProcess
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
workflowId |
String |
1..1 |
Идентификатор маршрута |
|
2 |
name |
String |
1..1 |
Название заявки |
|
3 |
initialTransitionId |
String |
1..1 |
Идентификатор перехода для создания заявки |
|
4 |
processContext |
Object |
1..1 |
Набор данных (структура, смотреть в контрольных примерах) |
|
5 |
roleContext |
Object |
1..1 |
Значение ролевого контекста пользователя |
Пример запроса
POST {{url}}/api/Commands/StartNewProcess
{
"workflowId": "b3393395-06f7-4261-b403-5dc0dab1296b",
"name": "Моя заявка",
"initialTransitionId": "e9b2cce6-93ec-4118-8728-1580af7b9e82",
"processContext": { <структура, смотреть в контрольных примерах> },
"roleContext": {}
}
Редактирование/обновление заявки (POST MoveToStage)
Для редактирования или обновления данных заявки в сервисе используется метод POST MoveToStage. В базовом назначении метод позволяет осуществить запрос перехода заявки в новое состояние согласно указанному правилу перехода. Далее представлены варианты использования запроса метода при которых происходит переход заявки в новое состояние.
Помимо редактирования заявки, запрос метода используется для обновления состояния заявки в любых других операциях доступных по заявке.
Описание параметров запроса
В таблице ниже представлено описание параметров запроса метода.
Таблица 9 Входные параметры для метода POST MoveToStage
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
processId |
String |
1..1 |
Идентификатор заявки |
|
2 |
transitionId |
String |
1..1 |
Идентификатор перехода |
|
3 |
processContext |
Object |
1..1 |
Набор данных (структура, смотреть в контрольных примерах) |
|
4 |
roleContext |
Object |
1..1 |
Значение ролевого контекста пользователя |
Пример запроса
POST {{url}}/api/Commands/MoveToStage
{
"processId": "b26c9527-c67b-4702-a525-df20a0645d23",
"transitionId": "6545013e-c9bc-4e35-b466-802769a394bc",
"processContext":{<структура, смотреть в контрольных примерах>},
"roleContext": {}
}
Получение списка доступных для действия заявок (POST //GetTransitionAvailableProcesses)
Для получения списка доступных для действия заявок в сервисе используется метод POST GetTransitionAvailableProcesses. Метод предназначен для получения списка заявок в статусах, которые имеют операции доступные для использования данному пользователю.
Описание параметров запроса
В таблице ниже представлено описание параметров запроса метода.
Таблица 10 Входные параметры для метода фильтрации
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
roleContext |
String |
1..1 |
Значение ролевого контекста пользователя. RoleContext – фильтрует заявки по правилам доступа. В результате отображаются все заявки, где нет ограничений по ролевому доступу (значение RoleContext игнорируется) и заявки где проверки данных ролевого контекста в текущем статусе позволяют пользователю выполнить операцию (значение RoleContext проверяются). |
|
2 |
workflowFilter |
Object |
0...1 |
Параметры фильтра по схеме описания метаданных маршрута. WorkflowFilter – фильтр заявок по атрибутам и метаданным маршрутов (workflows) по которым они движутся. Атрибуты и метаданные маршрута присваиваются ему при создании или редактировании администратором системы по соответствующей схеме (см. метод получения схем данных). • Name - название маршрута (Строка, точное совпадение) • Metadata - фильтр по объекту метаданных маршрута (Структура, правила сопоставления Json-объектов см. ниже под таблицей) |
|
3 |
processFilter |
Object |
0...1 |
Параметры фильтра по схеме описания метаданных заявки. ProcessFilter – фильтр заявок непосредственно по атрибутам и матаданным самой заявки. Атрибуты заявки присваиваются ей при создании и обновлении. Метаданные заявки генерируются при создании и каждом обновлении по соответствующей схеме (см. метод получения схем данных). |
|
4 |
StageFilter
|
Array |
0...1 |
Фильтр по идентификаторам текущих статусов заявок |
|
5 |
orderingField
|
String |
0...1 |
Поле сортировки |
|
6 |
descendingOrder
|
Boolean |
0...1 |
Направление сортировки |
|
7 |
Skip |
Number |
0..1 |
Количество пропущенных элементов в выборке |
|
5 |
Take |
Number |
0..1 |
Количество элементов в списке |
Подробное описание и примеры структуры схем метаданных для последующего использования в методах фильтрации заявок представлено в пункте 5.3.
Таблица 11 Выходные параметры для метода фильтрации
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
ErrorCode |
String |
1..1 |
Код результата операции |
|
2 |
Message |
String |
1..1 |
Описание результата операции |
|
3 |
Result.TransitionIds |
Array |
1..1 |
Идентификаторы переходов |
|
4 |
result.ProcessId |
String |
1..1 |
Системный идентификатор заявки |
|
5 |
result.ProcessHumanFriendlyId |
String |
1…* |
Человекоориентированный идентификатор заявки |
|
6 |
result.Metadata |
Object |
1..1 |
Метаданные маршрута |
|
7 |
result.CurrentStage |
String |
1..1 |
Текущий статус заявки |
|
8 |
result.WorkflowId |
String |
1..1 |
Идентификатор маршрута |
|
9 |
result.WorkflowName |
String |
1..1 |
Название маршрута |
|
10 |
result.ProcessName |
String |
1..1 |
Название заявки |
|
11 |
result.BusinessStatus |
Object |
0..1 |
Статус заявки |
|
12 |
result.BusinessStatus. System |
String |
0..1 |
Ссылка на справочник НСИ 1.2.643.2.69.1.1.1.148.2 |
|
13 |
result.BusinessStatus. Code |
string |
0..1 |
Код значения статуса. Код справочника НСИ |
Пример запроса
POST {{url}}/api/Queries/GetTransitionAvailableProcesses
{
"RoleContext": {
"5ff16ba7-9edd-41a4-bd06-2ee33cfd4597": {
"Role": "DEPCHIEF",
"Organization": "931a9317-586c-4dd5-bc32-cd8d3af78903"
}
},
"WorkflowFilter": {},
"ProcessFilter": {
"workflow": "b3393395-06f7-4261-b403-5dc0dab1296b",
"metadata": {
"resultMedicalCare": [
"3",
"5"
],
"resultAmbulanceDepartureType": [
"3",
"1"
]
},
"updated": [],
"created": [
"2020-12-17T11:58:30+03:00",
"2020-12-18T13:58:30+03:00"
]
},
"orderingField": "updated",
"descendingOrder": false,
"BusinessStatusCodes": [
"2"
],
"StageFilter": [],
"Skip": 0,
"Take": 10
}
Пример ответа
{
"result": {
"result": [
{
"transitionIds": [
"6545013e-c9bc-4e35-b466-802769a394bc",
"959450aa-a67d-45e7-b2ba-2f682959c12d"
],
"processId": "3c9b3659-b2b3-424a-ab87-cfde37f1196e",
"processHumanFriendlyId": "TMC122043OOX5",
"metadata": {
"patient": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3",
"performer": "fc2c38ce-6599-4ff3-ae82-915b91a07db9",
"resultMedicalCare": "5",
"resultAmbulanceDepartureType": "3"
},
"currentStageId": "d41a2f57-6c06-4f38-9982-ea1fc7730d01",
"currentStage": "Черновик",
"workflowId": "b3393395-06f7-4261-b403-5dc0dab1296b",
"workflowName": "Подсистемы Управление потоками_бп",
"processName": "Новая заявка ",
"created": "2020-12-17T13:33:18.966651+03:00",
"updated": "2020-12-17T13:33:18.966651+03:00",
"businessStatus": {
"system": "urn:oid:1.2.643.2.69.1.1.1.148.2",
"code": "2"
}
},
{
"transitionIds": [
"6545013e-c9bc-4e35-b466-802769a394bc",
"959450aa-a67d-45e7-b2ba-2f682959c12d"
],
"processId": "2806edea-0c7f-4f4f-9c01-faa4761eb286",
"processHumanFriendlyId": "TMC12200L75IN",
"metadata": {
"patient": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3",
"performer": "fc2c38ce-6599-4ff3-ae82-915b91a07db9",
"resultMedicalCare": "5",
"resultAmbulanceDepartureType": "3"
},
"currentStageId": "d41a2f57-6c06-4f38-9982-ea1fc7730d01",
"currentStage": "Черновик",
"workflowId": "b3393395-06f7-4261-b403-5dc0dab1296b",
"workflowName": "Подсистемы Управление потоками_бп",
"processName": "Новая заявка ",
"created": "2020-12-17T15:33:08.284762+03:00",
"updated": "2020-12-17T15:33:08.284762+03:00",
"businessStatus": {
"system": "urn:oid:1.2.643.2.69.1.1.1.148.2",
"code": "2"
}
},
{
"transitionIds": [
"6545013e-c9bc-4e35-b466-802769a394bc",
"959450aa-a67d-45e7-b2ba-2f682959c12d"
],
"processId": "5a6120a1-ceee-48c2-bd5c-a0c3cc83c980",
"processHumanFriendlyId": "TMC122094XD5X",
"metadata": {
"patient": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3",
"performer": "fc2c38ce-6599-4ff3-ae82-915b91a07db9",
"resultMedicalCare": "5",
"resultAmbulanceDepartureType": "3"
},
"currentStageId": "d41a2f57-6c06-4f38-9982-ea1fc7730d01",
"currentStage": "Черновик",
"workflowId": "b3393395-06f7-4261-b403-5dc0dab1296b",
"workflowName": "Подсистемы Управление потоками_бп",
"processName": "Новая заявка ",
"created": "2020-12-18T11:17:04.438225+03:00",
"updated": "2020-12-18T11:17:04.438225+03:00",
"businessStatus": {
"system": "urn:oid:1.2.643.2.69.1.1.1.148.2",
"code": "2"
}
},
{
"transitionIds": [
"6545013e-c9bc-4e35-b466-802769a394bc",
"959450aa-a67d-45e7-b2ba-2f682959c12d"
],
"processId": "e90d54af-c1e8-4127-bb4f-f573d7d3353d",
"processHumanFriendlyId": "TMC1220926SYY",
"metadata": {
"patient": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3",
"performer": "fc2c38ce-6599-4ff3-ae82-915b91a07db9",
"resultMedicalCare": "5",
"resultAmbulanceDepartureType": "3"
},
"currentStageId": "d41a2f57-6c06-4f38-9982-ea1fc7730d01",
"currentStage": "Черновик",
"workflowId": "b3393395-06f7-4261-b403-5dc0dab1296b",
"workflowName": "Подсистемы Управление потоками_бп",
"processName": "Новая заявка ",
"created": "2020-12-18T11:17:12.202303+03:00",
"updated": "2020-12-18T11:17:12.202303+03:00",
"businessStatus": {
"system": "urn:oid:1.2.643.2.69.1.1.1.148.2",
"code": "2"
}
},
{
"transitionIds": [
"6545013e-c9bc-4e35-b466-802769a394bc",
"959450aa-a67d-45e7-b2ba-2f682959c12d"
],
"processId": "4bf133a0-549f-4e28-b0e1-3a44c9b0bbde",
"processHumanFriendlyId": "TMC122052YL1B",
"metadata": {
"patient": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3",
"performer": "fc2c38ce-6599-4ff3-ae82-915b91a07db9",
"resultMedicalCare": "3",
"resultAmbulanceDepartureType": "3"
},
"currentStageId": "d41a2f57-6c06-4f38-9982-ea1fc7730d01",
"currentStage": "Черновик",
"workflowId": "b3393395-06f7-4261-b403-5dc0dab1296b",
"workflowName": "Подсистемы Управление потоками_бп",
"processName": "Новая заявка ",
"created": "2020-12-18T11:58:30.200089+03:00",
"updated": "2020-12-18T11:58:30.200089+03:00",
"businessStatus": {
"system": "urn:oid:1.2.643.2.69.1.1.1.148.2",
"code": "2"
}
},
{
"transitionIds": [
"6545013e-c9bc-4e35-b466-802769a394bc",
"959450aa-a67d-45e7-b2ba-2f682959c12d"
],
"processId": "727523ee-059e-40bf-a396-abcff9160287",
"processHumanFriendlyId": "TMC122055BU7D",
"metadata": {
"patient": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3",
"performer": "fc2c38ce-6599-4ff3-ae82-915b91a07db9",
"requester": "931a9317-586c-4dd5-bc32-cd8d3af78903",
"resultMedicalCare": "3",
"resultAmbulanceDepartureType": "3"
},
"currentStageId": "d41a2f57-6c06-4f38-9982-ea1fc7730d01",
"currentStage": "Черновик",
"workflowId": "b3393395-06f7-4261-b403-5dc0dab1296b",
"workflowName": "Подсистемы Управление потоками_бп",
"processName": "Новая заявка ",
"created": "2020-12-18T12:23:30.272053+03:00",
"updated": "2020-12-18T12:23:30.272053+03:00",
"businessStatus": {
"system": "urn:oid:1.2.643.2.69.1.1.1.148.2",
"code": "2"
}
}
],
"total": 6
},
"success": true,
"errorCode": 0,
"message": null,
"stackTrace": null
}
Получение списка доступных для просмотра заявок (POST //GetReadAvailableProcesses)
Для получения списка доступных для просмотра заявок в сервисе используется метод POST GetReadAvailableProcesses. Метод предназначен для получения списка заявок в статусах, которые доступны данному пользователю для просмотра и действия.
Описание параметров запроса
В таблице ниже представлено описание параметров запроса метода.
Таблица 12 Входные параметры для метода фильтрации
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
roleContext |
Object |
1..1 |
Значение ролевого контекста пользователя. RoleContext – фильтрует заявки по правилам доступа. В результате отображаются все заявки, где нет ограничений по ролевому доступу (значение RoleContext игнорируется) и заявки где проверки данных ролевого контекста в текущем статусе позволяют пользователю выполнить операцию (значение RoleContext проверяются). |
|
2 |
WorkflowFilter |
Object |
0...1 |
Параметры фильтра по схеме описания метаданных маршрута. WorkflowFilter – фильтр заявок по атрибутам и метаданным маршрутов (workflows) по которым они движутся. Атрибуты и метаданные маршрута присваиваются ему при создании или редактировании администратором системы по соответствующей схеме (см. метод получения схем данных). • Name - название маршрута (Строка, точное совпадение) • Metadata - фильтр по объекту метаданных маршрута (Структура, правила сопоставления Json-объектов см. ниже) |
|
3 |
ProcessFilter |
Object |
0...1 |
Параметры фильтра по схеме описания метаданных заявки. ProcessFilter – фильтр заявок непосредственно по атрибутам и матаданным самой заявки. Атрибуты заявки присваиваются ей при создании и обновлении. Метаданные заявки генерируются при создании и каждом обновлении по соответствующей схеме (см. метод получения схем данных). |
|
4 |
StageFilter |
Array |
0...1 |
Фильтр по идентификаторам текущих статусов заявок |
|
5 |
orderingField |
String |
0...1 |
Поле сортировки |
|
6 |
descendingOrder |
Boolean |
0...1 |
Направление сортировки. Для сортировки по убыванию в поле запроса descendingOrder нужно передать true. |
|
7 |
Skip |
Number |
0..1 |
Количество пропущенных элементов в выборке |
|
8 |
Take |
Number |
0..1 |
Количество элементов в списке |
Пример запроса
POST {{url}}/api/Queries/GetReadAvailableProcesses
{
"RoleContext": {
"5ff16ba7-9edd-41a4-bd06-2ee33cfd4597": {
"Role": "DEPCHIEF",
"Organization": "931a9317-586c-4dd5-bc32-cd8d3af78903"
}
},
"WorkflowFilter": {},
"ProcessFilter": {
"workflow": "b3393395-06f7-4261-b403-5dc0dab1296b",
"metadata": {
"resultMedicalCare": [
"3",
"5"
],
"resultAmbulanceDepartureType": [
"3",
"1"
]
},
"updated": [],
"created": [
"2020-12-17T11:58:30+03:00",
"2020-12-18T13:58:30+03:00"
]
},
"orderingField": "updated",
"descendingOrder": false,
"BusinessStatusCodes": [
"2"
],
"StageFilter": [],
"Skip": 0,
"Take": 10
}
Получение описания правил перехода по его идентификатору (GetTransition)
Метод возвращает описание условий перехода к новому состоянию заявки.
Описание параметров запроса и ответа
В таблице ниже представлено описание параметров запроса метода.
Таблица 13 Входные параметры для метода POST GetTransition
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
2 |
Id |
String |
1..1 |
Идентификатор перехода |
Описание структуры ответа
Таблица 14 Выходные параметры для метода POST GetTransition
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
ErrorCode |
string |
1..1 |
Код результата операции |
|
2 |
Message |
string |
1..1 |
Описание результата операции |
|
4 |
string |
1..1 |
Идентификатор перехода |
|
|
5 |
Result.Name |
string |
1..1 |
Название перехода |
|
6 |
Result.fromStageId |
string |
1..1 |
Стартовый статус |
|
7 |
Result.toStageId |
string |
1..1 |
Итоговый статус |
|
8 |
Result.schemaId |
string |
1..1 |
Идентификатор схемы данных необходимых для осуществления перехода |
Пример запроса
GET {{url}}/api/Queries/GetTransition/[id перехода]
GET http://[hostname]/api/Queries/GetTransition/e9b2cce6-93ec-4118-8728-1580af7b9e82
authorization: N3[пробел][GUID передающей системы]
content-type: application/json
Получение объекта контекста заявки (POST //GetProcessContext)
Для получения объекта контекста заявки в сервисе используется метод POST GetProcessContext. Метод предназначен для получения набора данных (объекта контекста), собранного при работе с заявкой.
Описание параметров запроса
В таблице ниже представлено описание параметров запроса метода.
Таблица 15 Входные параметры для метода POST GetProcessContext
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
RoleContext |
Object |
1..1 |
Структуры ролевого контекста согласно схемам предметной области |
|
2 |
ProcessId |
String |
1..1 |
Идентификатор процесса () |
Пример запроса
POST {{url}}/api/Queries/GetProcessContext
{
"RoleContext": {
"5ff16ba7-9edd-41a4-bd06-2ee33cfd4597": {
"Role": "DEPCHIEF",
"Organization": "931a9317-586c-4dd5-bc32-cd8d3af78903"
}
},
"ProcessId": "64f88f61-7747-402c-9e04-d93eaadc234f"
}
Редактирование маршрута (POST //UpdateProcess)
Для редактирования маршрута в сервисе используется метод POST UpdateProcess. Метод предназначен для внесения изменений в наименование маршрута.
Описание параметров запроса
В таблице ниже представлено описание параметров запроса метода.
Таблица 16 Входные параметры для метода POST UpdateProcess
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
ProcessId |
String |
1..1 |
Идентификатор процесса () |
|
2 |
Name |
String |
1..1 |
Наименование процесса |
Пример запроса
POST {{url}}/api/Commands/UpdateProcess
{
"ProcessId": "d7d7d4ae-a012-468c-b625-7fc4acb1e49a",
"Name": "Новая заявка"
}
Организация обмена файлами. Компонент XDS
Компонент XDS предназначен для распределенного хранения данных, поступающих в функциональные сервисы платформы N3. Компонент представляет собой REST-сервис и представляет собой сайт IIS. Компонент распространяется как самостоятельный компонент в виде nuget-пакета вида N3.XDS.0.1.0-unstable0030.nupkg.
В текущем решении реализованы следующие методы:
- Регистрация документа в XDS.
- Получение документа из XDS.
Передача файла вложения заявки (POST //api/Commands/xds)
Для передачи объекта файла вложения, прикрепленного к заявке (регистрация данных) в сервисе XDS используется метод POST {{url}}/api/Commands/xds, позволяющий загрузить файл и в результате получить ссылку (идентификатор) загруженного в ответ. Метод предназначен для отправки файлов, прикрепленных к заявке (например, результатов выполненных исследований).
Описание параметров запроса
В таблице ниже представлено описание параметров запроса метода.
Таблица 17 Входные параметры для метода POST //api/Commands/xds
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
formFile |
string |
0..1 |
Ссылка на файл, указывается для передачи расположение файла |
Пример запроса
POST {{url}}/api/Commands/xds
{
formFile
}
Получение файла вложения заявки (POST //xds)
Для получения объекта файла вложения, прикрепленного к заявке в сервисе, используется метод POST {{url}}/api/Queries/xds/{fileId}. Метод предназначен для получения файлов, прикрепленных к заявке (например, результатов выполненных исследований), при выполнении следующих условий:
- На входе передается идентификатор заявки, по которой необходимо получить файл, ссылку (идентификатор) на файл, ролевой контекст.
- Система проверяет ролевой контекст для текущего состояния заявки, наличие идентификатора файла в контексте заявки.
Если оба условия удовлетворены, то пользователю предоставляется возможность получить файл
Описание параметров запроса
В таблице ниже представлено описание параметров запроса метода.
Таблица 18 Входные параметры для метода POST //xds
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
fileId |
string |
0..1 |
Идентификатор файла, полученный в ответе при отправке. Идентификатор указывается в контексте заявки. |
|
2 |
RoleContext |
array |
0..1 |
Ролевой контекст для текущего состояния заявки в процессе |
Пример запроса
POST {{url}}/api/Queries/xds/{fileId}
{
"RoleContext": {
"5ff16ba7-9edd-41a4-bd06-2ee33cfd4597": {
"Role": "DEPCHIEF",
"Organization": "931a9317-586c-4dd5-bc32-cd8d3af78903"
}
},
"ProcessId": "b4fa714e-5d81-485a-bb22-16ae2b4ffe2f"
}
Организация поддержки FHIR-стандарта в методах сервиса
Сервис предоставляет возможность обмена данными по стандарту FHIR. С целью упрощения процесса интеграции с сервисом Подсистемы Управление потоками по стандарту FHIR реализовано два метода, позволяющие преобразовывать данные простого формата json к формату FHIR. Методы могут помочь при отладке в процессе интеграции. Использование методов преобразования не обязательно. Приведение к формату FHIR, если его применение предполагает обмен, можно выполнять самостоятельно.
Для конвертации данных в формат стандарта FHIR и обратно предназначены методы:
- /api/debug/convertSimpleJsonToFHIRJson - преобразование из простой структуры в FHIR;
- /api/debug/convertFHIRJsonToSimpleJson - обратное преобразование из FHIR в простую структуру.
Данный стандарт поддерживается для следующих методов обмена данными заявки /api/FHIR/StartNewProcess, /api/FHIR/MoveToStage, /api/FHIR/ProcessContext, /api/FHIR/Process/{processId}.
Общий принцип преобразования
При организации обмена по стандарту FHIR для указанных выше методов работы с заявкой происходит преобразование данных processContext и roleContext к формату ресурсов FHIR questionnaireresponse и parameters соответственно.
Для преобразования в формат FHIR в адресе запроса необходимо указать тип ресурса в формат которого конвертируются данные:
/api/debug/convertSimpleJsonToFHIRJson?FHIRType=QuestionnaireResponse
или
/api/debug/convertSimpleJsonToFHIRJson?FHIRType=Parameters.
При этом в теле запроса передаются данные processContext и roleContext в стандартном формате json.
Сценарий преобразования стандартного json в формат FHIR предполагает следующие шаги:
- Вызов метода преобразования контекста заявки processContext (/api/debug/convertSimpleJsonToFHIRJson?FHIRType=QuestionnaireResponse) и сохранение результата.
- Вызов метода преобразования ролевого контекста roleContext (/api/debug/convertSimpleJsonToFHIRJson?FHIRType=Parameters) и сохранение результата.
- Вызов метода обработки заявки FHIR (например, создания заявки POST /api/FHIR/StartNewProcess) и добавление в тело запроса результатов шагов 1 и 2.
- Получение результата создания заявки по стандарту FHIR.
Примеры полного преобразования тела запроса по созданию заявки в FHIR в тексте ниже.
Структуры данных заявки, ролевого контекста и метаданных приводятся к максимально утилитарному минималистичному формату json. Интерфейс на FHIR генерируется и интерпретируются автоматически. Данные передаваемые клиентскими системами при создании и изменении заявки интерпретируются как формы(анкеты), заполненные пользователем согласно формату ресурса questionnaireresponse стандарта FHIR и параметры пользователя для определения ролевого доступа – формат ресурса parameters стандарта FHIR.
Далее конвертированные результаты для processContext и roleContext можно использовать с методами обработки заявки по FHIR (См. описание в пунктах 5.15.4 - 5.15.8).
Для обратного преобразования предназначен метод /api/debug/convertFHIRJsonToSimpleJson, в теле запроса которого передаются данные processContext и roleContext в формате FHIR. В результате обработки будут получены объекты processContext и roleContext приведенные к простому виду json, которые можно применять со стандартными методами работы с заявкой.
Обработка данных из processContext в FHIR
При конвертации входящих данных из processContext к виду FHIR для методов startNewProcess и moveToStage преобразовываются структуры объекта "resourse", входящего в параметр запроса с именем "processContext" в структуры, которые хранятся физически.
Структура преобразовывается соответственно типам данных ресурса FHIR questionnaireresponse (подробное описание состава ресурса по ссылке http://FHIR-ru.github.io/questionnaireresponse.html).
- "valueString": "<string>" – строки;
- "valueBoolean": <boolean> – булевые;
- "valueInteger": <integer> – числа;
- "item": [{}] - вложенные сложные структуры, массивы, объекты.
Для разделения и преобразования объектов и массивов внутри processContext применяется следующая логика:
- Узел типа "object" и все элементы, которые содержит объект при конвертации приводятся к виду:
{
"linkId": "object",
"answer": [
{
"item": []
}
]
}
Объект FHIR "answer" - может содержать внутри элементы или item или value (), где item - object, value - примитивный тип (string, bool, interger, ...). Если указаны оба варианты, то выводится ошибка. Также, если в объекте FHIR item лежит другой item, это обозначает, что вложенный объект item – массив, все элементы внутри которого будут иметь вид, принятый для данного типа элементов.
- Узел типа "array" и все элементы, которые содержит объект при конвертации приводятся к виду:
{
"linkId": "array",
"item": []
}
Массив может состоять как из примитивных типов, так и из объектов, все элементы внутри которых будут иметь вид, принятый для данного типа элементов.
Например, узел «объект»:
Пример объекта
"patient": {
"patientIdMPI": "019802c4-7e56-4f60-a10b-34ba4b256219",
"patientName": "Гусев Евгений Викторович",
"patientemail": "89128329zxc813@mail.com"
}
Преобразовывается к виду:
Нажмите здесь для раскрытия...
{
"linkId": "patient",
"text": "object",
"item": [
{
"linkId": "patientIdMPI",
"answer": [
{
"valueString": "019802c4-7e56-4f60-a10b-34ba4b256219"
}
]
},
{
"linkId": "patientName",
"answer": [
{
"valueString": "Гусев Евгений Викторович"
}
]
},
{
"linkId": "patientemail",
"answer": [
{
"valueString": "89128329zxc813@mail.com"
}
]
}
]
}
Например, для узла «массив»:
Нажмите здесь для раскрытия...
"files": [
{
"id": "1",
"URL": "ya.ru",
"isDeleted": false
}
]
Преобразовывается к виду:
Пример запроса
{
"linkId": "files",
"item": [
{
"linkId": "0",
"answer": [
{
"item": [
{
"linkId": "id",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "URL",
"answer": [
{
"valueString": "ya.ru"
}
]
},
{
"linkId": "isDeleted",
"answer": [
{
"valueBoolean": false
}
]
}
]
}
]
}
]
}
Элементы массива нумеруются по порядку "linkId": "0", так как узел "linkId" в FHIR является обязательным.
В методах /api/FHIR/StartNewProcess и /api/FHIR/MoveToStage сервис поддерживает и обратное преобразование данных из переданных в по стандарту FHIR к внутреннему формату.
При работе с методом /api/FHIR/ProcessContext так же поддерживается преобразование в обратную сторону из структуры, хранящейся в системе к формату FHIR.
Пример стандартной структуры TMCore:
Нажмите здесь для раскрытия...
{
"patient": {
"idMPI": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3",
"identityDocument": [
{
"id": "1",
"system": "1.2.643.2.69.1.1.1.6.14",
"code": "0003123123"
},
{
"id": "2",
"system": "1.2.643.2.69.1.1.1.6.228",
"code": "7849500830000203"
}
],
"birthDate": "2002-11-14",
"gender": "male",
"social": {
"registration": "1",
"socialStatus": "1"
},
"placeOfWork": "Google",
"address": {
"district": "район",
"city": "город/село",
"line": "ул. Наименование улицы,д.№"
},
"fullName": "Вакуленко Борис Владимирович",
"contact": {
"name": "ФИО вызывавшего",
"telecom": "125-25-25"
}
}
}
Пример структуры FHIR преобразованной по структуре выше:
Нажмите здесь для раскрытия...
{
"resourceType": "QuestionnaireResponse",
"status": "completed",
"item": [
{
"linkId": "patient",
"answer": [
{
"item": [
{
"linkId": "idMPI",
"answer": [
{
"valueString": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3"
}
]
},
{
"linkId": "identityDocument",
"item": [
{
"linkId": "0",
"answer": [
{
"item": [
{
"linkId": "id",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "system",
"answer": [
{
"valueString": "1.2.643.2.69.1.1.1.6.14"
}
]
},
{
"linkId": "code",
"answer": [
{
"valueString": "0003123123"
}
]
}
]
}
]
},
{
"linkId": "1",
"answer": [
{
"item": [
{
"linkId": "id",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "system",
"answer": [
{
"valueString": "1.2.643.2.69.1.1.1.6.228"
}
]
},
{
"linkId": "code",
"answer": [
{
"valueString": "7849500830000203"
}
]
}
]
}
]
}
]
},
{
"linkId": "birthDate",
"answer": [
{
"valueString": "2002-11-14"
}
]
},
{
"linkId": "gender",
"answer": [
{
"valueString": "male"
}
]
},
{
"linkId": "social",
"answer": [
{
"item": [
{
"linkId": "registration",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "socialStatus",
"answer": [
{
"valueString": "1"
}
]
}
]
}
]
},
{
"linkId": "placeOfWork",
"answer": [
{
"valueString": "Google"
}
]
},
{
"linkId": "address",
"answer": [
{
"item": [
{
"linkId": "district",
"answer": [
{
"valueString": "район"
}
]
},
{
"linkId": "city",
"answer": [
{
"valueString": "город/село"
}
]
},
{
"linkId": "line",
"answer": [
{
"valueString": "ул. Наименование улицы,д.№"
}
]
}
]
}
]
},
{
"linkId": "fullName",
"answer": [
{
"valueString": "Вакуленко Борис Владимирович"
}
]
},
{
"linkId": "contact",
"answer": [
{
"item": [
{
"linkId": "name",
"answer": [
{
"valueString": "ФИО вызывавшего"
}
]
},
{
"linkId": "telecom",
"answer": [
{
"valueString": "125-25-25"
}
]
}
]
}
]
}
]
}
]
}
]
}
Обработка данных из roleContext в FHIR
При конвертации входящих данных из roleContext к виду FHIR для методов startNewProcess и moveToStage преобразовываются структуры объекта ролевого контекста в структуры, которые хранятся физически.
Структура преобразовываются в соответствии типов данных ресурса FHIR parameters (подробное описание состава ресурса по ссылке http://FHIR-ru.github.io/parameters.html).
Для разделения и преобразования объектов и массивов внутри roleContext применяется следующая логика:
- Узел типа "object" и все элементы, которые содержит объект при конвертации приводятся к виду:
Нажмите здесь для раскрытия...
{
"name": "object",
"resource": {
"resourceType": "Parameters",
"parameter": [
{
"name": "element",
"valueString": "value"
}
]
}
}
Объект FHIR "parameter" - может содержать внутри и элементы, и значения элементов value (), где value - примитивный тип (string, bool, interger, ...).
- Узел типа "array" и все элементы, которые содержит объект при конвертации приводятся к виду:
Нажмите здесь для раскрытия...
{
"name": "array",
"part": [
{
"name": "0",
"resource": {
"resourceType": "Parameters",
"parameter": [
{
"name": "Role",
"valueString": "DOCTOR"
}
]
}
]
}
Объект FHIR "part" - может содержать внутри объекты, все элементы внутри которых будут иметь вид, принятый для данного типа элементов.
Пример структуры ролевого контекста TMCore:
Нажмите здесь для раскрытия...
"RoleContext": {
"5ff16ba7-9edd-41a4-bd06-2ee33cfd4597": {
"organization": "910bbc2e-e8c3-489d-aee4-5810797b212b",
"SNILS": "11122233344"
}
}
Пример структуры ролевого контекста по FHIR преобразованной из структуры выше:
Нажмите здесь для раскрытия...
{
"resourceType": "Parameters",
"parameter": [
{
"name": "RoleContext",
"resource": {
"resourceType": "Parameters",
"parameter": [
{
"name": "5ff16ba7-9edd-41a4-bd06-2ee33cfd4597",
"resource": {
"resourceType": "Parameters",
"parameter": [
{
"name": "organization",
"valueString": "910bbc2e-e8c3-489d-aee4-5810797b212b"
},
{
"name": "SNILS",
"valueString": "11122233344"
}
]
}
}
]
}
}
]
}
Описание метода создания заявки по стандарту FHIR (POST //api/FHIR/StartNewProcess)
Метод предназначен для создания заявки по стандарту FHIR. В таблице ниже представлено описание параметров запроса метода.
Таблица 19 Входные параметры для метода POST /api/FHIR/StartNewProcess
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
workflowId |
String |
1..1 |
Идентификатор маршрута |
|
2 |
name |
String |
1..1 |
Название заявки |
|
3 |
initialTransitionId |
String |
1..1 |
Идентификатор перехода для создания заявки |
|
4 |
processContext |
Object |
1..1 |
Набор данных (структура, смотреть в контрольных примерах). Может быть получен в результате преобразования данных к формату FHIR |
|
5 |
roleContext |
Object |
1..1 |
Значение ролевого контекста пользователя. Может быть получен в результате преобразования данных к формату FHIR |
Пример формата запроса по стандарту FHIR
Пример запроса
{
"resourceType": "Parameters",
"parameter": [
{
"name": "workflowId",
"valueString": "00000000-0000-0000-0000-000000000000",
},
{
"name": "name",
"valueString": null,
},
{
"name": "initialTransitionId",
"valueString": null,
},
{
"name": "processContext",
"resource": {}
},
{
"name": "roleContext",
"part": "[{}]"
}
]
}
Полный пример запроса представлен в приложении с контрольными примерами.
Описание метода редактирования/обновления заявки по стандарту FHIR (POST //api/FHIR/MoveToStage)
Метод предназначен для редактирования и обновления заявки по маршруту по стандарту FHIR. В таблице ниже представлено описание параметров запроса метода.
Таблица 20 Входные параметры для метода POST /api/FHIR/MoveToStage
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
processId |
String |
1..1 |
Идентификатор заявки |
|
2 |
transitionId |
String |
1..1 |
Идентификатор перехода |
|
3 |
processContext |
Object |
1..1 |
Набор данных (структура, смотреть в контрольных примерах). Может быть получен в результате преобразования данных к формату FHIR |
|
4 |
roleContext |
Object |
1..1 |
Значение ролевого контекста пользователя. Может быть получен в результате преобразования данных к формату FHIR |
Пример формата запроса по стандарту FHIR
Пример запроса
{
"resourceType": "Parameters",
"parameter": [
{
"name": "processId",
"valueString": "00000000-0000-0000-0000-000000000000",
},
{
"name": "transitionId",
"valueString": "00000000-0000-0000-0000-000000000000",
},
{
"name": "processContext",
"resource": {}
},
{
"name": "roleContext",
"part": "{}",
}
]
}
Полный пример запроса представлен в приложении с контрольными примерами.
Описание метода получения объекта контекста заявки по стандарту FHIR (POST //api/FHIR/ProcessContext)
Метод предназначен для получения объекта контекста заявки по стандарту FHIR. В таблице ниже представлено описание параметров запроса метода.
Таблица 21 Входные параметры для метода POST //api/FHIR/ProcessContext
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
RoleContext |
Object |
1..1 |
Структуры ролевого контекста согласно схемам предметной области |
|
2 |
ProcessId |
String |
1..1 |
Идентификатор процесса |
Пример формата запроса по стандарту FHIR
Пример запроса
{
"resourceType": "Parameters",
"parameter": [
{
"name": "processId",
"valueString": "00000000-0000-0000-0000-000000000000",
},
{
"name": "roleContext",
"part": "{}",
}
]}
Полный пример запроса представлен в приложении с контрольными примерами.
Пример полного преобразования тела запроса по созданию заявки в FHIR
Пример запроса
{
"resourceType": "Parameters",
"parameter": [
{
"name": "workflowId",
"valueString": "b3393395-06f7-4261-b403-5dc0dab1296b"
},
{
"name": "name",
"valueUrl": "Sz-process6-FHIR"
},
{
"name": "initialTransitionId",
"valueUrl": "e9b2cce6-93ec-4118-8728-1580af7b9e82"
},
{
"name": "processContext",
"resource": {
"resourceType": "QuestionnaireResponse",
"status": "completed",
"item": [
{
"linkId": "patient",
"answer": [
{
"item": [
{
"linkId": "idMPI",
"answer": [
{
"valueString": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3"
}
]
},
{
"linkId": "identityDocument",
"item": [
{
"linkId": "0",
"answer": [
{
"item": [
{
"linkId": "id",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "system",
"answer": [
{
"valueString": "1.2.643.2.69.1.1.1.6.14"
}
]
},
{
"linkId": "code",
"answer": [
{
"valueString": "0003123123"
}
]
}
]
}
]
},
{
"linkId": "1",
"answer": [
{
"item": [
{
"linkId": "id",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "system",
"answer": [
{
"valueString": "1.2.643.2.69.1.1.1.6.228"
}
]
},
{
"linkId": "code",
"answer": [
{
"valueString": "7849500830000203"
}
]
}
]
}
]
}
]
},
{
"linkId": "birthDate",
"answer": [
{
"valueString": "2002-11-14"
}
]
},
{
"linkId": "gender",
"answer": [
{
"valueString": "male"
}
]
},
{
"linkId": "social",
"answer": [
{
"item": [
{
"linkId": "registration",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "socialStatus",
"answer": [
{
"valueString": "1"
}
]
}
]
}
]
},
{
"linkId": "placeOfWork",
"answer": [
{
"valueString": "Google"
}
]
},
{
"linkId": "address",
"answer": [
{
"item": [
{
"linkId": "district",
"answer": [
{
"valueString": "район"
}
]
},
{
"linkId": "city",
"answer": [
{
"valueString": "город/село"
}
]
},
{
"linkId": "line",
"answer": [
{
"valueString": "ул. Наименование улицы,д.№"
}
]
}
]
}
]
},
{
"linkId": "fullName",
"answer": [
{
"valueString": "Вакуленко Борис Владимирович"
}
]
},
{
"linkId": "contact",
"answer": [
{
"item": [
{
"linkId": "name",
"answer": [
{
"valueString": "ФИО вызывавшего"
}
]
},
{
"linkId": "telecom",
"answer": [
{
"valueString": "125-25-25"
}
]
}
]
}
]
}
]
}
]
},
{
"linkId": "dispatcherRole",
"answer": [
{
"item": [
{
"linkId": "identityDocument",
"answer": [
{
"item": [
{
"linkId": "system",
"answer": [
{
"valueString": "1.2.643.2.69.1.1.1.6.223"
}
]
},
{
"linkId": "code",
"answer": [
{
"valueString": "48835311311"
}
]
}
]
}
]
},
{
"linkId": "dispatcherNumber",
"answer": [
{
"valueString": "АБ-23"
}
]
},
{
"linkId": "organization",
"answer": [
{
"valueString": "931a9317-586c-4dd5-bc32-cd8d3af78903"
}
]
}
]
}
]
},
{
"linkId": "paramedicRole",
"answer": [
{
"item": [
{
"linkId": "identityDocument",
"answer": [
{
"item": [
{
"linkId": "system",
"answer": [
{
"valueString": "1.2.643.2.69.1.1.1.6.223"
}
]
},
{
"linkId": "code",
"answer": [
{
"valueString": "48835311311"
}
]
}
]
}
]
},
{
"linkId": "organization",
"answer": [
{
"valueString": "931a9317-586c-4dd5-bc32-cd8d3af78903"
}
]
}
]
}
]
},
{
"linkId": "seniorParamedicRole",
"answer": [
{
"item": [
{
"linkId": "identityDocument",
"answer": [
{
"item": [
{
"linkId": "system",
"answer": [
{
"valueString": "1.2.643.2.69.1.1.1.6.223"
}
]
},
{
"linkId": "code",
"answer": [
{
"valueString": "48835311311"
}
]
}
]
}
]
},
{
"linkId": "organization",
"answer": [
{
"valueString": "931a9317-586c-4dd5-bc32-cd8d3af78903"
}
]
}
]
}
]
},
{
"linkId": "depChiefRole",
"answer": [
{
"item": [
{
"linkId": "identityDocument",
"answer": [
{
"item": [
{
"linkId": "system",
"answer": [
{
"valueString": "1.2.643.2.69.1.1.1.6.223"
}
]
},
{
"linkId": "code",
"answer": [
{
"valueString": "48835311311"
}
]
}
]
}
]
},
{
"linkId": "organization",
"answer": [
{
"valueString": "931a9317-586c-4dd5-bc32-cd8d3af78903"
}
]
}
]
}
]
},
{
"linkId": "serviceRequest",
"answer": [
{
"item": [
{
"linkId": "reasonCallMedicalCare",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "territoryCode",
"answer": [
{
"valueString": "3"
}
]
},
{
"linkId": "requesterOrganization",
"answer": [
{
"valueString": "931a9317-586c-4dd5-bc32-cd8d3af78903"
}
]
},
{
"linkId": "brigadeNumber",
"answer": [
{
"valueString": "9317"
}
]
},
{
"linkId": "shiftNumber",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "placeCallReceived",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "reasonsBeingLate",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "ambulanceTeam",
"answer": [
{
"valueString": "3"
}
]
},
{
"linkId": "accidentCause",
"answer": [
{
"valueString": "3"
}
]
},
{
"linkId": "intoxication",
"answer": [
{
"valueBoolean": false
}
]
},
{
"linkId": "complaint",
"answer": [
{
"valueString": "жалобы"
}
]
},
{
"linkId": "complicationsExamination",
"answer": [
{
"item": [
{
"linkId": "complications",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "complicationsCodMKB",
"answer": [
{
"valueString": "T78.2"
}
]
},
{
"linkId": "effectivenessMeasures",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "assistanceProvidedLocationCallАmbulance",
"answer": [
{
"valueString": "оказанная помощь"
}
]
},
{
"linkId": "assistanceProvidedАmbulanceCar",
"answer": [
{
"valueString": "оказанная помощь в автомобиле скорой"
}
]
},
{
"linkId": "performanceIndicatorsEvents",
"answer": [
{
"item": [
{
"linkId": "bloodPressure",
"answer": [
{
"valueString": "120/80"
}
]
},
{
"linkId": "pulse",
"answer": [
{
"valueInteger": 60
}
]
},
{
"linkId": "heartRate",
"answer": [
{
"valueInteger": 30
}
]
},
{
"linkId": "respirationRate",
"answer": [
{
"valueInteger": 40
}
]
},
{
"linkId": "bodyHeat",
"answer": [
{
"valueString": "36.6"
}
]
},
{
"linkId": "pulseOximetry",
"answer": [
{
"valueString": "23.3"
}
]
},
{
"linkId": "glucose monitoring",
"answer": [
{
"item": [
{
"linkId": "bloodGlucoseLowerBound",
"answer": [
{
"valueString": "100.54"
}
]
},
{
"linkId": "bloodGlucoseUpperBound",
"answer": [
{
"valueString": "12.34"
}
]
}
]
}
]
}
]
}
]
}
]
}
]
},
{
"linkId": "deliveryMethodToCar",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "resultAmbulanceDepartureType",
"answer": [
{
"valueString": "3"
}
]
},
{
"linkId": "kilometers",
"answer": [
{
"valueString": "километраж"
}
]
},
{
"linkId": "time",
"answer": [
{
"item": [
{
"linkId": "receiveСallDateTime",
"answer": [
{
"valueDateTime": "2010-10-07T13:41:23+04:00"
}
]
},
{
"linkId": "callЕransferDateTime",
"answer": [
{
"valueDateTime": "2010-10-08T13:43:23+04:00"
}
]
},
{
"linkId": "checkoutTime",
"answer": [
{
"valueString": "hh:mm:ss"
}
]
},
{
"linkId": "arrivalTime",
"answer": [
{
"valueString": "hh:mm:ss"
}
]
},
{
"linkId": "startTimeTransportation",
"answer": [
{
"valueString": "hh:mm:ss"
}
]
},
{
"linkId": "arrivalTimeСlinic",
"answer": [
{
"valueString": "hh:mm:ss"
}
]
},
{
"linkId": "endTimeCall",
"answer": [
{
"valueString": "hh:mm:ss"
}
]
},
{
"linkId": "timeReturnToStation",
"answer": [
{
"valueString": "hh:mm:ss"
}
]
},
{
"linkId": "timeTakenComplete",
"answer": [
{
"valueString": "затраченное на вызов время"
}
]
}
]
}
]
},
{
"linkId": "ambulanceCallType",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "resultMedicalCare",
"answer": [
{
"valueString": "5"
}
]
},
{
"linkId": "performerOrganization",
"answer": [
{
"valueString": "fc2c38ce-6599-4ff3-ae82-915b91a07db9"
}
]
},
{
"linkId": "hospitalOrganization",
"answer": [
{
"valueString": "fc2c38ce-6599-4ff3-ae82-915b91a07db9"
}
]
},
{
"linkId": "idIEMK",
"answer": [
{
"valueString": "1110025"
}
]
},
{
"linkId": "consent",
"answer": [
{
"valueBoolean": true
}
]
},
{
"linkId": "comments",
"answer": [
{
"valueString": "доп.текст.инфа"
}
]
}
]
}
]
},
{
"linkId": "observation",
"answer": [
{
"item": [
{
"linkId": "generalCondition",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "behavior",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "consciousness",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "meningealSigns",
"answer": [
{
"valueString": "5"
}
]
},
{
"linkId": "eyes",
"answer": [
{
"item": [
{
"linkId": "pupils",
"answer": [
{
"valueString": "3"
}
]
},
{
"linkId": "anisocoria",
"answer": [
{
"valueString": "4"
}
]
},
{
"linkId": "nystagmus",
"answer": [
{
"valueString": "5"
}
]
},
{
"linkId": "lightResponse",
"answer": [
{
"valueString": "6"
}
]
}
]
}
]
},
{
"linkId": "skin",
"answer": [
{
"item": [
{
"linkId": "integument",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "acrocyanosis",
"answer": [
{
"valueString": "6"
}
]
},
{
"linkId": "marbling",
"answer": [
{
"valueString": "9"
}
]
},
{
"linkId": "edemas",
"answer": [
{
"valueString": "10"
}
]
},
{
"linkId": "localizationOfEdema",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "rash",
"answer": [
{
"valueString": "13"
}
]
},
{
"linkId": "rashLocalization",
"answer": [
{
"valueString": ""
}
]
}
]
}
]
},
{
"linkId": "breathing",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "wheezing",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "shortnessOfBreath",
"answer": [
{
"valueString": "3"
}
]
},
{
"linkId": "organsCirculatorySystem",
"answer": [
{
"item": [
{
"linkId": "heartSounds",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "noise",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "pulseLike",
"answer": [
{
"valueString": "1"
}
]
}
]
}
]
},
{
"linkId": "digestiveOrgans",
"answer": [
{
"item": [
{
"linkId": "tongue",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "belly",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "bellyInActOfBreathing",
"answer": [
{
"valueString": "7"
}
]
},
{
"linkId": "peritonealIrritationSymptoms",
"answer": [
{
"valueString": "8"
}
]
},
{
"linkId": "enlargedLiver",
"answer": [
{
"valueString": "11"
}
]
}
]
}
]
},
{
"linkId": "urination",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "feces",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "otherSymptoms",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "pressure",
"answer": [
{
"item": [
{
"linkId": "workingBloodPressure",
"answer": [
{
"valueString": "120/80"
}
]
},
{
"linkId": "bloodPressure",
"answer": [
{
"valueString": "120/80"
}
]
}
]
}
]
},
{
"linkId": "pulse",
"answer": [
{
"valueInteger": 60
}
]
},
{
"linkId": "heartRate",
"answer": [
{
"valueInteger": 30
}
]
},
{
"linkId": "respirationRate",
"answer": [
{
"valueInteger": 40
}
]
},
{
"linkId": "bodyHeat",
"answer": [
{
"valueString": "36.6"
}
]
},
{
"linkId": "pulseOximetry",
"answer": [
{
"valueString": "23.3"
}
]
},
{
"linkId": "glucose monitoring",
"answer": [
{
"item": [
{
"linkId": "bloodGlucoseLowerBound",
"answer": [
{
"valueString": "100.54"
}
]
},
{
"linkId": "bloodGlucoseUpperBound",
"answer": [
{
"valueString": "12.34"
}
]
}
]
}
]
},
{
"linkId": "additionalObjectiveData",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "ECG",
"answer": [
{
"item": [
{
"linkId": "preMedicalCareECG",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "preMedicalCareECGTime",
"answer": [
{
"valueString": "01:30:00"
}
]
},
{
"linkId": "postMedicalCareECG",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "postMedicalCareECGTime",
"answer": [
{
"valueString": "01:30:00"
}
]
}
]
}
]
}
]
}
]
},
{
"linkId": "condition",
"answer": [
{
"item": [
{
"linkId": "codeMKB",
"answer": [
{
"valueString": "S72.1"
}
]
},
{
"linkId": "complaints",
"answer": [
{
"valueString": "Жалобы"
}
]
},
{
"linkId": "anamnesis",
"answer": [
{
"valueString": "Дополнительные сведения по анамнезу заболевания"
}
]
}
]
}
]
},
{
"linkId": "attachedfiles",
"item": [
{
"linkId": "0",
"answer": [
{
"item": [
{
"linkId": "id",
"answer": [
{
"valueString": "1"
}
]
},
{
"linkId": "fileURL",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "signatureURL",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "isBlocked",
"answer": [
{
"valueBoolean": false
}
]
}
]
}
]
},
{
"linkId": "1",
"answer": [
{
"item": [
{
"linkId": "id",
"answer": [
{
"valueString": "2"
}
]
},
{
"linkId": "fileURL",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "signatureURL",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "isBlocked",
"answer": [
{
"valueBoolean": false
}
]
}
]
}
]
}
]
},
{
"linkId": "110/u",
"answer": [
{
"item": [
{
"linkId": "fileURL",
"answer": [
{
"valueString": ""
}
]
},
{
"linkId": "signatureURL",
"answer": [
{
"valueString": ""
}
]
}
]
}
]
}
]
}
},
{
"name": "RoleContext",
"part": [
{
"name": "0",
"resource": {
"resourceType": "Parameters",
"parameter": [
{
"name": "Role",
"valueInteger": 0
},
{
"name": "Organization",
"valueInteger": 0
}
]
}
}
]
}
]
}
Организация взаимодействия с внешними подсистемами и сервисами
Программный интерфейс подсистемы УП предоставляет возможность организации обмена данными с внешними подсистемами и сервисами, входящими в РЕГИЗ.
Взаимодействие с файловым хранилищем портала Телемедицины
Подсистема УП предоставляет возможность организовать доступ к файловому хранилищу портала Телемедицины для использования в качестве хранилища данных.
Выгрузка файлов
Общий алгоритм работы с файлами:
1) Загрузить файлы в файловое хранилище организации (п.1.1). Доступна загрузка одного файла за раз.
2) В ответе возвращается ссылка на файл в download_url .
3) Ссылка вставляется в ProcessContext в необходимый параметр либо в /api/Commands/StartNewProcess, либо в /api/Commands/MoveToStage.
Конфигурируемые данные
Для отправки файла в хранилище организации следуют сформировать POST-запрос в следующем формате:
Пример:
[base_url]/api/orgs/files?org_id=[org_id]&apikey=[apiKey]&token=[token] form 'file=@/Путь к файлу'
Описание параметров запроса
Описание параметров:
|
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
|
1 |
baseUrl |
string |
1..1 |
Адрес портала, обеспечивающего организацию доступа к мессенджеру |
|
2 |
apiKey |
string |
1..1 |
Региональный ключ к хранилищу |
|
3 |
org_id |
string |
1..1 |
Идентификатор МО согласно справочнику НСИ 1.2.643.2.69.1.1.1.64
|
|
4 |
token |
string |
1..1 |
Токен доступа для работы с подсистемой телемедицинских консультаций |
Пример ответа
Пример
{
"status": "ok",
"org_id": 670,
"org_external_id": "",
"endpoint": "orgs/files",
"name": "Медицинская Организация",
"info": {
"id": 9883,
"file_addr": "./upload/structureitems/670/d359bed08b463d644ea9eaa55c3f7f4b.jpg",
"file_key": "72a3779013bb900a1095696f5fc3bab9",
"description": "",
"title": "mrt-grudnoy-kletki-glav.jpg",
"ts": "1601034056",
"file_secondary_key": "480f687e8ef905ca7fb79b0638980d97",
"user_id": null,
"thread_id": null,
"deleted_at": "0",
"project_id": "0",
"thumbnail_url": "",
"updated_at": "0",
"broken_thumb_status": "0",
"template_signing_required": false,
"fullpath": "/srv/irida/irida.experimental/upload/structureitems/670/d359bed08b463d644ea9eaa55c3f7f4b.jpg",
"info": {
"basename": "d359bed08b463d644ea9eaa55c3f7f4b.jpg",
"extension": "jpg",
"filename": "d359bed08b463d644ea9eaa55c3f7f4b",
"collaborative": 0,
"collaborative_reviews": 0,
"url": "https://irida-vega.ru/experimental/upload/structureitems/670/d359bed08b463d644ea9eaa55c3f7f4b.jpg",
"icon": "https://irida-vega.ru/experimental/assets/images/fileicons/svg/jpg.svg",
"description": "",
"ts": 1601034056,
"fullpath": "./upload/structureitems/670/d359bed08b463d644ea9eaa55c3f7f4b.jpg",
"is_image": 1,
"filesize": 62.9,
"filesize_litera": "Кб",
"absolutePath": "/srv/irida/irida.experimental/upload/structureitems/670/d359bed08b463d644ea9eaa55c3f7f4b.jpg",
"thumburl": "https://irida-vega.ru/experimental/upload/thumbs/9883/d359bed08b463d644ea9eaa55c3f7f4b.jpg",
"gallery_type": "image",
"filesize_mb": 0.1,
"sign": false
},
"history": [],
"download_url": "https://irida-vega.ru/experimental/download?file=9883"
}
}
Использование данных ответа в телемедицинской заявке
В качестве ссылки а файл в телемедицинской заявке следует использовать абсолютный путь до файла, который в ответе лежит по адресу jsonpath: $.info.info.url
- Организация получения чата ВКС
После создания заявки на портале ТМК для нее генерируются чат и комната ВКС. Для получения ссылок необходимо получить токен доступа к порталу. Чтобы не генерировать дополнительные токены для МИС, сервис предоставляет возможность передавать данные с использованием его токена. Для чего реализован метод (проброс через сервис УП) для получения списка ссылок по заявке:
[base_url]/api/flows/process_links?process_id=[process_id]&apikey=[apiKey]
Более подробное описание правил взаимодействия представлено в описании профилей API портала Телемедицины (в том подробности о правилах организации чата и ВКС).
- Конфигурируемые данные
Для организации взаимодействия клиент-системы необходимо хранение конфигурируемых данных, к которым относятся следующие данные, определяемые провайдером:
- адрес портала, обеспечивающего организацию доступа к мессенджеру (baseUrl);
- ключ доступа к методам API (apiKey);
- идентификатор процесса в сервисе «Управление потоками».
Таблица 22 Входные параметры метода
|
№ п/п |
Параметр |
Тип |
Обязательность |
Описание |
|
1 |
baseUrl |
String |
1..1 |
Адрес портала, обеспечивающего организацию доступа к мессенджеру |
|
2 |
apiKey |
String |
1..1 |
Ключ доступа к методам |
|
3 |
process_id |
String |
1..1 |
Идентификатор процесса в сервисе «Сервис управления Маршрутами». Хранится в контексте заявки на портале Телемедицины |
Для получения ссылок на чат/комнату ВКС для каждого участника по заявке клиент-системой необходимо выполнить запросом с бэкэнда с помощью метода “api/flows/process_links” (GET).
- Пример запроса
[base_url]/api/flows/process_links?process_id=[process_id]&apikey=[apiKey]
Взаимодействие с подсистемой СЗПВ
Подсистема СЗПВ предоставляет возможность осуществлять запись на ТМК по схожему алгоритму взаимодействия с подсистемой УО (запись по направлению).
Для организации записи на ТМК в качестве аналога идентификатора направления в УО МИС МО необходимо получить и далее передавать идентификатор processHumanFriendlyId и метаданные заявки, которые формируется при регистрации заявки в подсистеме УП. Указанные данные можно получить с помощью метода
{{url}}/api/Queries/GetProcess/< processId>
где processId – идентификатор созданной заявки в подсистеме УП.
Более подробное описание правил взаимодействия представлено в описании профилей API подсистемы СЗПВ.
Пример запроса
{{url}}/api/Queries/GetProcess/521d041d-274c-47c3-a59c-010b10444225
Пример ответа
{
"result": {
"metadata": {
"id": "b6e53519-3b35-4fab-8740-99345eb719fb",
"processId": "521d041d-274c-47c3-a59c-010b10444225",
"metadata": {
"patient": "8ff30a0b-85c3-462c-aae1-3ec719b3c1a3",
"performer": "fc2c38ce-6599-4ff3-ae82-915b91a07db9",
"requester": "931a9317-586c-4dd5-bc32-cd8d3af78903",
"resultMedicalCare": "5",
"resultAmbulanceDepartureType": "3"
}
},
"id": "521d041d-274c-47c3-a59c-010b10444225",
"name": "Новая заявка. Активы",
"workflowId": "5fb7cefc-b7e0-467c-b79b-43f2859c95dc",
"metadataId": "b6e53519-3b35-4fab-8740-99345eb719fb",
"currentStageId": "617690fd-de03-41d6-b2df-793f765ef537",
"created": "2021-02-15T13:33:51.450247+03:00",
"updated": "2021-02-15T13:33:51.450247+03:00",
"businessStatus": {
"system": "urn:oid:1.2.643.2.69.1.1.1.148.2",
"code": "19"
},
"humanFriendlyId": "TMC0221X7S18Q"
},
"success": true,
"errorCode": 0,
"message": null,
"stackTrace": null
}
Взаимодействие с подсистемой «Индекс пациента» (сервис MPI)
Подсистема «Индекс пациента» предназначен для управления обменом идентификационными данными пациентов с внешними сервисами и системами для обеспечения: регистрации и хранения записей, содержащих идентификаторы субъектов ЭМК (пациентов МО), поддержки связей с внешними, находящимися на уровне медицинских организаций, реестрами идентификаторов пациентов МО, передачу отдельных карточек пациентов и их наборов во внешние системы, инициацию идентификации каждой новой карточки путем создания первичной связи patientlink.
Сервис TMCore предоставляет возможность организации информационного взаимодействия с сервисом MPI.
В программном интерфейсе TMCore для организации обмена данными с MPI поддержаны следующие методы:
- поставка данных пациента в MPI;
- методы поиска карточек: поиск мастер-карточки пациента по документу, поиск всех карточек по идентификатору карточки, Получение карточки пациента по идентификатору записи, получение карточки пациента по ФИО и Дате рождения.
Для передачи данных о пациентах (карточек пациентов) по правилам обмена сервиса MPI используется FHIR-ресурс «Patient».
Таблица 23 Описание параметров ресурса Patient
|
Имя параметра |
Кратность |
Тип данных (FHIR) |
Описание |
|
|
identifier |
1..1 |
где identifier.system = 1.2.643.5.1.13.2.7.100.5 (передающая ИС): |
||
|
value -идентификатор пациента в передающей ИС, должен заполняться автоматически формируемым значением [ТМК+слеш+IdPatientMis], (где IdPatientMis - идентификатор пациента в МИС МО); |
||||
|
+system - должен заполняться константой "urn:oid:1.2.643.5.1.13.2.7.100.5" |
||||
|
assigner.display - должен заполняться константой "urn:oid:1.2.643.2.69.1.2.116" (идентификатор передающей системы N3.Телемедицина по справочнику НСИ 1.2.643.2.69.1.2) |
||||
|
где identifier.system = 1.2.643.5.1.13.2.7.100.7 (первичная МИС МО) |
||||
|
value - идентификатор пациента в первичной системе(МИС МО первичная), должен заполняться идентификатором пациента из МИС МО {IdPatientMis} |
||||
|
system - заполнять константой "urn:oid:1.2.643.5.1.13.2.7.100.7" |
||||
|
assigner.display - заполнять кодом из справочника 1.2.643.2.69.1.2 для МИС МО |
||||
|
|
0..* |
Документы пациента. |
||
|
Для Identifier.system указывается тип документа по справочнику urn:oid:1.2.643.2.69.1.1.1.6 в формате {urn:oid:1.2.643.2.69.1.1.1.6}.{код записи} |
||||
|
name |
1..1 |
Имя, ассоциируемое с пациентом. |
||
|
1. family - Фамилия (кратность 1..1), отчество пациента (кратность 0..1) |
||||
|
gender |
0..1 |
Допустимые коды: |
||
|
male:1 |
||||
|
female:2 |
||||
|
unknown:3 |
||||
|
birthDate |
1..1 |
Дата рождения пациента |
||
|
0..* |
Адрес пациента: |
|||
|
temp = 8 по справочнику 1.2.643.2.69.1.1.1.28 (временный) |
||||
|
home = 2 (фактическое проживание) |
||||
|
work = 4 (служебный) |
||||
|
old = 1, 3, 5, 6, 7, 9 (регистрации, места рождения, почтовый и др.) |
||||
|
telecom |
0...* |
Контактные данные пациента (e-mail, phone) |
||
|
managingOrganization |
1..1 |
Reference(Organization) |
Организация, занимающаяся хранением записи пациента. Ссылка на managingOrganization должна указывать на объект типа Organization, хранящийся в сервисе Терминологии. Здесь указывается первичная организация пациента. Сведения об организации - отправителе определяются из авторизационного идентификатора (токена) сообщения и могут отличаться от первичной организации. Например: первичной организацией может быть поликлиника, где обслуживался пациент, а сообщение передано из сервиса ДЛИ, установленного в МИАЦ |
|
Поставка данных пациента в MPI
Программный интерфейс TMCore предоставляет возможность МИС МО поставлять данные пациента в сервис MPI. При поддержке метода поставки на стороне МИС МО необходимо обеспечить выполнение следующих общих условий:
- При передаче данных в сервис должен указываться токен TMCore. Токен указывается в адресной строке.
- На стороне TMCore выполняется поверка наличия и соответствия указанного токена. Если проверка токена успешна, то формируется запрос на перердачу данных в MPI. Если нет, то на сторону МИС МО передается сообщение об ошибке.
- После успешной проверки формируется и передается запрос в MPI в соответствии правил обмена.
- Передача данных пациента в объеме согласно требованиям сервиса MPI и по структуре ресурса Patient (стандарта FHIR).
- Выполнение условия для проверки на уникальность по параметрам: «identifier.system + identifier.value + managingOrganization»;
- Для этого во входных параметрах при запросе метода указываются две системы:
- первичная (пространство urn:oid:1.2.643.5.1.13.2.7.100.7) – для МИС МО;
- передающая (пространство urn:oid:1.2.643.5.1.13.2.7.100.5) – для Телемедицины (указывается по умолчанию, см. Таблица 23 Описание параметров ресурса Patient);
- для первичной в значении параметра identifier.value передается идентификатор пациента idPatientMis в МИС МО;
- для передающей в значении параметра identifier.value передается идентификатор пациента МИС МО по формату «TMC/ idPatientMis».
- Полученный ответ от MPI передается в ответе МИС МО.
Пример запроса
POST {{url}}/api/Regis/Mpi/SavePatient
authorization: N3[пробел][GUID передающей системы]
content-type: application/json
{
"resourceType": "Patient",
"identifier": [
{
"system": "urn:oid:1.2.643.5.1.13.2.7.100.5",
"value": "TMC/<idPatientMis>",
"assigner": {
"display": "1.2.643.2.69.1.2.116"
}
},
{
"system": "urn:oid:1.2.643.5.1.13.2.7.100.7",
"value": "<idPatientMis>",
"assigner": {
"display": "1.2.643.2.69.1.2.28"
}
},
{
"system": "urn:oid:1.2.643.2.69.1.1.1.6.223",
"value": "18477901518",
"assigner": {
"display": "ПФР"
}
}
],
"name": [
{
"family": [
"Андреев",
"Антонович"
],
"given": [
"Дмитрий"
]
}
],
"telecom": [
{
"system": "email",
"value": "+7-(989)1355987"
},
{
"system": "fax",
"value": "+7-(989)1355987"
},
{
"system": "other",
"value": "+7-(989)1355987"
},
{
"system": "pager",
"value": "+7-(989)1355987"
},
{
"system": "phone",
"value": "+7-(989)1355987"
}
],
"gender": "male",
"birthDate": "19-10-1995",
"address": [
{
"use": "home",
"text": "123456, г. Прегонь, ул. Северная, 4/2"
},
{
"use": "work",
"text": "123456, г. Прегонь, ул. Северная, 4/2"
},
{
"use": "old",
"text": "123456, г. Прегонь, ул. Северная, 4/2"
},
{
"use": "temp",
"text": "123456, г. Прегонь, ул. Северная, 4/2"
}
],
"managingOrganization": {
"reference": "Organization/3b4b37cd-ef0f-4017-9eb4-2fe49142f682"
}
}
Поиск данных пациента в MPI по документу
Программный интерфейс TMCore предоставляет возможность МИС МО выполнять поиск карточек в сервисе MPI. При поддержке метода поиска на стороне МИС МО необходимо обеспечить выполнение следующих общих условий:
- В запросе метода должен указываться токен TMCore. Токен указывается в адресной строке.
- На стороне TMCore выполняется поверка наличия и соответствия указанного токена. Если проверка токена успешна, то формируется запрос на передачу данных в MPI. Если нет, то на сторону МИС МО передается сообщение об ошибке.
- После успешной проверки формируется и передается запрос в MPI в соответствии правил обмена.
Предоставляемый метод поиска данных в MPI выполняется по следующему сценарию:
- Сервис TMCore получает запрос на поиск данных от МИС МО.
- Сервис TMCore проверяет выполнение условий, указанных выше и затем отправляет запросы в MPI.
- Сервис TMCore получает идентификатор карточки MPI.
- Ответы предыдущего шага передается в МИС МО.
Пример запроса
POST [base]/api/Regis/Mpi/GetMasterCardByDoc
authorization: N3[пробел][GUID передающей системы]
content-type: application/json
{
"resourceType": "Parameters",
"parameter": [{
"name": "docType",
"valueString": "urn:oid:1.2.643.2.69.1.1.1.6.223"
},
{
"name": "docNumber",
"valueString": "88950847590"
}]
}
Поиск данных пациента в MPI по идентификатору
Программный интерфейс TMCore предоставляет возможность МИС МО выполнять поиск карточек в сервисе MPI. При поддержке метода поиска на стороне МИС МО необходимо обеспечить выполнение следующих общих условий:
- В запросе метода должен указываться токен TMCore. Токен указывается в адресной строке.
- На стороне TMCore выполняется поверка наличия и соответствия указанного токена. Если проверка токена успешна, то формируется запрос на передачу данных в MPI. Если нет, то на сторону МИС МО передается сообщение об ошибке.
- После успешной проверки формируется и передается запрос в MPI в соответствии правил обмена.
Предоставляемый метод поиска данных в MPI выполняется по следующему сценарию:
- Сервис TMCore получает запрос на поиск данных от МИС МО.
- Сервис TMCore проверяет выполнение условий, указанных выше и затем отправляет запросы в MPI.
- Сервис TMCore получает список идентификаторов карточек MPI.
- По каждому идентификатору последовательно выполняется запрос карточки и получается ответ.
- Ответы предыдущего шага объединяются и общий результат обработки передается в МИС МО.
Пример запроса
GET [base]/api/Regis/Mpi/GetPatientCardById/[patientId] authorization: N3[пробел][GUID передающей системы]
Коды возвращаемых ошибок
|
Код |
Описание |
|
0 |
Ошибок не найдено |
|
1 |
Внутренняя ошибка приложения |
|
2 |
Ошибка валидации выполнения операции. Неверный код передаваемой сущности, отсутствие обязательных данных согласно спецификациям |
|
3 |
Множественный переход |
|
11 |
Указанный маршрут не найден |
|
12 |
Указанного статуса не существует |
|
14 |
Указанного валидатора не существует |
|
15 |
Указанного отклика не существует |
|
16 |
Заявка не найдена |
|
17 |
Указанной предметной области не существует |
|
18 |
Указанной схемы данных не существует |
|
19 |
Указанной операции (transition) не существует |
|
32 |
Нет данных ожидаемых для осуществления перехода или создания заявки |
|
33 |
Нет метаданных описания маршрута |
|
42 |
Данные расширения схемы не разрешены |
|
51 |
Метаданные маршрута не найдены |
|
52 |
Метаданные заявки не найдены |