УСТРОЙСТВО, СИСТЕМА И СПОСОБ ДЛЯ ОПЕРАЦИОННЫХ ПЕРСОНАЛЬНЫХ МЕДИЦИНСКИХ КАРТ Российский патент 2023 года по МПК G06F21/60 G16H10/60 

Уровень техники

[0001] Персональная медицинская карта (PHR) может включать в себя медицинскую информацию и другую связанную информацию, ассоциированную с человеком (совместно называется в данном документе "информацией медицинского характера"). PHR может принадлежать, храниться и управляться человеком (в дальнейшем "владельцем") персональным способом таким образом, что информация медицинского характера управляется частным, защищенным и конфиденциальным способом. Если владелец PHR является внимательным при обновлении PHR, PHR может использоваться для того, чтобы предоставлять охватывающую сводку всей истории болезни владельца. PHR может включать в себя информацию из множества других источников, в том числе от владельца, медицинского работника, из организации здравоохранения и т.д. Информация может вручную добавляться в PHR владельцем, может автоматически добавляться посредством услуги, предоставляющей PHR, либо как комбинация вышеозначенного. Например, услуга, предоставляющая PHR, может принимать ручные записи или вводы от владельца, может запрашивать информацию от медицинского работника, может пассивно собирать информацию медицинского характера из электронного устройства владельца и т.д.

[0002] PHR может использоваться в различных форматах. В простом формате PHR, может представлять собой бумажную карту, хранимую владельцем. Тем не менее, в качестве бумажной карты, PHR может не быть легкодоступной при необходимости, к примеру, во время консультации с медицинским работником. В другом формате, PHR может иметь электронный формат. В первом примере, PHR в электронном формате может сохраняться практически аналогично бумажной карты, в которой информация медицинского характера сохраняется в персональном файле владельца. Если персональный файл сохраняется в облаке или через онлайновый механизм, PHR может быть доступной онлайновым способом. Во втором примере, PHR в электронном формате может предоставляться посредством услуги, такой как онлайновая услуга (например, веб–узел). Таким образом, PHR может быть доступной онлайн до тех пор, пока онлайновая услуга может достигаться.

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

[0004] Когда PHR сохраняется в электронном формате, информация медицинского характера может разделяться на общедоступную информацию и конфиденциальную информацию. Например, персональная информация может классифицироваться в качестве конфиденциальной информации. Тем не менее, персональная информация также может разделяться на разделы, которые классифицируются в качестве конфиденциальной информации (например, информации о местожительстве) и общедоступной информации (например, контактного номера для экстренных вызовов). Другие типы информации также могут классифицироваться таким образом. Например, когда информация медицинского характера принимается от медицинского работника, эта информация может классифицироваться в качестве общедоступной информации. Следует отметить, что общедоступность может означать доступность для медицинских работников и организаций здравоохранения.

[0005] Когда PHR имеет бумажный формат или находится в персональном файле в электронном формате, информация медицинского характера в PHR может сохраняться с использованием любого предпочитаемого пользователем способа. Когда PHR предоставляется посредством услуги в электронном формате, информация медицинского характера в PHR может сохраняться или отображаться согласно способу, выбранному посредством услуги. Например, услуга может определять то, какая из информации PHR должна быть общедоступной или конфиденциальной. В другом примере, услуга может размещать информацию согласно стандарту, который выбирает услуга, к примеру, как страница персональной информации, страница общей медицинской информации, страница назначений лекарственных препаратов и т.д.

[0006] С учетом охватывающей сводки, которая может быть включена в PHR, могут быть предусмотрены выгоды от наличия самой актуальной PHR. Тем не менее, ведение и обновление PHR таким образом, что она является всесторонней, требует значительного времени и ресурсов. Например, владелец может принимать на себя использование собственного времени и ресурсов для того, чтобы обновлять PHR. Соответственно, владелец может контактировать с медицинским работником, чтобы собирать и вводить результаты процедуры или анализа, выполняемого медицинским работником. В другом примере, если уточнить, владелец может обновлять PHR каждый раз, когда возникает событие медицинского характера (например, каждый раз, когда посещается доктор, каждый раз, когда заполняется рецепт, каждый раз, когда выполняется тест, при каждом посещении больницы и т.д.).

[0007] Несмотря на потенциальную значимость наличия текущей PHR, которая доступна для использования медицинскими работниками и организациями здравоохранения (в дальнейшем совместно называются "субъектом здравоохранения"), управление и обновление PHR ограничено вышеописанным способом. К сожалению, субъекты здравоохранения (например, доктора, больницы, аптеки, страховые компании и т.д.) не приспосабливают универсальный способ использования информационных технологий для того, чтобы взаимодействовать при ведении текущей PHR для владельца. Фактически, могут быть предусмотрены только избранные субъекты здравоохранения (например, меньшинство), которые допускают передачу информации электронным способом даже для PHR, которая должна обновляться.

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

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

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

[0011] Кроме того, информация медицинского характера в PHR представляет собой конфиденциальную информацию, в которой учитываются проблемы конфиденциальности. Следовательно, информация медицинского характера PHR, в общем, не является общедоступной для осуществления доступа, в частности, когда PHR имеет электронный формат. Даже если к PHR должно осуществляться доступ посредством субъекта здравоохранения, весь контент информации медицинского характера может становиться доступным с традиционными признаками PHR. Когда весь контент информации медицинского характера становится доступным для субъекта здравоохранения, EHR, которая ведется для владельца субъектом здравоохранения, может теперь включать в себя эту информацию. Со стороны субъекта здравоохранения, специалисты в данной области техники должны понимать, что различные правила конфиденциальности установлены, к примеру, с помощью закона о страховании здоровья и медицинской ответственности 1996 (HIPAA), в котором информация медицинского характера человека и ее использование/раскрытие должны придерживаться стандартов, включенных в HIPAA. Таким образом, ведение уровня конфиденциальности в PHR из общественных субъектов и субъектов здравоохранения предоставляет важный признак. Тем не менее, текущее состояние PHR не обеспечивает возможность избирательной доступности идентифицированных частей в PHR.

Сущность изобретения

[0012] Примерные варианты осуществления направлены на способ, содержащий: на сервере персональных медицинских карт (PHR), ведение PHR владельца, причем PHR включает в себя множество разделов, причем один из разделов представляет собой агрегированный раздел, включающий в себя множество подразделов, причем один из подразделов соответствует субъекту здравоохранения; прием ввода с извлечением от владельца PHR, причем ввод на извлечение идентифицирует субъект здравоохранения, из которого должна запрашиваться информация; формирование запроса информации; передачу запроса в субъект здравоохранения; прием информации из субъекта здравоохранения; и включение информации в подраздел агрегированного раздела в PHR, соответствующей субъекту здравоохранения.

[0013] Примерные варианты осуществления направлены на сервер персональных медицинских карт (PHR), который ведет PHR владельца, содержащий: приемопередающее устройство, обменивающееся данными через сеть связи, причем приемопередающее устройство выполнено с возможностью обмениваться данными с пользовательским устройством, используемым владельцем PHR, и электронным устройством субъекта здравоохранения; запоминающее устройство, сохраняющее выполняемую программу; и процессор, который исполняет исполняемую программу, которая инструктирует процессору выполнять операции при ведении PHR, причем PHR включает в себя множество разделов, причем первый из разделов представляет собой персональный раздел, включающий в себя персональную информацию, ассоциированную с владельцем, причем второй из разделов представляет собой агрегированный раздел, включающий в себя множество подразделов, причем каждый из подразделов соответствует соответственному субъекту здравоохранения, причем подразделы включают в себя соответствующую информацию медицинского характера, ассоциированную с владельцем, на основе соответствующей карты, которая ведется этим соответственным субъектом здравоохранения.

[0014] Примерные варианты осуществления направлены на сервер персональных медицинских карт (PHR), который ведет PHR владельца, причем PHR включает в себя множество разделов, причем один из разделов представляет собой агрегированный раздел, включающий в себя множество подразделов, причем один из подразделов соответствует субъекту здравоохранения, содержащий: приемопередающее устройство, обменивающееся данными через сеть связи, причем приемопередающее устройство выполнено с возможностью обмениваться данными с пользовательским устройством, используемым владельцем PHR, и электронным устройством субъекта здравоохранения; запоминающее устройство, хранящее исполняемую программу; и процессор, который исполняет исполняемую программу, которая инструктирует процессору выполнять операции, содержащие: прием ввода с извлечением от владельца PHR, причем ввод на извлечение идентифицирует субъект здравоохранения, из которого должна запрашиваться информация; формирование запроса информации; передачу запроса в субъект здравоохранения; прием информации из субъекта здравоохранения; и включение информации в подраздел агрегированного раздела в PHR, соответствующей субъекту здравоохранения.

Краткое описание чертежей

[0015] Фиг. 1 показывает систему согласно примерным вариантам осуществления.

[0016] Фиг. 2 показывает сервер персональных медицинских карт по фиг. 1 согласно примерным вариантам осуществления.

[0017] Фиг. 3 показывает способ для включения информации в медицинскую карту пациента согласно примерным вариантам осуществления.

[0018] Фиг. 4 показывает способ для предоставления информации из медицинской карты пациента согласно примерным вариантам осуществления.

Осуществление изобретения

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

[0020] Примерные варианты осуществления выполнены с возможностью четко разделять информацию медицинского характера на основе того, создана или нет информация медицинского характера первоначально владельцем PHR, либо на основе того, создана или нет информация медицинского характера первоначально субъектом здравоохранения (например, медицинским работником, организацией здравоохранения и т.д.), либо на основе электронной медицинской карты (EHR), принадлежащей субъекту здравоохранения. В частности, информация медицинского характера PHR может разделяться на множество разделов: первый раздел для персональной информации, ассоциированный с владельцем, второй раздел, ассоциированный с агрегированными данными из субъектов здравоохранения, третий раздел для избирательно просматриваемой информации и т.д. Посредством организации информации медицинского характера согласно примерным вариантам осуществления, примерные варианты осуществления также могут предоставлять способ для каждой стороны (например, владельца PHR, субъекта здравоохранения или третьей стороны), чтобы добавлять и/или осуществлять доступ к соответствующим выборам информации медицинского характера на основе управления доступом и политик, реализуемых при организации PHR. Следовательно, примерные варианты осуществления включают в себя архитектуру, которая предоставляет более высокодетализированный доступ, а также совместное использование и делегирование информации медицинского характера в PHR.

[0021] Фиг. 1 показывает систему 100 согласно примерным вариантам осуществления. Система 100 относится к связи между различными компонентами, предусмотренными при использовании PHR, как при обновлении PHR до самого актуального состояния, так и при запросе информации из PHR. Система 100 может включать в себя пользовательское устройство 105, сеть 110 связи и множество устройств, ассоциированных с различными субъектами здравоохранения. Например, первый субъект здравоохранения может включать в себя медицинского работника 125 (HCP), второй субъект здравоохранения может включать в себя организацию 130 здравоохранения (HCO), которая включает в себя, по меньшей мере, HCP 135, и третий субъект здравоохранения может включать в себя HCO 140, которая включает в себя, по меньшей мере, три HCP 145, 150, 155. Как подробнее описано ниже, система 100 выполнена с возможностью добавлять информацию медицинского характера в PHR из информации, предоставляемой посредством пользовательского устройства 105 и/или субъектов здравоохранения, а также передавать запрашиваемую информацию медицинского характера з PHR в запрашивающий субъект здравоохранения. Система 100 дополнительно может включать в себя стороннее устройство 160. Стороннее устройство 160 также может запрашивать информацию медицинского характера из PHR, но не ассоциировано с субъектом здравоохранения (например, устройством, используемым посредством родственника владельца). Соответственно, чтобы предоставлять эти функциональности, система 100 также может включать в себя сервер 115 PHR и репозиторий 120 PHR.

[0022] Пользовательское устройство 105 может представлять собой любое электронное устройство, которое используется человеком, который владеет PHR (в дальнейшем "владельцем"). Например, пользовательское устройство 105 может представлять собой настольный компьютер, переносной компьютер, мобильный телефон, планшетный компьютер, смартфон, фаблет, встроенное устройство, носимый прибор и т.д. Пользовательское устройство 105 может включать в себя все аппаратные средства, программное обеспечение и микропрограммное обеспечение для операций и функциональностей, ассоциированных с PHR, включающих в себя аппаратные средства, программное обеспечение и микропрограммное обеспечение примерных вариантов осуществления, которые должны использоваться (например, процессор, запоминающее устройство, устройство отображения, приемопередающее устройство и т.д.). Соответственно, пользовательское устройство 105 может быть выполнено с возможностью выполнять приложение, которое обеспечивает возможность доступа для PHR и использования признаков PHR. Например, приложение может представлять собой собственное PHR–приложение, которое устанавливает соединение с сервером 115 PHR. В другом примере, приложение может представлять собой приложение браузера, в котором осуществляется доступ к онлайновой услуге или веб–странице сервера 115 PHR.

[0023] Пользовательское устройство 105 также может быть выполнено с возможностью устанавливать соединение с сетью 110 связи. В качестве иллюстрации, в данном документе описываются примерные варианты осуществления, в которых PHR представляет собой услугу, предоставляемую посредством сервера 115 PHR. Соответственно, обмен данными может выполняться между пользовательским устройством 105 и сервером 115 PHR таким образом, что сервер 115 PHR может предоставлять PHR–услугу. Тем не менее, следует отметить, что эта реализация является только примерной. PHR и соответствующее PHR–приложение могут работать локально на пользовательском устройстве 105. Дополнительная услуга или сторонний ретранслятор могут использоваться для обеспечения доступности PHR через сеть 110 связи.

[0024] Сеть 110 связи может быть выполнена с возможностью функционально соединять различные компоненты системы 100, чтобы обмениваться данными. В частности, сеть 110 связи может использоваться для того, чтобы обмениваться данными между сервером 115 PHR и пользовательским устройством 105, а также между сервером 115 PHR и субъектами здравоохранения (например, HCP 125, HCO 130 и HCO 140). Сеть 110 связи может представлять любую одну или множество сетей, используемых посредством компонентов системы 100 для того, чтобы обмениваться данными между собой. Например, HCO 140 может использовать частную сеть таким образом, что сеть 110 связи может функционально соединяться с частной сетью. Следует отметить, что сеть 110 связи и все сети, которые могут быть включены в нее, могут представлять собой любой тип сети. Например, сеть 110 связи может представлять собой локальную вычислительную сеть (LAN), глобальную вычислительную сеть (WAN), виртуальную LAN (VLAN), Wi–Fi–сеть, публичную точку доступа, сотовую сеть (например, 3G, 4G, по стандарту долгосрочного развития (LTE) и т.д.), облачную сеть, проводную форму этих сетей, беспроводную форму этих сетей, комбинированную проводную/беспроводную форму этих сетей и т.д.

[0025] Субъекты здравоохранения, включающие в себя HCO 130, 140 и HCP 125, 135, 145, 150, 155, могут включать в себя любой тип медицинского специалиста–практика. Например, HCP 125 (а также HCP 135, 145, 150, 155) может использоваться врачом, специалистом, техником и т.д. HCP 125 может представлять любое электронное устройство, которое выполнено с возможностью выполнять функциональности, ассоциированные с медицинским специалистом–практиком. HCP 125 также может представлять собой любой тип электронного устройства, такой как устройства, отмеченные выше для пользовательского устройства 105. Кроме того, HCP 125 может включать в себя необходимые аппаратные средства, программное обеспечение и/или микропрограммное обеспечение, чтобы выполнять различные операции, ассоциированные с медицинским специалистом–практиком, включающие в себя любые виды терапевтического лечения. HCP 125 дополнительно может включать в себя требуемые аппаратные средства, программное обеспечение и микропрограммное обеспечение для обеспечения соединения (например, приемопередающее устройство), чтобы устанавливать соединение с сетью 110 связи, с тем чтобы дополнительно устанавливать соединение с сервером 115 PHR из состава системы 100. Также следует отметить, что описание HCP 125 также может применяться к HCP 135, 145, 150, 155.

[0026] HCO 130, 140 могут включать в себя один или более HCP. Как проиллюстрировано, HCO 130 может включать в себя один HCP 135, в то время как HCO 140 может включать в себя более одного HCP 145, 150, 155. Тем не менее, следует отметить, что HCO 130, 140, включающие в себя определенное число HCP, проиллюстрированных в системе 100 по фиг. 1, являются только примерными. Специалисты в данной области техники должны понимать, что HCO 130, 140 могут включать в себя любое число HCP. HCO 130, 140 могут представлять любую организацию, с которой могут быть ассоциированы HCP. Например, HCO 130, 140 могут представлять собой организацию медицинского обеспечения (HMO). В другом примере, HCO 130, 140 могут составлять часть практической группы. В дополнительном примере, HCO 130, 140 могут представлять собой больницу. В еще одном другом примере, HCO 130, 140 могут составлять часть организации медицинского страхования.

[0027] Субъекты здравоохранения (и HCP и HCO) могут допускать формирование и ведение соответствующих электронных медицинских карт (EHR). EHR могут сохраняться в соответствующих репозиториях (не показаны). Например, HCP 125 может не составлять часть HCO и в силу этого сохранять EHR пациентов в локальном или удаленном репозитории. В другом примере, HCO 130, 140 могут включать в себя соответствующий сетевой репозиторий в соответствующей частной сети (не показана) HCO 130, 140. Таким образом, EHR пациентов HCP могут принадлежать, регулироваться, управляться и храниться посредством соответствующего HCP и/или HCO, с которой ассоциирован HCP. Например, HCP 125 может иметь EHR для пациента, соответствующего владельцу с использованием пользовательского устройства 105. Эта EHR может быть только собственной для HCP 125. В другом примере, HCO 140 может иметь EHR для пациента, соответствующего владельцу с использованием пользовательского устройства 105. Эта EHR может быть собственной для HCO 140 таким образом, что HCP 145, 150, 155 могут иметь доступ к этой EHR.

[0028] Следует отметить, что HCP 125, 135, 145, 150, 155 могут представлять собой электронные устройства, которые используются медицинским специалистом–практиком множеством различных способов. Например, HCP могут представлять собой профессиональные устройства, в которых выполняются функциональности ведения документации. Таким образом, создаваемые документы могут быть включены в EHR. В другом примере, HCP могут представлять собой процедурные устройства, к примеру, для захвата изображений, интерпретации изображений, лабораторных тестов и т.д. Когда процедуры выполняются, соответствующий документ может создаваться с возможностью включения в EHR.

[0029] Сервер 115 PHR может представлять собой компонент системы 100, которая выполняет функциональности, ассоциированные с потоком управления информацией PHR для владельца PHR (например, пользователя пользовательского устройства 105). Сервер 115 PHR дополнительно может быть выполнен с возможностью предоставлять дополнительные признаки, чтобы автоматизировать операции при обновлении PHR. Например, сервер 115 PHR может подписывать PHR на новостные потоки от медицинских работников, которые предоставляют автоматическое обновление PHR на основе информации, предоставляемой медицинскими работниками. Следовательно, каждый раз, когда владелец PHR принимает обновление медицинского характера (например, от медицинского работника), результат может автоматически вводиться в PHR. В третьем примере, комбинация ручного подхода и автоматизированного подхода может использоваться для того, чтобы обновлять PHR. Как подробнее описано ниже, в первом механизме, сервер 115 PHR может принимать вводы, инструктирующие то, как PHR должна храниться, управляться и/или обновляться. Вводы также могут инструктировать серверу 115 PHR извлекать информацию. Во втором механизме, сервер 115 PHR также может принимать запросы из субъектов здравоохранения или стороннего устройства 160, верифицировать запрос и передавать запрошенную информацию при авторизации. В качестве иллюстрации, примерные варианты осуществления, описанные в данном документе, относятся к запросам из субъектов здравоохранения. Тем не менее, примерные варианты осуществления также могут использоваться для запросов из стороннего устройства 160.

[0030] Репозиторий 120 PHR может представлять любой источник, из которого PHR сохраняются для использования сервером 115 PHR. Как отмечено выше, система 100 может включать в себя множество пользовательских устройств, имеющих соответствующих пользователей, которые могут представлять собой пациентов субъектов здравоохранения. Пользователи также могут иметь соответствующие PHR (например, представлять собой владельцев PHR) и использовать услугу, предоставляемую посредством сервера 115 PHR. Эти PHR в силу этого могут сохраняться в репозитории 120 PHR. Из PHR, которые сохраняются, PHR для владельца с использованием пользовательского устройства 105 может сохраняться в репозитории 120 PHR. В конкретной реализации, репозиторий 120 PHR может использоваться сервером 115 PHR для обеспечения облачной структуры хранения данных участников PHR арендуемой среды.

[0031] Следует отметить, что система 100, включающая в себя только пользовательское устройство 105, является только примерной. Система 100 может представлять субъекты здравоохранения, с которыми владелец с использованием пользовательского устройства 105 может быть ассоциирован или иметь опыт взаимодействия медицинского характера. Например, владелец с использованием пользовательского устройства 105 может посещать HCP 125, HCP 135 и, по меньшей мере, один из HCP 145, 150, 155. Соответственно, субъекты здравоохранения, показанные в системе 100, могут иметь владельца с использованием пользовательского устройства 105 в качестве пациента и ведут EHR для этого владельца. Тем не менее, полное представление системы 100 может включать в себя множество различных пользовательских устройств, имеющих соответствующих пользователей. Каждый пользователь также может иметь опыт взаимодействия с одним или более HCP таким образом, что каждый из этих пользователей имеет соответствующую EHR, которая ведется посредством их HCP. Соответственно, система 100 также может включать в себя дополнительные субъекты здравоохранения, некоторые из которых могут перекрываться между различными пациентами/пользователями.

[0032] Как описано выше, сервер 115 PHR может управлять информационным потоком PHR для владельца с использованием пользовательского устройства 105 посредством обработки вводов и запросов из пользовательского устройства 105, а также субъектов здравоохранения. Фиг. 2 показывает PHR 115 по фиг. 1 согласно примерным вариантам осуществления. Сервер 115 PHR может предоставлять различные функциональности при выполнении первого и второго механизмов, чтобы управлять информационным потоком. Хотя сервер 115 PHR описывается как сетевой компонент (в частности, как сервер), сервер 115 PHR может быть осуществлен во множестве аппаратных компонентов, таких как портативное устройство (например, планшетный компьютер, смартфон, переносной компьютер и т.д.), стационарное устройство (например, настольный терминал), включен в пользовательское устройство 105, включен в услугу на основе веб–узла, и т.д. сервер 115 PHR может включать в себя процессор 205, компоновку 210 запоминающих устройств, устройство 215 отображения, устройство 220 ввода–вывода, приемопередающее устройство 225 и другие компоненты 230 (например, модуль визуализации, аудиоустройство ввода–вывода, аккумулятор, устройство сбора данных, порты для того, чтобы электрически соединять сервер 115 PHR с другими электронными устройствами, и т.д.).

[0033] Процессор 205 может быть выполнен с возможностью выполнять множество приложений сервера 115 PHR. Как подробнее описано ниже, процессор 205 может использовать множество механизмов (средств), включающих в себя механизм 235 пользовательского интерфейса, механизм 240 управления, механизм 245 извлечения, механизм 250 доступа и механизм 255 разрешения конфликтов. Механизм 235 пользовательского интерфейса может быть выполнен с возможностью формировать пользовательский интерфейс, с помощью которого владелец с использованием пользовательского устройства 105 и субъектов здравоохранения может взаимодействовать с сервером 115 PHR. Механизм 240 управления может быть выполнен с возможностью обновлять PHR и организовывать информацию медицинского характера в PHR, в частности, во множество различных разделов. Механизм 245 извлечения может быть выполнен с возможностью, для первого механизма, обрабатывать запросы из пользовательского устройства 105, чтобы извлекать информацию медицинского характера из субъектов здравоохранения. Механизм 250 доступа может быть выполнен с возможностью, для второго механизма, обрабатывать запросы из субъектов здравоохранения для получения информации медицинского характера в PHR. Механизм 255 разрешения конфликтов может быть выполнен с возможностью определять конфликты в информации медицинского характера PHR.

[0034] Следует отметить, что вышеуказанные приложения и механизмы, представляющие собой приложение (например, программу), выполняемую посредством процессора 205 являются только примерными. Функциональность, ассоциированная с приложениями, также может представляться как компоненты одной или более многофункциональных программ, отдельный включенный компонент сервера 115 PHR либо может представлять собой модульный компонент, соединенный с сервером 115 PHR, например, интегральную схему с/без микропрограммного обеспечения.

[0035] Запоминающее устройство 210 может представлять собой аппаратный компонент, выполненный с возможностью сохранять данные, связанные с операциями, выполняемыми посредством сервера 115 PHR. В частности, запоминающее устройство 210 может сохранять данные, принимаемые из пользовательского устройства 105 и субъектов здравоохранения, которые включены в PHR, сохраненную в репозитории 120 PHR. Устройство 215 отображения может представлять собой аппаратный компонент, выполненный с возможностью показывать данные пользователю, в то время как устройство ввода–вывода 220 может представлять собой аппаратный компонент, который позволяет пользователю осуществлять вводы. Например, администратор сервера 115 PHR может задавать то, как механизмы 235–255 должны работать с использованием устройства 215 отображения и устройства ввода–вывода 220. Следует отметить, что устройство 215 отображения и устройство ввода–вывода 220 могут представлять собой отдельные компоненты или интегрироваться, к примеру, как сенсорный экран. Приемопередающее устройство 225 может представлять собой аппаратный компонент, выполненный с возможностью передавать и/или принимать данные через сеть 110 связи.

[0036] Согласно примерным вариантам осуществления, сервер 115 PHR может выполнять всевозможные операции, чтобы управлять потоком информации в/из PHR, принадлежащей владельцу, с использованием пользовательского устройства 105. Механизм 235 пользовательского интерфейса может быть выполнен с возможностью формировать пользовательский интерфейс, с помощью которого владелец с использованием пользовательского устройства 105 и субъектов здравоохранения может взаимодействовать с сервером 115 PHR. Пользовательский интерфейс, который предоставляется и показывается на пользовательском устройстве 105, может предоставлять прикладной программный интерфейс совместного использования данных между пользовательским устройством 105 и сервером 115 PHR, а также между субъектами здравоохранения и сервером 115 PHR.

[0037] Пользовательский интерфейс пользовательского устройства 105 может отображать начальный пользовательский интерфейс. Начальный пользовательский интерфейс может включать в себя общедоступную информацию относительно услуг, предоставляемых посредством сервера 115 PHR, в частности, чтобы вести PHR. Начальный пользовательский интерфейс может обеспечивать возможность новому пользователю создавать учетную запись на сервере 115 PHR и создавать новую PHR. Начальный пользовательский интерфейс также может предоставлять различные положения и условия, ассоциированные с применением услуг сервера 115 PHR. Как отмечено выше, примерные варианты осуществления описываются относительно сервера 115 PHR, предоставляющего услуги ведения PHR для владельца с использованием пользовательского устройства 105. Соответственно, начальный пользовательский интерфейс также может обеспечивать возможность уже существующему пользователю, имеющему учетную запись и PHR с использованием услуг сервера 115 PHR, входить в учетную запись и PHR. Например, владелец может использовать пользовательское устройство 105, чтобы передавать аутентификационную информацию, чтобы входить в учетную запись и осуществлять доступ к PHR.

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

[0039] Пользовательский интерфейс также может обеспечивать возможность владельцу предоставлять различные другие вводы в дополнение к вводам, используемым для того, чтобы просматривать информацию медицинского характера PHR. В первом примере, владелец может предоставлять ввод, чтобы обновлять информацию медицинского характера, которая допускает считывание и запись. Например, персональная информация (например, контактная информация, информация контактного лица для экстренных вызовов, информация участкового врача и т.д.) может изменяться владельцем. Соответственно, ввод на обновление может обеспечивать возможность добавления, изменения или удаления допускающих запись частей PHR. Персональная информация также может включать в себя план мероприятий по уходу владельца PHR, причем план мероприятий по уходу может идентифицировать цели в отношении здоровья владельца PHR. Как подробнее описано ниже, сервер 115 PHR может принимать ввод на обновление для персональной информации и обновлять персональный раздел PHR для владельца. Ввод на обновление также может использоваться для того, чтобы создавать разделы касаемо субъектов здравоохранения. Например, как отмечено выше, владелец с использованием пользовательского устройства 105 может иметь предысторию с HCP 125, 135, 145, 150, 155. Соответственно, ввод на обновление может использоваться для того, чтобы создавать разделы для этих HCP или с субъектами здравоохранения, такими как HCO 130, 140, когда HCP должны группироваться в общий раздел. Как подробнее описано ниже, сервер 115 PHR может принимать ввод на обновление для разделов касаемо субъектов здравоохранения и обновлять агрегированный раздел PHR для владельца.

[0040] Во втором примере, владелец может предоставлять ввод, чтобы запрашивать информацию медицинского характера из субъекта здравоохранения, который должен извлекаться. Например, владелец, возможно, недавно посещал HCP 125. Посещение может предусматривать то, что лабораторный тест должен выполняться касаемо пробы, которая предоставлена. Соответственно, владелец может подавать в сервер 115 PHR соответствующий ввод на извлечение, указывающий то, что результаты лабораторного теста должны быть извлечены и включены в PHR. Владелец может предоставлять аналогичный ввод для каждого посещения HCP. Также следует отметить, что владелец, вручную предоставляющий ввод на извлечение, является только примерным. Сервер 115 PHR может предоставлять автоматизированные операции для владельца, чтобы выполнять операции при извлечении информации из субъекта здравоохранения. Например, владелец может иметь календарь посещений HCP. Сервер 115 PHR может иметь доступ к этому календарю и, соответственно, выполнять операции извлечения для получения информации, ассоциированной с предыдущими посещениями. В другом примере (и как описано ниже), HCP или HCO может вручную выполнять или использовать автоматизированную операцию для того, чтобы проталкивать информацию посещения владельца PHR на сервер 115 PHR. Как подробнее описано ниже, запрошенная информация из ввода с извлечением может быть включена сервером 115 PHR в агрегированный раздел PHR, в частности, в подраздел, соответствующий HCP или HCO, из которой исходит запрошенная информация.

[0041] В третьем примере, владелец может предоставлять ввод, чтобы добавлять или изменять настройки, ассоциированные с субъектом здравоохранения. Хотя информация медицинского характера в PHR принадлежит владельцу с использованием пользовательского устройства 105, субъект здравоохранения также может запрашивать необходимость просматривать избранные части PHR. Например, последующее посещение HCP субъекта здравоохранения может требовать заблаговременного знания предыдущих тестов и/или процедур. Посредством просмотра соответствующей информации в PHR, HCP может легко принимать запрошенную информацию. Также следует отметить, что субъект здравоохранения является только примерным, и запрос на то, чтобы просматривать части PHR, может исходить из стороннего устройства 160. Таким образом, в ожидании запроса из HCP, ввод с заданием, чтобы изменять установки для указанного субъекта здравоохранения, может предоставляться владельцем. Ввод с заданием может задавать то, какие части PHR могут просматриваться посредством указанного субъекта здравоохранения. В частности, ввод с заданием может указывать доступ к агрегированному разделу PHR. Ввод с заданием дополнительно может задавать продолжительность, в течение которой могут просматриваться выбранные части. Таким образом, указанному субъекту здравоохранения может разрешаться просматривать выбранные части PHR только в течение ограниченной продолжительности. Ввод с заданием также может предоставлять более общую инструкцию касаемо того, как может просматриваться информация медицинского характера в PHR. Например, части персональной информации (например, имя и информация контактного лица для экстренных вызовов) могут быть общедоступными для просмотра в любой момент времени, тогда как другие части персональной информации (например, адрес) могут быть доступными только для выбранных субъектов здравоохранения или только для владельца. Таким образом, ввод с заданием дополнительно может указывать доступ к другим разделам PHR.

[0042] Механизм 235 пользовательского интерфейса дополнительно может быть выполнен с возможностью формировать пользовательские интерфейсы для субъектов здравоохранения, чтобы предоставлять вводы или запросы. Поскольку субъект здравоохранения не владеет PHR, вводы, которые могут предоставляться посредством субъекта здравоохранения, могут быть ограничены. В первом примере, если раздел для субъекта здравоохранения не доступен в PHR (например, владелец PHR никогда не предоставлял ввод на обновление, чтобы создавать раздел), субъект здравоохранения также может предоставлять ввод на обновление, чтобы создавать раздел (например, чтобы проталкивать информацию в этот раздел). Тем не менее, следует отметить, что субъект здравоохранения может создавать только собственный раздел в PHR. Таким образом, субъект здравоохранения не имеет возможностей влияния на другие разделы PHR. Во втором примере, субъект здравоохранения может запрашивать доступ к информации медицинского характера в PHR. В одной реализации, субъект здравоохранения также может иметь учетную запись с услугой сервера 115 PHR. После входа в учетную запись, субъект здравоохранения может предоставлять надлежащий ввод или запрос. Практически аналогичным способом, пользователь стороннего устройства 160 может использовать практически аналогичную реализацию.

[0043] Механизм 240 управления может быть выполнен с возможностью обновлять PHR и организовывать информацию медицинского характера в PHR. Первоначально, механизм 240 управления может ассоциировать PHR с универсально уникальным идентификатором (UUID), соответствующим владельцу PHR (например, пользователю пользовательского устройства 105). Таким образом, информация, которая принимается, может быть ассоциирована с UUID, который идентифицирует владельца, и PHR, в которую должна быть включена информация. Механизм 240 управления может структурировать PHR на множество разделов. В первом примере, разделы могут включать в себя раздел сформированных пользователем данных или персональный раздел. В частности, раздел сформированных пользователем данных может быть связан с разделом, в который включена персональная информация, ассоциированная с владельцем. Например, механизм 240 управления может вручную принимать персональную информацию от владельца через пользовательское устройство 105 или может принимать персональную информацию из других источников (например, IoT–устройств, обучающих программ и т.д.). Персональная информация, которая должна быть включена в PHR, может приниматься с использованием ресурсов быстрого взаимодействия в сфере здравоохранения (FHIR) и организовываться в качестве FHIR–представления данных.

[0044] Во втором примере, разделы могут включать в себя агрегированный раздел, в котором один или более подразделов, соответственно, могут соответствовать субъекту здравоохранения. Как отмечено выше, подразделы касаемо субъектов здравоохранения могут создаваться на основе вводов с обновлением (от владельца или из субъекта здравоохранения) для различных субъектов здравоохранения (или HCP), которые предоставляют медицинское обслуживание для владельца PHR. Следует отметить, что механизм 240 управления может обеспечивать полный доступ к этим разделам владельцем и предоставлять характеристики считывания и записи для разделов. Таким образом, владелец может просматривать разделы, добавлять/обновлять/удалять персональный раздел, а также информацию, включенную в персональный раздел, и добавлять/обновлять/удалять разделы касаемо субъектов здравоохранения.

[0045] Хотя разделы касаемо субъектов здравоохранения находятся в пределах управления владельцем, механизм 240 управления может ограничивать характеристики информации в разделах касаемо субъектов здравоохранения характеристиками только для чтения. Таким образом, владельцу может запрещаться добавление/обновление/удаление информации в разделах касаемо субъектов здравоохранения. В частности, информация, которая включена в раздел касаемо субъектов здравоохранения, может быть основана на EHR, принадлежащей соответствующему субъекту здравоохранения. Например, информация может представлять собой результаты или сводку сеанса владельца с HCP. Владелец может владеть информацией после включения в PHR и осуществлять доступ к информации в режиме только для чтения.

[0046] Механизм 245 извлечения может быть выполнен с возможностью, для первого механизма, обрабатывать запросы из пользовательского устройства 105, чтобы извлекать информацию медицинского характера из субъектов здравоохранения. Как отмечено выше, механизм 235 пользовательского интерфейса может позволять владельцу предоставлять ввод, чтобы инициировать извлечение информации из субъекта здравоохранения, которая должна быть включена в PHR. В конкретном примере, механизм 245 извлечения может формировать запрос на субъект здравоохранения и передавать в субъект здравоохранения сообщение, включающее в себя запрос. Запрос может включать в себя инструкции касаемо того, как проталкивать запрошенную информацию. Например, если сервер 115 PHR представляет собой услугу на основе приложения браузера, может предоставляться гиперссылка, которая перенаправляет субъект здравоохранения на веб–страницу, на которую может выгружаться текстовый документ. Сервер 115 PHR может использовать API FHIR для запрошенной информации, которая должна предоставляться на сервер 115 PHR из субъекта здравоохранения. Затем, механизм 245 извлечения может включать информацию в PHR в соответствующем разделе касаемо субъектов здравоохранения. В частности, механизм 245 извлечения может взаимодействовать с механизмом 240 управления таким образом, чтобы включать извлеченную информацию в агрегированный раздел PHR, в частности, в подраздел, соответствующий субъекту здравоохранения, в агрегированном разделе PHR, которая предоставляет извлеченную информацию.

[0047] Следует отметить, что субъект здравоохранения также может превентивно предоставлять информацию в механизм 245 извлечения. Таким образом, даже если владелец не инициирует извлечение, субъект здравоохранения может использовать услугу сервера 115 PHR. Если субъект здравоохранения также имеет учетную запись в сервере 115 PHR, субъект здравоохранения может предоставлять идентификатор (например, UUID) PHR для владельца (который может быть добровольно предложен владельцем). Соответственно, субъект здравоохранения может выгружать информацию, которая должна быть включена в PHR.

[0048] Также следует отметить, что субъект здравоохранения может предоставлять информацию на основе EHR с различными вариантами. Например, информация может быть выгружена с масками. Соответственно, конкретные клинические данные в загруженной информации могут маскироваться, так что владелец по–прежнему может владеть информацией, но не обязательно иметь все ассоциированные права или доступ. Таким образом, можно предотвращать просмотр, владельцем, конкретных клинических данных. Тем не менее, субъект здравоохранения также может делегировать и совместно использовать выгруженную информацию. Например, можно предотвращать просмотр, владельцем, конкретных клинических данных или любой информации, которая маскируется. Тем не менее, делегирование/совместное использование посредством субъекта здравоохранения может обеспечивать возможность другим субъектам здравоохранения просматривать маскированную информацию. Таким образом, механизм 240 управления дополнительно может использовать избирательно просматриваемый раздел. Если обобщить, избирательно просматриваемый раздел может включать в себя информацию, которая не может просматриваться владельцем, но может обмениваться между HCP, подробные планы мероприятий по уходу, которые являются просматриваемым владельцем, информацию рецептов и т.д. Следует отметить, что информация в избирательно просматриваемом разделе может быть динамической. Например, информация может быть основана на промежуточных приложениях (например, из HCP, команды амбулаторной помощи, обучающего плана, плана с рекомендациями по образу жизни и т.д.).

[0049] Механизм 250 доступа может быть выполнен с возможностью, для второго механизма, обрабатывать запросы из субъектов здравоохранения (или стороннего устройства 160) для получения информации медицинского характера в PHR. Механизм 250 доступа может использовать ввод с заданием из пользовательского устройства 105. Соответственно, механизм 250 доступа может обрабатывать запросы из субъектов здравоохранения на основе ввода с заданием. Если механизм 250 доступа определяет то, что запрос предназначен для конфиденциальной информации, которая является недоступной всем, за исключением владельца PHR, запрос может отклоняться. Если механизм 250 доступа определяет то, что запрос предназначен для доступной информации, механизм 250 доступа может продолжать обрабатывать запрос. Если запрос предназначен для общедоступной информации, запрос может обрабатываться, и информация может предоставляться. Если запрос не предназначен для общедоступной информации, но также и не предназначен для конфиденциальной информации, механизм 250 доступа затем может определять то, исходит или нет запрос из авторизованного субъекта здравоохранения. Если запрос исходит из авторизованного субъекта здравоохранения, запрашиваемая информация затем верифицируется на предмет того, что она находится в выбранных частях, идентифицированных во вводе с заданием. Если ввод с заданием также указывает длительность того, когда выбранная часть информации медицинского характера является доступной посредством указанного субъекта здравоохранения, механизм 250 доступа может выполнять эту дополнительную верификацию до предоставления запрошенной информации. Таким образом, механизм 250 доступа может предоставлять субъекту здравоохранения доступ на то, чтобы просматривать запрошенную информацию (например, с использованием FHIR API, когда идентификационные данные, используемые посредством субъекта здравоохранения, ассоциированы с идентификационными FHIR–данными пациентов и UUID). Следует отметить, что, поскольку информация в PHR принадлежит владельцу, субъекту здравоохранения, осуществляющему доступ к информации, может предоставляться характеристики только для чтения.

[0050] Механизм 255 разрешения конфликтов может быть выполнен с возможностью определять конфликты в информации медицинского характера PHR. Механизм 255 разрешения конфликтов может представлять собой дополнительный признак, предоставленный посредством услуг сервера 115 PHR. В частности, когда информация в PHR изменяется (например, добавление, обновление, удаление), механизм 255 разрешения конфликтов может определять то, возникает или нет конфликт в наиболее актуальной информации PHR. Например, существующий рецепт может выписываться первым HCP, который включен в раздел касаемо первого субъекта здравоохранения PHR. Последующий рецепт может также выписываться вторым HCP, который включен в раздел касаемо второго субъекта здравоохранения PHR. Механизм 255 разрешения конфликтов может формировать предупреждение для второго HCP, указывающее конфликт, что позволяет предоставлять возможность модификации последующего рецепта. В другом примере, план мероприятий по уходу владельца PHR может включать в себя сброс веса. Тем не менее, ход действий, рекомендуемый посредством HCP, включенный в соответствующий раздел касаемо субъектов здравоохранения PHR, может включать в себя лекарственный препарат, имеющий побочный эффект в виде набора веса. Механизм 255 разрешения конфликтов может формировать предупреждение касаемо того, что ход действий осуществляется вопреки плану мероприятий по уходу владельца PHR.

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

[0052] Фиг. 3 показывает способ 300 для включения информации в PHR согласно примерным вариантам осуществления. В частности, способ 300 может относиться к первому механизму примерных вариантов осуществления, в которых владелец взаимодействует с сервером 115 PHR и информацией медицинского характера PHR. Соответственно, в дальнейшем описывается способ 300 с точки зрения сервера 115 PHR. В дальнейшем также описывается способ 300 относительно системы 100 по фиг. 1 и множества механизмов 235–255 сервера 115 PHR по фиг. 2.

[0053] На 305, сервер 115 PHR принимает ввод. Например, ввод может исходить из пользовательского устройства 105 или из субъекта здравоохранения. Можно предполагать, что владелец представляет собой существующего пользователя услуг сервера 115 PHR, и владелец имеет PHR, которая ведется посредством сервера 115 PHR. Также можно предполагать, что субъект здравоохранения может быть выполнен с возможностью взаимодействовать с сервером 115 PHR (например, через учетную запись субъекта здравоохранения для услуг сервера 115 PHR). Как описано выше, ввод от владельца может быть связан с множеством различных операций. Таким образом, на 310, сервер 115 PHR определяет тип ввода, который принят.

[0054] На 315, сервер 115 PHR определяет то, направлен или нет ввод на обновление информации. Если ввод представляет собой ввод на обновление, на 320, сервер 115 PHR определяет способ включения информации. Поскольку ввод на обновление связан с операцией записи PHR, сервер 115 PHR может включать информацию ввода с обновлением с соответствующей операцией в надлежащий раздел. Например, если ввод на обновление представляет собой добавление, изменение или удаление для персонального раздела, имеющего персональную информацию, ассоциированную с владельцем, PHR, на 325, сервер 115 PHR может обновлять PHR соответствующим образом. В другом примере, если ввод на обновление представляет собой добавление, изменение или удаление для подраздела касаемо субъектов здравоохранения, ассоциированного с соответствующим субъектом здравоохранения, на 325, сервер 115 PHR может обновлять PHR соответствующим образом. В дополнительном примере, если ввод на обновление представляет собой информацию, которая должна быть включена в подраздел касаемо субъектов здравоохранения, на 325, сервер 115 PHR может обновлять PHR соответствующим образом.

[0055] Если ввод не представляет собой ввод на обновление, на 330, сервер 115 PHR определяет то, направлен или нет ввод на извлечение информации. Если ввод представляет собой ввод на извлечение, на 335, сервер 115 PHR формирует запрос в субъект здравоохранения, идентифицированный во вводе с извлечением, из которого должна приниматься запрошенная информация. Как описано выше, владелец, возможно, недавно посещал или имел сеанс с HCP, при этом сводка посещения и/или результаты теста и/или процедуры могут отслеживаться (например, храниться в EHR субъекта здравоохранения). Соответственно, ввод на извлечение может указывать посещение HCP, причем идентификационные данные субъекта здравоохранения соответствуют HCP, и т.д. Таким образом, на 340, сервер 115 PHR передает запрос в субъект здравоохранения. Субъект здравоохранения, в который передается запрос, может составлять часть одного или более медицинских специалистов–практиков, касаемо которых владелец PHR имеет опыт взаимодействия или посещения/сеансы. Таким образом, субъект здравоохранения может иметь EHR, сохраняемую для владельца.

[0056] На 345, сервер 115 PHR определяет то, принят или нет ответ на запрос. В частности, сервер 115 PHR определяет то, отвечает или нет субъект здравоохранения посредством выгрузки запрашиваемой информации (например, постклинической информации). Если ответ не принят, сервер 115 PHR может возвращаться на 340 для передачи другого запроса. Тем не менее, если ответ принят, на 325, сервер 115 PHR может обновлять PHR соответствующим образом. В частности, раздел касаемо субъектов здравоохранения может обновляться таким образом, что он включает в себя загруженную информацию.

[0057] Следует отметить, что сервер 115 PHR может передавать запрос на основе идентифицированного времени или на основе таймера ожидания. Например, ввод на извлечение может указывать то, когда субъект здравоохранения с большой вероятностью должен иметь подготовленную запрошенную информацию. Соответственно, сервер 115 PHR может передавать запрос в это время или в последующее время. В другом примере, ввод на извлечение может быть посвящен тому, когда указываемый субъект здравоохранения завершает подготовку EHR для идентифицированного посещения/теста/процедуры. Соответственно, сервер 115 PHR может передавать запрос на основе этого таймера ожидания.

[0058] Если ввод не представляет собой ввод на извлечение, на 350, сервер 115 PHR определяет то, направлен или нет ввод на доступ к информации владельцем. Если ввод представляет собой ввод для доступа владельцем, на 355, сервер 115 PHR извлекает и предоставляет запрошенную информацию. Поскольку ввод для доступа принимается от владельца PHR, который имеет полный доступ к информации в PHR, может не требоваться процедура верификации. Тем не менее, как отмечено выше, информация в разделах касаемо субъектов здравоохранения может включать в себя маскированные части, которые являются просматриваемыми только посредством субъектов здравоохранения. Таким образом, сервер 115 PHR может скрывать эти маскированные части от просмотра владельцем.

[0059] Если ввод не представляет собой ввод для доступа, на 360, сервер 115 PHR обрабатывает все запросы, включенные во ввод. Например, ввод может быть не связан с PHR или может быть связан с административным аспектом услуг, предоставляемых посредством сервера 115 PHR. В другом примере, сервер 115 PHR может обеспечивать возможность установления сеанса связи между пользовательским устройством 105 и субъектом здравоохранения.

[0060] Следует отметить, что способ 300 и вводы связаны только с владельцем PHR. Тем не менее, способ 300 также может включать в себя операции, ассоциированные с первым механизмом, когда принимаются вводы из субъекта здравоохранения. Например, субъект здравоохранения может предоставлять ввод, чтобы создавать соответствующий раздел касаемо субъектов здравоохранения в PHR, если уже не существует. Таким образом, когда ответ на 345 предоставляется, субъект здравоохранения может верифицировать то, что его раздел касаемо субъектов здравоохранения существует в PHR, и предоставлять этот ввод, если еще не представлен.

[0061] Фиг. 4 показывает способ 400 для предоставления информации из PHR согласно примерным вариантам осуществления. В частности, способ 400 может относиться ко второму механизму примерных вариантов осуществления, в которых информация медицинского характера из PHR запрашивается посредством субъекта здравоохранения. Соответственно, в дальнейшем описывается способ 400 с точки зрения сервера 115 PHR. В дальнейшем также описывается способ 400 относительно системы 100 по фиг. 1 и множества механизмов 235–255 сервера 115 PHR по фиг. 2.

[0062] На 405, сервер 115 PHR принимает запрос информации (например, из субъекта здравоохранения или стороннего устройства 160). Как отмечено выше, субъект здравоохранения может представлять собой HCP или HCO, включающую в себя один или более HCP. Субъект здравоохранения также может требовать просмотра части информации медицинского характера в PHR (например, для последующего посещения от владельца, чтобы подготавливать документ к владельцу и т.д.).

[0063] На 410, сервер 115 PHR определяет то, предназначен или нет запрос из субъекта здравоохранения для получения информации в PHR, которая является, в общем, доступной. Как описано выше, PHR может секционироваться на множество разделов. Владелец PHR может предоставлять ввод с заданием, который задает то, какая из информации медицинского характера в PHR должна поддерживаться конфиденциальной, в которой только владельцу разрешается доступ на то, чтобы выполнять просмотр и/или запись. Если запрос предназначен для недоступной информации, на 415, сервер 115 PHR отклоняет запрос.

[0064] Если запрос предназначен для доступной информации, на 420, сервер 115 PHR определяет то, представляет ли собой запросчик, передающий запрос, разрешенный субъект. Как описано выше, ввод для доступа от владельца может задавать идентификационные данные одного или более субъектов здравоохранения, которые могут осуществлять доступ к соответствующим выбранным частям информации медицинского характера в PHR. Таким образом, сервер 115 PHR может определять то, включены или нет идентификационные данные запрашивающего субъекта здравоохранения во ввод для доступа. Сервер 115 PHR также может использовать другой стандарт. Например, если имеется раздел, соответствующий запрашивающему субъекту здравоохранения, субъекту здравоохранения может всегда разрешаться доступ к этому разделу (и только к этому разделу, если не указывается касаемо дополнительного доступа во вводе для доступа). Если запрос исходит из неавторизованного субъекта, на 415, сервер 115 PHR отклоняет запрос.

[0065] Если запрос исходит из разрешенного субъекта, на 425, сервер 115 PHR определяет то, разрешается или нет предоставление части запрашиваемой информации в запрашивающий субъект здравоохранения. С другой стороны, объект доступа может задавать то, к каким частям медицинской информации в PHR может осуществляться доступ указанными субъектами здравоохранения. Таким образом, если запрос предназначен для неавторизованной доступной информации, на 415, сервер 115 PHR отклоняет запрос. Тем не менее, если запрос предназначен для авторизованной доступной информации, на 430, сервер 115 PHR передает запрошенную информацию в субъект здравоохранения или разрешает доступ на то, чтобы просматривать запрошенную информацию. Следует отметить, что субъекту здравоохранения могут предоставляться характеристики только для чтения.

[0066] Следует отметить, что способ 400 может включать в себя дополнительную операцию верификации. Как описано выше, сервер 115 PHR может использовать функциональность на основе времени, в которой разрешенному субъекту здравоохранения позволяется осуществлять доступ к разрешенным частям медицинской информации в PHR. Таким образом, способ 400 может включать в себя операцию для того, чтобы определять то, принимается или нет запрос в пределах этого заданного периода времени (например, как указано во вводе для доступа). За пределами этого периода времени, запрос может отклоняться. В пределах этого периода времени, запрос может обрабатываться.

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

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

[0069] Специалисты в данной области техники должны понимать, что вышеописанные примерные варианты осуществления могут реализовываться в любой подходящей программной или аппаратной конфигурации либо в комбинации вышеозначенного. Примерная аппаратная платформа для реализации примерных вариантов осуществления может включать в себя, например, платформу на основе Intel x86 с совместимой операционной системой, платформу Windows, платформу Mac и Mac OS, мобильное устройство, имеющее операционную систему, такую как iOS Android, и т.д. В дополнительном примере, примерные варианты осуществления вышеописанного способа могут быть осуществлены в качестве компьютерного программного продукта, содержащего строки кода, сохраненные на машиночитаемом носителе хранения данных, которые могут выполняться на процессоре или микропроцессоре. Носитель хранения данных, например, может представлять собой локальный или удаленный репозиторий данных, совместимый или отформатированный для использования с вышеуказанными операционными системами с использованием любой операции хранения.

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

Изобретение относится к вычислительной технике. Технический результат заключается в обеспечении высокодетализированного управления доступом к информации в персональной медицинской карте для различных субъектов с поддержанием надлежащего уровня конфиденциальности. Способ управления доступом к персональным медицинским картам содержит этапы, на которых: на сервере персональных медицинских карт (PHR), в котором ведется PHR владельца, причем PHR включает в себя множество разделов, при этом один из разделов представляет собой агрегированный раздел, включающий в себя множество подразделов: принимают от владельца PHR ввод на извлечение; формируют запрос информации и передают его в субъект здравоохранения; принимают информацию из субъекта здравоохранения; принимают ввод на обновление от одного из владельца PHR и субъекта здравоохранения, чтобы обновить PHR; принимают от владельца PHR ввод для доступа; и принимают от владельца PHR ввод с заданием, причем ввод с заданием задает привилегию доступа, ассоциированную с идентификационными данными субъекта, соответствующими субъекту здравоохранения. 3 н. и 14 з.п. ф-лы, 4 ил.

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

принимают от владельца PHR ввод на извлечение, причем ввод на извлечение идентифицирует субъект здравоохранения, из которого должна запрашиваться информация;

формируют запрос информации;

передают этот запрос в субъект здравоохранения;

принимают информацию из субъекта здравоохранения;

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

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

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

2. Способ по п.1, в котором упомянутая информация включает в себя маскированные части, при этом предотвращается отображение маскированных частей для владельца PHR.

3. Способ по п.1, дополнительно содержащий этап, на котором связывают PHR с универсально уникальным идентификатором, соответствующим владельцу PHR.

4. Способ по п.1, дополнительно содержащий этапы, на которых:

принимают из субъекта здравоохранения запрос доступа субъекта;

определяют, включает ли запрос доступа субъекта в себя идентификационные данные субъекта;

когда запрос доступа субъекта включает в себя идентификационные данные субъекта, определяют, включает ли запрос доступа субъекта в себя указание для упомянутого дополнительного подраздела; и

когда запрос доступа субъекта включает в себя упомянутое указание, предоставляют доступ к этому дополнительному подразделу в агрегированном разделе PHR.

5. Способ по п.1, дополнительно содержащий этапы, на которых:

определяют, возникает ли конфликт между упомянутой информацией и другой информацией PHR; и

когда конфликт определен, формируют предупреждение для субъекта здравоохранения.

6. Способ по п.1, в котором PHR хранится в репозитории PHR, который представляет собой облачную структуру хранения данных.

7. Способ по п.1, в котором субъект здравоохранения представляет собой одно из медицинского специалиста–практика и организации здравоохранения, включающей в себя одного или более медицинских специалистов–практиков.

8. Сервер персональных медицинских карт (PHR), который ведет PHR владельца, содержащий:

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

запоминающее устройство, хранящее исполняемую программу; и

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

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

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

9. Сервер PHR по п.8, в котором персональная информация принимается из пользовательского устройства.

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

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

12. Сервер PHR по п.11, в котором процессор выполняет операции, дополнительно содержащие:

определение идентификационных данных первого субъекта здравоохранения;

идентификацию одного из подразделов, соответствующих этим идентификационным данным; и

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

13. Сервер PHR по п.8, при этом третий из разделов представляет собой избирательно просматриваемый раздел, включающий в себя просматриваемую информацию для выбранных субъектов.

14. Сервер PHR по п.13, при этом предотвращается просмотр просматриваемой информации владельцем.

15. Сервер PHR по п.8, в котором приемопередающее устройство принимает ввод для доступа, указывающий идентификационные данные и выбранный подраздел агрегированного раздела.

16. Сервер PHR по п.15, в котором процессор выполняет операции, дополнительно содержащие:

прием запроса доступа от запрашивающей стороны;

определение запросных идентификационных данных запрашивающей стороны;

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

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

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

запоминающее устройство, хранящее исполняемую программу; и

процессор, который исполняет исполняемую программу, которая инструктирует процессору выполнять операции, содержащие:

прием, от владельца PHR, ввода на извлечение, причем ввод на извлечение идентифицирует субъект здравоохранения, из которого должна запрашиваться информация;

формирование запроса информации;

передачу этого запроса в субъект здравоохранения;

прием информации из субъекта здравоохранения;

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

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

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