Система управления подключениями на основе обмена сообщениями
Изобретение относится к системе управления подключениями, в частности для применения в медицинской информационной системе. Техническим результатом является улучшение характеристик системы управления подключениями. Медицинская информационная система включает информационную систему объекта, систему подачи заказов на формирование медицинских изображений и систему архивирования изображений, а система управления подключениями включает устройство ввода для приема сообщений от системы подачи заказов на формирование медицинских изображений, сервер бизнес-логики для генерирования отчета на основе сообщения от устройства ввода, хранилище данных для хранения данных от сервера бизнес-логики, интерфейс сохранения отчетов для обеспечения связи с сервером бизнес-логики и системой архивирования изображений, интерфейс браузера отчетов для обеспечения интерфейса для запроса сервера бизнес-логики и интерфейс статуса отчетов для обеспечения связи с сервером бизнес-логики и установления, обновления и передачи статуса отчетов. 18 з.п. ф-лы, 14 ил.
Область техники, к которой относится изобретение
Настоящее изобретение относится к системе управления подключениями, в частности для применения в медицинской информационной системе.
Предпосылки создания изобретения
Во многих информационных системах для облегчения связи между различными устройствами, программными средствами или и тем и другим используют системы с так называемым, "промежуточным программным обеспечением", "шлюзом" или "программой-посредником". Например, в некоторых случаях для облегчения связи между клиентами и серверами используется промежуточное программное обеспечение определенного типа, чтобы клиенту не требовалось быть осведомленным или знать о работе или структуре серверов, соединенных с сетью. Теоретически по меньшей мере клиент может направить запрос, который промежуточное программное обеспечение обрабатывает и передает соответствующему серверу. Выбранный сервер может генерировать ответ, который передается промежуточному программному обеспечению. Промежуточное программное обеспечение пересылает ответ клиенту.
Краткое изложение сущности изобретения
Упомянутый выше способ реализован в системе с признаками по п.1. Признаки предпочтительных вариантов изобретения изложены в зависимых пунктах.
Несмотря на существование систем с промежуточным программным обеспечением, шлюзами и программами-посредниками (в дальнейшем в целом именуемых системами управления подключениями (connectivity manager), они не всегда удовлетворяют требованиям или применимы в конкретной системе или обстоятельствах. Таким образом, существует потребность в усовершенствованной системе управления подключениями. Существует более конкретная потребность в системе управления подключениями, применимой в системах медицинской информации.
В некоторых вариантах осуществления изобретения описана система управления подключениями, применимая в медицинской информационной системе. Системы медицинской информации могут включать информационную систему объекта, систему подачи заказов на формирование медицинских изображений и систему архивирования изображений. Система управления подключениями может быть рассчитана на использование связи на основе обмена сообщениями для приема сообщений системы подачи заказов на формирование медицинских изображений, сохранения отчетов в системе архивирования изображений и поиска отчетов в системе архивирования изображений.
В дополнительных вариантах осуществления описан способ сохранения первого медицинского отчета в медицинской информационной системе. Система медицинской информации может включать систему подачи заказов на формирование медицинских изображений и систему архивирования изображений. Способ может включать стадии, на которых системе управления подключениями передают первый медицинский отчет в первом сообщении системы подачи заказов на формирование медицинских изображений, создают второе сообщение со вторым медицинским отчетом в зависимости от первого медицинского отчета, передают системе архивирования изображений второе сообщение системы управления подключениями, при этом первый или второй отчет не сохраняют во внутреннем запоминающем устройстве, и сохраняют второй медицинский отчет в системе архивирования изображений, когда система подачи заказов на формирование медицинских изображений не является запрашиваемым устройством, и игнорируют первое сообщение без сохранения первого отчета во внутреннем запоминающем устройстве, когда система подачи заказов на формирование медицинских изображений является запрашиваемым устройством.
В другом варианте осуществления описан способ поиска медицинского отчета в медицинской информационной системе. Система медицинской информации может включать систему подачи заказов на формирование медицинских изображений, систему управления подключениями и систему архивирования изображений. Способ может включать стадии, на которых системе управления подключениями передают запрос на получение отчета, генерируют первый запрос, передают системе подачи заказов на формирование медицинских изображений первый запрос системы управления подключениями и осуществляют поиск отчета в системе подачи заказов на формирование медицинских изображений, когда система подачи заказов на формирование медицинских изображений является запрашиваемым устройством, генерируют второй запрос, передают системе архивирования изображений второй запрос системы управления подключениями и осуществляют поиск отчета в системе архивирования изображений, когда система подачи заказов на формирование медицинских изображений не является запрашиваемым устройством.
В еще одном варианте осуществления описана система управления подключениями, применимая в медицинской информационной системе. Система медицинской информации может включать систему подачи заказов на формирование медицинских изображений и систему архивирования изображений. Система управления подключениями может включать устройство ввода, рассчитанное на взаимодействие с системой подачи заказов на формирование медицинских изображений и преобразование сообщения из первого формата во второй формат, процессор бизнес-логики, рассчитанный на взаимодействие с устройством ввода и генерирование отчета, хранилище данных, рассчитанное на взаимодействие с сервером бизнес-логики, интерфейс сохранения отчетов, рассчитанный на взаимодействие с сервером бизнес-логики и системой архивирования изображений, интерфейс браузера сообщений, рассчитанный на взаимодействие с сервером бизнес-логики и интерфейс статуса сообщений, рассчитанный на взаимодействие с сервером бизнес-логики.
В некоторых вариантах осуществления также описана система управления подключениями, применимая в медицинской информационной системе. Система медицинской информации включает запрашиваемую систему подачи заказов на формирование медицинских изображений и систему архивирования изображений. Система управления подключениями может быть способна принимать первое сообщение системы подачи заказов на формирование медицинских изображений, включающее первый отчет, и, если указанный в первом отчете первый статус не соответствует заданному статусу, генерировать второй отчет в зависимости от первого отчета и передавать системе архивирования изображений второе сообщение, включающее второй отчет.
Другие признаки и особенности вариантов осуществления изобретения станут понятны специалисту в данной области техники после ознакомления со следующим далее описанием, формулой изобретения и приложенными чертежами, на которых:
Краткое описание чертежей
на фиг.1-4 показаны схематические иллюстрации типичных систем медицинской информации,
на фиг.5 - схематические иллюстрации примера компонентов системы управления подключениями,
на фиг.6-13 - схематические иллюстрации примеров потоков данных между компонентами системы медицинской информации.
Подробное описание изобретения
Подразумевается, что варианты осуществления изобретения не ограничены в том, что касается подробностей конструкции и схемы расположения компонентов, которые приведены далее в описании или проиллюстрированы на чертежах. Изобретение допускает другие варианты осуществления, и оно может быть применено на практике или реализовано различными способами. Также подразумевается, что используемые в описании обороты и термины имеют описательное, а не ограничительное значение. Применяемые в описании термины "включающий", "содержащий" или "имеющий" и их варианты относятся к перечисляемым далее предметам и их аналогам, а также дополнительным предметам. Термины "соединенный", "связанный" и "смонтированный" и их варианты используются в настоящем описании расширительно и относятся к прямым и косвенным соединениям, связям и монтажу. Кроме того, значение терминов "соединенный", и "связанный" и их вариантов не ограничено физическими или механическими соединениями или связями.
На фиг.1 проиллюстрирован пример системы 20 медицинской информации. Система 20 включает информационную систему 22 объекта (ИСО), систему 24 подачи заказов на формирование медицинских изображений (СПЗ), систему 26 управления подключениями, систему 28 архивирования изображений (САИ), средство 30 формирования изображений и рабочую станцию 32. В некоторых вариантах осуществления ИСО 22 включает информационную систему больницы (ИСБ), рассчитанную на получение демографических данных пациентов, графика процедур и исследований результатов процедур, контроль выставления счетов и финансовых показателей, связанных с услугами, предоставляемыми пациентам, и т.п. ИСО 22 способна осуществлять связь с СПЗ 24 для составления графика процедур и исследований результатов процедур для пациентов, которым требуются конкретные услуги. Например, СПЗ 24 может включать систему радиологической информации (СИР), рассчитанную на составление графика, регистрацию и координацию радиологических процедур и исследований. В некоторых вариантах осуществления функциональные возможности ИСО 22 и СПЗ 24 могут быть объединены в общем компоненте системы 20. В некоторых вариантах осуществления ИСО 22 и/или СПЗ 24 также являются запрашиваемыми устройствами и рассчитаны на принятие запросов и предоставление данных в ответ на запросы.
СПЗ 24 способна осуществлять связь с системой 26 управления подключениями. Система 26 управления подключениями может выступать в качестве средства промежуточного программного обеспечения (middleware) между СПЗ 24 и САИ 28. Как показано на фиг.1, ИСО 22 также может осуществлять опосредованную связь с системой 26 управления подключениями через СПЗ 24. В некоторых вариантах осуществления ИСО 22 осуществляет непосредственную связь с системой 26 управления подключениями, минуя СПЗ 24. Система 26 управления подключениями может осуществлять обработку и/или форматирование сообщений, которыми обмениваются СПЗ 24 и САИ 28. В отличие от связи клиент-сервер, когда клиент запрашивает у сервера данные (например, имело ли место определенное событие или внес ли сервер изменения), при осуществлении связи на основе обмена сообщениями компонент передает сообщение, когда ему становится известно о произошедшем событии (например, поступлении пациента, назначении процедуры, завершении процедуры и т.д.). При помощи связи на основе обмена сообщениями система 26 управления подключениями может прослушивать и ожидать сообщение от СПЗ 24, обрабатывать сообщение и пересылать сообщение САИ 28. В некоторых вариантах осуществления данные, поступающие от ИСО 22 и/или СПЗ 24, упаковывают и передают согласно специальному протоколу. Для форматирования исходящих сообщений ИСО 22 и СПЗ 24 могут использовать протокол состояния здоровья уровня 7 (HL7). В условиях медицинского или лечебного учреждения ИСО 22 и/или СПЗ 24 может передавать сообщение HL7 о поступлении, переводе или выписке пациента, о назначении процедуры, завершении процедуры или других событиях. Сообщение HL7 может включать данные пациента, данные составления графика, данные процедур и любые их сочетания. Далее проиллюстрировано типичное сообщение HL7, которое может быть генерировано при поступлении пациента в медицинское учреждение.
Протокол HL7 задает тип данных, которые могут быть включены в сообщение, но не устанавливает и не предъявляет требования к формату данных. Две программы или системы могут генерировать сообщение HL7, касающееся перевода пациента, при этом оба сообщения содержат одинаковые данные, но их формат может различаться. Например, при регистрации пола пациента одна программа или система может как обозначать его как "мужской" или "женский", а другая программа - как "М" или "Ж".
В некоторых вариантах осуществления САИ 28 структурирует данные иначе, чем СПЗ 24, и может требовать, чтобы входящие сообщения были упакованы иначе, чем при их передаче системой 24 подачи заказов на формирование медицинских изображений. Система 26 управления подключениями может выступать в качестве адаптера для преобразования сообщений, передаваемых СПЗ 24, в сообщения, приемлемые для САИ 28. В некоторых вариантах осуществления система 26 управления подключениями преобразует сообщения HL7, поступающие от СПЗ 24, в стандарт DICOM (формирование, передача и хранение медицинских изображений), приемлемый для САИ 28. Система 26 управления подключениями также может быть рассчитана на преобразование поступающий сообщений в один или несколько определяемых поставщиком форматов, которые позволяют обмениваться данными и использовать данные нескольким системам, сетям и платформам.
Система 26 управления подключениями также может объединять данные множества сообщений и/или множества устройств ввода и/или баз данных для создания единого сообщения для САИ 28. В некоторых вариантах осуществления система 26 управления подключениями принимает от СПЗ 24 сообщение HL7, содержащее данные процедуры, и объединяет их с данными пациента для создания исследования или отчета, который поступает на хранение в САИ 28. В некоторых вариантах осуществления система 26 управления подключениями не обеспечивает кратковременное или длительное хранение результатов процедуры и/или отчетов и может не сохранять результаты и/или отчеты во внутреннем запоминающем устройстве. Вместо использования внутреннего запоминающего устройства для хранения исследований результатов процедур и/или отчетов система 26 управления подключениями может целиком полагаться на функциональные данные хранилища данных внешних устройств, таких как САИ 28 и/или СПЗ 24.
После приема сообщений и/или данных от системы 26 управления подключениями или других устройств САИ 28 может действовать как хранилище поступивших данных. В некоторых вариантах осуществления САИ 28 может включать одну или несколько таблиц языка структурированных запросов (SQL) для хранения данных, поступивших от системы 26 управления подключениями. САИ 28 также может получать данные от одного или нескольких средств 30 формирования изображений. Средство 30 формирования изображений может включать оборудование для компьютерного томографическое сканирования, ультразвуковое оборудование, оборудование для магнитно-резонансной томографии, рентгеновское оборудование и т.п. В ходе процедуры, которую проходит пациент, изображения или образы и данные поступают в средство 30 формирования изображений, которое передает изображения САИ 28. Для передачи полученных изображений САИ 28 средство 30 формирования изображений может использовать протокол DICOM. В некоторых вариантах осуществления одно или несколько средств 30 формирования изображений также поддерживают связи с системой 26 управления подключениями для получения рабочих списков. Рабочие списки могут включать график процедур, осуществляемых с использованием средства 30 формирования изображений. СПЗ 24 или ИСО 22 могут передавать системе 26 управления подключениями рабочие списки для распространения. Система 26 управления подключениями также может генерировать рабочие списки для средства 30 формирования изображений на основании данных, поступивших от СПЗ 24, ИСО 22 или другого внешнего устройства или программы. В некоторых вариантах осуществления система 26 управления подключениями может поддерживать связь со средством 30 формирования изображений через САИ 28. Система 26 управления подключениями также может сохранять рабочий список в САИ 28, в котором средство 30 формирования изображений при необходимости может найти рабочий список. Средство 30 формирования изображений также может получать рабочий список непосредственно от СПЗ 24 и/или ИСО 22. Средство 30 формирования изображений также может сообщать статус и/или результаты процедуры непосредственно СПЗ 24 и/или ИСО 22 или через системы 26 управления подключениями.
Для просмотра и/или редактирования данных, хранящихся в САИ 28, может использоваться рабочая станция 32. Например, врач, медицинский работник или специалист может использовать рабочую станцию 32 для передачи САИ 28 запроса на получение изображений и/или исследований результатов процедур. Врач также может иметь возможность находить и распечатывать данные на рабочей станции 32. В некоторых вариантах осуществления рабочая станция 32 поддерживает связь непосредственно с САИ 28, а не через системы управления подключениями, при этом САИ 28 пересылает системе 26 управления подключениями сообщения, поступившие от рабочей станции 32.
Подразумевается, что система 20 может включать дополнительные компоненты, такие как множество информационных систем 22 объекта, систем 24 подачи заказов на формирование медицинских изображений, систем 28 архивирования изображений, рабочих станций 32, модемов, маршрутизаторов, серверов, печатающих устройств и т.д. Как показано на фиг.2, система 26 управления подключениями может опосредованно поддерживать связь с компонентами системы 20, такими как ИСО 22 и СПЗ 24. В некоторых вариантах осуществления система 20 включает шлюз или промежуточное программное обеспечение 34. Шлюз 34 служит адаптером между устройствами, которые осуществляют связь с использованием пользовательских или внутренних протоколов или форматов, и системой 26 управления подключениями. Шлюз 34 может представлять собой шлюз или адаптер унаследованного или пользовательского формата, распознающий пользовательские протоколы или форматы, используемые системами, такими как информационная система объекта, система подачи заказов на формирование медицинских изображений и/или средство формирования изображений, которые осуществляют связь с использованием пользовательских или унаследованных форматов или протоколов. Шлюзы 34 также могут распознавать или быть настроены на распознавание стандартных протоколов, чтобы система 26 управления подключениями могла поддерживать связь со шлюзом 34. В некоторых вариантах для осуществления для связи со шлюзом 34 система 26 управления подключениями использует связь на основе обмена сообщениями. Система 26 управления подключениями и шлюз 34 могут обмениваться сообщениями DICOM и/или HL7. Подразумевается, что помимо протоколов связи на основе обмена сообщениями система 26 управления подключениями может использовать для связи со шлюзом 34 сообщения и протоколы связи других типов. Как показано на фиг.2а, в некоторых вариантах осуществления система 26 управления подключениями через шлюз 34 осуществляет связь с одной или несколькими информационными системами 22 объекта и/или одной или несколькими системами 24 подачи заказов на формирование медицинских изображений. Система 20 также может включать сервер авторизации (например, сервер облегченного протокола доступа к каталогам (LDAP)), который ведет данные авторизации, такие как имена пользователей, пароли, права доступа и т.п. Система 20 также может включать хранилище файлов регистрации выполняемых действий для ведения журналов контроля права перевода и возможности учета медицинской страховки (HIPPA). В некоторых вариантах осуществления система 26 управления подключениями передает записи контрольных данных в хранилище файлов регистрации выполняемых действий с использованием протокола системного журнала, который соответствует протоколу пользовательских дейтаграмм (UDP). Проиллюстрированные соединения между компонентами также могут представлять собой проводные и/или беспроводные соединения с использованием одной или нескольких сетей или систем связи, таких как Интернет, телефонная сеть, беспроводные сети, спутниковые сети, сети кабельного телевидения и различные другие ведомственные или общедоступные сети.
На фиг.3 проиллюстрирована другая типичная система 40 медицинской информации. В некоторых вариантах осуществления система 40 поддерживает инициативу "Интегрированное медицинское учреждение" (IHE от англ. "Integrating the Healthcare Enterprise"). Инициатива IHE является попыткой усовершенствовать способность к взаимодействию средств и информационных систем и устанавливает определенные структуры акторов и транзакции между акторами во время последовательности выполняемых действий. Акторы определяют функциональные возможности и обязанности средств системы, а транзакции определяют возможность взаимодействия между акторами во время последовательности выполняемых действий. В частности, система 40 поддерживает концепции интегрирующих профилей плановой последовательности выполняемых действий (SWF) и согласования информации о пациенте (PIR). В контексте интегрирующих профилей система 26 управления подключениями, САИ 28 и рабочая станция 32 играют две роли. Первой из них является роль администратора изображений/актора 42 архива IHЕ, а второй - роль администратора 43 выполненных шагов процедуры (ВШП) IHE. В качестве выходных данных проведенной процедуры администратор изображений/актор 42 архива IHЕ может получать наглядные объекты. Наглядные объекты могут включать изображения, результаты и/или исследования результатов процедуры, графики процедур, обновленные данные пациента и т.п. Администратор изображений/актор 42 архива IHE может получать наглядные объекты от актора 44 средства сбора данных IHЕ или актора 45 планировщика ведомственной системы/выполнителя заказов IHЕ. Актор 44 средства сбора данных IHЕ может быть аналогичен описанному выше средству 30 формирования изображений, а актор 45 планировщика ведомственной системы/выполнителя заказов IHЕ может быть аналогичен также описанной выше СПЗ 24. Администратор изображений/актор 42 архива IHЕ и, в частности, САИ 28 обеспечивают хранение и управления наглядными объектами.
В некоторых вариантах осуществления администратор 43 ВШП получает данные процедур. Администратор 43 ВШП может обмениваться данными процедур с актором 44 средства сбора данных IHЕ до, во время и после проведения процедуры. Администратор 43 ВШП также может обмениваться данными процедур, касающимися составления графика и транзакций пациента, с актором 45 планировщика ведомственной системы/выполнителя заказов IHЕ. Актор 45 планировщика ведомственной системы/выполнителя заказов IHЕ также может получать данные составления графика и данные пациента от актора 46 поступления, выписки и перевода (ПВП) IHЕ и/или актора 47 подателя заказов. Актор 46 ПВП IHЕ и актор 47 подателя заказов могут обеспечивать функциональные возможности, аналогичные описанным выше функциональным возможностям ИСО 22. Администратор 43 ВШП и, в частности, система 26 управления подключениями могут действовать как адаптер между актором 44 средства сбора данных IHЕ и актором 45 планировщика ведомственной системы/выполнителя заказов IHЕ. Система 26 управления подключениями может быть рассчитана на прием сообщений, передаваемых актором 44 средства сбора данных IHE (например, сообщений DICOM), и передачу сообщений актору 45 планировщика ведомственной системы/выполнителя заказов IHE в соответствующем формате (например, HL7).
Как также показано на фиг.3, актор 45 планировщика ведомственной системы/выполнителя заказов IHE также может поддерживать связь с актором 44 средства сбора данных IHE без установления перед этим связи с администратором 43 ВШП или, в частности, системой 26 управления подключениями. Актор 45 планировщика ведомственной системы/выполнителя заказов IHE может обмениваться рабочими списками средств и транзакциями выполненных шагов процедуры средства (ТВШП) непосредственно с актором 44 средства сбора данных IHЕ.
На фиг.4 проиллюстрирована другой пример системы 48 медицинской информации, обеспечивающей среду, не являющуюся средой IHE. Система 48 аналогична описанной выше системе 20, проиллюстрированной на фиг.1 и 2, и обеспечивает связь между стороной ввода, включающей ИСО 22 и СПЗ 24, и стороной вывода, включающей одно или несколько средств 30 формирования изображений, через систему 26 управления подключениями. В отличие от системы 40, проиллюстрированной на фиг.3, в системе 48 система 26 управления подключениями передает рабочий список средству 30 формирования изображений, а не актору 45 планировщика ведомственной системы/выполнителя заказов IHE. Как описано выше, ИСО 22 или СПЗ 24 могут передавать рабочий список системе 26 управления подключениями для его доставки средству 30 формирования изображений. Система 26 управления подключениями также может создавать рабочий список для средства 30 формирования изображений.
На фиг.5 проиллюстрированы примеры компонентов или модулей системы 26 управления подключениями. В некоторых вариантах осуществления система 26 управления подключениями включает устройство 50 для входящих сообщений, устройство 51 для исходящих запросов, сервер бизнес-логики (BLS) 52, хранилище данных или память (DS) 54, базу 56 данных пациента, базу 57 данных хранящихся процедур, интерфейс 58 сохранения отчетов, интерфейс 59 статуса отчетов и интерфейс 60 браузера отчетов. Устройство 50 для входящих сообщений может быть рассчитано на прослушивание и прием сообщений, поступающих от устройств ввода, таких как ИСО 22 или СПЗ 24. Устройство 50 для входящих сообщений также может быть рассчитано на синтаксический анализ и интерпретацию данных, содержащихся в принимаемом сообщении, с целью генерирования сообщения во внутреннем формате системы 26 управления подключениями. В некоторых вариантах осуществления устройство 50 для входящих сообщений может переформатировать принимаемое сообщение в сообщение согласно протоколу передачи пар "атрибут-значение" (AVP) с упорядоченными элементами, такого как протокол общей структуры Mitra (MCF). Устройство 50 для входящих сообщений также может переформатировать принимаемые сообщения в другой стандарт или пользовательские протоколы.
Устройство 51 для исходящих запросов может действовать в обратном порядке по сравнению с описанным порядком действия устройства 50 для входящих сообщений. В некоторых вариантах осуществления устройство 51 для исходящих запросов преобразует внутренние запросы и/или сообщения системы 26 управления подключениями, находящиеся во внутреннем формате, в запросы и/или сообщения, приемлемые для устройства ввода, такого как СПЗ 24. Устройство 51 для исходящих запросов также может быть рассчитано на прием ответов на запросы, поступающих от устройств ввода. Ответы на запросы, поступающие от устройства 51 для исходящих запросов, также могут передаваться устройству 50 для входящих сообщений, как это описано выше. После форматирования поступившего запроса устройство 50 для входящих сообщений может пересылать сообщение BLS 52. Помимо данных, переданных устройством ввода, форматированное сообщение может включать команды для BLS 52 с указанием того, как следует поступить с данными. Например, если СПЗ 24 передает результаты процедуры, устройство 50 для входящих сообщений может передать BLS 52 команду создать и сохранить в САИ 28 отчет на основании поступивших данных. Поступившие данные также могут быть переданы BLS 52 вместе с командой обновить ранее сохраненный отчет.
BLS 52 может затребовать дополнительные данные помимо данных, переданных устройством 50 для входящих сообщений, и может запросить DS 54 получить дополнительные данные. BLS 52 может запросить или передать сообщение DS 54 с использованием протокола MCF или другого протокола обмена сообщениями. DS 54 может действовать как уровень доступа к базе данных AVP. DS 54 может принимать сообщения MCF от BLS 52 и использовать данные, содержащиеся в сообщении, для запроса, обновления или изменения базы 56 данных пациента. База 56 данных пациента может содержать данные пациента, данные заказа процедуры или данные исследования результатов процедуры и/или другие демографические данные. База 56 данных пациента также может содержать результаты и/или исследования результатов прошлых процедур, которые могут быть объединены с результатами текущей процедуры. DS 54 может переводить сообщения MCF на стандартный язык доступа к базам данных, распознаваемый базой 56 данных пациента, такой как открытый интерфейс взаимодействия с базами данных (ODBC). DS 54 также может переформатировать данные, полученные от базы 56 данных пациента в формат, приемлемый для BLS 52, такой как формат MCF.
BLS 52 может быть рассчитан на создание отчетов на основании данных, поступивших от устройств ввода, и любых дополнительных данных, полученных от баз данных пациентов. В некоторых вариантах осуществления отчет создается на языке разметки, таком как язык разметки гипертекста (HTML) или расширяемый язык разметки (XML). Созданные отчеты через интерфейс 58 сохранения отчетов могут быть переданы САИ 28 для хранения. Интерфейс 58 сохранения отчетов может передавать созданные отчеты с использованием приемлемого для САИ 28 протокола обмена сообщениями на основе языка разметки, такого как простой протокол доступа к объектам (SOAP).
Интерфейс 59 статуса отчетов также может поддерживать связь с САИ 28 для установления и обновления статуса сохраненного отчета. BLS 52 может передавать интерфейсу 59 статуса отчетов команды обновления статуса, а интерфейс 59 статуса отчетов может передавать данные САИ 28. В некоторых вариантах осуществления интерфейс 59 статуса отчетов поддерживает связь с САИ 28 с использованием протокола DICOM и может включать адаптер DICOM, такой как адаптер Agfa AS300. Статус отчета может храниться отдельно от фактического отчета в справочной таблице сохраненных отчетов. Отчет может быть помечен как предварительный, только для чтения, окончательный и т.п. В статусе отчета может быть указана операция, которая может быть осуществлена с отчетом. Например, предварительный отчет может быть недоступен для просмотра или доступен только для конкретных пользователей. Отчет, имеющий статус "окончательный", также может быть защищен от обновления. В некоторых вариантах осуществления интерфейс 60 браузера отчетов служит интерфейсом рабочей станции 32 для запроса отчетов, хранящихся в САИ 28. Для получения доступа и просмотра отчета рабочая станция 32 может взаимодействовать с браузером отчетов, установленным на сервере отчетов или веб-сервере. Интерфейс 60 браузера отчетов может включать интерфейс браузера активных серверных страниц (ASP), обеспечивающий интерфейс запроса протокола передачи гипертекста (HTTP) для поиска одного или нескольких отчетов для отображения на HTML. В некоторых вариантах осуществления интерфейс запроса позволяет пользователю запрашивать отчет на основании опознавательного и/или входящего номера пациента.
Интерфейс 60 браузера отчетов, а также другие компоненты системы 26 управления подключениями могут быть рассчитаны на использование общей платформы, способной улучшать возможность взаимодействия и связи между компонентами. Например, для обеспечения общего интерфейса с интерфейсом 58 сохранения отчетов браузер отчетов может быть заключен в оболочку службы. Net web. Интерфейс 60 браузера отчетов также может включать в целом независимую от языка прикладную программу с компонентной структурой, такую как программа СОМ+. Прикладная программа с компонентной структурой может включать один или несколько объектов или дискретных компонентов, каждый из которых имеет уникальное название и известный интерфейс, позволяющий другим программам и компонентам получать доступ к его свойствам.
В некоторых вариантах осуществления интерфейс 60 браузера отчетов принимает от рабочей станции 32 запрос на получение отчета и пересылает запрос или создает и передает форматированный запрос или сообщение BLS 52. BLS 52 в свою очередь может находить заданный отчет в САИ 28 и возвращать отчет интерфейсу 60 браузера отчетов. В некоторых вариантах осуществления интерфейс 60 браузера отчетов пересылает возвращенный отчет рабочей станции 32, которая отображает его для пользователя. Пользователь также может иметь возможность изменять отображаемый отчет на одной из рабочих станций 32.
При помощи рабочей станции 32 и периферийный устройств ввода и вывода, таких как клавиатура, устройство управления курсором и/или печатающее устройство (не показаны) пользователь может изменять данные, добавлять комментарии, присоединять изображения, распечатывать отчет или т.п. Интерфейс 60 браузера отчетов также может быть рассчитан на отображение отчетов во множестве форматов с учетом происхождения запроса на получение отчета. Например, если пользователь обменивается сообщениями с системой 26 управления подключениями через Интернет, локальную сеть или другое сетевое соединение, интерфейс 60 браузера отчетов может создавать отчет, вернувшийся от BLS 52, в формате переносимого документа (PDF) или другом общем формате, не требующем специальной программы отображения для просмотра отчета на рабочей станции 32. Вместе с тем, в некоторых вариантах осуществления редактирование отображенного отчета может быть доступно только при использовании специальной программы просмотра отчетов. Рабочая станция 32 может передавать запросы и/или сообщения интерфейсу 60 браузера отчетов с использованием HTTP или подобных протоколов, таких как протокол управления передачей/протокол Интернет (TCP/IP). Для связи с BLS 52 интерфейс 60 браузера отчетов также может использовать HTTP, MCF, HL7 или другие протоколы передачи. В базе 57 данных хранящихся процедур могут храниться процедуры передачи системе 26 управления подключениями запроса на получение отчетов. В некоторых вариантах осуществления, чтобы создать запрос на получение отчета с целью поиска для просмотра и/или изменения, программа просмотра, установленная на сервере приложений/веб-сервере, взаимодействует с базой 57 данных хранящихся процедур. База 57 данных хранящихся процедур осуществляет доступ к процедуре, которую форматируют, как это требуется для поиска отчета, который выбрал пользователь или внешнее устройство с использованием программы просмотра, и пересылают BLS 52. BLS 52 обслуживает процедуру, и возвращает данные (т.е. выбранный отчет) программе просмотра. Программа просмотра и база 57 данных хранящихся процедур может позволять пользователям направлять системе 26 управления подключениями запросы на получение отчетов и другие сообщения через Интернет, локальную сеть или другое сетевое соединение. Как это описано применительно к интерфейсу 60 браузера отчетов, пользователь также может иметь возможность изменять отчет, отображаемый программой просмотра. В некоторых вариантах осуществления программа просмотра также может создавать отображаемый для пользователя документ PDF, содержащий возвращенный отчет.
Подразумевается, что система 26 управления подключениями может включать дополнительные компоненты и может включать множество описанных выше компонентов. Например, система 26 управления подключениями может включать множество интерфейсов сохранения отчетов. Каждый интерфейс сохранения отчетов может обеспечивать различное форматирование вывода для различных назначений. В некоторых вариантах осуществления система 26 управления подключениями рассчитана на вывод принимаемых данных на множество устройств вывода и может использовать отдельный интерфейсов сохранения отчетов для каждого назначения. Система 26 управления подключениями также может формировать цепочку интерфейсов сохранения отчетов для создания адаптера между различными протоколами обмена сообщениями или связи. Например, система 26 управления подключениями может включать один интерфейс сохранения отчетов, рассчитанный на прием сообщений AVP и создание соответствующих сообщений SOAP, и другой интерфейс сохранения отчетов, рассчитанный на прием сообщений SOAP и создание соответствующих документов, процедур или команд SQL. Функциональные возможности, которые обеспечивают компоненты системы 26 управления подключениями, как это описано выше, можно сочетать разнообразными способами и в разнообразных вариантах.
На фиг.6-13 проиллюстрированы взаимодействия и потоки данных между компонентами системы медицинской информации, такими как проиллюстрированы на фиг.1-5. На фиг.6 проиллюстрирован процесс сохранения в САИ 28 отчета, включающего результаты процедуры и/или исследования результатов процедуры, который передала СПЗ 24 или другая система сбора информации. В некоторых вариантах осуществления на первом шаге процесса СПЗ 24 генерирует сообщение 70 RESULTS, содержащее результаты завершенной процедуры. Сообщение 70 RESULTS может представлять собой сообщение в формате HL7, формате HTTP или подобном формате. В некоторых вариантах осуществления СПЗ 24 передает результаты процедуры системе 26 управления подключениями в сообщении о незатребованном заказе (ORU) в формате HL7. В некоторых вариантах осуществления сообщение 70 RESULTS, передаваемое СПЗ 24, принимает устройство 50 для входящих сообщений системы 26 управления подключениями. Как описано выше, устройство 50 для входящих сообщений может быть рассчитано на переформатирование данных, содержащихся в сообщении 70 RESULTS, в данные, которые распознает BLS 52. В некоторых вариантах осуществления устройство 50 для входящих сообщений переформатирует сообщение, принимаемое от СПЗ 24, в сообщение согласно протоколу передачи пар атрибут/значение с упорядоченными элементами, такому как протокол MCF. На следующем шаге процесса устройство 50 для входящих сообщений создает сообщение 72 CREATE_RESULTS, полностью или частично включающее содержание сообщения 70 RESULTS, и передает сообщение 72 CREATERE_SULTS BLS 52. Сообщение 72 CREATE_RESULTS также может включать команды обработки для BLS 52.
После приема сообщения 72 CREATE_RESULTS BLS 52 определяет, является ли устройство ввода (т.е. СПЗ 24), передавшее сообщение 70 RESULTS, запрашиваемым устройством. Как описано выше, ИСО 22 и/или СПЗ 24 могут являться запрашиваемыми устройствами, и могут быть способны принимать и обслуживать запросы или сообщения. Чтобы решить, следует ли сохранять отчет в САИ 28, BLS 52 может использовать запрашиваемую конфигурацию устройства ввода. Если запрашиваемое устройство ввода передает сообщение с результатами процедуры, результаты могут быть сохранены в запрашиваемом устройстве ввода и, таким образом, могут быть при необходимости извлечены из устройства ввода. Однако если устройство ввода не является запрашиваемым, результаты процедуры могут быть недоступны для извлечения из устройства ввода. Таким образом, чтобы впоследствии можно было при необходимости извлечь данные, результаты могут быть сохранены в САИ 28. Если устройство ввода не является запрашиваемым, BLS 52 может получать от DS 54 дополнительные данные отчета. BLS 52 может генерировать сообщение 74 GET_STUDY_REQUEST и пересылать сообщение 74 DS 54. Сообщение 74 GET_STUDY_REQUEST может представлять собой сообщение в формате MCF или другое форматированное сообщение, приемлемое для DS 54. Сообщение 74 GET_STUDY_REQUEST может уточнять демографическую информацию о пациенте и/или данные исследования поступивших результатов процедуры для получения из базы 56 данных пациента. Как описано выше, DS 54 может являться уровнем доступа, и может использовать данные из сообщения 74 GET_STUDY_REQUEST для запроса базы 56 данных пациента. DS 54 генерирует сообщение 76 DATABASE_ACCESS на стандартном языке доступа к базам данных, который распознает база 56 данных пациента, таком как открытый интерфейс взаимодействия с базами данных (ODBC). В некоторых вариантах осуществления база 56 данных пациента передает извлеченные данные DS 54 в сообщении 78 DATABASE_DATA. DS 54 может форматировать возвращенные данные и пересылать данные BLS 52 в сообщении 80 GET_STUDY_REPLY.
BLS 52 принимает от DS 54 сообщение 80 GET_STUDY_REPLY и создает отчет с использованием данных, возвращенных из DS 54, и данных, полученных в сообщении 72 CREATE_RESULTS. Как описано выше, отчет может быть генерирован на языке разметки, таком как язык разметки гипертекста (HTML) или расширяемый язык разметки (XML). После создания отчета BLS 52 передает интерфейсу 58 сохранения отчетов сообщение 82 OUTPUT_REPORT, содержащее созданный отчет. В некоторых вариантах осуществления сообщение 82 OUTPUT_REPORT может представлять собой сообщение в формате AVP.
Интерфейс 58 сохранения отчетов принимает сообщение 82 OUTPUT_REPORT, содержащее отчет, и пересылает отчет САИ 28 в сообщении 84 STOREREPORT. В некоторых вариантах осуществления сообщение 84 STORE_REPORT представляет собой документ или процедуру SQL для сохранения отчета и любых соответствующих метаданных в таблице SQL, содержащейся в САИ 28. Как описано выше, интерфейс 58 сохранения отчетов также может создавать промежуточное сообщение согласно определенному протоколу, такое сообщение в формате SOAP, и пересылать промежуточное сообщение другому интерфейсу сохранения отчетов.
После того, как интерфейс 58 сохранения отчетов передает САИ 28 сообщение 84 STORE_REPORT, САИ 28 генерирует для интерфейса 58 сохранения отчетов ответное сообщение 86 REPORT_STORED. В сообщении 86 REPORT_STORED указано, был ли успешно сохранен отчет. Интерфейс 58. сохранения отчетов пересылает BLS 52 статус сохранения в сообщении 88 OUTPUT_REPORT_RESPONSE. После приема сообщения 88 OUTPUT_REPORT_RESPONSE BLS 52 может проверить сообщение, чтобы определить, был ли отчет успешно сохранен. Если в сообщении указан отрицательный результат и/или указано, что в процессе сохранения произошла ошибка, BLS 52 повторно передает отчет и ожидает другого сообщения 88 OUTPUT_REPORT_RESPONSE. BLS 52 может продолжать данный процесс бесконечно, пока не будет осуществлено успешное сохранение, или может осуществлять заданное число попыток сохранить отчет.BLS 52 также может генерировать и регистрировать предупреждение об ошибке и сохранять отчет в ячейке внутреннего запоминающего устройства или удалить отчет, если его невозможно успешно сохранить. BLS 52 также может пытаться повторно создать отчет и/или повторно запросить базу данных пациента и пытаться сохранить новый отчет.
Если в сообщении 88 OUTPUT_REPORT_RESPONSE указан положительный результат, BLS 52 передает интерфейсу 59 статуса отчетов сообщение 90 UPDATE_REPORT_STATUS. Сообщение 90 UPDATE_REPORT_STATUS может включать статус отчета и входящий номер, опознавательный номер исследования результатов процедуры или подобную информацию, используемую для идентификации отчета. Статус отчета может быть настроен как "ДЛЯ ЧТЕНИЯ" или "ПРЕДВАРИТЕЛЬНЫЙ", и его используют, чтобы установить операции, которые могут быть осуществлены с отчетом, и/или чтобы обеспечить отображение, изменение и/или обработку последнего по времени отчета. Интерфейс 59 статуса отчетов генерирует сообщение 92 DETACHED_INTERPRETATION_MANAGEMENT (MGMT) и передает САИ 28 сообщение 92. Сообщение 92
DETACHED_INTERPRETATION_MGMT может представлять собой сообщение в формате DICOM и может включать данные, содержащиеся в сообщении 90 UPDATE_REPORT_STATUS. В некоторых вариантах осуществления вместо или помимо САИ 28 интерфейс статуса отчета может сохранять данные статуса отчета в отдельном запоминающем устройстве.
Если в сообщении 88 OUTPUT_REPORT_RESPONSE, которое интерфейс 58 сохранения отчетов передает BLS 52, указан положительный результат сохранения, BLS 52 также может генерировать сообщение 94 STUDY_READ. Сообщение 94 STUDY_READ может включать данные статуса отчета, а также данные идентификации отчета, такие как опознавательный номер исследования результатов процедуры, идентификатор пациента или подобные данные. В некоторых вариантах осуществления BLS 52 передает сообщение 94 STUDY_READ DS 54. DS 54 принимает сообщение и обновляет базу 54 данных пациента данными, касающимися статуса отчета, которые поступили от BLS 52. DS 54 также может быть рассчитано на пересылку сообщения 94 STUDY_READ другим компонентам системы 26 управления подключениями, которые рассчитаны на прием сообщения 94 STUDY_READ, таким как интерфейс 59 статуса отчетов. Интерфейс 59 статуса отчетов может принимать от DS 54 сообщение 94 STUDY_READ и передавать САИ 28 сообщение 96 DETACHED-STUD Y-MGMT. САИ 28 может использовать данные, содержащиеся в сообщении 96 DETACHED-STUD Y-MGMT, для обновления и/или проверки данных статуса отчета, которые содержатся в САИ 28.
На фиг.7 проиллюстрирован другой процесс сохранения отчета, который СПЗ 24 передает САИ 28. В частности, на фиг.7 проиллюстрирован процесс сохранения отчета, когда СПЗ 24 является запрашиваемым устройством. Как описано выше, если СПЗ 24 является запрашиваемым устройством, система 26 управления подключениями может не сохранять в отчете, передаваемом САИ 28, результаты процедуры или исследования, поскольку система 26 управления подключениями может при необходимости запросить у СПЗ 24 результаты процедуры и исследования. Предварительные шаги процесса, СПЗ 24 является запрашиваемым устройством, аналогичны случаю, когда СПЗ 24 не является запрашиваемым устройством. На первых шагах СПЗ 24 генерирует сообщение 100 RESULTS, содержащее результаты процедуры, устройство для входящих сообщений принимает сообщение 100 RESULTS и передает BLS 52 сообщение 102 CREATE_REPORT.
Как описано выше, после приема Сообщения 102 CREATE_REPORT BLS 52 определяет, является ли устройство ввода (СПЗ 24), которое передало сообщение 100 RESULTS, запрашиваемым устройством. Когда устройство ввода является запрашиваемым устройством, BLS 52 может игнорировать сообщение 102 CREATE_REPORT и не пересылать отчет САЙ 28. Вместе с тем, BLS 52 контролирует статус результатов процедуры, полученных от СПЗ 24. Чтобы гарантировать отображение и/или обработку последних по времени данных, в некоторых вариантах осуществления BLS 52 контролирует статут отчета или данных процедуры. Чтобы контролировать статус отчета, BLS 52 может получать от DS 54 данные для идентификации отчета. В некоторых вариантах осуществления BLS 52 генерирует сообщение 104 GET_STUDY_REQUEST и пересылает его DS 54, чтобы получить демографические данные пациента и/или данные исследования полученных результатов процедуры. DS 54 может генерировать сообщение 106 DATA_ACCESS для запроса требуемых данных в базе 56 данных пациента. В некоторых вариантах осуществления база 56 данных пациента передает найденные данные DS 54 в сообщении 108 DATABASE_RESPONSE. DS 54 может форматировать возвращенные данные и пересылать данные BLS 52 в сообщении 110 GET_STUDY_REPLY. BLS 52 принимает от DS 54 сообщение 110 GET_STUDY_REPLY и создает для интерфейса 59 статуса отчетов 112 UPDATE_STATUS. Сообщение 112 UPDATE_STATUS может включать статус отчета и входящий номер, опознавательный номер исследования результатов процедуры или подобную информацию, используемую для идентификации результатов процедуры, содержащихся в сообщении 102 CREATE_REPORT. Интерфейс 59 статуса отчетов может генерировать и передавать САИ 28 сообщение 114 DETACHED_INTERPRETATION_MGMT, а САИ 28 обновляет и/или проверяет содержащиеся в нем данные в зависимости от данных, содержащихся в сообщении 114 DETACHED_INTERPRETATION_MGMT.
После получения от DS 54 сообщения 110 GET_STUDY_REPLY BLS 52 также может создать сообщение 116 STUDY_READ. В некоторых вариантах осуществления BLS 52 передает сообщение 116 STUDY_READ DS 54. DS 54 получает сообщение и обновляет базу 54 данных пациента согласно указаниям. DS 54 также может быть рассчитан на пересылку сообщения 116 STUDY_READ другим компонентам, которым требуется отчет или данные статуса отчета, таким как интерфейс 59 статуса отчетов. Интерфейс 59 статуса отчетов может принимать от DS 54 сообщение 116 STUDY_READ и передавать САИ 28 сообщение 118 DETACHED_STUDY_MGMT. САИ 28 может использовать данные, содержащиеся в сообщении 118 DETACHED_STUDY_MGMT, для создания, обновления и/или проверки данных статуса отчета, содержащихся в САИ 28.
На фиг.8 проиллюстрирован процесс поиска отчета во внешнем устройстве, таком как рабочая станция 32. На первом шаге процесса рабочая станция 32 генерирует сообщение 124 REPORT_QUERY. Сообщение 124 REPORT_QUERY может представлять собой сообщение HTTP, содержащее входящий номер, номер пациента и/или опознавательные данные отчета. В некоторых вариантах осуществления рабочая станция 32 получает доступ к системе 26 управления подключениями посредством универсального указателя ресурса (URL) через Интернет, локальную сеть или другое сетевое соединение. Сообщение 124 REPORT_QUERY может быть передано интерфейсу 60 браузера отчетов системы 26 управления подключениями. В некоторых вариантах осуществления интерфейс 60 браузера отчетов включает веб-сервер, выполняющий серверную страницу Java (JSP). Веб-сервер может выполнять JSP интерфейса 60 браузера отчетов и может генерировать и передавать BLS 52 сообщение 126 GET_REPORT_REQUEST, включающее данные, содержащиеся в сообщении 124 REPORT_QUERY. В некоторых вариантах осуществления сообщение 126 GET_REPORT_REQUEST представляет собой сообщение в формате AVP, приемлемое для BLS 52.
После приема сообщения 126 GET_REPORT_REQUEST BLS 52 может сначала определять, является ли СПЗ 24 или другое устройство ввода запрашиваемым устройством. Как описано выше, если СПЗ 24 или другое устройство ввода является запрашиваемым устройством, результаты процедуры и/или исследования могут быть не сохранены в виде отчета в САИ 28 и могут быть сохранены в запрашиваемом устройстве ввода. Если СПЗ 24 не является запрашиваемым устройством, BLS 52 может генерировать сообщение 128 QUERY_REPORT_REQUEST. BLS 52 может пересылать сообщение 128 QUERY_REPORT_REQUEST интерфейсу 58 сохранения отчетов. В ответ интерфейс 58 сохранения отчетов может генерировать и передавать САИ 28 сообщение 130 RETRIE_VEREPORT. После приема сообщения 130 RETRIEVE_REPORT от интерфейса 58 сохранения отчетов САИ 28 находит отчет, указанный в сообщении 130 RETRIEVE_REPORT. САИ 28 может возвращать интерфейсу 58 сохранения отчетов найденный отчет в сообщении 132 REPОRT_RETRIE VED. Если САИ 28 не может найти отчет, указанный в сообщении 130 RETRIEVE_REPORT, САИ 28 может передать пустой отчет или состояние ошибки, предупреждение или указание в сообщении 132 REPORT_RETRIEVED. Как описано выше, возвращенный отчет может представлять собой отчет на языке XML или другом языке разметки. В некоторых вариантах осуществления интерфейс 58 сохранения отчетов пересылает BLS 52 возвращенный отчет в сообщении 134 QUERY_REPORT_REPLY. BLS 52 принимает сообщение 134 QUERY_REPORT_REPLY и пересылает интерфейсу 60 браузера отчетов отчет в сообщении 136 GET_REPORT_REPLY. Интерфейс 60 браузера отчетов может принимать сообщение 136 GET_REPORT_REPLY, содержащее отчет, и может обрабатывать и/или форматировать отчет, чтобы рабочая станция 32 могла принять и отобразить отчет.В некоторых вариантах осуществления интерфейс 60 браузера отчетов преобразует отчет в страницу на языке разметки гипертекста (HTML). Форматированный отчет в сообщении 138 REPORT передают рабочей станции 32, которая отображает отчет для пользователя.
На фиг.9 проиллюстрирован другой процесс поиска отчета во внешнем устройстве, когда система 24 медицинской информации является запрашиваемой. Первые шаги процесса аналогичны шагам, описанным со ссылкой на фиг.8. Рабочая станция 32 генерирует сообщение 140 REPORT_QUERY и передает его интерфейсу 60 браузера отчетов. Интерфейс 60 браузера отчетов генерирует и передает BLS 52 сообщение 142 GET_REPORT_REQUEST, включающее данные, которые содержатся в сообщении 140 REPORT_QUERY. После приема сообщения 142 GET_REPORT_REQUEST BLS 52 определяет, является ли СПЗ 24 или другое устройство ввода запрашиваемым устройством. Если СПЗ 24 является запрашиваемым устройством, BLS 52 может генерировать и передавать устройству 51 для исходящих запросов, сообщение 144 QUERY_REPORT_REQUEST. В ответ устройство 51 для исходящих запросов может генерировать и передавать СПЗ 24 сообщение 146 RETRIEVE_RESULTS. Как описано выше, устройство 51 для исходящих запросов может преобразовывать внутренние запросы или сообщения системы 26 управления подключениями в запросы или сообщения, которые могут быть переданы СПЗ 24. В некоторых вариантах осуществления устройство 51 для исходящих запросов преобразует сообщения в формате MCF, которые передает BLS 52, в сообщения в формате HL7, приемлемые для СПЗ 24.
Когда СПЗ 24 принимает от устройства 51 для исходящих запросов сообщение 146 RETRIEVE_RESULTS, СПЗ 24 находит и возвращает данные, указанные в сообщении 146 RETRIEVE_RESULTS. Система подачи заказов на формирование медицинских изображений может возвращать найденные данные устройству 51 для исходящих запросов в сообщении 148 RESULTS_RETRIEVED. Если СПЗ 24 не может найти данные, указанные в сообщении 146 RETRIEVE_RESULTS, система 24 может передать пустое сообщение и/или состояние ошибки, предупреждение или указание в сообщении 148 RESULTS_RETRIEVED.
В некоторых вариантах осуществления устройство 51 для исходящих запросов пересылает BLS 52 возвращенные данные в сообщении 150 QUERY_REPORT_REPLY. В некоторых вариантах осуществления BLS 52 принимает сообщение 150 QUERY_REPORT_REPLY и определяет, были найдены данные, указанные в сообщении 144 QUERY_REPORT_REQUEST. Если в сообщении 150 QUERY_REPORT_REPLY, переданном устройством 51 для исходящих запросов, указано, что данные не были найдены и, следовательно, возвращены, BLS 52 может в сообщении 152 GET_REPORT_REPLY пересылать интерфейсу 60 браузера отчетов пустое сообщение и/или состояние ошибки, указанное в сообщении 150 QUERY_REPORT_REPLY. BLS 52 также может генерировать пустой отчет или отчет об ошибке и пересылать его интерфейсу 60 браузера отчетов. Интерфейс 60 браузера отчетов может принимать сообщение 152 GET_REPORT_REPLY, содержащее пустое сообщение или отчет и/или состояние ошибки или отчет об ошибке, и может генерировать HTML-сообщение с указанием отчета о несуществующей ошибке. Отчет об ошибке в сообщении 154 REPORT передают рабочей станции 32, которая может отображать сообщение для пользователя. Однако если отчет был найден и поступил от СПЗ 24, BLS 52 может генерировать сообщение 156 GET_STUDY_REQUEST и пересылать сообщение 156 DS 54. В сообщении 156 GET_STUDY_REQUEST могут быть указаны демографические данные пациента и/или данные исследования результатов процедуры и/или процедура, соответствующая результатам процедуры, полученным от СПЗ 24. Поскольку СПЗ 24 является запрашиваемым устройством, в некоторых вариантах осуществления не создают и не сохраняют отчет, содержащий как данные процедуры, переданные СПЗ 24, так и данные пациента и процедуры, хранящиеся в базе 56 данных пациента. Таким образом, BLS 52 получает от DS 54 дополнительные данные для дополнения результатов, полученных от запрашиваемой СПЗ 24.
Для получения дополнительных данных из базы 56 данных пациента DS 54 создает сообщение 158 DATABASE_ACCESS, а база 56 данных пациента передает найденные данные DS 54 в сообщении 160 DATABASE_DATA. DS 54 пересылает данные BLS 52 в сообщении 162 GET_STUDY_REPLY.
BLS 52 принимает от DS 54 сообщение 162 GET_STUDY_REPLY и создает отчет с использованием данных, вернувшихся от DS 54, и данных, полученных от запрашиваемой СПЗ 24. Как описано выше, отчет может быть создан на языке разметки, таком как язык разметки гипертекста (HTML) или расширяемый язык разметки (XML). BLS 52 передает отчет интерфейсу 60 браузера отчетов в сообщении 152 GET_REPORT_REPLY, а интерфейс 60 браузера отчетов пересылает отчет рабочей станции 32 в сообщении 164 REPORT. Затем рабочая станция 32 может отображать найденный отчет для пользователя. BLS 52 также может передавать интерфейсу 59 статуса отчетов сообщение 166 UPDATER_EPORT_STATUS. Внутренний статус отчета мог измениться в запрашиваемой системе 24 подачи заказов на формирование медицинских изображений, и изменение статуса может быть документировано в САИ 28. Интерфейс 59 статуса отчетов может принимать от BLS 52 сообщение 166 UPDATE_REPORT_SТATUS и может передавать САИ 28 сообщение 168 DETACHED_INTERPRETATION_MGMT с указанием статуса отчета и других опознавательных данных отчета. САИ 28 принимает сообщение 168 и соответствующим образом обновляет данные, находящиеся в САИ 28.
На фиг.10 и 11 проиллюстрированы дополнительные типичные процессы поиска отчета. Как описано выше, программа 170 просмотра, установленная на веб-сервере/сервере приложений, может взаимодействовать с базой 57 данных хранящихся процедур, чтобы запросить у системы 26 управления подключениями отчеты для просмотра и/или изменения. На фиг.10 проиллюстрирован поток данных, когда СПЗ 24 не является запрашиваемым устройством, а на фиг.11 проиллюстрирован поток данных, когда СПЗ 24 является запрашиваемым устройством. Как показано на фиг.10 и фиг 11, программа 170 просмотра создает сообщение 172 STORED_PROCEDURE_CALL и пересылает сообщение 172 базе 57 данных хранящихся процедур. База 57 данных хранящихся процедур находит процедуру, по мере необходимости форматирует ее и передает BLS 52 сообщение 174 GET_REPORT_REQUEST. Сообщение 174 GET_REPORT_REQUEST, передаваемое базой 57 данных хранящихся процедур, может быть аналогично сообщениям GET_REPORT_REQUEST, которые передает интерфейс 60 браузера отчетов, как это описано со ссылкой на фиг.8 и 9.
Когда СПЗ 24 является запрашиваемым устройством (см. фиг.10), после приема сообщения 174 GET_REPORT_REQUEST от базы 57 данных хранящихся процедур BLS 52 действует, как это описано со ссылкой на фиг.8, и передает САИ 28 сообщение 128 QUERY_REPORT_REQUEST. САИ 28 принимает сообщение 128 и передает САИ 28 сообщение 130 RETRIEVE_REPORT. САИ 28 находит отчет, указанный в сообщении 130 RETRIEVE_REPORT, и в сообщении 132 REPORT_RETRIEVED передает отчет интерфейсу 58 сохранения отчетов. Интерфейс 58 сохранения отчетов пересылает найденный отчет BLS 52 в сообщении 134 QUERY_REPORT_REPLY. Когда СПЗ 24 не является запрашиваемым устройством (см. фиг.10), после приема сообщения 174 GET_REPORT_REQUEST от базы 57 данных хранящихся процедур BLS 52 действует, как это описано со ссылкой на фиг.9, и передает устройству 51 для исходящих запросов сообщение 144 QUERY_REPORT_REQUEST. Устройство 51 для исходящих запросов принимает сообщение 144 и передает запрашиваемой СПЗ 24 сообщение 146 RETRIEVE_RESULTS. СПЗ 24 находит отчет, указанный в сообщении 146 RETRIEVE_RESULTS, и в сообщении 148 RESULTS_RETRIEVED передает отчет устройство 51 для исходящих запросов. Устройство 51 для исходящих запросов пересылает найденный отчет BLS 52 в сообщении 150 QUERY_REPORT_REPLY.
При обеих конфигурациях системы (т.е. запрашиваемой и незапрашиваемой СПЗ 24) найденный отчет возвращают BLS 52 и программе 170 просмотра в сообщении 176 STORED_PROCEDURE_RESULTS.
Подразумевается, что описанные процессы поиска, проиллюстрированные на фиг.8-11, могут использоваться для поиска отдельного отчета, одного или нескольких отчетов, касающихся конкретного пациента, одного или нескольких отчетов о конкретной процедуре, одного или нескольких отчетов за конкретный период времени и любого их сочетания.
На фиг.12 проиллюстрирован типичный поток данных для обновления данных в медицинской информационной системе. В некоторых вариантах осуществления обновление включает обновление данных пациента, процедуры или результатов процедур, объединение данных пациента и любое их сочетание. Источником обновления может являться ИСО 22, СПЗ 24 или другая информационная система. Как показано на фиг.12, СПЗ 24 передает устройству 50 для входящих сообщений сообщение 190 PATIENT/STUDY_UPDATE. В некоторых вариантах осуществления сообщение 190 PATIENT/STUDY_UPDATE включает сообщение в формате HL7 об обновлении данных поступления, выписки и перевода (ПВП) пациента или сообщение в формате HL7 об обновлении данных незатребованного заказа (ORU). Устройство 50 для входящих сообщений принимает сообщение 190 и осуществляет его синтаксический анализ, и передает DS 54 сообщение 192 UPDATE_PATIENT_STUDY.
DS 54 принимает сообщение 192 UPDATE_PATIENT_STUDY и обновляет соответствующие данные в базе 56 данных пациента при помощи сообщения 193 UPDATE_DATABASE. В некоторых вариантах осуществления DS 54 использует для обновления базы 56 данных пациента сообщение стандарта ODBC. DS 54 также может пересылать сообщение 192 UPDАТЕ_РATIENT_STUDY другим компонентам системы 26 управления подключениями. BLS 52 может принимать сообщение 192 UPDАТЕ_РATIENT_STUDY и создавать сообщение 194 UPDATE_REPORT для интерфейса 58 сохранения отчетов. Интерфейс 58 сохранения отчетов принимает сообщение 194 UPDATE_REPORT и создает сообщение 196 UPDATE_REPORT_REQUEST. Интерфейс 58 сохранения отчетов пересылает сообщение 196 UPDATE_REPORT_REQUEST САИ 28, а САИ 28 обновляет указанные данные и возвращает интерфейсу 58 сохранения отчетов сообщение 197 UPDATE_REPORT_REPLY.
Интерфейс 59 статуса отчетов также может принимать сообщение 192 UPDATE_PATIENT_STUDY, которое передает DS 54. В некоторых вариантах осуществления интерфейс 59 статуса отчетов принимает сообщение 192 UPDATE_PATIENT_STUDY и передает САИ 28 сообщение 198 DETACHED_PATIENT/STUDY_MGMT. После приема сообщения 198 DETACHED_PATIENT/STUDY_MGMT САИ 28 обновляет и/или проверяет данные, указанные в сообщении 198.
На фиг.13 проиллюстрирован аналогичный процесс обновления данных в медицинской информационной системе, когда СПЗ 24 является запрашиваемым устройством. Как показано на фиг.13, предварительные шаги процесса аналогичны описанным ранее. СПЗ 24 передает устройству 50 для входящих сообщений сообщение 200 PATIENT/STUDY_UPDATE, содержащее обновленные данные. Устройство 50 для входящих сообщений создает и передает DS 54 сообщение 202 UPDATE/PATIENT_STUDY. DS 54 обновляет базу 56 данных пациента при помощи сообщения 204 UPDATE_DATABASE, как это указано в сообщении 202 UPDATE/PATIENT_STUDY, и пересылает сообщение 202 UPDATE/PATIENT_STUDY BLS 52 и интерфейсу 59 статуса отчетов.
BLS 52 может принимать сообщение 202 UPDATE/PATIENT_STUDY от DS 54. Вместе с тем, последующие действия по обновлению отчета являются необязательными. Поскольку СПЗ 24 может являться запрашиваемым устройством, отчет, требующий обновления, мог быть не сохранен в САИ 28. Однако после приема от DS 54 сообщения 202 UPDATE/PATIENT_STUDY интерфейс 59 статуса отчетов все же создает сообщение 206 DETACHED_PATIENTS/STUDY_MGMT. Интерфейс 59 статуса отчетов передает сообщение 206 DETACHED_PATIENTS/STUDY_MGMT САИ 28 для обновления соответствующих данных.
Подразумевается, что компоненты, показанные на фиг.1-13, отображают типичные конфигурации. Могут быть добавлены дополнительные компоненты или множество показанных компонентов. Компоненты также могут быть объединены или разбиты на отдельные компоненты. Например, функциональные возможности устройства 50 для входящих сообщений могут быть включены в BLS 52. Устройство 50 для входящих сообщений также может быть разбито на множество компонентов, включая буфер сообщений, синтаксический анализатор, устройство отображения или подобные компоненты. Такие компоненты, как хранилище 54 данных, база 56 данных пациента, база 57 данных хранящихся процедур, интерфейс 60 браузера отчетов и интерфейс 59 статуса отчетов также могут быть выведены из системы 26 управления подключениями и добавлены к другим компонентам системы медицинской информации или быть реализованы в виде автономных внешних устройств. Например, данные, содержащиеся в базе данных пациента, могут храниться в СПЗ 24 с возможностью их поиска. Шаги процесса, проиллюстрированные на фиг.6-13, являются типичными с точки зрения очередности и содержания, при этом процессы могут осуществляться с использованием поднабора показанных шагов или дополнительных или альтернативных шагов. Также подразумевается, что описанные типичные процессы или потоки данных могут быть объединены и сгруппированы в различные конфигурации, а очередность отдельных шагов типичного процесса приведена лишь в качестве иллюстрации и может быть реализована в виде других последовательностей. Например, система 26 управления подключениями может поддерживать связь с запрашиваемыми устройствами ввода и незапрашиваемыми устройствами ввода и, таким образом, осуществлять как типичные процессы, установленные для запрашиваемых устройств ввода, так и процессы, установленные для незапрашиваемых устройств ввода. Даже когда устройство ввода, такое как СПЗ 24, является запрашиваемым, в некоторых вариантах осуществления система 26 управления подключениями может быть рассчитана на сохранение в САИ 28 результатов, полученных из запрашиваемого устройства ввода. Например, система 26 управления подключениями может на основании статуса результатов определять, сохранять ли в отчете для САИ 28 результаты, полученные из запрашиваемого устройства ввода. Система 26 управления подключениями может сохранять в САИ 28 все результаты, полученные из запрашиваемого устройства ввода, которые не имеют заданного статуса, такого как "окончательный". Система 26 управления подключениями может сохранять все "неокончательные" результаты в отчете для САИ 28, чтобы результаты можно было легко найти в САИ 28 для их обновления и/или изменения при изменении их статуса (т.е. от "предварительного" до "окончательного"). Система 26 управления подключениями может аналогичным образом использоваться статус отчета, чтобы определять, где осуществлять поиск отчета. Отчеты со статусом "окончательный" могут быть найдены в запрашиваемом устройстве ввода, а отчеты со с другими статусами помимо статуса "окончательный" могут быть найдены в САИ 28. Как это также должно быть ясно для специалиста в данной области техники, системы, показанные на чертежах, являются моделями того, как могут выглядеть реальные системы. Как было отмечено, многие описанные модули и логические структуры могут быть реализованы в программах, выполняемых микропроцессором или подобным устройством, или в оборудовании с использованием разнообразных компонентов, включая, например, специализированные интегральные микросхемы (ASIC). Кроме того, такие термины, как "процессор" могут включать или означать как аппаратное, так и программное обеспечение. Помимо этого, в описании используются термины, выделенные заглавными буквами. Такие термины используются в соответствии с общепринятой практикой и помогают согласованию описания с примерами кодирования и чертежами. Вместе с тем, не следует подразумевать или предполагать особый смысл только на основании использования заглавных букв. Так, притязания не должны быть ограничены конкретными примерами или терминологией или конкретной аппаратной или программной реализацией или сочетанием программных или аппаратных средств.
Различные признаки изобретения изложены в следующей далее формуле изобретения.
1. Система управления подключениями для использования в медицинской информационной системе, включающей систему подачи заказов на формирование медицинских изображений и систему архивирования изображений, отличающаяся тем, что она содержит
устройство ввода для приема сообщений от системы подачи заказов на формирование медицинских изображений,
сервер бизнес-логики для генерирования отчета на основе сообщения от устройства ввода,
хранилище данных для хранения данных от сервера бизнес-логики,
интерфейс сохранения отчетов для обеспечения связи с сервером бизнес-логики и системой архивирования изображений,
интерфейс браузера отчетов для обеспечения интерфейса для запроса сервера бизнес-логики и
интерфейс статуса отчетов для обеспечения связи с сервером бизнес-логики и установления, обновления и передачи статуса отчетов.
2. Система управления подключениями по п.1, сконфигурированная с возможностью поиска отчетов в системе подачи заказов на формирование медицинских изображений.
3. Система управления подключениями по п.2, в котором система подачи заказов на формирование медицинских изображений является запрашиваемым устройством.
4. Система управления подключениями по п.2, сконфигурированная с возможностью:
приема сообщений системы подачи заказов на формирование медицинских изображений, включающих обновленные данные, и
обновления отчетов, хранящихся в системе подачи заказов на формирование медицинских изображений, с использованием связи на основе обмена сообщениями с обновленными данными.
5. Система управления подключениями по п.1, сконфигурированная с возможностью:
приема сообщений рабочей станции, включающих запросы на получение отчетов, и
пересылки найденных отчетов рабочей станции.
6. Система управления подключениями по п.1, где система медицинской информации также включает информационную систему объекта, при этом система управления подключениями сконфигурирована с возможностью приема сообщений информационной системы объекта с использованием связи на основе обмена сообщениями.
7. Система управления подключениями по п.6, сконфигурированная с возможностью:
приема сообщений информационной системы объекта, включающих обновленные данные, и
обновления отчетов, хранящихся в системе архивирования изображений, с использованием связи на основе обмена сообщениями с обновленными данными.
8. Система управления подключениями по п.1, сконфигурированная с возможностью:
приема включающих запросы на получение отчетов сообщений программы просмотра, взаимодействующей с базой данных хранящихся процедур, и
пересылки найденных отчетов программе просмотра.
9. Система управления подключениями по п.4, сконфигурированная с возможностью:
передачи рабочих списков одному или нескольким средствам формирования изображений,
приема сообщений о статусе от одного или нескольких средств формирования изображений,
направления сообщений о статусе, принятых от одного или нескольких средств формирования изображений, по меньшей мере медицинской информационной системе или информационной системе объекта.
10. Система управления подключениями по п.4, сконфигурированная с возможностью приема сообщений шлюза, которые включают сообщения, переданные системой подачи заказов на формирование медицинских изображений.
11. Система управления подключениями по пп.1-10, где устройство ввода выполнено с возможностью взаимодействия с системой подачи заказов на формирование медицинских изображений и преобразования сообщения из первого формата во второй формат.
12. Система управления подключениями по п.11, где сервер бизнес-логики сконфигурирован с возможностью взаимодействия с устройством ввода и создания отчета.
13. Система управления подключениями по п.12, где хранилище данных сконфигурировано с возможностью взаимодействия с сервером бизнес-логики.
14. Система управления подключениями по п.13, где интерфейс сохранения отчетов сконфигурирован с возможностью взаимодействия с сервером бизнес-логики и системой архивирования изображений.
15. Система управления подключениями по п.14, где интерфейс браузера отчетов сконфигурирован с возможностью взаимодействия с сервером бизнес-логики.
16. Система управления подключениями по п.15, где интерфейс статуса отчетов сконфигурирован с возможностью взаимодействия с сервером бизнес-логики.
17. Система управления подключениями по пп.1-9, где система медицинской информации включает запрашиваемую систему подачи заказов на формирование медицинских изображений, при этом система управления подключениями сконфигурирована с возможностью приема первого сообщения системы подачи заказов на формирование медицинских изображений, включающего первый отчет, и, если указанный в первом отчете первый статус не соответствует заданному статусу, создания второго отчета в зависимости от первого отчета и передачи системе архивирования изображений второго сообщения, включающего второй отчет.
18. Система управления подключениями по п.17, в которой шлюз использует для связи с первой системой подачи заказов на формирование медицинских изображений внутренний протокол связи, а для связи с системой управления подключениями использует протокол связи общего пользования, при этом система управления подключениями использует для связи со шлюзом протокол связи общего пользования.
19. Система управления подключениями по п.18, в которой для связи между системой управления подключениями и шлюзом используют связь на основе обмена сообщениями.
