CC BY
118
Терминология и стандартизация www.idmz.ru
2015, № 3
Г. д. КОПАНИЦА,
кандидат технических наук, доцент кафедры оптимизации систем управления Института Кибернетики, Национального Исследовательского Томского Политехнического Университета; доцент Томского государственного архитектурно-строительного университета e-mail: [email protected] И. А. СЕМЕНОВ,
кандидат технических наук, директор департамента информационных технологий. Лабораторная служба «Хеликс»
РАЗРАБОТКА ПРОТОКОЛА ОБМЕНА ДАННЫМИ МЕЖДУ ЛАБОРАТОРНОЙ И МЕДИЦИНСКОЙ ИНФОРМАЦИОННЫМИ СИСТЕМАМИ
УДК 005
Копаница Г. Д., Семёнов И. А. Разработка протокола обмена данными между лабораторной и медицинской информационными системами (Институт Кибернетики; Национальный Исследовательский Томский Политехнический Университет; Лабораторная служба «Хеликс»)
Аннотация. В статье приводятся результаты разработки протокола обмена данными между лабораторной и медицинской информационными системами (МИС и ЛИС). Протокол разработан на основе метода взаимодействия компонентов распределённого приложения (REST). Разработанный протокол позволяет автоматизировать процесс формирования заказа на лабораторные исследования на стороне МИС, передачи его для выполнения в ЛИС и получения результатов.
Ключевые слова: Интеграция, ЛИС, МИС, REST. UDC 005
Kopanitsa G. D. Semenov I. A. Implementation of a data exchange protocol for a HIS—LIS data exchange
(Institute of Cybernetics, Tomsk Polytechnic University, Tomsk State University of Architecture and Building; Helix Laboratory Service)
Abstract. The paper presents the results of the implementation of a data exchange protocol. The protocol is based on the Representational State Transfer methodology. It allows automating a data exchange process between a hospital and a laboratory information system (HIS—LIS). The protocol covers all the steps of the process from order definition to the receiving the results of a test. Keywords: integration, LIS, HIS, REST.
F4H
-I_
*
Введение
Интеграция лабораторных и медицинских информационных систем (ЛИС и МИС) позволяет организовать единое информационное пространство, позволяя всем участникам процесса обмена данными повысить эффективность работы [12; 13]. Каждая из взаимодействующих сторон получает специфические преимущества, которые представлены ниже: ■ Лабораторная служба:
• Сокращение издержек на сортировку и предварительную аналитику
• Уменьшение человеческого фактора
• Ускорение выполнения заказа
>
© Г. Д. Копаница, И. А. Семенов, 2015 г.
и информационные
технологии
г
Медицинская организация:
• Уменьшение нагрузки на медицинский персонал
• Полнота ведения электронной карты (ЭМК)
• Отсутствие двойного ввода данных
■ Пациент:
• Оперативное получение результатов
• Возможность использования персональных медицинских записей.
В настоящее время существует множество факторов, затрудняющих разработку эффективных и универсальных интеграционных решений. Среди основных факторов можно выделить следующие:
• Большинство МИС не поддерживают импорт/экспорт медицинских данных без дополнительной доработки
• Фрагментация МИС, использование принципиально различных способов обработки данных
• Узкое распространение стандартных медицинских номенклатур, таких как SNOMed и LOINC
• Медицинские организации не располагают достаточными ресурсами для разработки и внедрения интеграционных решений
• Не решена проблема однозначной идентификации пациента.
Для преодоления этих сложностей разработано большое количество методов, каждый из которых позволяет решить специфическую задачу из приведённого списка. Опыт показывает, что сложно добиться решения всех задач за один шаг, поэтому требуется поэтапное решение, которое бы с каждым шагом поднимало интеграцию на новый уровень. В данной статье предпринята попытка классификации зрелости интеграционных решений, также приводится обзор лучших практик в области интеграции лабораторных и медицинских информационных систем и представлены результаты разработки и внедрения интеграционного протокола.
Методы
Был произведен поиск статей, посвященных интеграции ЛИС и МИС в научных индексах Pubmed и science direct. Для поиска исследований использовались следующие запросы: LIS integration, HIS LIS integration, HIS LIS data exchange. На основе анализа публикаций были определены требования к обмену данными, построена схема взаимодействия и разработан REST ориентированный протокол обмена данными.
Результаты
Обзор опыта ведущих мировых лабораторий позволяет построить идеальную среду, в которой функционирует интеграционное решение. Ниже представлены основные параметры информационной среды обмена медицинскими данными:
• Для передачи данных используются стандарт HL7 [1; 2]
• Кодирование исследований происходит в номенклатуре LOINC (Logical Observations, Identifiers, Names and Codes) [3; 4; 10]
• Методы исследований кодируются в номенклатуре SNOMED (Systematized Nomenclature of Medicine) [8; 11]
• Профили IHE поддерживают однозначную идентификацию пациента [7; 9]
• Результаты исследований представляют собой хорошо структурированные данные, советующие стандарту HL 7 CDA или ISO 13606 [5; 6].
Теперь рассмотрим уровни интеграционных решений (рис. 1). Переход с одного уровня на другой добавляет ценности решению и приближает его к идеальной ситуации.
На первом уровне необходимо обеспечить безопасный обмен данными. Данные могут быть неструктурированными, например, результаты исследований в виде pdf-документа.
На втором уровне ЛИС поддерживает инфраструктуру импорта-экспорта данных для различных МИС. В свою очередь МИС поддерживает логику формирования полноцен-
Терминология и стандартизация
www.idmz.ru
F4H
2015, № 3
4 • Уровень бизнес-процессов
3 • Однозначная идентификация • Семантическая связанность
2 •Инфраструктура
1 •Обмен данными
•Безопасность
Рис. 1. уровни интеграции
ных структурированных электронных заказов и способна корректно обрабатывать результаты исследований с учетом их семантики.
На третьем уровне участники обмена данными используют сервисы однозначной идентификации пациента. Семантическую связанность обеспечивает применение стандартов кодирования медицинских терминов ^О^С для кодирования номенклатуры исследований, SNOMed для кодирования методов исследования). Становится возможным обмен данными между множеством агентов, что позволяет создавать масштабируемые решения регионального, национального и международного уровня.
На четвёртом уровне применяются методы интеграции бизнес-процессов. Это позволяет обеспечить непрерывный процесс медицинской помощи. Для достижения данного уровня требуются большие организационные решения, однако они будут неэффективными без развитых технических решений предыдущих уровней.
схема взаимодействия мис и лис
На рисунке 2 представлена схема взаимодействия МИС и ЛИС. Семантическую связан-
ность систем обеспечивает применение стандартов SNOMed для кодирования методики проведения исследования и LOINC для кодирования номенклатуры исследования.
Протокол обмена данными (API интеграции)
Для реализации обмена медицинскими данными были разработаны единый внешний интерфейс для взаимодействия с внешними информационными системами партнёров, двухфазный https протокол с REST интерфейсом, позволяющий организовать асинхронный обмен данными между МИС и ЛИС, обеспечивающий независимость Системы от изменений внешних медицинских информационных систем.
Для управления ресурсами используются следующие методы HTTP:
• GET - используется для запроса содержимого указанного ресурса
• POST - применяется для передачи пользовательских данных заданному ресурсу;
• PUT - применяется для загрузки содержимого запроса на указанный в запросе URI;
• PATCH - применяется для частичного обновления ресурса;
>
и информационные
технологии
т
LOINC
LOINC SNOMED
Заказ Результат Исследование 1
Исследование 1
Исследование n Исследование n
-----■----- _____.—----
Рисунок 2. схема взаимодействия лис и мис
• DELETE - применяется для удаления ресурса.
Протокол позволяет автоматизировать следующие действия:
• Синхронизацию справочников системы Helix;
• Создание заказов;
• Получение результатов по заказам в целом и конкретным исследованиям в рамках заказа;
Взаимодействие подсистемы API с ЛИС может осуществляться по внутреннему протоколу, в который преобразовываются внешние сообщения. Нагрузка на API интеграции балансируется между несколькими входящими API шлюзами и работает в режиме автобалансировки, обеспечивая отказоустойчивость системы и распределение нагрузки по серверам.
Природа и модель передаваемых объектов
Подход к организации данных и передаче их через протокол тесно связан со строением структур данных в ЛИС. Данные структурированы таким образом, чтобы лучше выразить предметную область; передаваемые через протокол, они являются образом предметной области в своей структуре, мета-описанием, представляющим все её сущности в определённых форматах выбранной модели данных, на основе которой строятся процессы работы с данными.
Одним из главных аспектов при проектировании структуры данных и протокола обмена данными был механизм передачи данных, учитывающий динамические свойства объектов, передаваемых через протокол данных, способных к видоизменению и адаптации под
Терминология и стандартизация www.idmz.ru ,_
2015, № 3 *
предметный мир таким образом, чтобы динамика изменяющегося мира могла отражаться в динамике разработанного протокола.
Выбранная модель данных и построенная на её основе структура данных позволяет сохранить семантическое представление предметной области и предоставляет логическое отображение данных в передаваемых структурах за счёт сохранения логики и семантики связей сущностей друг с другом. Одним из положительных свойств выбранной модели является то, что сущности и связи между ними - достаточный инструмент для описания взаимосвязи данных, позволяют формировать сеть или иерархию сущностей, являющихся необходимым инструментом в медицинской сфере.
Безопасность
Для обеспечения безопасности используется HTTPS с авторизацией посредством выдаваемых Системой клиентских сертификатов. Сертификат контрагента должен соответствовать стандарту X.509 Version 3. Используется базовая авторизация HTTP по логину и паролю согласно стандарту RFC-1945.
двухфазная модель протокола
Создание заказа в системе осуществляется в две фазы. Первая фаза - создание заказа, получение идентификатора заказа в системе. Для асинхронного сообщения успешный ответ означает лишь то, что данные приняты на рассмотрение, проведена валидация и ошибок нет. Вторая фаза - проведение заказа.
Независимое выполнение фаз обеспечивает контроль над созданием заказа и обмен информацией между двумя системами.
состояния заказа
Статусы заказа
Заказ может находиться в следующих статусах (рис. 3):
• Created - заказ создан. Статус назначается на первой фазе создания заказа. В данном состоянии возможно редактирование заказа (текущая версия поддерживает только удаление заказа, это позволяет создать новый заказ с тем же клиентским идентификатором).
• Process - заказ в процессе выполнения. Статус назначается на второй фазе.
Рис. 3. статусы заказа
>
и информационные
технологии
г
Error - возникла ошибка, из-за которой заказ не удалось отправить на обработку. В данном состоянии заказ можно отредактировать, после чего повторно отправить на обработку.
• Completed - заказ выполнен. Этот статус считается финальным.
• Canceled - заказ отменен. Этот статус считается финальным.
Статусы образцов
Образец может находиться в следующих статусах:
• Initial - образец прикреплён к заказу.
• Authorized - исследования по образцу выполнены.
• Rejected - образец забракован либо не был получен лабораторией.
Статусы тестов
Результат выполнения заказа представлен набором тестов и их результатами.
Тест может находиться в следующих статусах:
• Initial - тест назначен.
• Process - выполняется.
• Completed - тест завершён, набор результатов зафиксирован.
• Rejected - тест забракован.
Статусы результатов тестов
Результат теста может находиться в следующих статусах:
• Success - результат успешно получен.
• Rejected - результат теста забракован.
метод работы с нси
Справочник - это, как правило, однородные элементы данных, при помощи которых организуется ввод стандартизированной информации в преаналитике и заказах, а также согласованный обмен данными межу МИС и ЛИС. С помощью справочников происходит сопоставление единиц измерения систем, они задают структуру и семантику общую для разных документов.
Виды передаваемых справочников:
• номенклатура;
• типы контейнеров;
• типы образцов;
• правила обработки образцов;
• правила подготовки пациента;
• протоколы забора образцов;
• единицы измерения;
• правила хранения образцов;
• правила транспортировки образцов;
• типы исследований.
• и др.
метод работы с контрактами и точками забора
Идентификаторы мест забора и номера доступных контрактов выдаются лабораторией и определяют доступные исследования (номенклатуры) и некоторые индивидуальные характеристики исследований для конкретных точек забора. Номер контракта является уникальным среди всех контрактов всех точек доступа.
Запрос на получение списка контрактов:
GET /contracts
GET /contracts/trade}
Формат ответа: {
«ContractCode»:«777», ^идентификатор контракта
«AccountCode»:«888» * идентификатор места забора }
Терминология и стандартизация www idmz ru
—
2015, № 3
*
Запрос по доступным исследованиям и индивидуальным характеристикам номенклатур для определённого контракта:
GET /œntracts/{œntractCode}/nomendatures - список номенклатуры.
GET /œntracts/{œntractCode}/nomendatures/{œde} - информация по коду номенклатуры.
Формат ответа: {
«NomendatureCode»:«111», * Идентификатор номенклатуры «PerfTime»: «222», * Время выполнения «Priœ»:«100,00», *Цена «Exceptions»:
[*Периоды, когда номенклатура не доступна. {
«StartTime»:«15:00»,
«EndTime»:«19:00» },{•••}
]
}
метод работы с заказами Фаза 1. Создание заказа
Запрос на создание заказа: POST /ordering/orders
Формат сообщения: {
«Contractld»: (string), * Идентификатор контракта. Выдаётся лабораторией «ExternalOrderld»: (string), * Уникальный идентификатор заказа МИС «ExternalCreateDate»: (datetime), * Дата и время создания заказа МИС «Patientlnformation»: {* Информация о пациенте «MIS_PATIENT_ID»: (string), * Идентификатор пациента МИС «BIRTH_DATE»: (datetime), * Дата рождения «FIRST_NAME»: (string), * Имя
«Samples»: [* Параметры образцов заказа {
«Label»: (string), * Штрих-код, наклеенный на пробирку «ContainerTypeCode»: (string), * Тип контейнера «SampleTypeCode»: (string), * Тип биоматериала
«Rules»: [* Правила, которые необходимо применить к данному образцу {
«NomenclatureCode»: (string), * Код номенклатуры из справочника номенклатур. «Ruleld»: (int32), * Код правила из справочника номенклатур.
>
и информационные
технологии
г
Фаза 2. Подтверждение заказа
Запрос на проведение заказа:
POST /ordering/orders/{orderId}/confirmation
Ответное сообщение: {
«OrderId»: (string), * Идентификатор заказа «ExternalOrderId»: (string), * Идентификатор заказа МИС «ContractId»: (string), * Идентификатор контракта «Comment»: (string), * Комментарий сотрудника лаборатории «Status»: (string), * Статус заказа
«Samples»: [* Биоматериал заказа {
«SampleId»: (int32), * Идентификатор образца в системе «Label»: (string), * Штрих-код, наклеенный на пробирку «Status»: (string), * Статус образца
«Comment»: (string) * Комментарии сотрудника лаборатории },
]
}
Запрос статуса заказа
Запрос статуса заказа: GET /ordering/orders/{orderId}
Ответное сообщение: {
«OrderId»: (string), * Идентификатор заказа «ExternalOrderId»: (string), * Идентификатор заказа МИС «ContractId»: (string), * Идентификатор контракта «Comment»: (string), * Комментарий сотрудника лаборатории «Status»: (string), * Статус заказа
«ExternalCreateDate»: (datetime), * Дата и время создания заказа МИС
«Samples»: [* Биоматериал, включённый в заказ. {
«SampleId»: (int32), * Идентификатор образца в системе «Label»: (string),* Штрих-код, наклеенный на пробирку «Status»: (string),* Статус образца
«Comment»: (string),* Комментарии сотрудника лаборатории «ContainerTypeCode»: (string),* Тип контейнера «SampleTypeCode»: (string),* Тип биоматериала
}
}
Терминология и стандартизация
www.idmz.ru
F4H
2015, № 3
Удаление заказа
Запрос:
DELETE /ordering/orders/{orderld} Ответ:
Status: 200 OK Отмена заказа
Запрос:
POST /ordering/orders/cancel/{orderId} Ответ:
Status: 200 OK
Запрос результатов выполнения тестов
Запрос результатов выполнения тестов представлен в таблице 1.
Запрос результатов выполнения тестов
Таблица 1
Шаблон URL Метод Тип ответа Описание
/ordering/results/?{фильтры} GET OrderResultInfo[] Результаты заказов.
/ordering/results/{order_num}/results GET OrderResult Результат конкретного заказа по идентификатору заказа.
/ordering/results/ex_{order_num}/results GET OrderResult Результат конкретного заказа по идентификатору заказа внешней системы.
Запрос информации о тестах: {
«Orderld»: (string), * Идентификатор заказа «Contractld»: (string), * Идентификатор контракта «ExternalOrderld»: (string), * Идентификатор заказа МИС
},]
}
Ответ на запрос информации о тестах заказа: {
«Orderld»: (string), * Идентификатор заказа «Comment»: (string), * Комментарий сотрудника лаборатории «OrderStatus»: (string), * Статус заказа «Contractld»: (string), * Идентификатор контракта «ExternalOrderld»: (string), * Идентификатор заказа МИС «Comment»: (string), * Комментарий сотрудника лаборатории Tests: [
{
«AnalysisCode»: (string), * Код показателя
«ReportedName»: (string), * Название показателя в форме результатов «Status»: (string), * Статус
>
[{
и информационные
технологии
т
«NomenclatureCode»: (string), * Номер номенклатуры «SampleId»: (int), * Идентификатор образца в системе «Label»: (string), * Штрих-код, наклеенный на пробирку
Results: [* Результаты {
]
AntibioticTests: [* Тесты на устойчивость к антибиотикам, выполненные по результатам текущего теста {
}
обсуждение
Реализация данного протокола обмена позволяет организовать эффективную интеграцию МИС и ЛИС, решая следующие основные задачи:
• развитие инфраструктуры
Предоставляет различные варианты импорта/экспорта.
• семантическая связанность
Использование номенклатур LOINC
и SNOMED дает возможность взаимодействия с МИС, поддерживающими данные номенклатуры, в том числе с международными регистрами медицинских знаний.
• идентификация
Гибкая система идентификации позволяет идентифицировать исследование по идентификатору МИС, не устанавливая жестких требований к типу и размеру идентификатора.
• Безопасность
Поддержка анонимных заказов.
Алгоритмы шифрования, соответствующие ФЗ 152.
• различия бизнес-процессов
Гибкая модель составления заказа и идентификации биоматериала позволяет наладить процесс обмена данными с медицинскими учреждениями как с централизованной, так и с распределенной идентификацией исследований.
Заключение
В статье представлен протокол обмена данными между МИС и ЛИС для организации эффективного процесса формирования электронного заказа исследований. Реализация данного протокола позволяет организовать обмен данными для обеспечения процесса непрерывного оказания медицинской помощи.
Терминология и стандартизация www.idmz.ru ,_
2015, № 3 *
ЛИТЕРАТУРА
d I Г) /1 Duim М., Boferenbrood F., Goossen W. Т. Continuity of care with HL7 v3 care record for
oncology nursing 11 Stud Health Technol Inform. 2014. T. 201. - C. 476-82.
2. Goossen W., Langford L.H. Exchanging care records using HL7 V3 care provision messages // J Am Med Inform Assoc. 2014. T. 21. № e2. - C. e363"8.
3. Khan A. N., Griffith S. P., Moore C., Russell D., Rosario A. C., Jr., Bertolli J. Standardizing laboratory data by mapping to LOINC // J Am Med Inform Assoc. 2006. Т. 13. № 3. -C. 353-5.
4. Khan A. N, Russell D, Moore C., Rosario A. C., Jr., Griffith S. P., Bertolli J. The map to LOINC project // AMIA Annu Symp Proc. 2003. - C. 890.
5. Kopanitsa G. Arranging ISO 13606 archetypes into a knowledge base // Stud Health Technol Inform. 2014. Т. 205. - C. 33-7.
6. Kopanitsa G. Arranging ISO 13606 archetypes into a knowledge base using UML connectors // Stud Health Technol Inform. 2014. Т. 197. - C. 9-13.
7. Lundqvist A., Steen Carlsson K, Johansen P., Andersson E, Willis M. Validation of the IHE Cohort Model of Type 2 Diabetes and the impact of choice of macrovascular risk equations // PLoS One. 2014. Т. 9. № 10. - C. e110235.
8. Ochs C., Geller J, Perl Y, Chen Y, Xu J, Min H., Case J. Т., Wei Z. Scalable quality assurance for large SNOMED CT hierarchies using subject-based subtaxonomies // J Am Med Inform Assoc. 2014.
9. Schneider G., Heidenreich G., Van De Sand L., Teixeira J., Rathmer A., Bockmann B., Ot-ten H., Bergh B., Thun S. Towards IHE profiles for e-supply in the healthcare domain // Stud Health Technol Inform. 2014. Т. 205. - C. 383-7.
10. Stark M. A look at LOINC // J AHIMA. 2006. Т. 77. № 7. - C. 52, 54-5; quiz 57-8.
11. Stearns M., Fuller J. What's the difference? SNOMED CT and ICD systems are suited for different purposes // J AHIMA. 2014. Т. 85. № 11. - C. 70-2.
12. Yu H., Zhai N. [Study on integration solution of laboratory small system and LIS] // Zhong-guo Yi Liao Qi Xie Za Zhi. 2012. Т. 36. № 4. - C. 259-61.
13. Zhou Q., He J., Liu J. [A study on the LIS and HIS integration] // Sheng Wu Yi Xue Gong Cheng Xue Za Zhi. 2008. Т. 25. № 6. - C. 1294-8.
>
