Руководство по внедрению

Издатель: IT-MED LLC.
Версия: 1.1.3
Язык: ru (русский)

Версия документа

Данный документ имеет версию. Текущая версия указана в начале документа.
Версия документа обозначается тремя целыми числами, разделенными точкой.
Первая цифра — обозначает мажорную, следующая — минорную версии, третья цифра обозначает патч.
Подробнее о семантическом версионировании - здесь

История изменений

Нарратив	Техническая документация	Изменения
1.1.3	2.1.2	Добавлен ресурс DispensaryRegistration
1.1.2		Добавлена информация о классификаторах и справочниках
1.1.1		Добавлено описание методов поиска
	2.1.1	Organization: поиск по адресу - изменены ключи (мажорная версия не изменена, так как api не использовался); добавлены дополнительные параметры поиска.
1.1.0	2.1.0	Patient: добавлено свойство link
	2.0.2	MedicationRequest: исправлены ошибки
		Метод: PATH удален (фактически и не было), для обновления используется PUT
	2.0.1	openApi: добавлены свойства externalDocs и contact
		Тип данных: добавлено Dosage
1.0.0	2.0.0	Первая публичная версия

Ключевые слова

Слова «ДОЛЖЕН» (MUST), «НЕ ДОЛЖЕН» (MUST NOT), «ОБЯЗАТЕЛЬНО» (REQUIRED), «СЛЕДУЕТ» (SHOULD), «НЕ СЛЕДУЕТ» (SHOULD NOT), «РЕКОМЕНДОВАННЫЙ» (RECOMMENDED), «МОЖЕТ» (MAY) и «НЕОБЯЗАТЕЛЬНЫЙ» (OPTIONAL) в этом документе должны быть интерпретированы в соответствии с RFC 2119.

Обзор

Настоящее руководство описывает порядок и правила использования информационных ресурсов в домене здравоохранения Республики Узбекистан.

Данное руководство по внедрению (implementation guide, or IG) основано на FHIR® версии R4 и предназначено для поддержки использования FHIR® в Республике Узбекистан. Руководство определяет минимальный набор аттрибутов ресурсов FHIR и ограничений на эти ресурсы для создания основных профилей. Руководство также определяет минимальный набор взаимодействий RESTful API для каждого из основных профилей Республики Узбекистан для доступа к данным конкретного экземпляра ресурса. Любая информационная система, для функционирования в контуре здравоохранения, ДОЛЖНА поддерживать как структуру содержимого основного профиля РУз, так и взаимодействия RESTful, определённые для данного ресурса.

В данном руководстве:

представлены основные ресурсы, идентификаторы, кодовые системы, наборов значений и систем именования в контуре экосистеме цифрового здравоохранения Республики Узбекистан.
определены спецификации (структура) ресурсов, необходимые для использования в экосистеме цифрового здравоохранения Республики Узбекистан.

Ресурс – это сущность, которая:

имеет известный идентификатор (URL), по которому к нему можно обратиться;
идентифицирует себя как один из типов ресурсов, определенных в этой спецификации;
содержит набор структурированных элементов данных, как описано в определении типа ресурса.

Список доступных ресурсов, описания к ним и порядок работы с ними будет дополняться по мере обновления.

Пожалуйста, обратите внимание, что:

Данное руководство является первым выпуском, поэтому может содержать некоторые неточности, которые будут исправляться по мере выявления.
Руководство содержит описание только некоторых ресурсов, доступных на данный момент. По мере добавления ресурсов версия руководства будет изменяться.
Техническая документация может не содержать некоторые элементы (например, переводы кодовых систем (CodeSystem) и/или наборов значений (ValueSet)).
В настоящее время спецификация не устанавливает необходимость наличия идентифицированной версии ресурса, которая меняется при изменении содержимого ресурса. Включение идентифицированной версии ресурса будет реализовано в следующих выпусках спецификации.
Данное руководство по внедрению не является полноценной спецификацией FHIR API, это также будет сделано в одной из следующих итераций.
Термины REST и RESTful эквиваленты. Основная спецификация FHIR RESTful.
Данное руководство предусматривает только синхронное взаимодействие и может накладывать дополнительные ограничения на FHIR RESTful.

Область действия

Областью данного документа является только контур цифровизации системы здравоохранения и предназначен только для обеспечения технической возможности обмена медицинской информацией.
Под термином «медицинская информация» в данном документе (если в конкретном месте документа не указано иное) подразумевается:

общая нормативная информация — информация, предназначенная для единообразного кодирования национальных справочников и классификаторов (например, справочник территориально-административного деления РУЗ, классификатор должностей РУ и т.п.);
медицинская нормативная информация — информация, предназначенная для единообразного кодирования классификаторов и справочников медицинского назначения (например, классификатор нозологий МКБ-10);
административная и демографическая информация — информация о характеристиках конкретного экземпляра ресурса (например, наименование медицинской организации, адрес места оказания медицинских услуг, фамилия врача, фамилия пациента и т. п.) ;
клинико-статистическая информация — информация о поставленных диагнозах, факте завершения лечения пациента;
клиническая информация — подробная информация о проведённом лечении пациента;
финансовая информация — информация о финансировании деятельности медицинской организации и/или финансировании проведённого лечения пациента.

В данном документе представлены концепции использования в Республике Узбекистан, определённые с помощью обрабатываемых артефактов FHIR.

Профили и расширения — ограничения, расширения и другие условия основных ресурсов и типов данных для использования в Республике Узбекистан.
Терминология — определённые или упомянутые кодовые системы и наборы значений для Республики Узбекистан.

Каждый профиль определяет минимальные обязательные элементы (properties: аттрибуты, свойства) которые ДОЛЖНЫ присутствовать в каждом экземпляре ресурса. Каждый профиль определят терминологические требования (используемые коды и/или кодовые системы и/или наборы значений), которые ДОЛЖНЫ соблюдаться в соответствии с описанием к ресурсу. Требования и рекомендации приведены в описательной части профиля.

Примечание
Определения ресурсов подставлены не строго в формате FHIR, а в формате JSON SCHEMA. Это вызвано тем, что формат JSON SCHEMA легче в понимании, что позволит включить в работу больше заинтересованных сторон.
Данное руководство фокусируется только на одном методе обмена информацией - RESTFull, без поддержки асинхронного использования и GraphQL. Тем не менее IT-Med будет стремиться к максимальному соответствию требованиям стандарта FHIR.
В одной из следующих итераций все ресурсы будут изложены в стандарте FHIR (в виде StructureDefinitions).

Уведомление о мерах обеспечения безопасности

В этом руководстве по внедрению определены элементы данных, ресурсы, форматы и методы обмена медицинскими данными между различными участниками процесса здравоохранения.
Так как медицинские данные являются крайне чувствительными с точки зрения обеспечения информационной безопасности — обеспечение безопасности является ключевой задачей.
Несмотря на то, что данное руководство даёт пользователям возможность соблюдать правила защиты и безопасности данных, её использование не гарантирует соблюдение этих правил.
Эффективное соблюдение требований должно обеспечиваться соответствующими мерами в повседневной деятельности.
Некоторые меры по реализации описаны в данном руководстве, в политике информационной безопасности Министерства здравоохранения, а также в стандарте FHIR.
Необходимо учитывать, что спецификация (включая данное руководство, политику безопасности и стандарт) может повлиять на соблюдение правил безопасности только в технической области стандартизации.
Спецификация не может повлиять на организационные и договорные вопросы.

Примечание
В настоящее время одной из мер обеспечения информационной безопасности является обязательное применение токенов доступа, выдаваемых службой идентификации IT-Med.
А также обязательное применение протоколов защиты транспортного уровня / уровня сокетов (не ниже TLS 1.2 / SSL 3.0) при передаче информации.
В настоящий момент использование токена доступа, выдаваемого службой идентификации IT-Med, является обязательным .
Формат и порядок взаимодействия в контексте информационной безопасности может быть изменен. О любых изменениях будет сообщено дополнительно и заблаговременно.
При этом, мы понимаем, что: 1) только этих мер недостаточно для обеспечения полной безопасности; 2) эти меры могут быть не очень удобными в применении; 3) могут быть и иные решения, но с чего-то нужно начинать. 4) (и поэтому) меры обеспечения безопасности будут совершенствоваться.

Предупреждение!

Нарушение правил, изложенных в настоящем руководстве, включая, но не ограничиваясь, требования о мерах обеспечения безопасности, приведет к блокировке доступа к экосистеме от одного месяца и более (вплоть до перманентной), согласно внутренним регламентам Министерства здравоохранения (и компании IT-MED).

Основные действующие лица

Следующие участники являются частью UZ Core implementation guide:

Запрашивающий или Клиент (Requester, Client): информационная система / приложение, которое инициирует запрос доступа к данным для получения медицинских данных. Это можно рассматривать как клиента во взаимодействии клиент-сервер. Термины «Запрашивающий» и «Клиент» взаимозаменяемы в этом руководстве и не предназначены для ограничения этого участника только приложениями для пациентов и поставщиков. Эти термины необходимо рассматривать как сокращённое обозначение чего-то вроде «пользовательского приложения».
Ответчик или Сервер (Responder, Server): информационная система / приложение, которое отвечает на запрос доступа к данным и предоставляет медицинские данные. Это можно рассматривать как сервер во взаимодействии клиент-сервер. Термины «Ответчик» и «Сервер» взаимозаменяемы в этом руководстве и не предназначены для ограничения этого участника только системой электронных медицинских записей. Та же самая технология может использоваться в платформах координации помощи, системах здравоохранения населения и т. д. Эти термины необходимо рассматривать как сокращённое обозначение чего-то вроде «взаимодействующей платформы здравоохранения».

Любая информационная система / приложение может выступать как в роли Запрашивающего, так и в роли Ответчика.

Регуляторами в отрасли здравоохранения являются Министерство здравоохранения РУз и компания IT-MED.
Техническим держателем ядра экосистемы (ecosystem core holder) является компания IT-MED, уполномоченная соответствущими нормативными актами (в частности, ПП-5000)

Ресурсы

Список основных профилей и расширений типов данных РУз приведён ниже.
Каждый профиль определяет требования к наличию обязательных элементов и терминологии, которые ДОЛЖНЫ быть выполнены.
Требования и рекомендации для каждого профиля представлены в виде нарратива и формальной иерархической таблицы, которая описывает логическое представление содержимого ресурса, а также ссылки на соответствующую терминологию и, возможно, примеры.
Для каждого основного профиля РУз приведён обзор необходимого набора взаимодействий REST API — например, операций поиска и чтения при соблюдении требований основных возможностей для этого профиля.
Техническая документация приведена в формате openAPI.

Техническая документация API здесь

В текущей версии данного руководства определены следующие ресурсы:

Наименование ресурса	Описание ресурса
Patient	Пациент (демографическая и другая административная информация)
Organization	Организация (общая информация)
Practitioner	Медицинский работник (общая информация)
PractitionerRole	Роль медицинского работника (специфические задачи, который медицинский работник может выполнять в данной организации)
Appointment	Бронирование записи на прием
Encounter	Взаимодействие врача и пациента (прием у врача)
Observation	Измерения и простые утверждения о пациенте
Condition	Клиническое состояние (проблема, диагноз) пациента
Procedure	Действие, которое выполняется или было выполнено над пациентом
ServiceRequest	Запрос на обслуживание, такие как диагностические исследования, лечение или операции (включая льготные направления на лечение)
StatisticalForm066	Статистическая карта выписанных из больницы (Форма 066)
DispensaryRegistration	Справка о диспансерном учете пациента

При взаимодействующих с ядром экосистемы (а также другими сервисами IT-Med) ДОЛЖНЫ использоваться только ресурсы, описанные в данном документе, с учетом соответствующего контекста.
Ядро экосистемы (а также сервисы IT-Med) НЕ ОБЯЗАНЫ принимать или передавать ресурсы, не описанные в данном документе или документации к API.
Ресурсы, не описанные в данном документе, МОГУТ использоваться только в локальных информационных системах, не взаимодействующих с ядром экосистемы.
Принятие решения об отнесении той или иной системы к локальной выходит за рамки настоящего руководства. При этом любая информационная система, намеренная взаимодействовать с ядром экосистемы, ДОЛЖНА выполнять требования, изложенные в данном руководстве.

Обратите внимание, что ресурсы или свойства ресурсов, которые отсылаются на страницу TO-DO - в текущей версии не реализуются. Эти ресурсы и/или свойства будут добавлены в будущих выпусках.

Скоро будет также готов сервер с фиктивными данными для тестов без авторизации

Электронное правительство

Отдельно определены следующие ресурсы, получаемые из информационных систем «Электронного правительства». Данные ресурсы не являются ресурсами домена здравоохранения, поэтому НЕ МОГУТ использоваться для передачи информации, но МОГУТ использоваться для обогащения других ресурсов полученными данными.
К ресурсам, получаемым из информационных систем «Электронного правительства», не предъявляются требования, установленные для других ресурсов домена здравоохранения.
Все требования к ресурсам, получаемым из информационных систем «Электронного правительства», описаны в соответствующих схемах.

Наименование ресурса	Описание ресурса
Citizen	Физическое лицо (гражданин РУз или иностранный гражданин, получивший ПИН ФЛ)
Child	Новорожденный

Типы данных

Спецификация FHIR определяет набор типов данных, которые используются для элементов ресурсов. В данном руководстве типы данных МОГУТ быть частично переопределены. Под термином “переопределение” типов данных имеется в виду не только изменение/добавление ключей (key), но и определение их обязательности (required).
Отсутствие описания типа данных в данном документе или документации к API явно означает, что тип данных определен в точности так, как это указано в FHIR.
Описание типа данных в данном документе или документации к API МОЖЕТ означать, что тип данных переопределен.

Идентификаторы

Любой ресурс, хранящийся в ядре экосистемы, ДОЛЖЕН иметь свойство id — логический идентификатор ресурса, присваиваемый Министерством здравоохранения и используемый в URL-адресе этого ресурса при обращении к центральным серверам (глобальный логический идентификатор).
После присвоения, значение этого id никогда НЕ ДОЛЖНО меняться.
Формат id — uuid, как это определено в rfc 4122.
Данный id предназначен для машинного обмена данными.

Бизнес-идентификатор (человеко-читабельный), присваемый Министерством здравоохранения (глобальный бизнес-идентификатор) МОЖЕТ быть реализован в следующих итерациях.
Любые другие идентификаторы (включая, но не ограничиваясь, глобальный бизнес-идентификатор, бизнес идентификаторы и/или логические идентификаторы, присваиваемыми другими компаниями или сервисами) МОГУТ быть записаны в виде элемента массива Identifier.
При отправке запроса на создание любого ресурса, информационная система ДОЛЖНА включить в Identifier элемент, содержащий значение логического идентификатора, присвоенного данной системой.

Общие свойства ресурсов

Любые ресурсы, вне зависимости от указания в профиле, МОГУТ иметь следующие свойства (аттрибуты):

meta — метаданные о ресурсе: версия, дата последнего обновления и т.д, подробнее
implicitRules — набор правил, по которым был создан этот контент (подробнее)
language — язык содержания ресурса (по умолчанию и если не указано, то uz — узбекский-латиница) (подробнее)

Примечание
В текущей реализации для всех языковых тегов, кроме uz, принимаются во внимание только основной тэг языка normal language tags (2 ALPHA or 3 ALPHA), значения субтэгов (script, region, variant, extension, privateuse) МОГУТ игнорироваться.
Полный список языковых тэгов можно посмотреть, например, здесь
Для узбекского языка (uz) принимается во внимание только субтег script (то есть различается uz-Latn и uz-Cyrl; без указания субтега считается uz-Latn), все остальные субтэги МОГУТ игнорироваться.

Методы поиска

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

Обратите внимание, что сервер ядра экосистемы ДОЛЖЕН выполнить запрос клиента, но не обязан это делать. Ecosystem core server SHOULD honor the client’s request, but are not required to do so. Запрос может быть не выполнен, если он содержит не поддерживаемые аттрибуты поиска или сервер не смог распознать критерии поиска.

Стандартные запросы

Для всех ресурсов имеется стандартный запрос по идентификатору, вида:

GET [base]/ResourceType/id

Например, ответом на авторизованный запрос вида:

GET [base]/Patient/1bf5c108-4bc7-11ed-8517-d45d646bc9f2

будет ресурс Patient с идентификатором 1bf5c108-4bc7-11ed-8517-d45d646bc9f2

Механизм поиска

Механизм поиска зависит от типа данных. Основной тип данных, доступный в поиске на данный момент - это строка (string) Аттрибуты, по которым доступен поиск, указаны в технической документации. Например, для ресурса Organization доступны следующие критерии поиска:

Аттрибут	Назначение
name	Наименование организации
address-state	Код области (региона) Республики Узбекистан, включая город Ташкент
address-city	Код района/города, включая районы города Ташкент
address-district	Код махалли районов/городов Республики Узбекистан
partOf	Организация, частью которой является данная организация
type-level	Уровень медицинского обслуживания
type-medical	Тип (категория) медицинской организации
type-service	Тип (категория) медицинских услуг

В простейшем случае поиск выполняется путем выполнения операции GET. Например, ответом на авторизованный запрос вида:

GET [base]/Organization?address-state=UZ-AN

будет список организаций, у которых область в адресе является “Андижанская область”

Ответом на авторизованный запрос вида:

GET [base]/Organization?partOf=dc4a8950-4bc4-11ed-840b-d45d646bc9f2

будет список организаций, которые являются дочерними по отношению к организации с id = dc4a8950-4bc4-11ed-840b-d45d646bc9f2

Сложные запросы

Запросы могут быть более сложными. Для поиска ресурса, одновременно удовлетворяющего нескольким критериям используется символ &, между этими критериями. Символ & означает операцию AND

Например:

GET [base]/Organization?type-service=2&type-medical=3

Критерии запроса могут повторяться, например

GET [base]/Organization?type-service=2&type-service=4

Для запросов может использоваться символ , означающий операцию OR

Внимание! символ , используется только в отношении одного параметра поиска. Например, запрос вида:

GET [base]/Organization?type-service=2,4

будет верным

Однако, запрос вида

GET [base]/Organization?type-service=2,type-medical=3

на данный момент не поддерживается.

Для поиска с логическим ИЛИ (OR) необходимо использовать два отдельных запроса

GET [base]/Organization?type-service=2
GET [base]/Organization?type-medical=3

с пост-обработкой результатов поиска, если это не обходимо.

В следующих версиях будет реализована поддержка более сложных запросов.

Интеграция информационных систем

Концептуальная модель интеграции описана здесь

Техническая документация

Техническая документация API (формат Open API 3.x) доступна здесь

Классификаторы и справочники

Предварительный выпуск справочников и классификаторов доступен по адресу

https://fhir.ssv.uz

для получения списков доступных кодов необходимо отправить GET запрос на адрес

https://fhir.ssv.uz/CodeSystem

или

https://fhir.ssv.uz/ValueSet

Непосредственно кода доступны по идентификатору. Например, справочник административно-территориальных единиц доступен по

https://fhir.ssv.uz/CodeSystem/administrative-territory

Обратите внимание, что в данный момент сервер находится в тестовом режиме! Некоторые ValueSets и CodeSystems могут не содержать все значения и/или их переводы. Полный набор будет доступен не позднее начала ноября. В этом случае фактические коды не изменятся.