Версия |
Дата |
Автор |
Примечание |
1.0 |
01/02/2021 |
Павлова А.Н. |
Первая версия регламента |
2.0 |
12/02/2021 |
Павлова А.Н. |
Добавлено описание взаимодействия с ВКС, файловым хранилищем. Расширено описание методов. |
3.0 |
17/02/2021 |
Павлова А.Н. |
Обновлена схема. Добавлено описание взаимодействия с MPI |
4.0 |
18/02/2021 |
Павлова А.Н. |
Добавлены примеры обмена с MPI |
5.0 |
25/02/2021 |
Павлова А.Н. |
Изменено описание обмена с MPI |
6.0 |
01/04/2021 |
Павлова А.Н. |
Изменена структура файла описания, правки по тексту, добавлено описание метода UpdateProcess |
7.0 | 26/07/2021 | Туркин А.А. | Изменены примеры методов работы с данными о пациентах |
8.0 | 05/10/2021 | Туркин А.А. | Внесены изменение в описание формата ролевого контекста. В новой версии его передача осуществляется в формате словаря. |
9.0 | 28/10/2021 | Туркин А.А. | Исправлена ошибка схеме на рисунке 1. Исправлен порядок выполнения запросов целевой МО |
10.0 | 29/09/2022 | Пискарева А. В. | Уточнена структура входных данных для методов StartNewProcess и MoveToStage |
10.1 | 25/10/2022 | Пискарева А. В. | Добавлено описание выходных данных метода GetProcess, уточнен пример выходных данных |
10.2 | 26/10/2022 | Пискарева А. В. | Добавлено описание и пример выходных данных метода StartNewProcess |
10.3 | 21/11/2022 | Пискарева А. В. | Уточнено описание методов POST Commands/xds и GET Queries/xds. Добавлено описание метода GET /Queries/xds |
10.4 | 28/11/2022 | Пискарева А. В. | Уточнено описание метода GET Queries/GetSchema/<schemaId> |
10.5 | 14/12/2022 | Пискарева А. В. | Уточнены выходные данные метода GET Queries/GetWorkflow: добавлены атрибуты относящиеся к контролю просрочек |
10.6 | 08/02/2023 | Пискарева А. В. | Добавлено описание метода POST Queries/GetProcessWithAvailableTransitions |
11.0 | 27/11/2023 | Пискарева А. В. | Разделы посвященные работе с XDS и MPI переписаны в соответствии с переводом работы с этими сервисами на TM-Widgets |
Сервис интеграционной платформы 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 (объектный идентификатор).
Параметры схемы, указывающие на значения справочников, представляются в следующей виде:
Роли пользователей передаются согласно справочнику НСИ: 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-схема, описывающая набор и структуру данных необходимых для передачи информации о пользователе при проверке доступа к функциям системы. Можно создать в рамках предметной области столько, сколько требуется. Пользователь может на входе передавать несколько наборов присвоенных ему ролей. Например, пользователь может быть одновременно врачом в одной организации и административным руководителем в другой. Соответственно заявки и маршруты ему будут подбираться с учетом обеих его ролей.
Маршрут - описание порядка выполнения операций в ходе исполнения работ по заявкам.
Маршрут описывается с помощью названия, описания и структуры метаданных. Суть маршрута заключается в наборе состояний и операций с заявками.
Состояния или статусы (1, 2, 3 на рисунке) - это контрольные точки в бизнес-процессе. Они создаются в рамках маршрута с указанием имени и правил доступа. Правило доступа описывает, какому пользователю может быть доступна заявка для просмотра в данном статусе.
Переходы (а, б, в, г, д, е на рисунке) - это операции над заявкой по данному маршруту.
Если стартовое состояние перехода не указано (а, б на рисунке), то он используется для создания заявки в том статусе, который указан как конечный. Операций создания заявки по маршруту может быть сколько угодно с любой логикой. Например, можно настроить создание заявки со статусом доступным исполнителю. Можно создать заявку в статусе “черновик”, доступным заявителю.
Если стартовое состояние указано тоже, что и конечное (е на рисунке), то операция не изменит статус заявки. Решает задачу редактирования данных заявки без необходимости изменения статуса.
При указании конечного состояния отличного от стартового - заявка меняет состояние (в, г, д на рисунке).
Для типового маршрута в подсистеме Управление потоками определен следующий набор состояний заявки:
Каждое из состояний заявки имеет свой уникальный идентификатор в системе.
Содержание правил перехода в рамках маршрута:
Для определения ролевого доступа к просмотру и работе с заявками используется «ролевой контекст». Например, для предметной области «Тестовая область» ролевой контекст определён набором json-схем. Основной ролевой схемой для работы пользователей МИС является данная схема:
Пример ролевого контекста согласно данной схеме:
Так же идентификатор схемы ролевого контекста возможно получить при получении сведений о маршруте (getWorkflow) и операции над заявкой (getTransition). Саму схему в последствии можно запросить методом «getSchema».
"5ff16ba7-9edd-41a4-bd06-2ee33cfd4597" – в примере ролевого контекста должно являться идентификатором ролевой схемы соответствующей настройкам доступа на маршруте, смотрите приложение к регламенту.
Функциональность подсистемы Управление потоками обеспечивается следующими методами:
В методах сервиса для передачи набора данных заявки используется параметр типа «Object» - processContext.
В обмене для структуры данных о заявке используется несколько объектов. Перечень объектов и описание их назначения представлено в таблице ниже.
Данные в параметре типа «Object» - processContext могут быть описаны в формате стандарту FHIR.
Таблица 1 Описание объектов, входящих в состав типовой заявки
№ п/п |
Объект |
Назначение объекта по бизнес-логике |
Описание |
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 |
Состав консилиума |
В объекте указывается информация о составе консилиума и председателе консилиума |
Использование метаданных заявок применяется для вывода контекстной информацию о заявках в списке, для построения форм фильтрации по заявкам. Это общая логика для всех заявок вне зависимости от методов работы с заявками.
В приведенном ниже примере описания структуры метаданных заявки описывается набор и структура формируемых параметров заявки и пути их нахождения в её контексте (наборе структурированных данных агрегированных по ходу заявки по маршруту).
Описание принципа сопоставления Json-объектов при использовании в качестве фильтров метаданных маршрута или заявки:
В качестве фильтра принимается Json-объект, в котором путь к искомому значению будет таким же как в объекте, где производится поиск. Например, в метаданных процесса есть следующие данные в формате обмена:
В таком случае, для доступа к полю "code" в объекте "diagnosis" нужно повторить путь к полю:
Все выбранные данные в объекте в любом случае будут приведены к строке, и выбор сопоставление производится с помощью SQL-конструкции LIKE (поиск вхождения подстроки). То следующее выражение будет эквивалентно предыдущему:
Для выбора нескольких значений, одного и того же поля можно использовать перечисление значений в массиве, однако в таком случае будет использовано полное совпадение:
В случае, если в объекте фильтра будет несколько полей — итоговое выражение будет собираться с учётом того, что все выражения должны быть истиной.
Передача дат фильтрации:
Для передачи периода дат ожидается структура, представляющая собой массив дат, сериализованный в JSON:
В случае если в массиве одна дата, будут выбраны все данные, в которых искомая дата будет больше чем, переданная в дата массиве. В случае, если передано больше 2х дат — все кроме первых двух будут проигнорированы.
Параметры сортировки:
Для передачи сортировки необходимо передать имя из ответа в поле запроса orderingField. Поля доступные для передачи «Created», «Updated».
Для сортировки по убыванию в поле запроса descendingOrder нужно передать true.
Метод предоставляет перечень маршрутов и описания операций, в рамках которых возможно создавать заявки.
Описание параметров запроса метода в таблице ниже.
Таблица 2 Входные параметры метода 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-объектов описаны выше).
Метаданные маршрута описываются по соответствующей схеме и указываются при его создании или редактировании администратором системы.
Описание структуры ответа:
Таблица 3 Выходные параметры метода POST GetAvailableTransitions
№ п/п | Параметр | Тип | Кратность | Описание |
---|---|---|---|---|
1. | result | object | 1..1 | объект-контейнер |
1.1. | result.result | array | 1..1 | массив-контейнер |
1.1.1. | result.result[] | object | 0..* | Результат по маршруту объект-контейнер |
1.1.1.1. | result.result[].workflowIsConstruction | boolean | 1..1 | Статус маршрута |
1.1.1.2. | result.result[].workflowIsDisabled | boolean | 1..1 | Метка удаления маршрута |
1.1.1.3. | result.result[].workflowName | string | 1..1 | Название маршрута |
1.1.1.4. | result.result[].workflowMetadata | string | 1..1 | метаданные маршрута |
1.1.1.5. | result.result[].workflowId | string | 1..1 | Идентификатор маршрута |
1.1.1.6. | result.result[].transitions | array | 1..1 | Переходы массив-контейнер |
1.1.1.6.1. | result.result[].transitions[] | object | 0..* | объект-контейнер |
1.1.1.6.1.1. | result.result[].transitions[].id | string | 1..1 | Идентификатор перехода |
1.1.1.6.1.2. | result.result[].transitions[].name | string | 1..1 | Название перехода |
1.1.1.6.1.3. | result.result[].transitions[].fromStageId | string | 0..1 | Идентификатор состояния, с которого производится переход |
1.1.1.6.1.4. | result.result[].transitions[].toStageId | string | 1..1 | Идентификатор состояния, на который производится переход |
1.1.1.6.1.5. | result.result[].transitions[].schemaId | string | 1..1 | Идентификатор схемы передаваемых данных |
1.1.1.6.1.6. | result.result[].transitions[].validatorIds | array | 1..1 | Проверки массив-контейнер |
1.1.1.6.1.6.1. | result.result[].transitions[].validatorIds[] | string | 0..* | Идентификатор проверки |
1.1.1.6.1.7. | result.result[].transitions[].callbackIds | array | 1..1 | Внешние вызовы массив-контейнер |
1.1.1.6.1.8. | result.result[].transitions[].roleSchemaIds | array | 1..1 |
Ролевые схемы (не используется) массив-контейнер |
1.2. | result.total | integer | 1..1 | количество элементов в выдаче |
2. | success | boolean | 1..1 | Успешность обработки запроса |
3. | errorCode | integer | 1..1 | Код ошибки |
4. | message | string | 0..1 | Сообщение об ошибке |
5. | stackTrace | string | 0..1 | Техническая информация об ошибке |
Пример запроса
Метод предоставляет описание заявки со списком переходов, доступных пользователю в данной заявке, учитывая текущий статус заявки.
Описание параметров запроса метода в таблице ниже.
Таблица 4 Входные параметры метода POST GetProcessWithAvailableTransitions
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
roleContext |
object |
1..1 |
Значение ролевого контекста пользователя |
2 |
processId |
object |
1..1 |
Идентификатор заявки |
Описание структуры ответа:
Таблица 5 Выходные параметры метода POST GetProcessWithAvailableTransitions
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | result | object | 1..1 | не указывается при неуспешном вызове объект-контейнер |
1.1. | result.availableTransitions | array | 1..1 | массив-контейнер |
1.1.1. | result.availableTransitions[] | object | 0..1 | Переходы объект-контейнер |
1.1.1.1. | result.availableTransitions[].id | string | 1..1 | Идентификатор перехода |
1.1.1.2. | result.availableTransitions[].name | string | 1..1 | Наименование перехода |
1.1.1.3. | result.availableTransitions[].fromStageId | string | 1..1 | Идентификатор состояния, с которого производится переход |
1.1.1.4. | result.availableTransitions[].toStageId | string | 1..1 | Идентификатор состояния, на который производится переход |
1.1.1.5. | result.availableTransitions[].schemaId | string | 1..1 | Идентификатор схемы передаваемых данных |
1.1.1.6. | result.availableTransitions[].validatorIds | array | 1..1 | Проверки массив-контейнер |
1.1.1.6.1. | result.availableTransitions[].validatorIds[] | string | 0..* | Идентификатор проверки |
1.1.1.7. | result.availableTransitions[].callbackIds | array | 1..1 | Внешние вызовы массив-контейнер |
1.1.1.7.1. | result.availableTransitions[].callbackIds[] | string | 0..* | Идентификатор внешнего вызова |
1.1.1.8. | result.availableTransitions[].roleSchemaIds | array | 1..1 | Ролевые схемы (не используется) массив-контейнер |
1.2. | result.metadata | object | 1..1 | Метаданные заявки. Структура метаданных соответствует json-схеме, которая может быть получена в поле $.result.schema запроса GET /tm-core/api/Queries/GetSchema/, где primarySchemaId - значение одноименного поля настоящего запроса объект-контейнер |
1.3. | result.scopedMetadata | object | 1..1 | Расшифрованные метаданные в состав расшифрованных метаданных включаются все поля метаданных у которых в json-схеме указан атрибут "displayInUI": true (см. пояснение к полю result.metadata) объект-контейнер |
1.4. | result.statusName | string | 1..1 | Название текущего статуса заявки |
1.5. | result.primarySchemaId | string | 1..1 | Идентификатор схемы данных предметной области |
1.6. | result.id | string | 1..1 | Идентификатор заявки |
1.7. | result.name | string | 1..1 | Наименование заявки |
1.8. | result.workflowId | string | 1..1 | Идентификатор маршрута |
1.9. | result.metadataId | string | 1..1 | Идентификатор метаданных |
1.10. | result.currentStageId | string | 1..1 | Идентификатор текущего статуса заявки |
1.11. | result.created | string | 1..1 | Отметка времени создания заявки |
1.12. | result.updated | string | 1..1 | Отметка времени последнего изменения заявки |
1.13. | result.businessStatus | object | 1..1 | Бизнес статус заявки объект-контейнер |
1.13.1. | result.businessStatus.system | string | 1..1 | OID справочника состояний Пример urn:oid:1.2.643.2.69.1.1.1.148.2 |
1.13.2. | result.businessStatus.code | string | 1..1 | Код состояния Пример 17 |
1.14. | result.humanFriendlyId | string | 1..1 | Человекочитаемый идентификатор заявки |
2. | success | boolean | 1..1 | Успешность выполнения запроса |
3. | errorCode | integer | 1..1 | Код ошибки 0 - без ошибок |
4. | message | string | 0..1 | Описание ошибки для пользователя null - без ошибок |
5. | stackTrace | string | 0..1 | Техническое описание ошибки null - без ошибок |
Пример запроса
Метод возвращает данные о статусах и операциях на маршруте по идентификатору. С помощью возвращаемых данных можно узнать все возможные состояния заявки, перечень возможных операций и переходов между статусами, выполняемые проверки при попытках выполнения переходов и условия доступности заявок на каждом из статусов.
В таблице ниже представлено описание параметров запроса метода.
Таблица 6 Входные параметры метода GET GetWorkflow
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
workflowId |
String |
1..1 |
Идентификатор маршрута |
Описание структуры ответа
Таблица 7 Выходные параметры метода GET GetWorkflow
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. |
result |
object | 1..1 | объект-контейнер |
1.1. | result. id |
string | 1..1 | Идентификатор маршрута |
1.2. | result. name |
string | 1..1 | Наименование маршрута |
1.3. | result. description |
string | 1..1 | Описание маршрута |
1.4. | result. isConstruction |
boolean | 1..1 | Статус отладки маршрута true - тестовый |
1.5. | result. areaId |
string | 1..1 | Идентификатор предметной области |
1.6. | result. areaName |
string | 1..1 | Наименование предметной области |
1.7. | result. metadataId |
string | 1..1 | Идентификатор метаданных маршрута |
1.8. | result. stages |
object | 1..1 | Состояния объект-контейнер |
1.8.1. | result.stages. <stageId> |
object | 0..* | Состояние объект-контейнер |
1.8.1.1. | result.stages.<stageId>. id |
string | 1..1 | Идентификатор состояния |
1.8.1.2. | result.stages.<stageId>. name |
string | 1..1 | Наименование состояния |
1.8.1.3. | result.stages.<stageId>. description |
string | 1..1 | Описание состояния |
1.8.1.4. | result.stages.<stageId>. validators |
array | 1..1 | Проверки, выполняемые для доступа к заявке, когда она находится в данном состоянии массив-контейнер |
1.8.1.4.1. | result.stages.<stageId>.validators[] | object | 0..* | объект-контейнер |
1.8.1.4.1.1. | result.stages.<stageId>.validators[]. id |
string | 1..1 | Идентификатор проверки |
1.8.1.4.1.2. | result.stages.<stageId>.validators[]. name |
string | 1..1 | Наименование проверки |
1.8.1.5. | result.stages.<stageId>. isDisabled |
boolean | 1..1 | Статус блокировки состояния |
1.8.1.6. | result.stages.<stageId>. businessStatus |
object | 1..1 | Код состояния согласно справочнику НСИ объект-контейнер |
1.8.1.6.1. | result.stages.<stageId>.businessStatus. system |
string | 1..1 | OID справочника состояний Пример urn:oid:1.2.643.2.69.1.1.1.148.2 |
1.8.1.6.2. | result.stages.<stageId>.businessStatus. code |
string | 1..1 | Код состояния Пример 17 |
1.8.1.7. | result.stages.<stageId>. processDataAvailabilityIds |
array | 1..1 | Ограничения доступа к данным по заявке, когда она находится в данном состоянии массив-контейнер |
1.8.1.7.1. | result.stages.<stageId>.processDataAvailabilityIds[] | object | 0..* | объект-контейнер |
1.8.1.7.1.1. | result.stages.<stageId>.processDataAvailabilityIds[]. description |
string | 1..1 | Описание ограничения |
1.8.1.7.1.2. | result.stages.<stageId>.processDataAvailabilityIds[]. id |
string | 1..1 | Идентификатор ограничения |
1.8.1.7.1.3. | result.stages.<stageId>.processDataAvailabilityIds[]. name |
string | 1..1 | Наименование ограничения |
1.9. | result. transitions |
object | 1..1 | Переходы объект-контейнер |
1.9.1. | result.transitions. <transitionId> |
object | 0..* | Переход объект-контейнер |
1.9.1.1. | result.transitions.<transitionId>. id |
string | 1..1 | Идентификатор перехода |
1.9.1.2. | result.transitions.<transitionId>. name |
string | 1..1 | Наименование перехода |
1.9.1.3. | result.transitions.<transitionId>. fromStageId |
string | 0..1 | Идентификатор состояния заявки, из которого можно совершить переход. При отсутствии, переход используется для создания заявки |
1.9.1.4. | result.transitions.<transitionId>. toStageId |
string | 1..1 | Идентификатор состояния заявки, на который будет осуществлен переход |
1.9.1.5. | result.transitions.<transitionId>. schemaId |
string | 0..1 | Идентификатор схемы данных необходимых для выполнения операции |
1.9.1.6. | result.transitions.<transitionId>. schemaName |
string | 0..1 | Наименование схемы данных необходимых для выполнения операции |
1.9.1.7. | result.transitions.<transitionId>. validators |
array | 1..1 | Проверки доступа,выполняемые перед выполнением перехода массив-контейнер |
1.9.1.7.1. | result.transitions.<transitionId>.validators[] | object | 0..* | объект-контейнер |
1.9.1.7.1.1. | result.transitions.<transitionId>.validators[]. id |
string | 1..1 | Идентификатор проверки |
1.9.1.7.1.2. | result.transitions.<transitionId>.validators[]. name |
string | 1..1 | Наименование проверки |
1.9.1.8. | result.transitions.<transitionId>. callbacks |
array | 1..1 | Преднастроенные вызовы внешних систем, выполняемые после перехода массив-контейнер |
1.9.1.8.1. | result.transitions.<transitionId>.callbacks[] | object | 0..* | объект-контейнер |
1.9.1.8.1.1. | result.transitions.<transitionId>.callbacks[]. id |
string | 1..1 | Идентификатор вызова |
1.9.1.8.1.2. | result.transitions.<transitionId>.callbacks[]. name |
string | 1..1 | Наименование вызова |
1.10. | result. workflowTimeouts |
array | 1..1 | Правила контроля просрочек маршрута массив-контейнер |
1.10.1. | result.workflowTimeouts[] | object | 0..* | объект-контейнер |
1.10.1.1. | result.workflowTimeouts[]. id |
string | 1..1 | Идентификатор правила контроля просрочек маршрута |
1.10.1.2. | result.workflowTimeouts[]. workflowId |
string | 1..1 | Идентификатор маршрута |
1.10.1.3. | result.workflowTimeouts[]. targetStageIds |
array | 1..1 | Целевые состояния для контроля массив-контейнер |
1.10.1.3.1. | result.workflowTimeouts[].targetStageIds[] | string | 1..* | Идентификатор целевого состояния (достижение каких состояний, считать контрольной точкой) |
1.10.1.4. | result.workflowTimeouts[]. timeout |
string | 1..1 | Время контролируемое правилом Пример 00:05:00 |
1.10.1.5. | result.workflowTimeouts[]. expression |
string | 0..1 | Выражение для фильтрации контролируемых заявок Пример ({entity} @? '$ ? (@.b > "7")') |
1.11. | result. stageTimeouts |
array | 1..1 | Правила контроля просрочек состояния массив-контейнер |
1.11.1. | result.stageTimeouts[] | object | 0..* | объект-контейнер |
1.11.1.1. | result.stageTimeouts[]. id |
string | 1..1 | Идентификатор правила контроля просрочек состояния |
1.11.1.2. | result.stageTimeouts[]. stageId |
string | 1..1 | Целевое состояния для контроля (пребывание заявки, в каком состоянии контролируется правилом) |
1.11.1.3. | result.stageTimeouts[]. timeout |
string | 1..1 | Время контролируемое правилом Пример 00:05:00 |
1.11.1.4. | result.stageTimeouts[]. expression |
string | 0..1 | Выражение для фильтрации контролируемых заявок Пример ({entity} @? '$ ? (@.b > "7")') |
1.12. | result. isDisabled |
boolean | 1..1 | Признак неактивности маршрута. Если маршрут заблокирован, то по нему будет невозможно создать новую заявку |
1.13. | result. metadata |
object | 1..1 | Структура метаданных маршрута. Определяется настройками маршрута объект-контейнер |
2. |
success |
boolean | 1..1 | Отметка об успешности выполнения запроса |
3. |
errorCode |
integer | 1..1 | Код ошибки |
4. |
message |
string | 1..1 | Текст сообщения об ошибке |
5. |
stackTrace |
string | 1..1 | Технические сведения об ошибке |
Метод предназначен для получения схемы данных (объекта контекста), необходимого для осуществления перехода к новому состоянию заявки.
В таблице ниже представлено описание параметров запроса метода.
Таблица 8 Входные параметры для метода POST GetSchema
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
id |
String |
1..1 |
Идентификатор схемы |
Описание структуры ответа
В описании структур, передаваемых в ответе данных в формате json-схемы, содержится описания типов передаваемых данных, кратности и обязательности. Справочные материалы в обмене данными в заявках используются в рамках справочников НСИ. В случае использования справочника, в описании структуры данных "description" указывается код справочника.
Таблица 9 Выходные параметры для метода POST GetSchema
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | result | object | 0..1 | объект-контейнер |
1.1. | id | string | 1..1 | Идентификатор схемы |
1.2. | name | string | 1..1 | Название схемы |
1.3. | type | string | 1..1 | Тип схемы |
1.4. | areaId | string | 1..1 | Идентификатор предметной области |
1.5. | areaName | string | 1..1 | Название предметной области |
1.6. | schema | object | 1..1 | JSON-схема объект-контейнер |
1.7. | isDisabled | boolean | 1..1 | Признак неактивности |
2. | success | boolean | 1..1 | Признак успешного выполнения запроса |
3. | errorCode | integer | 1..1 | Код ошибки |
4. | message | string | 0..1 | Текст сообщения об ошибке |
5. | stackTrace | string | 0..1 | Технические сведения об ошибке |
Если в рамках заявки требуется передать информацию о пациенте, зарегистрированном в ГИС, случае ИЭМК, результатах лабораторных или инструментальных исследований, направлении на оказание медицинской помощи, то согласно схеме описания данных для осуществления операции над заявкой потребуется указать идентификаторы данных объектов из соответствующих сервисов: Индекс пациента, ИЭМК, ОДЛИ, ОДИИ, УО.
Для создания заявки в сервисе используется метод POST StartNewProcess. Метод создаёт заявку по маршруту согласно переданному переходу.
В таблице ниже представлено описание параметров запроса метода.
Таблица 10 Входные параметры для метода POST StartNewProcess
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
workflowId |
String |
1..1 |
Идентификатор маршрута |
2 |
name |
String |
1..1 |
Название заявки |
3 |
initialTransitionId |
String |
1..1 |
Идентификатор перехода для создания заявки |
4 |
processContext |
Object |
1..1 |
Набор данных соответствующий json-схеме для указанного перехода. Схема может быть получена с помощью последовательного применения двух запросов: |
5 |
roleContext |
Object |
1..1 |
Значение ролевого контекста пользователя |
Таблица 11 Выходные параметры метода POST StartNewProcess
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | workflowId | string | 0..1 | Идентификатор маршрута не указывается при неуспешном вызове |
2. | processId | string | 0..1 | Идентификатор заявки не указывается при неуспешном вызове |
3. | stageId | string | 0..1 | Идентификатор текущего статуса заявки не указывается при неуспешном вызове |
4. | humanFriendlyId | string | 0..1 | Человекочитаемый номер заявки не указывается при неуспешном вызове |
5. | validationResults | array | 1..1 | Ошибки валидации null при успешном вызове массив-контейнер |
6. | success | boolean | 1..1 | Успешность выполнения запроса |
7. | errorCode | integer | 1..1 | Код ошибки 0 - без ошибок |
8. | message | string | 1..1 | Описание ошибки для пользователя null - без ошибок |
9. | stackTrace | null | 1..1 | Техническое описание ошибки null - без ошибок |
Для редактирования или обновления данных заявки в сервисе используется метод POST MoveToStage. В базовом назначении метод позволяет осуществить запрос перехода заявки в новое состояние согласно указанному правилу перехода. Далее представлены варианты использования запроса метода при которых происходит переход заявки в новое состояние.
Помимо редактирования заявки, запрос метода используется для обновления состояния заявки в любых других операциях доступных по заявке.
В таблице ниже представлено описание параметров запроса метода.
Таблица 12 Входные параметры для метода POST MoveToStage
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
processId |
String |
1..1 |
Идентификатор заявки |
2 |
transitionId |
String |
1..1 |
Идентификатор перехода |
3 |
processContext |
Object |
1..1 |
Набор данных соответствующий json-схеме для указанного перехода. Схема может быть получена с помощью последовательного применения двух запросов: |
4 |
roleContext |
Object |
1..1 |
Значение ролевого контекста пользователя |
Для получения списка доступных для действия заявок в сервисе используется метод POST GetTransitionAvailableProcesses. Метод предназначен для получения списка заявок в статусах, которые имеют операции доступные для использования данному пользователю.
В таблице ниже представлено описание параметров запроса метода.
Таблица 13 Входные параметры для метода фильтрации
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
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.
Таблица 14 Выходные параметры для метода фильтрации
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
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 GetReadAvailableProcesses. Метод предназначен для получения списка заявок в статусах, которые доступны данному пользователю для просмотра и действия.
В таблице ниже представлено описание параметров запроса метода.
Таблица 15 Входные параметры для метода фильтрации
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
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 |
Количество элементов в списке |
Метод возвращает описание условий перехода к новому состоянию заявки.
В таблице ниже представлено описание параметров запроса метода.
Таблица 16 Входные параметры для метода POST GetTransition
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
Id |
String |
1..1 |
Идентификатор перехода |
Описание структуры ответа
Таблица 17 Выходные параметры для метода POST GetTransition
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
ErrorCode |
string |
1..1 |
Код результата операции |
2 |
Message |
string |
1..1 |
Описание результата операции |
3 |
string |
1..1 |
Идентификатор перехода |
|
4 |
Result.Name |
string |
1..1 |
Название перехода |
5 |
Result.fromStageId |
string |
1..1 |
Стартовый статус |
7 |
Result.toStageId |
string |
1..1 |
Итоговый статус |
8 |
Result.schemaId |
string |
1..1 |
Идентификатор схемы данных необходимых для осуществления перехода |
Для получения объекта контекста заявки в сервисе используется метод POST GetProcessContext. Метод предназначен для получения набора данных (объекта контекста), собранного при работе с заявкой.
В таблице ниже представлено описание параметров запроса метода.
Таблица 18 Входные параметры для метода POST GetProcessContext
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
RoleContext |
Object |
1..1 |
Структуры ролевого контекста согласно схемам предметной области |
2 |
ProcessId |
String |
1..1 |
Идентификатор процесса () |
Для редактирования маршрута в сервисе используется метод POST UpdateProcess. Метод предназначен для внесения изменений в наименование маршрута.
В таблице ниже представлено описание параметров запроса метода.
Таблица 19 Входные параметры для метода POST UpdateProcess
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
ProcessId |
String |
1..1 |
Идентификатор процесса () |
2 |
Name |
String |
1..1 |
Наименование процесса |
Компонент XDS предназначен для распределенного хранения данных, поступающих в функциональные сервисы платформы N3. Компонент представляет собой REST-сервис и представляет собой сайт IIS. Компонент распространяется как самостоятельный компонент в виде nuget-пакета вида N3.XDS.0.1.0-unstable0030.nupkg.
В текущем решении реализованы следующие методы:
Для передачи объекта файла вложения, прикрепленного к заявке (регистрация данных) в сервисе XDS используется метод POST {{url}}/tm-widgets/api/Xds/xds, позволяющий загрузить файл и в результате получить идентификатор загруженного файла в ответ. Метод предназначен для отправки файлов, прикрепленных к заявке (например, результатов выполненных исследований).
В таблице ниже представлено описание параметров запроса метода.
Таблица 20 Входные параметры для метода POST /tm-widgets/api/Xds/xds
№ п/п | Параметр | Тип | Кратность | Описание |
---|---|---|---|---|
1 | formFile | string | 0..1 | Ссылка на файл, указывается для передачи расположение файла. |
Тело запроса передается в формате multipart/form-data. Пример приведен в форме curl-запроса.
POST {{url}}/tm-widgets/api/Xds/xds
curl --request POST \
--url <BaseURL>/tm-widgets/api/Xds/xds \
--header 'Authorization: N3 <token>' \
--header 'Content-Type: multipart/form-data' \
--header 'accept: text/plain' \
--form 'formFile=@C:\Files\testFile.md'
В таблице ниже представлено описание параметров ответа метода.
Таблица 21 Выходные параметры для метода POST /tm-widgets/api/Xds/xds
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | success | boolean | 1..1 | Успешность выполнения запроса |
2. | errorCode | integer | 1..1 | Код ошибки 0 - без ошибок |
3. | message | string | 0..1 | Описание ошибки для пользователя null - без ошибок |
4. | stackTrace | string | 0..1 | Техническое описание ошибки null - без ошибок |
5. | result | object | 0..1 | объект-контейнер не указывается при неуспешном вызове |
5.1. | result.id | string | 1..1 | Идентификатор файла в системе хранения |
5.2. | result.url | string | 1..1 | Ссылка для скачивания файла |
{
"result": {
"id": "389050e8-8e9f-428f-8ebb-9578aeed6614",
"url": "<BaseURL>/tm-widgets/api/Xds/xds?fileId=389050e8-8e9f-428f-8ebb-9578aeed6614"
},
"success": true,
"errorCode": 0,
"message": null,
"stackTrace": null
}
В таблице ниже представлено описание параметров запроса метода.
Таблица 22 Входные параметры для метода GET /tm-widgets/api/Xds/{id}/info
№ п/п | Параметр | Тип | Кратность | Описание |
---|---|---|---|---|
1 | id | string | 1..1 | Идентификатор файла |
GET {{url}}/tm-widgets/api/Xds/{id}/info
accept: text/plain
В таблице ниже представлено описание параметров ответа метода.
Таблица 23 Выходные параметры для метода GET /tm-widgets/api/Xds/{id}/info
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | result | object | 0..1 | объект-контейнер не указывается при неуспешном вызове |
1.1. | result.id | string | 1..1 | Идентификатор файла в системе хранения |
1.2. | result.mimeType | string | 1..1 | Медиа тип файла |
1.3. | result.title | string | 1..1 | Название файла |
1.4. | result.description | string | 0..1 | Описание файла |
1.5. | result.metadata | array | 1..1 | массив-контейнер прочих метаданных |
1.5.1. |
(storage_type) result.metadata[] |
object | ..1 | Тип хранения объект-контейнер |
1.5.1.1. |
(storage_type) result.metadata[].key |
string | 1..1 | Название свойства Допустимые значения storage_type |
1.5.1.2. |
(storage_type) result.metadata[].value |
string | 1..1 | Тип хранения Допустимые значения Xds |
1.5.2. |
(extension) result.metadata[] |
object | 1..1 | Расширение файла объект-контейнер |
1.5.2.1. |
(extension) result.metadata[].key |
string | 1..1 | Название свойства Допустимые значения extension |
1.5.2.2. |
(extension) result.metadata[].value |
string | 1..1 | Расширение файла Пример |
1.5.3. |
(is_available) result.metadata[] |
object | 1..1 | Доступность объект-контейнер |
1.5.3.1. |
(is_available) result.metadata[].key |
string | 1..1 | Название свойства Допустимые значения is_available |
1.5.3.2. |
(is_available) result.metadata[].value |
string | 1..1 | Доступность Допустимые значения true false |
1.5.4. |
(size) result.metadata[] |
object | 1..1 | Размер файла объект-контейнер |
1.5.4.1. |
(size) result.metadata[].key |
string | 1..1 | Название свойства Допустимые значения size |
1.5.4.2. |
(size) result.metadata[].value |
string | 1..1 | Размер файла в килобайтах Пример 9 |
1.5.5. |
(hash) result.metadata[] |
object | 1..1 | Хэш объект-контейнер |
1.5.5.1. |
(hash) result.metadata[].key |
string | 1..1 | Название свойства Допустимые значения hash |
1.5.5.2. |
(hash) result.metadata[].value |
string | 1..1 | Хэш |
2. | success | boolean | 1..1 | Успешность выполнения запроса |
3. | errorCode | integer | 1..1 | Код ошибки 0 - без ошибок |
4. | message | null | 0..1 | Описание ошибки для пользователя null - без ошибок |
5. | stackTrace | null | 0..1 | Техническое описание ошибки null - без ошибок |
{
"result": {
"id": "389050e8-8e9f-428f-8ebb-9578aeed6614",
"mimeType": "text/plain*.*txt",
"title": "FileName",
"description": null,
"metadata": [
{
"key": "storage_type",
"value": "Xds"
},
{
"key": "extension",
"value": "txt"
},
{
"key": "is_available",
"value": "true"
},
{
"key": "size",
"value": "9"
},
{
"key": "hash",
"value": "eu3/pGh9N9QAe72Of88ADQ=="
}
]
},
"success": true,
"errorCode": 0,
"message": null,
"stackTrace": null
}
Для получения объекта файла вложения, может использоваться метод GET {{url}}/tm-widgets/api/Xds/xds. Метод предназначен для получения файлов по идентификатору.
Метод возвращает файл
В таблице ниже представлено описание параметров запроса метода.
Таблица 24 Входные параметры для метода GET /tm-widgets/api/Xds/xds
№ п/п | Параметр | Тип | Кратность | Описание |
---|---|---|---|---|
1 | fileId | string | 1..1 | Идентификатор файла, полученный в ответе при отправке |
Сервис предоставляет возможность обмена данными по стандарту FHIR. С целью упрощения процесса интеграции с сервисом Подсистемы Управление потоками по стандарту FHIR реализовано два метода, позволяющие преобразовывать данные простого формата json к формату FHIR. Методы могут помочь при отладке в процессе интеграции. Использование методов преобразования не обязательно. Приведение к формату FHIR, если его применение предполагает обмен, можно выполнять самостоятельно.
Для конвертации данных в формат стандарта 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 предполагает следующие шаги:
Примеры полного преобразования тела запроса по созданию заявки в 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 для методов startNewProcess и moveToStage преобразовываются структуры объекта "resourse", входящего в параметр запроса с именем "processContext" в структуры, которые хранятся физически.
Структура преобразовывается соответственно типам данных ресурса FHIR questionnaireresponse (подробное описание состава ресурса по ссылке http://FHIR-ru.github.io/questionnaireresponse.html).
Для разделения и преобразования объектов и массивов внутри processContext применяется следующая логика:
{ "linkId": "object", "answer": [ { "item": [] } ] }
Объект FHIR "answer" - может содержать внутри элементы или item или value (), где item - object, value - примитивный тип (string, bool, interger, ...). Если указаны оба варианты, то выводится ошибка. Также, если в объекте FHIR item лежит другой item, это обозначает, что вложенный объект item – массив, все элементы внутри которого будут иметь вид, принятый для данного типа элементов.
{ "linkId": "array", "item": [] }
Массив может состоять как из примитивных типов, так и из объектов, все элементы внутри которых будут иметь вид, принятый для данного типа элементов.
Например, узел «объект»:
Преобразовывается к виду:
Например, для узла «массив»:
Преобразовывается к виду:
Элементы массива нумеруются по порядку "linkId": "0", так как узел "linkId" в FHIR является обязательным.
В методах /api/FHIR/StartNewProcess и /api/FHIR/MoveToStage сервис поддерживает и обратное преобразование данных из переданных в по стандарту FHIR к внутреннему формату.
При работе с методом /api/FHIR/ProcessContext так же поддерживается преобразование в обратную сторону из структуры, хранящейся в системе к формату FHIR.
Пример стандартной структуры TMCore:
Пример структуры FHIR преобразованной по структуре выше:
При конвертации входящих данных из roleContext к виду FHIR для методов startNewProcess и moveToStage преобразовываются структуры объекта ролевого контекста в структуры, которые хранятся физически.
Структура преобразовываются в соответствии типов данных ресурса FHIR parameters (подробное описание состава ресурса по ссылке http://FHIR-ru.github.io/parameters.html).
Для разделения и преобразования объектов и массивов внутри roleContext применяется следующая логика:
Объект FHIR "parameter" - может содержать внутри и элементы, и значения элементов value (), где value - примитивный тип (string, bool, interger, ...).
Объект FHIR "part" - может содержать внутри объекты, все элементы внутри которых будут иметь вид, принятый для данного типа элементов.
Пример структуры ролевого контекста TMCore:
Пример структуры ролевого контекста по FHIR преобразованной из структуры выше:
Метод предназначен для создания заявки по стандарту FHIR. В таблице ниже представлено описание параметров запроса метода.
Таблица 25 Входные параметры для метода 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. В таблице ниже представлено описание параметров запроса метода.
Таблица 26 Входные параметры для метода 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. В таблице ниже представлено описание параметров запроса метода.
Таблица 27 Входные параметры для метода POST //api/FHIR/ProcessContext
№ п/п |
Параметр |
Тип |
Кратность |
Описание |
1 |
RoleContext |
Object |
1..1 |
Структуры ролевого контекста согласно схемам предметной области |
2 |
ProcessId |
String |
1..1 |
Идентификатор процесса |
Полный пример запроса представлен в приложении с контрольными примерами.
Программный интерфейс подсистемы УП предоставляет возможность организации обмена данными с внешними подсистемами и сервисами, входящими в РЕГИЗ.
Подсистема УП предоставляет возможность организовать доступ к файловому хранилищу портала Телемедицины для использования в качестве хранилища данных.
Общий алгоритм работы с файлами:
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 |
Токен доступа для работы с подсистемой телемедицинских консультаций |
Использование данных ответа в телемедицинской заявке
В качестве ссылки а файл в телемедицинской заявке следует использовать абсолютный путь до файла, который в ответе лежит по адресу jsonpath: $.info.info.url
После создания заявки на портале ТМК для нее генерируются чат и комната ВКС. Для получения ссылок необходимо получить токен доступа к порталу. Чтобы не генерировать дополнительные токены для МИС, сервис предоставляет возможность передавать данные с использованием его токена. Для чего реализован метод (проброс через сервис УП) для получения списка ссылок по заявке:
[base_url]/api/flows/process_links?process_id=[process_id]&apikey=[apiKey]
Более подробное описание правил взаимодействия представлено в описании профилей API портала Телемедицины (в том подробности о правилах организации чата и ВКС).
Для организации взаимодействия клиент-системы необходимо хранение конфигурируемых данных, к которым относятся следующие данные, определяемые провайдером:
Таблица 28 Входные параметры метода
№ п/п |
Параметр |
Тип |
Обязательность |
Описание |
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}}/tm-core/api/Queries/GetProcess/< processId>
где processId – идентификатор созданной заявки в подсистеме УП.
Таблица 29 Выходные параметры метода
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | result | object | 0..1 |
объект-контейнер не указывается при неуспешном вызове |
1.1. | result.metadata | object | 1..1 | Общие метаданные заявки объект-контейнер |
1.1.1. | result.metadata.id | string | 1..1 | Идентификатор общих метаданных |
1.1.2. | result.metadata.processId | string | 1..1 | Идентификатор заявки |
1.1.3. | result.metadata.metadata | object | 1..1 | Метаданные заявки. Структура метаданных соответствует json-схеме, которая может быть получена запросом POST /tm-core/api/Queries/GetSchemas. В теле запроса необходимо указать параметры "areaId" - идентификатор предметной области и "schemaType": 1 Значение идентификатора предметной области может быть получено в одноименном поле ответа на запрос GET /tm-core/api/Queries/GetWorkflow/<workflowId> объект-контейнер |
1.1.4. | result.metadata.scopedMetadata | object | 1..1 | Расшифрованные метаданные в состав расшифрованных метаданных включаются все поля метаданных у которых в json-схеме указан атрибут "displayInUI": true (см. пояснение к полю result.metadata.metadata) объект-контейнер |
1.2. | result.statusName | string | 1..1 | Название текущего статуса заявки |
1.3. | result.id | string | 1..1 | Идентификатор заявки |
1.4. | result.name | string | 1..1 | Название заявки |
1.5. | result.workflowId | string | 1..1 | Идентификатор маршрута |
1.6. | result.metadataId | string | 1..1 | Идентификатор метаданных |
1.7. | result.currentStageId | string | 1..1 | Идентификатор текущего статуса заявки |
1.8. | result.created | string | 1..1 | Отметка времени создания заявки |
1.9. | result.updated | string | 1..1 | Отметка времени последнего изменения заявки |
1.10. | result.businessStatus | object | 1..1 | Бизнес статус заявки объект-контейнер |
1.10.1. | result.businessStatus.system | string | 1..1 | Идентификатор справочника бизнес статусов заявок |
1.10.2. | result.businessStatus.code | string | 1..1 | Код текущего бизнес статуса заявки |
1.11. | result.humanFriendlyId | string | 1..1 | Человекочитаемый идентификатор заявки |
2. | success | boolean | 1..1 | Успешность выполнения запроса |
3. | errorCode | integer | 1..1 | Код ошибки 0 - без ошибок |
4. | message | string | 1..1 | Описание ошибки для пользователя null - без ошибок |
5. | stackTrace | string | 1..1 | Техническое описание ошибки null - без ошибок |
Более подробное описание правил взаимодействия представлено в описании профилей API подсистемы СЗПВ.
Подсистема «Индекс пациента» предназначен для управления обменом идентификационными данными пациентов с внешними сервисами и системами для обеспечения: регистрации и хранения записей, содержащих идентификаторы субъектов ЭМК (пациентов МО), поддержки связей с внешними, находящимися на уровне медицинских организаций, реестрами идентификаторов пациентов МО, передачу отдельных карточек пациентов и их наборов во внешние системы, инициацию идентификации каждой новой карточки путем создания первичной связи patientlink.
Сервис TMWidgets предоставляет возможность организации информационного взаимодействия с сервисом MPI.
В программном интерфейсе TMWidgets для организации обмена данными с MPI поддержаны следующие методы:
Программный интерфейс TMWidgets предоставляет возможность МИС МО поставлять данные пациента в сервис MPI.
В таблице ниже представлено описание параметров запроса метода.
Таблица 30 Входные параметры для метода POST /tm-widgets/api /mpi/CreatePatient
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | misPatId | string | 1..1 | Идентификатор пациента в 1.2.643.5.1.13.2.7.100.7 МИС |
2. | moPatId | string | 1..1 | Идентификатор пациента в 1.2.643.5.1.13.2.7.100.5 МО |
3. | organization | string | 0..1 | Идентификатор МО в 1.2.643.2.69.1.1.1.64 Пример dfe3eec2-8a79-4921-9b58-0ce03a5e6c10 |
4. | firstName | string | 0..1 | Имя |
5. | middleName | string | 1..1 | Отчество |
6. | lastName | string | 1..1 | Фамилия |
7. | gender | string | 0..1 | Пол Пример M - большая латинская любое другое |
8. | birthDate | string | 1..1 | Дата рождения Пример 1985-12-20 |
9. | snils | string | 0..1 | СНИЛС |
10. | passport | string | 0..1 | Серия и номер паспорта Пример 6600:874511 |
11. | polis | string | 0..1 | полис ОМС Пример 7848710894041511 |
12. | phone | string | 0..1 | Номер телефона |
13. | address | string | 0..1 | Адрес |
14. | birthCertificate | string | 0..1 | Серия и номер свидетельства о рождении Пример I-AK:123411 |
15. | inn | string | 0..1 | ИНН |
В запросе требуется представление хотя бы одного из следующих параметров
POST {{url}}/tm-widgets/api/mpi/CreatePatient authorization: N3[пробел][GUID передающей системы] content-type: application/json
{
"misPatId":"1b508774-37f2-4339-b692-f9559c61cf1a",
"moPatId": "422ce65c-6ddb-49c1-9949-eec4996f5c83",
"firstName": "Виктор",
"middleName": "Андреевич",
"lastName": "Решетников",
"gender": "M",
"birthDate": "1985-12-20",
"snils": "00094773141",
"passport": "6600:874511",
"polis": "7848710894041511",
"phone": "+79991112439",
"address": "Какой-то текст тут",
"birthCertificate": "I-AK:123411",
"inn": "1234654311"
}
В таблице ниже представлено описание параметров ответа метода.
Таблица 31 Выходные параметры для метода POST /tm-widgets/api/mpi/CreatePatient
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | success | boolean | 1..1 | Успешность выполнения запроса |
2. | errorCode | integer | 1..1 | Код ошибки 0 - без ошибок |
3. | message | string | 0..1 | Описание ошибки для пользователя null - без ошибок |
4. | stackTrace | string | 0..1 | Техническое описание ошибки null - без ошибок |
5. | result | string | 0..1 | Идентификатор пациента в подсистеме «Индекс пациента» не указывается при неуспешном вызове |
{
"result": "3a316fa0-82e1-4c19-a9d6-035f98ef1f68",
"success": true,
"errorCode": 0,
"message": null,
"stackTrace": null
}
В таблице ниже представлено описание параметров запроса метода.
Таблица 32 Входные параметры для метода POST /tm-widgets/api/mpi/SearchPatientByDoc
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | resourceType | string | 1..1 | Тип ресурса Допустимые значения Parameters |
2. | parameter | array | 1..1 | массив-контейнер |
2.1. |
(docType) parameter[] |
object | 1..1 | объект-контейнер |
2.1.1. |
(docType) parameter[].name |
string | 1..1 | Название параметра Допустимые значения docType |
2.1.2. |
(docType) parameter[].valueString |
string | 1..1 | Значение параметра Допустимые значения urn:oid:1.2.643.2.69.1.1.1.6.14 - паспорт urn:oid:1.2.643.2.69.1.1.1.6.223 - СНИЛС urn:oid:1.2.643.2.69.1.1.1.6.228 - полис ОМС urn:oid:1.2.643.2.69.1.1.1.6.249 - свидетельство о рождении urn:oid:1.2.643.2.69.1.1.1.6.224 - ИНН |
2.2. |
(docNumber) parameter[] |
object | 1..1 | объект-контейнер |
2.2.1. |
(docNumber) parameter[].name |
string | 1..1 | Название параметра Допустимые значения docNumber |
2.2.2. |
(docNumber) parameter[].valueString |
string | 1..1 | Значение параметра |
POST {{url}}/tm-widgets/api/mpi/SearchPatientByDoc
authorization: N3[пробел][GUID передающей системы] accept: text/plain
{
"resourceType": "Parameters",
"parameter": [
{
"name": "docType",
"valueString": "urn:oid:1.2.643.2.69.1.1.1.6.228"
},
{
"name": "docNumber",
"valueString": "7848710894001555"
}
]
}
В таблице ниже представлено описание параметров ответа метода.
Таблица 33 Выходные параметры для метода POST /tm-widgets/api/mpi/SearchPatientByDoc
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | resourceType | string | 1..1 | Тип ресурса Допустимые значения Parameters |
2. | parameter | array | 1..1 | массив-контейнер |
2.1. | parameter[] | object | 1..1 | объект-контейнер |
2.1.1. | parameter[].name | string | 1..1 | Название параметра Допустимые значения Patients |
2.1.2. | parameter[].resource | object | 1..1 | объект-контейнер |
2.1.2.1. | parameter[].resource.resourceType | string | 1..1 | Тип ресурса Допустимые значения Bundle |
2.1.2.2. | parameter[].resource.entry | array | 0..1 | массив-контейнер |
2.1.2.2.1. | parameter[].resource.entry[] | object | 0..* | объект-контейнер |
2.1.2.2.1.1. | parameter[].resource.entry[].resource | object | 1..1 | Ресурс типа Patient. См. описание выходных данных метода поиска пациента по идентификатору объект-контейнер |
{
"resourceType": "Parameters",
"parameter": [
{
"name": "Patients",
"resource": {
"resourceType": "Bundle",
"entry": [
{
"resource": {
"resourceType": "Patient",
"id": "9533ac65-943c-411c-a320-bc9eaf7ab693",
"meta": {
"extension": [
{
"url": "fhir-request-method",
"valueString": "PUT"
},
{
"url": "fhir-request-uri",
"valueUri": "Patient"
}
],
"versionId": "47a4fa1e-d19a-4342-bbcd-a52712ba17f4",
"lastUpdated": "2023-03-01T15:45:55.3258381+03:00"
},
"identifier": [
{
"system": "urn:oid:1.2.643.5.1.13.2.7.100.5",
"value": "/5d3740e9-a4ef-4116-ace8-7cf95add1545",
"assigner": {
"display": "1.2.643.2.69.1.2.116"
}
},
{
"system": "urn:oid:1.2.643.5.1.13.2.7.100.7",
"value": "5d3740e9-a4ef-4116-ace8-7cf95add1545",
"assigner": {
"display": "1.2.643.2.69.1.2.116"
}
},
{
"system": "urn:oid:1.2.643.2.69.1.1.1.6.14",
"value": "6600:879546",
"assigner": {
"display": "УФМС"
}
},
{
"system": "urn:oid:1.2.643.2.69.1.1.1.6.223",
"value": "00094773292",
"assigner": {
"display": "ПФР"
}
},
{
"system": "urn:oid:1.2.643.2.69.1.1.1.6.228",
"value": "7848710894001555"
},
{
"system": "urn:oid:1.2.643.2.69.1.1.1.6.249",
"value": "I-AK:123456"
},
{
"system": "urn:oid:1.2.643.2.69.1.1.1.6.224",
"value": "123456789654321"
}
],
"name": [
{
"family": [
"Александров",
"Эминович"
],
"given": [
"Алексаей"
]
}
],
"telecom": [
{
"system": "phone",
"value": "79991112233"
}
],
"gender": "female",
"birthDate": "1974-12-19",
"address": [
{
"use": "home",
"text": "Какой-то текст тут"
}
],
"managingOrganization": {
"reference": "Organization/dfe3eec2-8a79-4921-9b58-0ce03a5e6c10"
}
}
}
]
}
}
]
}
В таблице ниже представлено описание параметров запроса метода.
Таблица 34 Входные параметры для метода GET /tm-widgets/api/mpi/SearchPatientById
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | patientId | string | 1..1 | Идентификатор пациента в подсистеме "Индекс пациента" |
POST {{url}}/tm-widgets/api/mpi/SearchPatientById?patientId=e9034f97-88ac-4eeb-b7b0-5935d91e94e0
authorization: N3[пробел][GUID передающей системы]
accept: text/plain
В таблице ниже представлено описание параметров ответа метода.
Таблица 35 Выходные параметры для метода GET /tm-widgets/api/mpi/SearchPatientById
# | Название | Тип | Кард. | Описание |
---|---|---|---|---|
1. | resourceType | string | 1..1 | Тип ресурса Допустимые значения Patient |
2. | id | string | 1..1 | Идентификатор пациента в подсистеме "Индекс пациента" Пример 8e4c76fa-aa65-45d5-9afc-79d01d1be623 |
3. | meta | object | 1..1 | Метаданные объект-контейнер |
3.1. | meta.extension | array | 1..1 | массив-контейнер |
3.1.1. |
(fhir-request-method) meta.extension[] |
object | 1..1 | fhir-request-method объект-контейнер |
3.1.1.1. |
(fhir-request-method) meta.extension[].url |
string | 1..1 |
Допустимые значения fhir-request-method |
3.1.1.2. |
(fhir-request-method) meta.extension[].valueString |
string | 1..1 | Метод запроса Допустимые значения POST |
3.1.2. |
(fhir-request-uri) meta.extension[] |
object | 1..1 | объект-контейнер |
3.1.2.1. |
(fhir-request-uri) meta.extension[].url |
string | 1..1 |
Допустимые значения fhir-request-uri |
3.1.2.2. |
(fhir-request-uri) meta.extension[].valueUri |
string | 1..1 |
Допустимые значения Patient |
3.2. | meta.versionId | string | 1..1 | Идентификатор версии |
3.3. | meta.lastUpdated | string | 1..1 | Время последнего обновления |
4. | identifier | array | 1..1 | Идентификатор объекта в НСИ массив-контейнер |
4.1. |
(Идентификатор пациента в МО) identifier[] |
object | 1..1 | объект-контейнер |
4.1.1. |
(Идентификатор пациента в МО) identifier[].system |
string | 1..1 | Идентификатор справочника Допустимые значения urn:oid:1.2.643.5.1.13.2.7.100.5 |
4.1.2. |
(Идентификатор пациента в МО) identifier[].value |
string | 1..1 | Идентификатор пациента в МО |
4.1.3. |
(Идентификатор пациента в МО) identifier[].assigner |
object | 1..1 | Участник информационного обмена - поставщик данных объект-контейнер |
4.1.3.1. |
(Идентификатор пациента в МО) identifier[].assigner.display |
string | 1..1 | Идентификатор поставщика данных по справочнику участников информационного обмена Пример 1.2.643.2.69.1.2.116 |
4.2. |
(Идентификатор пациента в МИС) identifier[] |
object | 1..1 | объект-контейнер |
4.2.1. |
(Идентификатор пациента в МИС) identifier[].system |
string | 1..1 | Идентификатор справочника Допустимые значения urn:oid:1.2.643.5.1.13.2.7.100.7 |
4.2.2. |
(Идентификатор пациента в МИС) identifier[].value |
string | 1..1 | Идентификатор пациента в МИС |
4.2.3. |
(Идентификатор пациента в МИС) identifier[].assigner |
object | 1..1 | Участник информационного обмена - поставщик данных объект-контейнер |
4.2.3.1. |
(Идентификатор пациента в МИС) identifier[].assigner.display |
string | 1..1 | Идентификатор поставщика данных по справочнику участников информационного обмена Пример 1.2.643.2.69.1.2.116 |
4.3. |
(Паспорт) identifier[] |
object | 0..1 | объект-контейнер |
4.3.1. |
(Паспорт) identifier[].system |
string | 1..1 | Идентификатор документа "паспорт" в справочнике видов документов Допустимые значения urn:oid:1.2.643.2.69.1.1.1.6.14 |
4.3.2. |
(Паспорт) identifier[].value |
string | 1..1 | Серия и номер паспорта Пример 6600:874511 |
4.3.3. |
(Паспорт) identifier[].assigner |
object | 1..1 | Поставщик данных объект-контейнер |
4.3.3.1. |
(Паспорт) identifier[].assigner.display |
string | 1..1 | Кем выдан Пример УФМС |
4.4. |
(СНИЛС) identifier[] |
object | 0..1 | объект-контейнер |
4.4.1. |
(СНИЛС) identifier[].system |
string | 1..1 | Идентификатор документа "СНИЛС" в справочнике видов документов Допустимые значения urn:oid:1.2.643.2.69.1.1.1.6.223 |
4.4.2. |
(СНИЛС) identifier[].value |
string | 1..1 | СНИЛС Пример 00094773141 |
4.4.3. |
(СНИЛС) identifier[].assigner |
object | 1..1 | Поставщик данных объект-контейнер |
4.4.3.1. |
(СНИЛС) identifier[].assigner.display |
string | 1..1 | Кем выдан Пример ПФР |
4.5. |
(Полис ОМС) identifier[] |
object | 0..1 | объект-контейнер |
4.5.1. |
(Полис ОМС) identifier[].system |
string | 1..1 | Идентификатор документа "полис ОМС" в справочнике видов документов Допустимые значения urn:oid:1.2.643.2.69.1.1.1.6.228 |
4.5.2. |
(Полис ОМС) identifier[].value |
string | 1..1 | номер полиса |
4.6. |
(Свидетельство о рождении) identifier[] |
object | 0..1 | объект-контейнер |
4.6.1. |
(Свидетельство о рождении) identifier[].system |
string | 1..1 | Идентификатор документа "свидетельство о рождении" в справочнике видов документов Допустимые значения urn:oid:1.2.643.2.69.1.1.1.6.249 |
4.6.2. |
(Свидетельство о рождении) identifier[].value |
string | 1..1 | Серия и номер свидетельства о рождении Пример I-AK:123411 |
4.7. |
(ИНН) identifier[] |
object | 0..1 | объект-контейнер |
4.7.1. |
(ИНН) identifier[].system |
string | 1..1 | Идентификатор документа "ИНН" в справочнике видов документов Допустимые значения urn:oid:1.2.643.2.69.1.1.1.6.224 |
4.7.2. |
(ИНН) identifier[].value |
string | 1..1 | ИНН |
5. | name | array | 1..1 | ФИО массив-контейнер |
5.1. | name[] | object | 1..1 | объект-контейнер |
5.1.1. |
(Фамилия Отчество) name[].family |
array | 1..1 | массив-контейнер |
5.1.1.1. |
(Фамилия) name[].family[] |
string | 1..1 | Фамилия |
5.1.1.2. |
(Отчество) name[].family[] |
string | 0..1 | Отчество |
5.1.2. | name[].given | array | 1..1 | массив-контейнер |
5.1.2.1. | name[].given[] | string | 1..1 | Имя |
6. | telecom | array | 0..1 | Контакты массив-контейнер |
6.1. | telecom[] | object | 0..* | объект-контейнер |
6.1.1. | telecom[].system | string | 1..1 | Канал связи Допустимые значения phone fax url other |
6.1.2. | telecom[].value | string | 1..1 | Контакт |
7. | gender | string | 1..1 | Пол Допустимые значения male female |
8. | birthDate | string | 1..1 | Дата рождения Пример 1985-12-20 |
9. | address | array | 0..1 | Адрес массив-контейнер |
9.1. | address[] | object | 0..* | объект-контейнер |
9.1.1. | address[].use | string | 1..1 | Тип адреса Допустимые значения home |
9.1.2. | address[].text | string | 1..1 | Адрес |
10. | managingOrganization | object | 1..1 | Медицинская организация создавшая запись о пациенте объект-контейнер |
10.1. | managingOrganization.reference | string | 1..1 | Ссылка на МО Идентификатор МО в 1.2.643.2.69.1.1.1.64 Пример Organization/dfe3eec2-8a79-4921-9b58-0ce03a5e6c10 |
{
"resourceType": "Patient",
"id": "3a316fa0-82e1-4c19-a9d6-035f98ef1f68",
"meta": {
"extension": [{
"url": "fhir-request-method",
"valueString": "POST"
}, {
"url": "fhir-request-uri",
"valueUri": "Patient"
}
],
"versionId": "4a2b71f1-7fa7-4dc2-b126-3faf6ee573ca",
"lastUpdated": "2023-11-22T18:13:14.5915285+03:00"
},
"identifier": [{
"system": "urn:oid:1.2.643.5.1.13.2.7.100.5",
"value": "c82c3ee1-8e5e-4d0a-8e40-c4721fd56720",
"assigner": {
"display": "1.2.643.2.69.1.2.116"
}
}, {
"system": "urn:oid:1.2.643.5.1.13.2.7.100.7",
"value": "1db3c29e-2242-4720-a94e-b828af49e80b",
"assigner": {
"display": "1.2.643.2.69.1.2.116"
}
}, {
"system": "urn:oid:1.2.643.2.69.1.1.1.6.14",
"value": "6600:874511",
"assigner": {
"display": "УФМС"
}
}, {
"system": "urn:oid:1.2.643.2.69.1.1.1.6.223",
"value": "00094773141",
"assigner": {
"display": "ПФР"
}
}, {
"system": "urn:oid:1.2.643.2.69.1.1.1.6.228",
"value": "7848710894041511"
}, {
"system": "urn:oid:1.2.643.2.69.1.1.1.6.249",
"value": "I-AK:123411"
}, {
"system": "urn:oid:1.2.643.2.69.1.1.1.6.224",
"value": "1234654311"
}
],
"name": [{
"family": [
"Решетников",
"Андреевич"
],
"given": [
"Виктор"
]
}
],
"telecom": [{
"system": "phone",
"value": "79991112439"
}
],
"gender": "male",
"birthDate": "1985-12-20",
"address": [{
"use": "home",
"text": "Какой-то текст тут"
}
],
"managingOrganization": {
"reference": "Organization/dfe3eec2-8a79-4921-9b58-0ce03a5e6c10"
}
}
Код |
Описание |
0 |
Ошибок не найдено |
1 |
Внутренняя ошибка приложения |
2 |
Ошибка валидации выполнения операции. Неверный код передаваемой сущности, отсутствие обязательных данных согласно спецификациям |
3 |
Множественный переход |
11 |
Указанный маршрут не найден |
12 |
Указанного статуса не существует |
14 |
Указанного валидатора не существует |
15 |
Указанного отклика не существует |
16 |
Заявка не найдена |
17 |
Указанной предметной области не существует |
18 |
Указанной схемы данных не существует |
19 |
Указанной операции (transition) не существует |
32 |
Нет данных ожидаемых для осуществления перехода или создания заявки |
33 |
Нет метаданных описания маршрута |
42 |
Данные расширения схемы не разрешены |
51 |
Метаданные маршрута не найдены |
52 |
Метаданные заявки не найдены |
Чек-лист: Проверка_интеграции_с_TMK v3.docx
Чек-лист СПб 2021: Проверка_интеграции_с_TMK v3 2021.docx
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
Описание бизнес процесса_TMCore_Концепт_draft4.docx |
|
Добавлено описание концепции решения для типового бизнес-процесса |
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
Описание бизнес процесса_TMCore_Концепт_Пациент-врач_Архангельск_v1.docx |
|
|||
Описание бизнес процесса_TMCore_Концепт_ОНМК_Архангельск.docx |
|
|||
|
||||
|
||||
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
|
||||
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
Приложение_к_регламенту_подсистемы_Управление_потоками_версия_2_3.docx |
|
Исправлена опечатка в описании ролевых контекстов | ||
Приложение_к_регламенту_подсистемы_Управление_потоками_версия_2_2.docx | ||||
|
||||
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
08.11.2021 | ||||
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
08.11.2021 | ||||
|
||||
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
08.08.2022 | ||||
|
||||
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
|
||||
|
||||
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
|
Номер версии | Дата согласования | Файл документа | Дата выпуска | Описание изменений |
---|---|---|---|---|
|
||||
|