УПРАВЛЕНИЕ ДЕЙСТВИЯМИ, ВЫПОЛНЯЕМЫМИ С ДЕИДЕНТИФИЦИРОВАННЫМИ ДАННЫМИ О ПАЦИЕНТЕ В ОБЛАЧНОЙ СИСТЕМЕ ПОДДЕРЖКИ ПРИНЯТИЯ КЛИНИЧЕСКИХ РЕШЕНИЙ (СППКР)

Настоящее изобретение в целом относится к системе поддержки принятия клинических решений (СППКР), в частности, к управлению действиями, выполняемыми с деидентифицированными данными о пациенте, находящимися в облачной системе поддержки принятия клинических решений (СППКР); однако настоящее изобретение также может использоваться с другими данными вместо деидентифицированных данных о пациенте и/или с клиническими и/или другими неклиническими данными, которые находятся в месте, отличном от облачной системы поддержки принятия клинических решений.

Система поддержки принятия клинических решений (СППКР) содержит, например, компьютерное программное обеспечение, которое помогает клиницистам и/или другим работникам здравоохранения принимать решения, например, при постановке диагноза по данным о пациенте. Облачные вычисления в целом представляют собой доставку вычислительной мощности и/или объема памяти в виде услуги группе конечных получателей, в которой конечные пользователи могут иметь доступ к облачным приложениям через веб-браузер, мобильное приложение и т.д., тогда как программное обеспечение и данные хранятся на дистанционно расположенных серверах.

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

Один известный подход к обеспечению конфиденциальности и безопасности данных пациента включает использование гарантированных уникальных идентификаторов (от англ. - Guaranteed Unique Identifier, GUID). Согласно данному подходу, данные о пациенте, хранящиеся в облаке, деидентифицируют таким образом, что идентификационная информация пациента (например, имя, номер социального страхования и т.д.) заменяется идентификатором GUID. После этого, доступом к данным о пациенте и/или выполнением действий с ними управляют через идентификатор GUID. Если интересующие деидентифицированные данные подлежат объединению с недеидентифицированными данными, то деидентифицированные данные идентифицируют повторно.

В US 2011/153351 описана система и способ получения, хранения и распределения медицинских изображений для работников здравоохранения. Обезличенные части изображений медицинских записей могут храниться в облаке. Может быть предоставлена центральная сеть или сервер, в том числе сервер веб-сайта, причем соответствующие веб-сервисы защищены как протоколом защиты информации (от англ. - Secure Sockets Layer, SSL), так и идентификационными маркерами сеансов, которые изменяются в течение заданного периода времени.

В US 2011/283110 описан способ безопасной связи, в котором первый маркер безопасности вырабатывают сервером и принимают от клиентской машины. Запрос, содержащий второй маркер безопасности, вырабатывают клиентской машиной и передают серверу. Определяют, соответствует ли первый маркер безопасности второму маркеру безопасности.

В WO 2014/020490 описан способ, включающий получение данных о пациенте в электронном формате. Гарантированные уникальные идентификаторы вырабатываются и сохраняются. Деидентифицированные отмеченные сохраненные данные о пациенте сохраняют в облачной СПКР и извлекают с использованием соответствующих гарантированных уникальных идентификаторов.

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

Описанные в настоящем документе аспекты направлены на решение вышеуказанных проблем и др.

Далее описан подход для обеспечения конфиденциальности и безопасности данных о пациенте, хранящихся в облачной СППКР. В одном примере он включает в себя использование ролей (role) и маркеров, при этом роли определяют разрешения на допустимые действия с данными о пациенте (например, обзор, формирование отчетов, повторную идентификацию, экспорт и т.д.) в конкретном объекте (site), а маркеры обеспечивают возможность ведения конкретным объектом своего списка пользователей и предотвращения повторной идентификации деидентифицированных данных несанкционированным пользователем, а также обеспечивают возможность повторной идентификации данных о пациенте на основе аутентификации пользователя объектом, обладающим данными, без отправки идентификационной информации пациента, удостоверяясь в том, что запрос аутентифицированного пользователя действительно пришел от объекта, обладающего данными.

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

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

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

Изобретение может принимать вид различных компонентов и схем размещения компонентов, и различных этапов и порядка выполнения этапов. Чертежи служат лишь в целях иллюстрации предпочтительных вариантов реализации и не должны рассматриваться в качестве ограничения настоящего изобретения.

Фигура 1 схематически показывает пример системы, содержащей облачную СППКР и множество объектов, при этом каждый объект содержит систему аутентификации пользователей, а облако содержит систему аутентификации объектов.

Фигура 2 схематически показывает пример системы аутентификации пользователей.

Фигура 3 показывает пример способа получения объектом доступа к облачной СППКР со стороны объекта.

Фигура 4 показывает пример способа получения объектом доступа к облачной СППКР со стороны облачной СППКР.

Как показано на фиг. 1, система 100 содержит облачную СППКР 102 и N-ное количество объектов 1041,.., 104N (вместе именуемых объектами 104), где N представляет собой целое число, которое больше или равно единице (1). Как используется в настоящем документе, термин «объект» (site) относится к учреждению, которое предоставляет данные о пациентах и/или другую информацию облачной СППКР 102 и/или осуществляет доступ к данным о пациентах и/или другой информации облачной СППКР 102. Примеры объектов 104 включают, но не ограничиваются ими, больницу, клинику, другие места ухода, кабинет врача, визуализационный центр и т.д.

Облачная СППКР 102 предоставляет вычислительные услуги и/или услуги хранения. Указанные услуги, включают услуги 106, которые реализуются микропроцессором(ами), центральным(и) процессором(ами) и т.д., и данные 108, которые хранятся в базе данных или т.п.Примеры вычислительных услуг и/или услуг хранения описаны в заявке с номером PCT/IB2013/056055, поданной 24 июля 2013 г., под названием Federated patient guaranteed unique identification (guid) matching (Совместное сопоставление гарантированных уникальных идентификаторов (GUID) пациентов), которая полностью включена в настоящий документ посредством ссылки.

Облачная СППКР 102 также содержит систему 110 аутентификации объектов. Как описано более подробно далее, система 110 аутентификации объектов аутентифицирует объект 104 перед выполнением действия, запрошенного объектом 104, которое требует аутентификации объекта. Система 110 аутентификации объектов реализована с помощью процессора (например, микропроцессора, центрального процессора и т.д.), выполняющего исполняемую на компьютере инструкцию, хранящуюся на машиночитаемом носителе данных, за исключением промежуточного носителя.

Объект 104 содержит по меньшей мере одно вычислительное(ые) устройство(а) 112. Вычислительное устройство 112 содержит один или более процессоров, машиночитаемый носитель информации, такой как физическая память, устройство ввода (например, манипулятор-мышь, клавиатуру и т.д.) и устройство вывода (например, экранный монитор). Вычислительное устройство 112 находится в приемном отделении, пункте экстренной помощи, лаборатории, отделении интенсивной терапии и т.д. Примером вычислительного устройства 112 является персональный компьютер, прикроватный монитор, портативный монитор, переносной монитор, центральная диспетчерская станция и т.д.

Кроме того, объект 104 содержит процессор 114 гарантированного уникального идентификатора (GUID), который генерирует идентификатор GUID для пациента. Примером идентификатора GUID является n-битовая буквенно-цифровая строка, основанная на случайном числе, сгенерированном с использованием тактового генератора, и т.д. Процессор 114 GUID также генерирует соответствие между GUID и пациентами. Идентификатор GUID используется для замены личности пациента для деидентификации данных о пациенте, например, из соображений конфиденциальности и безопасности. Пример генерирования и использования идентификатора GUID, а также соответствия, описан в заявке с номером PCT/IB2013/056055.

Кроме того, объект 104 содержит систему 116 аутентификации пользователей. Как описано более подробно далее, система 116 аутентификации пользователей способствует аутентификации пользователя вычислительного устройства 112 и объекта 104 для получения доступа к деидентифицированным данным о пациенте, содержащимся в облачной системе 102 ППКР, манипуляции с этими данными, извлечения этих данных, повторной их идентификации и т.д.. Система 116 аутентификаци пользователей реализована с помощью процессора, выполняющего исполняемую на компьютере инструкцию, хранящуюся на машиночитаемом носителе данных.

Кроме того, объект 104 содержит сервер 118 объекта, который обеспечивает связь между объектом 104 и облачной системой 102 ППКР. Сервер 118 деидентифицирует пациента перед передачей этих данных облачной системе 102 ППКР. Это включает в себя замену идентификационной информации пациента на идентификатор GUID перед передачей этих данных облачной СППКР 102. Деидентифицированные данные о пациенте, передаваемые облачной СППКР 102, не могут быть идентифицированы, поскольку они не содержат какой-либо информации, идентифицирующей подлинную личность пациента. В одном случае, это позволяет повысить возможность сохранения конфиденциальности и/или обеспечения безопасности.

Кроме того, сервер 118 повторно идентифицирует пациента в облачной системе 102 ППКР. Это включает замену идентификатора GUID идентификационной информацией пациента. Повторно идентифицированные данные о пациенте могут быть идентифицированы, поскольку они содержат информацию, которая идентифицирует подлинную личность пациента. Пример деидентификации личности пациента и связывание идентификатора GUID с деидентифицированными данными о пациенте, а также повторной идентификации личности пациента, описан в заявке с номером PCT/IB2013/056055.

Фиг. 2 показывает пример системы 116 аутентификации пользователей, соединенной с системой 110 аутентификации объектов, облачной СППКР 102.

Система 116 аутентификации пользователей содержит клиентский интерфейс 202. Клиентский интерфейс 202 обеспечивает интерфейс между вычислительным устройством 112 и системой 116 аутентификации пользователей. Клиентский интерфейс 202 получает от вычислительного устройства 112 «облачную» информацию для входа пользователя (например, имя пользователя и пароль, биоидентификацию, такую как отпечаток пальца, электронная информация с магнитной или оптической полосы на идентификационной карте и т.д.), предоставленную пользователем вычислительному устройству 112.

Кроме того, система 116 аутентификации пользователей содержит устройство 204 проверки достоверности пользователей и базу 206 данных пользователей, в которой хранится перечень авторизированных пользователей 208. Устройство 204 проверки достоверности пользователей сравнивает «облачную» информацию для входа пользователя с перечнем авторизированных пользователей. В результате определения несоответствия «облачной» информации для входа пользователя авторизированному пользователю из перечня авторизированных пользователей, устройство 204 проверки достоверности генерирует сигнал недостоверности или сообщение об ошибке, который(ое) передается клиентскому интерфейсу 202 и, как правило, визуально отображается пользователю через вычислительное устройство 112.

В результате определения соответствия «облачной» информации для входа пользователя авторизированному пользователю из перечня авторизированных пользователей, устройство 204 проверки достоверности пользователей генерирует сигнал достоверности. Клиентский интерфейс 202, в результате получения сигнала достоверности, инициирует извлечение роли (ролей), назначенной (назначенных) пользователю объектом 104. Примеры ролей включают: обеспечение возможности отображения пользователю перечня типов отчетов; обеспечение пользователю возможности просмотра отчета(ов); обеспечение пользователю возможности повторной идентификации личности пациента из отчета; обеспечение пользователю возможности изменения отчета и/или другие роли. В данном документе предполагается использование других и/или различных ролей.

Устройство 210 извлечения ролей получает запрос на роль (роли) от клиентского интерфейса 202. База 212 данных ролей хранит роль, заданную для объекта (роли, заданные для объекта), а также соответствие 216 пользователя роли, которое обеспечивает соответствие «облачной» информации для входа пользователя роли (ролям). Роли обеспечивают объекту 104 возможность управления действиями, выполняемыми с данными о пациенте. Устройство 210 извлечения ролей возвращает перечень ролей пользователя на клиентский интерфейс 202. Клиентский интерфейс 202 визуально отображает доступные пользователю действия через вычислительное устройство 112.

Обработчик 218 запросов запрашивает выполнение действия облачной СППКР 102 на основе извлеченного действия из перечня доступных пользователю действий. Генератор 220 маркеров генерирует маркер сеанса объекта для действия, требующего аутентификации объекта. Маркер сеанса объекта, например, содержит уникальный идентификатор, сгенерированный генератором 220 маркера в объекте 102 для идентификации сеанса взаимодействия объекта 104 с облачной ССПКР 102.

При получении запроса система 110 аутентификации объектов проверяет, требует ли запрошенное действие аутентификации объекта. База 222 данных действий содержит перечень действий 224, требующих аутентификации объекта. Если действие не требует аутентификации объекта, облачная ССПКР 102 выполняет действие. Если действие требует аутентификации объекта и не содержит маркера сеанса, облачная СППКР 102 отклоняет запрос и возвращает сообщение об ошибке.

В целом, это обеспечивает возможность ведения объектом 104 списка пользователей и позволяет тому, кто желает, иметь разрешение на доступ без добавления пользователей в облачную систему аутентификации. Кроме того, маркер сеанса предотвращает выполнение неавторизированным пользователем или пользователем-злоумышленником, который может узнать информацию для входа пользователя и роли в облаке, действия облачной СППКР 102, такого как повторная идентификация деидентифицированных данных о пациенте без начальной аутентификации объектом 104.

Если действие требует аутентификацию объекта и содержит маркер сеанса, система 110 аутентификации объектов отправляет обработчику 218 запросов запрос проверки достоверности вместе с маркером сеанса. Обработчик 218 запросов сравнивает отправленные и принятые маркеры сеанса и генерирует сигнал, указывающий на то, соответствуют ли отправленные и принятые маркеры сеанса друг другу (т.е. они одинаковы) или же отправленные и принятые маркеры сеанса не соответствуют друг другу (т.е. они не одинаковы).

Система 110 аутентификации объектов, при получении сигнала достоверности маркера сеанса, выполняет действие, инициирует выполнение запрошенного действия облачной СППКР 102. Например, если запрос представляет собой запрос на повторную идентификацию данных о пациенте в конкретном отчете, данные о пациенте повторно идентифицируют с использованием GUID. Система 110 аутентификации объектов может отправить обработчику 218 запросов уведомление, указывающее на то, что запрошенное действие было выполнено облачной СППКР 102.

Если объект 104 не содержит генератора 234 маркеров, объект 104 не будет иметь доступа к действиям, требующим аутентификации объекта. Кроме того, различные объекты 104 могут иметь различные роли и/или различные действия, требующие аутентификации объекта. Более того, пользователь, который непосредственно входит в облачную СППКР 102, даже если пользователь аутентифицирован, не будет иметь возможности доступа к действиям, требующим аутентификации объекта, поскольку пользователь не запрашивает действие от объекта 104.

Фиг. 3 показывает пример способа получения доступа объектом к облачной СППКР со стороны объекта.

Следует понимать, что последовательность этапов в способах, описанная в настоящем документе, не является ограничивающей. Следовательно, другие последовательности также входят в объем настоящего документа. Дополнительно, один или более этапов могут быть опущены и/или один или более дополнительных этапов могут быть включены.

На этапе 302 системе 116 аутентификации пользователей на объекте 104 предоставляется информация для входа пользователя через вычислительное устройство 112 пользователя на объекте 104.

На этапе 304 система 116 аутентификации пользователей аутентифицирует пользователя на основе информации для входа пользователя.

На этапе 306 система 116 аутентификации пользователей извлекает роли, назначенные пользователю, на основе информации для входа пользователя.

На этапе 308 система 116 аутентификации пользователей отправляет запрос, вместе с ролями, на перечень доступных пользователю действий облачной СППКР 102.

На этапе 310 система 116 аутентификации пользователей получает перечень доступных пользователю действий от облачной СППКР 102 и визуально отображает перечень через вычислительное устройство 112. Как описано в настоящем документе, одно или более действий из перечня действий может требовать аутентификацию объекта. Полученный перечень действий идентифицирует, какие действия, при наличии таковых, требуют аутентификации объекта.

На этапе 312 вычислительное устройство 112 получает входные данные с выбором одного действия из перечня.

На этапе 314 система 116 аутентификации пользователей определяет, требует ли выбранное действие аутентификации объекта.

На этапе 316 система 116 аутентификации пользователей отправляет запрос, который содержит действие и маркер сеанса, облачной СППКР.

На этапе 318 система 116 аутентификации пользователей получает от облачной СППКР 102 запрос на проверку достоверности маркера сеанса.

На этапе 320 система 116 аутентификации пользователей осуществляет проверку достоверности маркера в случае, если отправленные и принятые маркеры сеанса соответствуют друг другу (т.е. они являются одинаковыми).

На этапе 322, если система 116 аутентификации пользователей устанавливает достоверность маркера сеанса, облачная СППКР 102 считает запрос выполненным.

На этапе 324, если система 116 аутентификации пользователей не устанавливает достоверность маркера сеанса, облачная СППКР 102 отклоняет запрос.

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

Фиг. 4 показывает пример получения объектом доступа к облачной СППКР со стороны облачной СППКР.

Следует понимать, что последовательность этапов в способах, описанная в настоящем документе, не является ограничивающей. Следовательно, другие последовательности также входят в объем настоящего документа. Дополнительно, один или более этапов могут быть опущены и/или один или более дополнительных этапов могут быть включены.

На этапе 402 облачная СППКР 102 получает запрос, вместе с перечнем ролей пользователя, от системы 116 аутентификации пользователей на объекте 104, на перечень доступных аутентифицированному пользователю действий.

На этапе 404 облачная СППКР 102 возвращает перечень доступных действий.

На этапе 406 облачная СППКР 102 получает запрос на действие вместе с маркером сеанса.

На этапе 408 облачная СППКР 102 отправляет запрос, вместе с маркером сеанса, объекту 104 на проверку достоверности маркера сеанса.

На этапе 410 определяется, установлена ли достоверность маркера сеанса.

На этапе 412, если достоверность маркера сеанса установлена, например, если отправленный маркер сеанса соответствует принятому маркеру сеанса, облачная СППКР 102 выполняет запрос.

На этапе 414, если достоверность маркера сеанса не установлена, например, если отправленный маркер сеанса не соответствует принятому маркеру сеанса, облачная СППКР 102 отклоняет запрос.

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

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