Результат интеллектуальной деятельности: СПОСОБ И СИСТЕМА ДЛЯ ПРИДАНИЯ АНОНИМНОСТИ МНОГОУЗЛОВОМУ ПОКАЗАТЕЛЮ ЭФФЕКТИВНОСТИ И ДЛЯ УПРАВЛЕНИЯ ДЕЙСТВИЯМИ И ПОВТОРНОЙ ИДЕНТИФИКАЦИЕЙ АНОНИМНЫХ ДАННЫХ

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

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

Отображение узлов в общих ID было использовано в качестве способа частичной деидентификации данных эффективности, однако все же существует возможность декодирования некоторых узлов, зная сколько узлов и отделений являются частью системы. Например, если были закодированы одна больница с отделением интенсивной терапии (ICU) на 12 койко-мест и отделением интенсивной терапии для больных с острой коронарной недостаточностью (CCU) на 12 койко-мест и предприятие с 6 больницами, каждая с 6 ICU (включая неонатальное отделение интенсивной терапии (NICU)), будет очевидно, что 36 отделений принадлежат к большому объекту, а 2 принадлежат к небольшому. Аналогично, если за год было 3600 обращений в одном узле и 78000 обращений в другом, или присутствуют данные NICU в данных одного узла, будет очевидно какой объект был каким.

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

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

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

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

Настоящая заявка предоставляет новую и улучшенную аппаратуру и способ, которые решают проблемы, описанные выше и прочие проблемы.

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

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

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

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

Другое преимущество заключается в повторной идентификации де-нормализованных данных на основании аутентификации пользователя без отправки мандата за пределы домена хостинга.

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

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

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

Другое преимущество заключается в улучшенном клиническом лечении и эффективности, которые следуют из эталонного тестирования, обеспечиваемого данным изобретением.

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

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

Фиг. 1 является структурной схемой инфраструктуры IT в соответствии с настоящей заявкой.

Фиг. 2 является блок-схемой последовательности способа для придания анонимности многоузловым показателям эффективности в соответствии с настоящей заявкой.

Фиг. 3 является схемой конфигурации поставщика медицинского обслуживания в соответствии с настоящей заявкой.

Фиг. 4 является схемой сценария доступа поставщика медицинского обслуживания в соответствии с настоящей заявкой.

Фиг. 5 является схемой логики повторной идентификации в соответствии с настоящей заявкой.

Фиг. 6 является схемой сценария непосредственного облачного доступа в соответствии с настоящей заявкой.

Фиг. 7 является блок-схемой последовательности способа для управления действием и повторной идентификацией анонимных данных в соответствии с настоящей заявкой.

Со ссылкой на Фиг. 1, структурная схема иллюстрирует один вариант осуществления инфраструктуры 10 информационной технологии (IT) системы для управления доступом к клиническим данным, анализируемым удаленным вычислительным ресурсом. Инфраструктура 10 IT соответственно включает в себя одну или более системы и поставщиков 12 медицинского обслуживания, удаленный вычислительный ресурс или объединенное хранилище 14 данных, и подобное, взаимосвязанные через сеть 16 связи. Предполагается, что сеть 16 связи включает в себя одно или более из Интрасети, локальной сети, глобальной сети, беспроводной сети, проводной сети, сотовой сети, шины данных, персональной сети, и подобного. Поставщик 12 медицинского обслуживания собирает клинические данные, которые относятся к одному или более пациентам, в отношении которых осуществляется лечение посредством системы медицинского обслуживания или медицинского учреждения, которые анализируются и хранятся удаленным вычислительным ресурсом 14, который в одном варианте осуществления располагается в облачной инфраструктуре. В других вариантах осуществления, система может быть расположена в одном местоположении. В еще одном другом варианте осуществления может существовать в среде безопасности, а передача данных осуществляется через открытые средства связи или совместно используемую инфраструктуру.

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

Используемые в данном документе «клинические данные» могут относиться к данным, собранным у пациента или из медицинского учреждения посредством любого количества обычных способов. Например, клинические данные могут быть собраны в полевых условиях поставщиком медицинского обслуживания, таким как врач или клиницист. В другом варианте осуществления, клинические данные включают в себя данные, которые относятся к самочувствию заданного пациента или субпопуляции. В другом варианте осуществления, клинические данные включают в себя данные, которые относятся к структуре и локальной эффективности поставщика медицинского обслуживания. В качестве альтернативы, пациент может быть принят к поставщику медицинского обслуживания, как например, в больницу или клинику экстренной помощи и соответствующие клинические данные могут быть собраны, например, посредством госпитализации или назначения в поставщике медицинского обслуживания. Клинические данные могут быть собраны посредством других медицинских устройств, таких как регистрирующие устройства пациента, включающие в себя различные подсистемы для каждого основного показателя состояния организма, такого как SpO₂, температура, кровяное давление, частота сердцебиения и т.д., различное оборудование формирования изображения, регистрирующих устройств-кардиостимуляторов и опрашивающих устройств, лабораторного оборудования, и других систем сбора клинических данных. Клинические данные также могут быть собраны домашними системами регистрации пациента, которые могут предоставлять отчет о физических, химических, электрических или других клинических параметрах пациента. Используемый в данном документе сбор данных может быть эпизодическим, основанным на предварительно заданном событии или вероятностным процессом, периодическим, таким как каждые 4 часа, или непрерывным. Сбор данных может быть в режиме реального времени, в режиме близком к реальному времени или ранее полученным и позже выгруженным.

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

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

Для денормализации клинических данных таким образом, что другие поставщики медицинского обслуживания, не могут выявить источник клинических данных, поставщик 12 медицинского обслуживания включает в себя машину 22 преобразования, которая денормализует клинические данные, созданные поставщиком 12 медицинского обслуживания, которые сохраняются в базе 24 данных набора де-нормализованных данных. В частности, машина 22 преобразования преобразует клинические данные таким образом, что уникальный атрибут является де-нормализованным и анонимным, когда просматривается в отношении другого набора клинических данных. Для выполнения этого, удаленный вычислительный ресурс 14 определяет целевое количество записей для каждого уникального атрибута клинических данных, которые отправляются к или на которые ссылается машина 22 преобразования. Например, удаленный вычислительный ресурс 14 сообщает формат преобразования, который выдает машине 22 преобразование инструкцию в отношении того, каким образом прореживать клинические данные, включающие в себя целевое количество записей для каждого уникального атрибута для каждого поставщика 12 медицинского обслуживания. Целевое количество для каждого уникального атрибута в клинических данных является набором, где требуется анонимность поставщика медицинского обслуживания. Например, если набор данных первого поставщика медицинского обслуживания включает в себя шесть (6) лечебных отделений, а набор данных второго поставщика медицинского обслуживания включает в себя два (2) лечебных отделения, удаленный вычислительный ресурс 14 будет определять целевое количество записей для атрибута лечебного отделения как наименьшая общая размерная величина записей наборов данных. В данном случае, набор данных первого поставщика медицинского обслуживания будет преобразован из записей шести (6) лечебных отделений в три (3) разные записи двух (2) лечебных отделений, таким образом придавая анонимность набору данных первого поставщика медицинского обслуживания в отношении набора данных второго поставщика медицинского обслуживания. Машина 22 преобразования преобразует клинические данные в соответствии с целевым количеством для каждого уникального атрибута таким образом, что источник клинических данных является анонимным. В частности, машина 22 преобразования денормализует клинические данные в кубы данных на основании уникальных атрибутов, которым должна быть придана анонимность, целевого количества каждых уникальных атрибутов, и определения куба данных, принятого от удаленного вычислительного ресурса 14. Определение куба данных является стандартным форматом данных, используемым удаленным вычислительным ресурсом 14 таким образом, что де-нормализованные клинические данные могут быть эффективно сравнены с клиническими данными другого поставщика медицинского обслуживания. В другом варианте осуществления, машина 22 преобразования генерирует таблицу глобальных уникальных идентификаторов (GUID), которая отображает каждый атрибут в де-нормализованных данных обратно в формат нормализованных данных. Для того чтобы повторно идентифицировать де-нормализованные данные, машина 26 повторной идентификации использует таблицу GUID для обратного отображения де-нормализованных данных в их исходный нормализованный формат. Поставщик 12 медицинского обслуживания также включает в себя устройства ввода пользователя для ввода клинических данных или регулировки целевого количества каждого из уникальных атрибутов и/или определения куба данных. В некоторых вариантах осуществления, поставщик 12 медицинского обслуживания включает в себя дисплейные устройства, предоставляющие пользователям интерфейс пользователя, в котором вручную вводят клинические данные и/или для демонстрации сгенерированных отчетов и/или анализа клинических данных.

Например, в сценарии, описываемом в Таблице A, Поставщик A Медицинского Обслуживания включает в себя три (3) больницы (Больница 1, 2, и 3) с различными отделениями (MICU, SICU, CCU, NICO, ICU, CVICU, RICU, и PICU) и соответствующим количеством койко-мест на отделение. Поставщик B Медицинского Обслуживания включает в себя больницу с тремя (3) отделениями (CCU, ICU, и NICU) и соответствующим количеством койко-мест на отделение.

В удаленной вычислительной системе 14, присутствует конфигурация, которая считывается поставщиками 12 медицинского обслуживания и содержит, в дополнение к определениям куба преобразования, целевое количество параметров атрибута для замещения GUID. В данном примере, размер отделения равен шести (=6), а количество отделений для отделений на больницу равно двум (=2). В данном примере существует потребность придать анонимность койко-месту источника. Если данные не ассоциированы с койко-местом, а вместо этого с обращением, то данные обращения могут быть произвольно назначены новому представлению объединенного отделения.

Машина 22 преобразования денормализует клинические данные посредством произвольного разбиения койко-мест из одного лечебного отделения на отделения из шести (6) койко-мест и системы больниц с двумя (2) лечебными отделениями. Как упомянуто ранее, удаленный вычислительный ресурс 14 сообщает формат преобразования, который выдает машине 22 преобразования инструкцию о том, каким образом прореживать клинические данные, включая целевое количество записей для каждого уникального атрибута каждого поставщика 12 медицинского обслуживания. Данные обращения от пациентов, госпитализированных на эти койко-места, теперь могут быть представлены как клинические данные без возможности другими узлами определения источника. Таблица B ниже описывает преобразование в последовательную форму идентификации преобразования, чтобы было проще видно преобразование, однако в предпочтительном варианте осуществления, идентификация преобразования не будет представлена в любой различимой очередности и содержать вместо этого длинный буквенно-цифровой случайный GUID. Нижеследующее представляет собой результирующее преобразование:

Машина 22 преобразования также создает таблицу GUID, представляющую собой дескрипторы, которые были изменены (в данном случае Больницы и Отделения) и сохраняет таблицу ссылок для повторной идентификации данных на поставщике медицинского обслуживания источнике. Для Больницы Поставщика B Медицинского Обслуживания Таблица C описывает таблицу GUID в данном примере.

В данном примере, Поставщик B Медицинского Обслуживания будет знать, что ID больницы с 1aa по 1ad представляют собой его лечебные отделения CCU8 и CCU9 и в частности лечебное отделение на 16 койко-мест Поставщика B Медицинского Обслуживания, но другие поставщики медицинского обслуживания, смотрящие на данные, не могут разглядеть, какое из койко-мест CCU относится к какой больнице. Когда поставщик 12 медицинского обслуживания запрашивает отчет и/или анализ на основании хранилища сохраненных объединенных данных, поставщик 12 медицинского обслуживания может сравнить свою эффективность с другими подобными лечебными отделениями и объектами, не зная того, какой объект источник принадлежит к результатам группы. Если поставщик медицинского обслуживания выбирает эталонное тестирование друг с другом, им просто требуется совместно использовать таблицу GUID для того, чтобы видеть эффективность и любых поставщиков медицинского обслуживания эталонного тестирования, которые согласились совместно использовать идентификационные данные. Пример выше может быть легко расширен с тем, чтобы вызывать преобразование клинических данных с поставщиками 12 медицинского обслуживания, содержащими одну больницу, так что таблица выше будет казаться сформированной из сорока трех (43) предприятий, каждое из одной больницы с двумя (2) лечебными отделениями, содержащими не более шести (6) койко-мест. Дополнительные дескрипторы могут быть добавлены к определению куба, чтобы способствовать оперативным исследованиям. Например, новый параметр может быть добавлен к представлению клинических данных, указывающий на то, является ли объединенное отделение из большого отделения (скажем более 16 койко-мест) или небольшого.

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

В другом варианте осуществления, один или более поставщики 12 медицинского обслуживания передают нормализованные клинические данные удаленному вычислительному ресурсу 14, который сохраняет нормализованные клинические данные в удаленной базе 30 данных набора нормализованных данных. Для денормализации клинических данных таким образом, что другие поставщики медицинского обслуживания не могут выявить источник клинических данных, удаленный вычислительный ресурс 14 включает в себя машину 22 преобразования, которая денормализует клинические данные, созданные поставщиком 12 медицинского обслуживания, которые сохраняются в удаленной базе 32 данных набора де-нормализованных данных. Машина 22 преобразования преобразует клинические данные в соответствии с целевым количеством для каждого уникального атрибута как описано выше. В частности, машина 22 преобразования де-нормализует клинические данные в один или более кубы данных на основании уникальных атрибутов, в отношении которых требуется придать анонимность, целевого количества каждого из уникальных атрибутов, и определения куба данных удаленного вычислительного источника 14. Машина 22 преобразования также генерирует таблицу глобальных уникальных идентификаторов (GUID), которая отображает каждый атрибут в де-нормализованных данных обратно в формат нормализованных данных. Для того чтобы повторно идентифицировать де-нормализованные данные, машина 26 идентификации использует таблицу GUID для отображения де-нормализованных данных обратно в их исходный нормализованный формат. Удаленный вычислительный ресурс 14 также включает в себя устройства ввода пользователя для ввода клинических данных и регулировки целевого количества каждого из уникальных атрибутов и/или определения куба данных. В некоторых вариантах осуществления, удаленный вычислительный ресурс 14 включает в себя дисплейные устройства, предоставляющие пользователям интерфейс пользователя, в котором вручную вводить клинические данные и/или для демонстрации сгенерированных отчетов и/или анализа клинических данных.

Со ссылкой на Фигуру 2, иллюстрируется блок-схема 200 последовательности способа для придания анонимности многоузловым показателям эффективности. На этапе 202, один или более поставщики медицинского обслуживания соединяются с удаленным вычислительным ресурсом. На этапе 204, один или более поставщики медицинского обслуживания считывают определение куба данных из удаленного вычислительного ресурса. На этапе 206, один или более поставщики медицинского обслуживания считывают список денормализации атрибута и целевое количество параметров для каждого атрибута из удаленного вычислительного ресурса. На этапе 208, один или более поставщики медицинского обслуживания создают кубы данных в соответствии с определением куба данных. На этапе 210, один или более поставщики медицинского обслуживания преобразуют данные посредством создания случайных GUID согласно определениям куба и списку рандомизации атрибута. На этапе 212, таблица GUID для повторной идентификации данных создается в поставщике медицинского обслуживания. На этапе 214, преобразованные данные отправляются удаленному вычислительному ресурсу. На этапе 216, один или более поставщики медицинского обслуживания выполняют проверку на наличие новых определений куба согласно расписанию преобразования.

Продолжая ссылаться на Фигуру 1 и в сценарии, при котором один или более поставщики 12 медицинского обслуживания передают нормализованные клинические данные удаленному вычислительному ресурсу 14, который денормализует клинические данные, удаленный вычислительный ресурс 14 управляет доступом и повторной идентификацией в отношении де-нормализованных данных. В частности, удаленный вычислительный ресурс включает в себя предварительно заданные роли в отношении того, какие действия могут быть вызваны пользователями поставщиков 12 медицинского обслуживания при попытке осуществления доступа к и повторной идентификации де-нормализованных клинических данных. Эти роли синхронизированы с ролями пользователя поставщика медицинского обслуживания для аутентификации. В частности, пользователь поставщика 12 медицинского обслуживания осуществляет вход в приложение поставщика медицинского обслуживания и на основании своих одобренных ролей, им предлагаются действия для вызова над де-нормализованными клиническими данными, такие как построение списка отчетов, списка отделений, отчета по пациенту и т.д. Как только пользователь устанавливает интересующий отчет на основании де-нормализованных данных, пользователь может вызвать удаленный вычислительный ресурс 14 для повторной идентификации де-нормализованных клинических данных. Данное действие вызывает передачу сертификата от поставщика 12 медицинского обслуживания машине 26 повторной идентификации удаленного вычислительного ресурса 14. Де-нормализованные клинические данные затем повторно идентифицируются на основании таблицы GUID и удаленного вычислительного ресурса 14, для которого сертификат, хранящий в удаленном вычислительном ресурсе 14, совпадает с сертификатом, принятым от поставщика 12 медицинского обслуживания.

В частности, один или более поставщики 12 медицинского обслуживания включают в себя машину 34 аутентификации, которая позволяет пользователям входить в приложение поставщика медицинского обслуживания для выбора одного или более действий для вызова машины 28 анализа и отчетности удаленного вычислительного ресурса 14 на основании полей, установленных для этого конкретного пользователя. Например, если одобренной ролью пользователя является врач, машина 28 анализа и отчетности предоставляем им возможность создания отчета по пациенту. Подобным образом, если ролью пользователя является администратор, машина 28 анализа и отчетности позволяет пользователю создавать отчеты, которые относятся к эффективности одного или более поставщиков медицинского обслуживания. После того, как пользователь выбирает интересующее действие на основании де-нормализованных данных, пользователю представляется опция для повторно идентификации де-нормализованных клинических данных, ассоциированных с их поставщиком 12 медицинского обслуживания. Если пользователь выбирает повторную идентификацию де-нормализованных клинических данных, машина 34 аутентификации передает сертификат машине 22 повторной идентификации удаленного вычислительного ресурса 14. Если машина 22 повторной идентификации удаленного вычислительного ресурса 14 определяет, что сертификат, принятый от машины 34 аутентификации, совпадает с сертификатом, который хранится в удаленном вычислительном ресурсе 14, машина 22 повторной идентификации использует таблицу GUID для обратного отображения де-нормализованных клинических данных, ассоциированных с поставщиком медицинского обслуживания, в их исходном нормализованном формате. Также следует иметь в виду, что вышеприведенный процесс аутентификации также может быть использован для управления доступом к де-нормализованным клиническим данным подобным образом.

Компоненты инфраструктуры 10 IT соответственно включают в себя процессоры 40, исполняющие исполняемые компьютером инструкции, воплощающие вышеприведенные функциональные возможности, при этом исполняемые компьютером инструкции хранятся в памяти 42, ассоциированной с процессорами 40. Тем не менее, предполагается, что, по меньшей мере, некоторые из вышеприведенных функциональных возможностей могут быть реализованы в аппаратном обеспечении без использования процессоров. Например, может быть использована аналоговая схема. Кроме того, компоненты инфраструктуры 10 IT включают в себя блоки 44 связи, предоставляющие процессорам 40 интерфейс, через который осуществлять связь по сети 20 связи. Даже больше, несмотря на то, что вышеприведенные компоненты инфраструктуры 10 IT были описаны по отдельности, следует иметь в виду, что компоненты могут быть объединены.

Со ссылкой на Фигуру 3, иллюстрируется схема 300 конфигурации поставщика медицинского обслуживания. Пользователь входит 302 в приложение 304 просмотра поставщика медицинского обслуживания. Затем пользователь аутентифицируется 306 через активный каталог 308 поставщика медицинского обслуживания. Приложение 304 просмотра поставщика медицинского обслуживания представляет отчет о роле пользователя 310. Пользователем выбирается действие для вызова над де-нормализованными данными 312 и сообщается удаленному вычислительному ресурсу 314. Затем роль пользователя и выбранное действие сохраняются локально 316 для дальнейшей обработки.

Со ссылкой на Фигуру 4, иллюстрируется схема 400 сценария доступа поставщика медицинского обслуживания. Пользователь входит 402 в приложение 404 просмотра поставщика медицинского обслуживания. Затем пользователь аутентифицируется через активный каталог 408 поставщика медицинского обслуживания. Приложение 404 просмотра поставщика медицинского обслуживания ищет действие, выбранное пользователем для вызова над де-нормализованными данными 410. От удаленного вычислительного ресурса 414 предоставляется доступный пользователю 412 список действий для вызова над де-нормализованными данными и демонстрируется пользователю 416 в приложении 404 просмотра поставщика медицинского обслуживания. Пользователь щелкает по действию 416 в приложении 404 просмотра поставщика медицинского обслуживания. В ответ на щелчок по действию, маркер сеанса отправляется 418 услуге 420 повторной идентификации. Действие, вызванное пользователем 422 запускается с помощью маркера 424. В ответ на запуск вызванного действия, маркер подтверждается 426 через услугу 420 повторной идентификации. Если подтверждение завершается неудачей 428, демонстрируется страница 430 ошибки. Если подтверждение проходит 432, действие вызывается и данные нормализуются и демонстрируются пользователю.

Со ссылкой на Фигуру 5, иллюстрируется схема 500 логики повторной идентификации. При выборе действия для вызова 502, команда 504 повторной идентификации передается услуге повторной идентификации. Если подтверждение маркера заканчивается неудачей 506, демонстрируется страница 508 ошибки. Если подтверждение маркера проходит 510, действие вызывается и данные нормализуются 512 и демонстрируются пользователю.

Со ссылкой на Фигуру 6, иллюстрируется схема 600 сценария непосредственного облачного доступа. Пользователь входит 602 в приложение 604 управления поставщика медицинского обслуживания. Затем пользователь аутентифицируется 6066 через облачный активный каталог 608. Управление доступом к действиям для вызова над де-нормализованными данными осуществляется на основании роли пользователя 610, которая принимается 612 от облачного активного каталога 608. На основании ролей пользователя, осуществляется управление 614 функцией просмотра и доступа к де-нормализованным данным.

Со ссылкой на Фигуру 7, иллюстрируется блок-схема 700 последовательности способа для управления действием и повторной идентификацией анонимных данных. На этапе 702, де-нормализованные данные сохраняются в удаленном вычислительном ресурсе. На этапе 704, пользователь входит в приложение поставщика медицинского обслуживания. На этапе 706, удаленный вычислительный ресурс предоставляет действия пользователя для вызова над де-нормализованными данными на основании роли пользователя. На этапе 708, поставщик медицинского обслуживания передает сертификат удаленному вычислительному ресурсу в ответ на вызов пользователем действия для повторной идентификации нормализованных данных. На этапе 710, удаленный вычислительный ресурс повторно идентифицирует де-нормализованные данные в ответ на сертификат, принятый от поставщика медицинского обслуживания, совпадающий с сертификатом, который хранится в удаленном вычислительном ресурсе.

Используемая в данном документе, память включает в себя одно или более из: не-временный машиночитаемый носитель информации; магнитный диск или другой магнитный запоминающий носитель информации; оптический диск или другой оптический запоминающий носитель информации; запоминающее устройство с произвольной выборкой (RAM), постоянное запоминающее устройство (ROM), или другое электронное устройство памяти или чип или набор оперативно взаимно-соединенных чипов; сервер Интернет/Интрасети, от которого хранящиеся инструкции могут быть извлечены через Интернет/Интрасеть или локальную сеть; и т.п. Кроме того, используемый в данном документе, процессор включает в себя одно или более из: микропроцессор, микроконтроллер, графический блок обработки (GPU), проблемно-ориентированную интегральную микросхему (ASIC), программируемую вентильную матрицу (FPGA), и подобное; устройство ввода пользователя включает в себя одно или более из: манипулятор типа мышь, клавиатуру, дисплей с сенсорным экраном, одну или более кнопки, один или более переключатели, один или более тумблеры, и подобное; дисплейное устройство включает в себя одно или более из: LCD дисплей, LED дисплей, плазменный дисплей, проекционный дисплей, дисплей с сенсорным экраном, и подобное.

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