RU2793605C2

RU2793605C2 - Device, system and method for operating personal health records

Info

Publication number: RU2793605C2
Application number: RU2019144359A
Authority: RU
Inventors: Франсуа АНДРИ; Карла-Кристин АНДРАДЕ; Джон Коридон ХАФФМАН
Original assignee: Конинклейке Филипс Н.В.
Priority date: 2017-06-07
Filing date: 2018-06-05
Publication date: 2023-04-04

Abstract

FIELD: computing technology.

SUBSTANCE: method for managing access to personal health records is performed by the following stages: a personal health record (PHR) server in which the owner's PHR is maintained, the PHR including a plurality of sections, wherein one of the sections is an aggregated section including a plurality of subsections: accept input from the PHR owner for retrieval; form a request for information and transmit it to the healthcare provider; receive information from the healthcare provider; receive an update input from one of the PHR owner and the healthcare provider to update the PHR; receive from the owner of the PHR input for access; and receive a task input from the PHR owner, the task input specifying an access privilege associated with a subject identity corresponding to the healthcare provider.

EFFECT: providing highly detailed access control to information in a personal medical record for various subjects while maintaining an appropriate level of confidentiality.

17 cl, 4 dwg

Description

Уровень техникиState of the art

[0001] Персональная медицинская карта (PHR) может включать в себя медицинскую информацию и другую связанную информацию, ассоциированную с человеком (совместно называется в данном документе "информацией медицинского характера"). PHR может принадлежать, храниться и управляться человеком (в дальнейшем "владельцем") персональным способом таким образом, что информация медицинского характера управляется частным, защищенным и конфиденциальным способом. Если владелец PHR является внимательным при обновлении PHR, PHR может использоваться для того, чтобы предоставлять охватывающую сводку всей истории болезни владельца. PHR может включать в себя информацию из множества других источников, в том числе от владельца, медицинского работника, из организации здравоохранения и т.д. Информация может вручную добавляться в PHR владельцем, может автоматически добавляться посредством услуги, предоставляющей PHR, либо как комбинация вышеозначенного. Например, услуга, предоставляющая PHR, может принимать ручные записи или вводы от владельца, может запрашивать информацию от медицинского работника, может пассивно собирать информацию медицинского характера из электронного устройства владельца и т.д.[0001] A personal health record (PHR) may include medical information and other related information associated with a person (collectively referred to herein as "health information"). PHR may be owned, held and managed by an individual (hereinafter "owner") in a personal manner such that medical information is managed in a private, secure and confidential manner. If the PHR owner is careful when updating the PHR, the PHR can be used to provide a comprehensive summary of the owner's entire medical history. The PHR may include information from a variety of other sources, including the owner, healthcare professional, healthcare organization, and so on. The information may be manually added to the PHR by the owner, may be automatically added by the service providing the PHR, or a combination of the above. For example, a PHR service may accept manual entries or inputs from the owner, may request information from a healthcare professional, may passively collect medical information from the owner's electronic device, and so on.

[0002] PHR может использоваться в различных форматах. В простом формате PHR, может представлять собой бумажную карту, хранимую владельцем. Тем не менее, в качестве бумажной карты, PHR может не быть легкодоступной при необходимости, к примеру, во время консультации с медицинским работником. В другом формате, PHR может иметь электронный формат. В первом примере, PHR в электронном формате может сохраняться практически аналогично бумажной карты, в которой информация медицинского характера сохраняется в персональном файле владельца. Если персональный файл сохраняется в облаке или через онлайновый механизм, PHR может быть доступной онлайновым способом. Во втором примере, PHR в электронном формате может предоставляться посредством услуги, такой как онлайновая услуга (например, веб–узел). Таким образом, PHR может быть доступной онлайн до тех пор, пока онлайновая услуга может достигаться.[0002] PHR can be used in various formats. In a simple PHR format, this may be a paper card held by the owner. However, as a paper card, the PHR may not be readily available when needed, such as during a consultation with a healthcare professional. In another format, the PHR may be in electronic format. In the first example, the PHR in electronic format can be stored in much the same way as a paper card, in which medical information is stored in the owner's personal file. If the personal file is stored in the cloud or through an online mechanism, the PHR can be accessed in an online manner. In the second example, the PHR in electronic format may be provided through a service such as an online service (eg, a web site). Thus, the PHR can be available online as long as the online service can be reached.

[0003] PHR может включать в себя множество различных типов информации медицинского характера. Например, информация медицинского характера может включать в себя персональную информацию, такую как дата рождения, адрес, контактный номер(а), контактное лицо для экстренных вызовов, контактный номер для экстренных вызовов и т.д. В другом примере, информация медицинского характера может быть направлена на медицинские темы, такие как информация участкового врача, информация любых специалистов, группа крови, аллергические реакции, реакции на лекарственные препараты, хронические заболевания, семейный анамнез, предыдущие болезни, предыдущие госпитализации, отчеты с визуализацией, результаты лабораторных тестов, текущие или предыдущие назначения лекарственных препаратов с соответствующими дозами и продолжительностью применения, карта с рецептами, предыдущие хирургические операции или другие процедуры, вакцинационный анамнез, реиммунизационный анамнез, даты медосмотров/тестов/обследований и т.д. В дополнительном примере, информация медицинского характера может включать в себя юридическую информацию, такую как распоряжение о поддержании жизни, предварительные распоряжения и т.д. В еще одном другом примере, информация медицинского характера может включать в себя информацию активности владельца, такую как распорядок физических упражнений и пищевые привычки, а также цели в отношении здоровья или планы мероприятий по уходу.[0003] A PHR may include many different types of medical information. For example, medical information may include personal information such as date of birth, address, contact number(s), emergency contact, emergency contact number, and so on. In another example, medical information may be directed to medical topics such as GP information, any specialist information, blood types, allergic reactions, drug reactions, chronic illnesses, family history, previous illnesses, previous hospitalizations, imaging reports. , laboratory test results, current or previous drug prescriptions with appropriate doses and duration of use, prescription card, previous surgeries or other procedures, vaccination history, re-immunization history, dates of medical examinations / tests / examinations, etc. In an additional example, the medical information may include legal information such as a life-sustaining directive, advance directives, and so on. In yet another example, the health information may include activity information of the wearer, such as exercise routines and eating habits, as well as health goals or care plans.

[0004] Когда PHR сохраняется в электронном формате, информация медицинского характера может разделяться на общедоступную информацию и конфиденциальную информацию. Например, персональная информация может классифицироваться в качестве конфиденциальной информации. Тем не менее, персональная информация также может разделяться на разделы, которые классифицируются в качестве конфиденциальной информации (например, информации о местожительстве) и общедоступной информации (например, контактного номера для экстренных вызовов). Другие типы информации также могут классифицироваться таким образом. Например, когда информация медицинского характера принимается от медицинского работника, эта информация может классифицироваться в качестве общедоступной информации. Следует отметить, что общедоступность может означать доступность для медицинских работников и организаций здравоохранения.[0004] When the PHR is stored in an electronic format, medical information may be separated into public information and confidential information. For example, personal information may be classified as confidential information. However, personal information may also be divided into sections that are classified as confidential information (such as location information) and public information (such as an emergency contact number). Other types of information may also be classified in this way. For example, when medical information is received from a healthcare professional, that information may be classified as public information. It should be noted that accessibility can mean accessibility to healthcare professionals and healthcare organizations.

[0005] Когда PHR имеет бумажный формат или находится в персональном файле в электронном формате, информация медицинского характера в PHR может сохраняться с использованием любого предпочитаемого пользователем способа. Когда PHR предоставляется посредством услуги в электронном формате, информация медицинского характера в PHR может сохраняться или отображаться согласно способу, выбранному посредством услуги. Например, услуга может определять то, какая из информации PHR должна быть общедоступной или конфиденциальной. В другом примере, услуга может размещать информацию согласно стандарту, который выбирает услуга, к примеру, как страница персональной информации, страница общей медицинской информации, страница назначений лекарственных препаратов и т.д.[0005] When the PHR is in paper format or is in a personal file in electronic format, the medical information in the PHR can be stored using any method preferred by the user. When the PHR is provided via a service in an electronic format, the medical information in the PHR may be stored or displayed according to the method selected by the service. For example, the service may determine which of the PHR information should be public or private. In another example, the service may post information according to a standard that the service selects, such as a personal information page, a general health information page, a prescription page, and so on.

[0006] С учетом охватывающей сводки, которая может быть включена в PHR, могут быть предусмотрены выгоды от наличия самой актуальной PHR. Тем не менее, ведение и обновление PHR таким образом, что она является всесторонней, требует значительного времени и ресурсов. Например, владелец может принимать на себя использование собственного времени и ресурсов для того, чтобы обновлять PHR. Соответственно, владелец может контактировать с медицинским работником, чтобы собирать и вводить результаты процедуры или анализа, выполняемого медицинским работником. В другом примере, если уточнить, владелец может обновлять PHR каждый раз, когда возникает событие медицинского характера (например, каждый раз, когда посещается доктор, каждый раз, когда заполняется рецепт, каждый раз, когда выполняется тест, при каждом посещении больницы и т.д.).[0006] Given the scope summary that may be included in the PHR, there may be benefits from having the most up-to-date PHR. However, maintaining and updating the PHR in such a way that it is comprehensive requires significant time and resources. For example, the owner may assume the use of their own time and resources in order to update the PHR. Accordingly, the owner may contact the healthcare professional to collect and enter the results of a procedure or analysis performed by the healthcare professional. In another example, to be more specific, the owner can update the PHR every time a medical event occurs (e.g., every time a doctor visits, every time a prescription is filled, every time a test is performed, every hospital visit, etc.). d.).

[0007] Несмотря на потенциальную значимость наличия текущей PHR, которая доступна для использования медицинскими работниками и организациями здравоохранения (в дальнейшем совместно называются "субъектом здравоохранения"), управление и обновление PHR ограничено вышеописанным способом. К сожалению, субъекты здравоохранения (например, доктора, больницы, аптеки, страховые компании и т.д.) не приспосабливают универсальный способ использования информационных технологий для того, чтобы взаимодействовать при ведении текущей PHR для владельца. Фактически, могут быть предусмотрены только избранные субъекты здравоохранения (например, меньшинство), которые допускают передачу информации электронным способом даже для PHR, которая должна обновляться.[0007] Despite the potential value of having a current PHR that is available for use by healthcare professionals and healthcare organizations (hereinafter collectively referred to as a "health care subject"), managing and updating the PHR is limited to the method described above. Unfortunately, healthcare entities (eg, doctors, hospitals, pharmacies, insurance companies, etc.) do not adopt a universal way of using information technology to interact in maintaining an owner's current PHR. In fact, only selected healthcare entities (eg a minority) can be envisaged that allow information to be transmitted electronically even for a PHR that must be updated.

[0008] Информация, принимаемая от субъекта здравоохранения, может быть основана на электронной медицинской карте (EHR). EHR представляет собой полностью отдельную карту относительно PHR, поскольку EHR принадлежит и регулируется субъектом здравоохранения (например, таких учреждений, как больницы) и включает в себя данные, введенные пользователями, ассоциированными с субъектом здравоохранения (например, врачами), или другую информацию, связанную с процедурами, ассоциированными с отдельным пациентом (например, биллинговые данные, чтобы поддерживать страховые иски). Таким образом, субъект здравоохранения владеет, регулирует, управляет и обновляет EHR для собственных карт, связанных с конкретным отдельным пациентом. Хотя EHR может потенциально совместно использоваться субъектами здравоохранения, отсутствует способ надлежащего включения EHR в PHR. Вместо этого, когда информация запрашивается из субъекта здравоохранения, предоставляется файл, включающий в себя релевантную информацию для владельца, выбранную субъектом здравоохранения, и PHR обновляется с этой информацией.[0008] The information received from the health care subject may be based on an electronic health record (EHR). The EHR is a completely separate card from the PHR because the EHR is owned and operated by the healthcare entity (e.g., institutions such as hospitals) and includes data entered by users associated with the healthcare entity (e.g., physicians) or other information related to procedures associated with an individual patient (for example, billing data to support insurance claims). Thus, the healthcare entity owns, regulates, manages and updates the EHR for its own records associated with a particular individual patient. Although the EHR can potentially be shared between healthcare subjects, there is no way to properly include the EHR in the PHR. Instead, when information is requested from a health care subject, a file is provided including the owner-relevant information selected by the health care subject, and the PHR is updated with this information.

[0009] В конкретном способе реализации PHR, консенсусная модель представляет собой модель, в которой информация медицинского характера принадлежит пациенту, а не субъекту здравоохранения, который может формировать данные. Информация медицинского характера может сохраняться с различным шифрованием в целях конфиденциальности. Функции управления информацией медицинского характера могут быть реализованы через ориентированную на предоставление услуг архитектуру (SOA) и доступны в качестве уровня платформы как услуга (PaaS) конкретного медицинского характера. Высокодетализированное управление доступом может быть включено, чтобы позволять нескольким людям иметь дифференциальный доступ к PHR и информации медицинского характера. В этой консенсусной модели, минимальные характеристики PHR могут включать в себя автономный защищенный от несанкционированного использования цифровой комплект, быть постоянными и быть доступными для владельца в любое время и из любого места, иметь конфиденциальную или конфиденциальную информацию, чтобы всегда оставаться под строгим управлением владельца PHR без необходимости доверенной третьей стороны, предоставлять подходящие механизмы для доступа и обеспечивать возможность владельцу совместно использовать только частичные версии PHR при необходимости.[0009] In a particular way of implementing PHR, the consensus model is a model in which the medical information belongs to the patient, and not to the health care subject who can generate the data. Medical information may be stored with various encryption for confidentiality purposes. The health information management functions can be implemented through a service-oriented architecture (SOA) and available as a health-specific platform as a service (PaaS) layer. Fine-grained access control can be enabled to allow multiple people to have differential access to PHR and medical information. In this consensus model, the minimum characteristics of a PHR may include a stand-alone tamper-proof digital kit, be permanent and accessible to the owner at any time and from any location, have sensitive or sensitive information, so as to always remain under the strict control of the PHR owner without the need for a trusted third party, provide appropriate mechanisms for access, and enable the owner to share only partial versions of the PHR when needed.

[0010] Согласно консенсусной модели и другим моделям PHR с использованием традиционных технологий, вся информация медицинского характера, включенная в PHR, сохраняется в идентичной карте. Следовательно, даже при всех вышеуказанных функциональных свойствах консенсусной модели, владелец PHR или владелец, которому относится информация медицинского характера, должен управлять тем, как информация должна быть разделена или организована в PHR для признаков, которые должны быть реализованы. Соответственно, PHR ограничена в вариантах и признаках и требует значительного участия владельца PHR.[0010] According to the consensus model and other PHR models using traditional technologies, all medical information included in the PHR is stored in an identical card. Therefore, even with all of the above functional properties of the consensus model, the owner of the PHR, or the owner to whom the medical information belongs, must control how the information should be divided or organized in the PHR for the features to be implemented. Accordingly, PHR is limited in options and features and requires significant involvement of the PHR owner.

[0011] Кроме того, информация медицинского характера в PHR представляет собой конфиденциальную информацию, в которой учитываются проблемы конфиденциальности. Следовательно, информация медицинского характера PHR, в общем, не является общедоступной для осуществления доступа, в частности, когда PHR имеет электронный формат. Даже если к PHR должно осуществляться доступ посредством субъекта здравоохранения, весь контент информации медицинского характера может становиться доступным с традиционными признаками PHR. Когда весь контент информации медицинского характера становится доступным для субъекта здравоохранения, EHR, которая ведется для владельца субъектом здравоохранения, может теперь включать в себя эту информацию. Со стороны субъекта здравоохранения, специалисты в данной области техники должны понимать, что различные правила конфиденциальности установлены, к примеру, с помощью закона о страховании здоровья и медицинской ответственности 1996 (HIPAA), в котором информация медицинского характера человека и ее использование/раскрытие должны придерживаться стандартов, включенных в HIPAA. Таким образом, ведение уровня конфиденциальности в PHR из общественных субъектов и субъектов здравоохранения предоставляет важный признак. Тем не менее, текущее состояние PHR не обеспечивает возможность избирательной доступности идентифицированных частей в PHR.[0011] In addition, the medical information in the PHR is confidential information that takes into account privacy concerns. Therefore, PHR medical information is generally not publicly available for access, in particular when the PHR is in electronic format. Even if the PHR is to be accessed by a health care subject, all health information content can be made available with traditional PHR features. When all health information content is made available to a health care subject, the EHR maintained for the owner by the health care subject may now include that information. On the part of the healthcare subject, those skilled in the art should understand that various privacy rules are established, for example, through the Health Insurance and Medical Liability Act of 1996 (HIPAA), in which a person's medical information and its use/disclosure must adhere to standards. included in HIPAA. Thus maintaining a privacy level in the PHR from public and health actors provides an important indication. However, the current state of the PHR does not allow the identified parts to be selectively available in the PHR.

Сущность изобретенияThe essence of the invention

[0012] Примерные варианты осуществления направлены на способ, содержащий: на сервере персональных медицинских карт (PHR), ведение PHR владельца, причем PHR включает в себя множество разделов, причем один из разделов представляет собой агрегированный раздел, включающий в себя множество подразделов, причем один из подразделов соответствует субъекту здравоохранения; прием ввода с извлечением от владельца PHR, причем ввод на извлечение идентифицирует субъект здравоохранения, из которого должна запрашиваться информация; формирование запроса информации; передачу запроса в субъект здравоохранения; прием информации из субъекта здравоохранения; и включение информации в подраздел агрегированного раздела в PHR, соответствующей субъекту здравоохранения.[0012] Exemplary embodiments are directed to a method comprising: on a personal health record (PHR) server, maintaining an owner's PHR, wherein the PHR includes a plurality of partitions, wherein one of the partitions is an aggregated partition including a plurality of subsections, wherein one of the subsections corresponds to the subject of healthcare; receiving a retrieval input from the owner of the PHR, wherein the retrieval input identifies the healthcare subject from which the information is to be requested; formation of a request for information; transfer of a request to a healthcare subject; receiving information from a healthcare subject; and including information in a subsection of the aggregated section in the PHR corresponding to the health care subject.

[0013] Примерные варианты осуществления направлены на сервер персональных медицинских карт (PHR), который ведет PHR владельца, содержащий: приемопередающее устройство, обменивающееся данными через сеть связи, причем приемопередающее устройство выполнено с возможностью обмениваться данными с пользовательским устройством, используемым владельцем PHR, и электронным устройством субъекта здравоохранения; запоминающее устройство, сохраняющее выполняемую программу; и процессор, который исполняет исполняемую программу, которая инструктирует процессору выполнять операции при ведении PHR, причем PHR включает в себя множество разделов, причем первый из разделов представляет собой персональный раздел, включающий в себя персональную информацию, ассоциированную с владельцем, причем второй из разделов представляет собой агрегированный раздел, включающий в себя множество подразделов, причем каждый из подразделов соответствует соответственному субъекту здравоохранения, причем подразделы включают в себя соответствующую информацию медицинского характера, ассоциированную с владельцем, на основе соответствующей карты, которая ведется этим соответственным субъектом здравоохранения.[0013] Exemplary embodiments are directed to a personal health record (PHR) server that maintains the owner's PHR, comprising: a transceiver communicating over a communications network, the transceiver being configured to communicate with a user device used by the owner of the PHR and an electronic the device of the subject of health care; a storage device that stores the executable program; and a processor that executes an executable program that instructs the processor to perform operations while maintaining the PHR, the PHR including a plurality of partitions, the first of the partitions being a personal partition including personal information associated with the owner, the second of the partitions being an aggregated section including a plurality of subsections, each of the subsections corresponding to a respective health care entity, the subsections including relevant health information associated with the holder based on a respective card maintained by that respective health care entity.

[0014] Примерные варианты осуществления направлены на сервер персональных медицинских карт (PHR), который ведет PHR владельца, причем PHR включает в себя множество разделов, причем один из разделов представляет собой агрегированный раздел, включающий в себя множество подразделов, причем один из подразделов соответствует субъекту здравоохранения, содержащий: приемопередающее устройство, обменивающееся данными через сеть связи, причем приемопередающее устройство выполнено с возможностью обмениваться данными с пользовательским устройством, используемым владельцем PHR, и электронным устройством субъекта здравоохранения; запоминающее устройство, хранящее исполняемую программу; и процессор, который исполняет исполняемую программу, которая инструктирует процессору выполнять операции, содержащие: прием ввода с извлечением от владельца PHR, причем ввод на извлечение идентифицирует субъект здравоохранения, из которого должна запрашиваться информация; формирование запроса информации; передачу запроса в субъект здравоохранения; прием информации из субъекта здравоохранения; и включение информации в подраздел агрегированного раздела в PHR, соответствующей субъекту здравоохранения.[0014] Exemplary embodiments are directed to a personal health record (PHR) server that maintains the owner's PHR, wherein the PHR includes a plurality of partitions, where one of the partitions is an aggregated partition including a plurality of subsections, where one of the subsections corresponds to a subject health care, comprising: a transceiver device that communicates through a communication network, and the transceiver device is configured to communicate with the user device used by the owner of the PHR, and the electronic device of the health care subject; a storage device storing the executable program; and a processor that executes an executable program that instructs the processor to perform operations comprising: receiving a fetch input from a PHR owner, the fetch input identifying the healthcare subject from which the information is to be requested; formation of a request for information; transfer of the request to the subject of health care; receiving information from a healthcare subject; and including the information in a subsection of the aggregated section in the PHR corresponding to the health care subject.

Краткое описание чертежейBrief description of the drawings

[0015] Фиг. 1 показывает систему согласно примерным вариантам осуществления.[0015] FIG. 1 shows a system according to exemplary embodiments.

[0016] Фиг. 2 показывает сервер персональных медицинских карт по фиг. 1 согласно примерным вариантам осуществления.[0016] FIG. 2 shows the personal health record server of FIG. 1 according to exemplary embodiments.

[0017] Фиг. 3 показывает способ для включения информации в медицинскую карту пациента согласно примерным вариантам осуществления.[0017] FIG. 3 shows a method for including information in a patient's medical record according to exemplary embodiments.

[0018] Фиг. 4 показывает способ для предоставления информации из медицинской карты пациента согласно примерным вариантам осуществления.[0018] FIG. 4 shows a method for providing information from a patient's medical record according to exemplary embodiments.

Осуществление изобретенияImplementation of the invention

[0019] Примерные варианты осуществления дополнительно могут пониматься со ссылкой на нижеприведенное описание и связанные прилагаемые чертежи, на которых аналогичные элементы содержат идентичные ссылки с номерами. Примерные варианты осуществления относятся к устройству, системе и способу для формирования операционной персональной медицинской карты (PHR), которая предоставляет различные признаки и операции для получения информации медицинского характера, которая должна управляться и обновляться в PHR. В частности, примерные варианты осуществления предоставляют первый механизм, в котором информация медицинского характера добавляется в PHR, и второй механизм, в котором информация медицинского характера из PHR передается в запросчик. Как подробнее описано ниже, способ, которым информация медицинского характера сохраняется и организуется, может использоваться при выполнении первого и второго механизмов.[0019] Exemplary embodiments may be further understood with reference to the following description and the associated accompanying drawings, in which like elements are identically referenced with numbers. Exemplary embodiments relate to an apparatus, system, and method for generating a transactional personal health record (PHR) that provides various features and operations for obtaining medical information to be managed and updated in the PHR. In particular, the exemplary embodiments provide a first mechanism in which the medical information is added to the PHR and a second mechanism in which the medical information from the PHR is passed to the interrogator. As described in more detail below, the manner in which medical information is stored and organized can be used in performing the first and second mechanisms.

[0020] Примерные варианты осуществления выполнены с возможностью четко разделять информацию медицинского характера на основе того, создана или нет информация медицинского характера первоначально владельцем PHR, либо на основе того, создана или нет информация медицинского характера первоначально субъектом здравоохранения (например, медицинским работником, организацией здравоохранения и т.д.), либо на основе электронной медицинской карты (EHR), принадлежащей субъекту здравоохранения. В частности, информация медицинского характера PHR может разделяться на множество разделов: первый раздел для персональной информации, ассоциированный с владельцем, второй раздел, ассоциированный с агрегированными данными из субъектов здравоохранения, третий раздел для избирательно просматриваемой информации и т.д. Посредством организации информации медицинского характера согласно примерным вариантам осуществления, примерные варианты осуществления также могут предоставлять способ для каждой стороны (например, владельца PHR, субъекта здравоохранения или третьей стороны), чтобы добавлять и/или осуществлять доступ к соответствующим выборам информации медицинского характера на основе управления доступом и политик, реализуемых при организации PHR. Следовательно, примерные варианты осуществления включают в себя архитектуру, которая предоставляет более высокодетализированный доступ, а также совместное использование и делегирование информации медицинского характера в PHR.[0020] Exemplary embodiments are configured to clearly separate health information based on whether or not the health information was originally created by the owner of the PHR, or based on whether or not the health information was originally created by the healthcare entity (e.g., healthcare professional, healthcare organization etc.), or on the basis of an electronic health record (EHR) belonging to a healthcare entity. In particular, the PHR health information may be divided into a plurality of sections: a first section for personal information associated with the owner, a second section associated with aggregated data from health care subjects, a third section for selectively viewed information, and so on. By organizing the health information according to the exemplary embodiments, the exemplary embodiments may also provide a method for each party (e.g., PHR owner, health care subject, or third party) to add and/or access appropriate choices of health information based on access control. and policies implemented by the PHR organization. Therefore, exemplary embodiments include an architecture that allows for finer-grained access, as well as sharing and delegation of health information in the 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.[0021] FIG. 1 shows a system 100 according to exemplary embodiments. The system 100 relates to communication between the various components involved in using the PHR, both in updating the PHR to the most up-to-date state and in requesting information from the PHR. System 100 may include a user device 105, a communications network 110, and a plurality of devices associated with various healthcare entities. For example, the first healthcare entity may include a healthcare professional 125 (HCP), the second healthcare entity may include a healthcare organization (HCO) 130 that includes at least an HCP 135, and the third healthcare entity may include HCO 140, which includes at least three HCPs 145, 150, 155. As described in more detail below, system 100 is configured to add medical information to the PHR from information provided by user device 105 and/or healthcare subjects, and transmit the requested health information from the PHR to the requesting health entity. The system 100 may further include a third party device 160. The third party device 160 may also request medical information from the PHR but is not associated with a healthcare entity (eg, a device used by a relative of the owner). Accordingly, to provide these functionalities, system 100 may also include a PHR server 115 and a PHR repository 120.

[0022] Пользовательское устройство 105 может представлять собой любое электронное устройство, которое используется человеком, который владеет PHR (в дальнейшем "владельцем"). Например, пользовательское устройство 105 может представлять собой настольный компьютер, переносной компьютер, мобильный телефон, планшетный компьютер, смартфон, фаблет, встроенное устройство, носимый прибор и т.д. Пользовательское устройство 105 может включать в себя все аппаратные средства, программное обеспечение и микропрограммное обеспечение для операций и функциональностей, ассоциированных с PHR, включающих в себя аппаратные средства, программное обеспечение и микропрограммное обеспечение примерных вариантов осуществления, которые должны использоваться (например, процессор, запоминающее устройство, устройство отображения, приемопередающее устройство и т.д.). Соответственно, пользовательское устройство 105 может быть выполнено с возможностью выполнять приложение, которое обеспечивает возможность доступа для PHR и использования признаков PHR. Например, приложение может представлять собой собственное PHR–приложение, которое устанавливает соединение с сервером 115 PHR. В другом примере, приложение может представлять собой приложение браузера, в котором осуществляется доступ к онлайновой услуге или веб–странице сервера 115 PHR.[0022] The user device 105 may be any electronic device that is used by a person who owns the PHR (hereinafter "owner"). For example, user device 105 may be a desktop computer, laptop computer, mobile phone, tablet computer, smartphone, phablet, embedded device, wearable device, and so on. The user device 105 may include all hardware, software, and firmware for operations and functionality associated with the PHR, including the hardware, software, and firmware of the exemplary embodiments to be used (e.g., processor, memory , display device, transceiver, etc.). Accordingly, user device 105 may be configured to execute an application that enables PHR access and use of PHR features. For example, the application may be a native PHR application that establishes a connection with the PHR server 115 . In another example, the application may be a browser application that accesses an online service or web page of the PHR server 115.

[0023] Пользовательское устройство 105 также может быть выполнено с возможностью устанавливать соединение с сетью 110 связи. В качестве иллюстрации, в данном документе описываются примерные варианты осуществления, в которых PHR представляет собой услугу, предоставляемую посредством сервера 115 PHR. Соответственно, обмен данными может выполняться между пользовательским устройством 105 и сервером 115 PHR таким образом, что сервер 115 PHR может предоставлять PHR–услугу. Тем не менее, следует отметить, что эта реализация является только примерной. PHR и соответствующее PHR–приложение могут работать локально на пользовательском устройстве 105. Дополнительная услуга или сторонний ретранслятор могут использоваться для обеспечения доступности PHR через сеть 110 связи.[0023] The user device 105 may also be configured to establish a connection with the communication network 110. By way of illustration, this document describes exemplary embodiments in which the PHR is a service provided by the PHR server 115. Accordingly, communication can be performed between the user equipment 105 and the PHR server 115 so that the PHR server 115 can provide a PHR service. However, it should be noted that this implementation is only exemplary. The PHR and the associated PHR application may operate locally on the user device 105. A supplementary service or third party relay may be used to make the PHR available over the communication network 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) и т.д.), облачную сеть, проводную форму этих сетей, беспроводную форму этих сетей, комбинированную проводную/беспроводную форму этих сетей и т.д.[0024] Communication network 110 may be configured to operably connect various components of system 100 to exchange data. In particular, communication network 110 may be used to communicate between PHR server 115 and user device 105, and between PHR server 115 and healthcare entities (eg, HCP 125, HCO 130, and HCO 140). Communication network 110 may represent any one or multiple networks used by components of system 100 to communicate with each other. For example, HCO 140 may use a private network such that communications network 110 may be operably connected to the private network. It should be noted that communication network 110 and all networks that may be included therein may be any type of network. For example, communication network 110 may be a local area network (LAN), a wide area network (WAN), a virtual LAN (VLAN), a Wi-Fi network, a public hotspot, a cellular network (e.g., 3G, 4G, long-term development (LTE), etc.), cloud network, wired form of these networks, wireless form of these networks, combined wired/wireless form of these networks, etc.

[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.[0025] Health subjects including HCO 130, 140 and HCP 125, 135, 145, 150, 155 may include any type of medical practitioner. For example, HCP 125 (as well as HCP 135, 145, 150, 155) can be used by a physician, specialist, technician, etc. HCP 125 may represent any electronic device that is configured to perform functionality associated with a medical practitioner. HCP 125 may also be any type of electronic device, such as those noted above for user device 105. In addition, HCP 125 may include the necessary hardware, software, and/or firmware to perform various operations associated with medical practitioner, including any type of therapeutic treatment. The HCP 125 may further include the required connection hardware, software, and firmware (eg, a transceiver) to establish a connection with the communication network 110 so as to further establish a connection with the PHR server 115 of the system 100. Also It should be noted that the description of HCP 125 may also apply to 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 могут составлять часть организации медицинского страхования.[0026] HCO 130, 140 may include one or more HCPs. As illustrated, HCO 130 may include one HCP 135, while HCO 140 may include more than one HCP 145, 150, 155. However, it should be noted that HCO 130, 140, including a certain number The HCPs illustrated in system 100 of FIG. 1 are exemplary only. Those skilled in the art will appreciate that HCO 130, 140 may include any number of HCPs. HCOs 130, 140 may represent any organization with which HCPs may be associated. For example, HCO 130, 140 may be a health care organization (HMO). In another example, HCO 130, 140 may form part of the practice group. In an additional example, HCO 130, 140 may be a hospital. In yet another example, HCO 130, 140 may be part of a health insurance organization.

[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.[0027] Healthcare entities (both HCPs and HCOs) may allow the generation and maintenance of appropriate electronic health records (EHRs). The EHRs may be stored in their respective repositories (not shown). For example, the HCP 125 may not be part of the HCO and therefore store the patient EHRs in a local or remote repository. In another example, HCOs 130, 140 may include a respective network repository on a respective private network (not shown) of HCOs 130, 140. Thus, HCP patient EHRs may be owned, managed, managed, and stored by the respective HCP and/or HCO, with which the HCP is associated. For example, HCP 125 may have an EHR for a patient corresponding to an owner using user device 105. This EHR may only be proprietary to HCP 125. In another example, HCO 140 may have an EHR for a patient corresponding to an owner using user device 105. This EHR may be proprietary to HCO 140 such that HCPs 145, 150, 155 can access this EHR.

[0028] Следует отметить, что HCP 125, 135, 145, 150, 155 могут представлять собой электронные устройства, которые используются медицинским специалистом–практиком множеством различных способов. Например, HCP могут представлять собой профессиональные устройства, в которых выполняются функциональности ведения документации. Таким образом, создаваемые документы могут быть включены в EHR. В другом примере, HCP могут представлять собой процедурные устройства, к примеру, для захвата изображений, интерпретации изображений, лабораторных тестов и т.д. Когда процедуры выполняются, соответствующий документ может создаваться с возможностью включения в EHR.[0028] It should be noted that HCPs 125, 135, 145, 150, 155 may be electronic devices that are used by a medical practitioner in a variety of different ways. For example, HCPs may be professional devices that run documentation functionality. Thus, the generated documents can be included in the EHR. In another example, HCPs may be procedural devices, such as for image capture, image interpretation, laboratory tests, and so on. When the procedures are executed, a corresponding document can be created with the possibility of inclusion in the 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.[0029] PHR server 115 may be a component of system 100 that performs functionality associated with a PHR information control flow for a PHR owner (eg, a user of user device 105). The PHR server 115 may further be configured to provide additional features to automate operations when updating the PHR. For example, PHR server 115 may subscribe PHRs to news feeds from healthcare professionals that provide automatic PHR updates based on information provided by healthcare professionals. Therefore, each time the owner of the PHR receives a medical update (eg, from a healthcare professional), the result can be automatically entered into the PHR. In a third example, a combination of a manual approach and an automated approach may be used to update the PHR. As described in more detail below, in a first mechanism, the PHR server 115 may receive inputs instructing how the PHR should be stored, managed, and/or updated. The inputs may also instruct the PHR server 115 to retrieve information. In a second mechanism, the PHR server 115 may also receive requests from healthcare entities or third party device 160, verify the request, and transmit the requested authorization information. By way of illustration, the exemplary embodiments described herein relate to requests from health care subjects. However, exemplary embodiments may also be used for requests from third party device 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 арендуемой среды.[0030] PHR repository 120 may represent any source from which PHRs are stored for use by PHR server 115. As noted above, system 100 may include a plurality of user devices having respective users, which may be patients of healthcare subjects. Users may also have corresponding PHRs (eg, be PHR holders) and use the service provided by the PHR server 115 . These PHRs can therefore be stored in the PHR repository 120 . Of the PHRs that are stored, the PHR for the owner using the user device 105 may be stored in the PHR repository 120. In a particular implementation, the PHR repository 120 may be used by the PHR server 115 to provide a cloud storage structure for the data of the PHR members of the leased environment.

[0031] Следует отметить, что система 100, включающая в себя только пользовательское устройство 105, является только примерной. Система 100 может представлять субъекты здравоохранения, с которыми владелец с использованием пользовательского устройства 105 может быть ассоциирован или иметь опыт взаимодействия медицинского характера. Например, владелец с использованием пользовательского устройства 105 может посещать HCP 125, HCP 135 и, по меньшей мере, один из HCP 145, 150, 155. Соответственно, субъекты здравоохранения, показанные в системе 100, могут иметь владельца с использованием пользовательского устройства 105 в качестве пациента и ведут EHR для этого владельца. Тем не менее, полное представление системы 100 может включать в себя множество различных пользовательских устройств, имеющих соответствующих пользователей. Каждый пользователь также может иметь опыт взаимодействия с одним или более HCP таким образом, что каждый из этих пользователей имеет соответствующую EHR, которая ведется посредством их HCP. Соответственно, система 100 также может включать в себя дополнительные субъекты здравоохранения, некоторые из которых могут перекрываться между различными пациентами/пользователями.[0031] It should be noted that the system 100, including only the user device 105, is only exemplary. The system 100 may represent healthcare entities with which the owner, using the user device 105, may be associated or have medical experience. For example, an owner using user device 105 may visit HCP 125, HCP 135, and at least one of HCPs 145, 150, 155. Accordingly, healthcare subjects shown in system 100 may have an owner using user device 105 as patient and maintain an EHR for that owner. However, a complete view of system 100 may include many different user devices having respective users. Each user may also have experience with one or more HCPs such that each of those users has a corresponding EHR maintained through their HCP. Accordingly, system 100 may also include additional healthcare subjects, some of which may overlap between different patients/users.

[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 с другими электронными устройствами, и т.д.).[0032] As described above, the PHR server 115 can manage the PHR information flow for the owner using the user device 105 by processing inputs and requests from the user device 105 as well as healthcare subjects. Fig. 2 shows the PHR 115 of FIG. 1 according to exemplary embodiments. The PHR server 115 may provide various functionalities while executing the first and second mechanisms to manage the information flow. Although the PHR server 115 is described as a network component (specifically, as a server), the PHR server 115 may be implemented in a variety of hardware components such as a portable device (e.g., tablet computer, smartphone, laptop, etc.), a stationary device (eg, a desktop terminal), included in the user device 105, included in a website-based service, and so on. the PHR server 115 may include a processor 205, a storage assembly 210, a display device 215, an input/output device 220, a transceiver 225, and other components 230 (e.g., a renderer, an audio input/output device, a battery, a data collector, ports to electrically connect the PHR server 115 with other electronic devices, etc.).

[0033] Процессор 205 может быть выполнен с возможностью выполнять множество приложений сервера 115 PHR. Как подробнее описано ниже, процессор 205 может использовать множество механизмов (средств), включающих в себя механизм 235 пользовательского интерфейса, механизм 240 управления, механизм 245 извлечения, механизм 250 доступа и механизм 255 разрешения конфликтов. Механизм 235 пользовательского интерфейса может быть выполнен с возможностью формировать пользовательский интерфейс, с помощью которого владелец с использованием пользовательского устройства 105 и субъектов здравоохранения может взаимодействовать с сервером 115 PHR. Механизм 240 управления может быть выполнен с возможностью обновлять PHR и организовывать информацию медицинского характера в PHR, в частности, во множество различных разделов. Механизм 245 извлечения может быть выполнен с возможностью, для первого механизма, обрабатывать запросы из пользовательского устройства 105, чтобы извлекать информацию медицинского характера из субъектов здравоохранения. Механизм 250 доступа может быть выполнен с возможностью, для второго механизма, обрабатывать запросы из субъектов здравоохранения для получения информации медицинского характера в PHR. Механизм 255 разрешения конфликтов может быть выполнен с возможностью определять конфликты в информации медицинского характера PHR.[0033] The processor 205 may be configured to execute multiple applications of the PHR server 115. As described in more detail below, the processor 205 may use a variety of mechanisms (tools), including a user interface engine 235, a control engine 240, a retrieval engine 245, an access engine 250, and a conflict resolution engine 255 . The user interface engine 235 may be configured to generate a user interface with which the owner, using the user device 105 and health care subjects, can interact with the PHR server 115. The control engine 240 may be configured to update the PHR and organize the medical information in the PHR, in particular into many different sections. The extraction engine 245 may be configured, for the first mechanism, to process requests from the user device 105 in order to extract medical information from healthcare subjects. The access mechanism 250 may be configured, for the second mechanism, to process requests from healthcare subjects for medical information in the PHR. The conflict resolution mechanism 255 may be configured to detect conflicts in PHR medical information.

[0034] Следует отметить, что вышеуказанные приложения и механизмы, представляющие собой приложение (например, программу), выполняемую посредством процессора 205 являются только примерными. Функциональность, ассоциированная с приложениями, также может представляться как компоненты одной или более многофункциональных программ, отдельный включенный компонент сервера 115 PHR либо может представлять собой модульный компонент, соединенный с сервером 115 PHR, например, интегральную схему с/без микропрограммного обеспечения.[0034] It should be noted that the above applications and mechanisms representing an application (eg, a program) executed by the processor 205 are exemplary only. Application-associated functionality may also be represented as components of one or more feature-rich programs, a separate included component of PHR server 115, or may be a modular component coupled to PHR server 115, such as an integrated circuit with or without firmware.

[0035] Запоминающее устройство 210 может представлять собой аппаратный компонент, выполненный с возможностью сохранять данные, связанные с операциями, выполняемыми посредством сервера 115 PHR. В частности, запоминающее устройство 210 может сохранять данные, принимаемые из пользовательского устройства 105 и субъектов здравоохранения, которые включены в PHR, сохраненную в репозитории 120 PHR. Устройство 215 отображения может представлять собой аппаратный компонент, выполненный с возможностью показывать данные пользователю, в то время как устройство ввода–вывода 220 может представлять собой аппаратный компонент, который позволяет пользователю осуществлять вводы. Например, администратор сервера 115 PHR может задавать то, как механизмы 235–255 должны работать с использованием устройства 215 отображения и устройства ввода–вывода 220. Следует отметить, что устройство 215 отображения и устройство ввода–вывода 220 могут представлять собой отдельные компоненты или интегрироваться, к примеру, как сенсорный экран. Приемопередающее устройство 225 может представлять собой аппаратный компонент, выполненный с возможностью передавать и/или принимать данные через сеть 110 связи.[0035] The storage device 210 may be a hardware component configured to store data associated with operations performed by the server 115 PHR. In particular, the storage device 210 may store data received from the user device 105 and healthcare subjects that are included in the PHR stored in the PHR repository 120. The display device 215 may be a hardware component configured to display data to the user, while the I/O device 220 may be a hardware component that allows the user to make inputs. For example, an administrator of the PHR server 115 may specify how the engines 235-255 should operate using the display device 215 and the input/output device 220. It should be noted that the display device 215 and the input/output device 220 may be separate components or integrated, such as a touch screen. Transceiver 225 may be a hardware component configured to transmit and/or receive data via communication network 110.

[0036] Согласно примерным вариантам осуществления, сервер 115 PHR может выполнять всевозможные операции, чтобы управлять потоком информации в/из PHR, принадлежащей владельцу, с использованием пользовательского устройства 105. Механизм 235 пользовательского интерфейса может быть выполнен с возможностью формировать пользовательский интерфейс, с помощью которого владелец с использованием пользовательского устройства 105 и субъектов здравоохранения может взаимодействовать с сервером 115 PHR. Пользовательский интерфейс, который предоставляется и показывается на пользовательском устройстве 105, может предоставлять прикладной программный интерфейс совместного использования данных между пользовательским устройством 105 и сервером 115 PHR, а также между субъектами здравоохранения и сервером 115 PHR.[0036] According to exemplary embodiments, the PHR server 115 may perform various operations to manage the flow of information to/from the owner-owned PHR using the user device 105. The user interface engine 235 may be configured to generate a user interface with which the owner using the user device 105 and healthcare subjects can interact with the server 115 PHR. The user interface that is provided and displayed on the user device 105 may provide a data sharing application programming interface between the user device 105 and the PHR server 115, and between healthcare subjects and the PHR server 115.

[0037] Пользовательский интерфейс пользовательского устройства 105 может отображать начальный пользовательский интерфейс. Начальный пользовательский интерфейс может включать в себя общедоступную информацию относительно услуг, предоставляемых посредством сервера 115 PHR, в частности, чтобы вести PHR. Начальный пользовательский интерфейс может обеспечивать возможность новому пользователю создавать учетную запись на сервере 115 PHR и создавать новую PHR. Начальный пользовательский интерфейс также может предоставлять различные положения и условия, ассоциированные с применением услуг сервера 115 PHR. Как отмечено выше, примерные варианты осуществления описываются относительно сервера 115 PHR, предоставляющего услуги ведения PHR для владельца с использованием пользовательского устройства 105. Соответственно, начальный пользовательский интерфейс также может обеспечивать возможность уже существующему пользователю, имеющему учетную запись и PHR с использованием услуг сервера 115 PHR, входить в учетную запись и PHR. Например, владелец может использовать пользовательское устройство 105, чтобы передавать аутентификационную информацию, чтобы входить в учетную запись и осуществлять доступ к PHR.[0037] The user interface of the user device 105 may display an initial user interface. The initial user interface may include public information regarding the services provided by the PHR server 115, in particular to maintain PHR. The initial user interface may allow a new user to create an account on the PHR server 115 and create a new PHR. The initial user interface may also provide various terms and conditions associated with using the services of the PHR server 115 . As noted above, the exemplary embodiments are described with respect to the PHR server 115 providing PHR maintenance services to the owner using the user device 105. Accordingly, the initial user interface may also allow an already existing user having an account and a PHR using the services of the PHR server 115, sign in to your account and PHR. For example, the owner may use the user device 105 to transmit authentication information to log into an account and access the PHR.

[0038] После того, как владелец входит в учетную запись, пользовательский интерфейс может предоставлять различные экраны, которые обеспечивают возможность просмотра владельцем информации медицинского характера, включенной в PHR. Например, информация медицинского характера может запрашиваться или включаться посредством автоматизированной операции в PHR. После того, как запрашиваемая информация медицинского характера включена, экран также может включать эту информацию в PHR для просмотра владельцем.[0038] After the owner logs into the account, the user interface may provide various screens that allow the owner to view the medical information included in the PHR. For example, medical information may be requested or included through an automated operation in the PHR. Once the requested medical information is included, the screen can also include that information in the PHR for the owner to view.

[0039] Пользовательский интерфейс также может обеспечивать возможность владельцу предоставлять различные другие вводы в дополнение к вводам, используемым для того, чтобы просматривать информацию медицинского характера PHR. В первом примере, владелец может предоставлять ввод, чтобы обновлять информацию медицинского характера, которая допускает считывание и запись. Например, персональная информация (например, контактная информация, информация контактного лица для экстренных вызовов, информация участкового врача и т.д.) может изменяться владельцем. Соответственно, ввод на обновление может обеспечивать возможность добавления, изменения или удаления допускающих запись частей PHR. Персональная информация также может включать в себя план мероприятий по уходу владельца PHR, причем план мероприятий по уходу может идентифицировать цели в отношении здоровья владельца PHR. Как подробнее описано ниже, сервер 115 PHR может принимать ввод на обновление для персональной информации и обновлять персональный раздел PHR для владельца. Ввод на обновление также может использоваться для того, чтобы создавать разделы касаемо субъектов здравоохранения. Например, как отмечено выше, владелец с использованием пользовательского устройства 105 может иметь предысторию с HCP 125, 135, 145, 150, 155. Соответственно, ввод на обновление может использоваться для того, чтобы создавать разделы для этих HCP или с субъектами здравоохранения, такими как HCO 130, 140, когда HCP должны группироваться в общий раздел. Как подробнее описано ниже, сервер 115 PHR может принимать ввод на обновление для разделов касаемо субъектов здравоохранения и обновлять агрегированный раздел PHR для владельца.[0039] The user interface may also allow the owner to provide various other inputs in addition to the inputs used to view PHR medical information. In the first example, the owner may provide an input to update medical information that is readable and writeable. For example, personal information (eg, contact information, emergency contact information, district doctor information, etc.) can be changed by the owner. Accordingly, the update input may allow for adding, changing, or deleting writable portions of the PHR. The personal information may also include the care plan of the PHR owner, where the care plan may identify the health goals of the PHR owner. As described in more detail below, the PHR server 115 may receive an update input for the personal information and update the personal PHR section for the owner. The update entry can also be used to create sections regarding healthcare subjects. For example, as noted above, an owner using user device 105 may have a history with HCPs 125, 135, 145, 150, 155. Accordingly, update input may be used to create partitions for these HCPs or with healthcare entities such as HCO 130, 140 when HCPs are to be grouped into a common section. As described in more detail below, the PHR server 115 may receive update input for the health care subject partitions and update the owner's aggregated PHR partition.

[0040] Во втором примере, владелец может предоставлять ввод, чтобы запрашивать информацию медицинского характера из субъекта здравоохранения, который должен извлекаться. Например, владелец, возможно, недавно посещал HCP 125. Посещение может предусматривать то, что лабораторный тест должен выполняться касаемо пробы, которая предоставлена. Соответственно, владелец может подавать в сервер 115 PHR соответствующий ввод на извлечение, указывающий то, что результаты лабораторного теста должны быть извлечены и включены в PHR. Владелец может предоставлять аналогичный ввод для каждого посещения HCP. Также следует отметить, что владелец, вручную предоставляющий ввод на извлечение, является только примерным. Сервер 115 PHR может предоставлять автоматизированные операции для владельца, чтобы выполнять операции при извлечении информации из субъекта здравоохранения. Например, владелец может иметь календарь посещений HCP. Сервер 115 PHR может иметь доступ к этому календарю и, соответственно, выполнять операции извлечения для получения информации, ассоциированной с предыдущими посещениями. В другом примере (и как описано ниже), HCP или HCO может вручную выполнять или использовать автоматизированную операцию для того, чтобы проталкивать информацию посещения владельца PHR на сервер 115 PHR. Как подробнее описано ниже, запрошенная информация из ввода с извлечением может быть включена сервером 115 PHR в агрегированный раздел PHR, в частности, в подраздел, соответствующий HCP или HCO, из которой исходит запрошенная информация.[0040] In a second example, the owner may provide an input to request medical information from a healthcare subject to be retrieved. For example, the owner may have recently visited HCP 125. The visit may require that a laboratory test be performed on the sample that is provided. Accordingly, the owner may submit to the PHR server 115 an appropriate retrieval input indicating that the lab test results should be retrieved and included in the PHR. The owner may provide a similar entry for each HCP visit. It should also be noted that the owner manually providing input for extraction is only exemplary. The PHR server 115 may provide automated operations for the owner to perform operations when information is retrieved from a healthcare subject. For example, the owner may have an HCP visit calendar. The PHR server 115 may access this calendar and, accordingly, perform retrieval operations to obtain information associated with previous visits. In another example (and as described below), the HCP or HCO may manually perform or use an automated operation to push the PHR owner visit information to the PHR server 115 . As described in more detail below, the requested information from the extract input may be included by the PHR server 115 in an aggregated PHR section, in particular, in a subsection corresponding to the HCP or HCO from which the requested information originates.

[0041] В третьем примере, владелец может предоставлять ввод, чтобы добавлять или изменять настройки, ассоциированные с субъектом здравоохранения. Хотя информация медицинского характера в PHR принадлежит владельцу с использованием пользовательского устройства 105, субъект здравоохранения также может запрашивать необходимость просматривать избранные части PHR. Например, последующее посещение HCP субъекта здравоохранения может требовать заблаговременного знания предыдущих тестов и/или процедур. Посредством просмотра соответствующей информации в PHR, HCP может легко принимать запрошенную информацию. Также следует отметить, что субъект здравоохранения является только примерным, и запрос на то, чтобы просматривать части PHR, может исходить из стороннего устройства 160. Таким образом, в ожидании запроса из HCP, ввод с заданием, чтобы изменять установки для указанного субъекта здравоохранения, может предоставляться владельцем. Ввод с заданием может задавать то, какие части PHR могут просматриваться посредством указанного субъекта здравоохранения. В частности, ввод с заданием может указывать доступ к агрегированному разделу PHR. Ввод с заданием дополнительно может задавать продолжительность, в течение которой могут просматриваться выбранные части. Таким образом, указанному субъекту здравоохранения может разрешаться просматривать выбранные части PHR только в течение ограниченной продолжительности. Ввод с заданием также может предоставлять более общую инструкцию касаемо того, как может просматриваться информация медицинского характера в PHR. Например, части персональной информации (например, имя и информация контактного лица для экстренных вызовов) могут быть общедоступными для просмотра в любой момент времени, тогда как другие части персональной информации (например, адрес) могут быть доступными только для выбранных субъектов здравоохранения или только для владельца. Таким образом, ввод с заданием дополнительно может указывать доступ к другим разделам PHR.[0041] In a third example, the owner may provide input to add or change settings associated with the healthcare subject. While the medical information in the PHR belongs to the owner using the user device 105, the health care subject may also request to view selected portions of the PHR. For example, a subsequent HCP visit to a healthcare subject may require advance knowledge of previous tests and/or procedures. By viewing the relevant information in the PHR, the HCP can easily receive the requested information. It should also be noted that the health care subject is only exemplary, and a request to view portions of the PHR may originate from the third party device 160. provided by the owner. The task input may specify which portions of the PHR may be viewed by the specified health care subject. In particular, a task input may indicate access to an aggregated PHR section. The task input may further specify the duration for which the selected portions may be viewed. Thus, said healthcare subject may only be allowed to view selected portions of the PHR for a limited duration. The task entry can also provide more general guidance on how medical information can be viewed in the PHR. For example, parts of personal information (for example, name and emergency contact information) may be publicly viewable at any time, while other parts of personal information (for example, address) may be visible only to selected healthcare subjects or only to the owner. . Thus, a task entry may additionally indicate access to other sections of the PHR.

[0042] Механизм 235 пользовательского интерфейса дополнительно может быть выполнен с возможностью формировать пользовательские интерфейсы для субъектов здравоохранения, чтобы предоставлять вводы или запросы. Поскольку субъект здравоохранения не владеет PHR, вводы, которые могут предоставляться посредством субъекта здравоохранения, могут быть ограничены. В первом примере, если раздел для субъекта здравоохранения не доступен в PHR (например, владелец PHR никогда не предоставлял ввод на обновление, чтобы создавать раздел), субъект здравоохранения также может предоставлять ввод на обновление, чтобы создавать раздел (например, чтобы проталкивать информацию в этот раздел). Тем не менее, следует отметить, что субъект здравоохранения может создавать только собственный раздел в PHR. Таким образом, субъект здравоохранения не имеет возможностей влияния на другие разделы PHR. Во втором примере, субъект здравоохранения может запрашивать доступ к информации медицинского характера в PHR. В одной реализации, субъект здравоохранения также может иметь учетную запись с услугой сервера 115 PHR. После входа в учетную запись, субъект здравоохранения может предоставлять надлежащий ввод или запрос. Практически аналогичным способом, пользователь стороннего устройства 160 может использовать практически аналогичную реализацию.[0042] The user interface engine 235 can further be configured to generate user interfaces for healthcare subjects to provide inputs or queries. Since the health care subject does not own the PHR, the inputs that can be provided by the health care subject may be limited. In the first example, if the section for the health care subject is not available in the PHR (e.g., the owner of the PHR never provided an update input to create the section), the health care subject may also provide an update input to create the section (e.g., to push information into this section). chapter). However, it should be noted that a healthcare subject can only create their own section in the PHR. Thus, the healthcare entity does not have the ability to influence other sections of the PHR. In the second example, the health care subject may request access to health information in the PHR. In one implementation, the health care subject may also have an account with the PHR server 115 service. After logging into the account, the healthcare subject can provide the appropriate input or request. In a substantially similar manner, a user of third party device 160 may use a substantially similar implementation.

[0043] Механизм 240 управления может быть выполнен с возможностью обновлять PHR и организовывать информацию медицинского характера в PHR. Первоначально, механизм 240 управления может ассоциировать PHR с универсально уникальным идентификатором (UUID), соответствующим владельцу PHR (например, пользователю пользовательского устройства 105). Таким образом, информация, которая принимается, может быть ассоциирована с UUID, который идентифицирует владельца, и PHR, в которую должна быть включена информация. Механизм 240 управления может структурировать PHR на множество разделов. В первом примере, разделы могут включать в себя раздел сформированных пользователем данных или персональный раздел. В частности, раздел сформированных пользователем данных может быть связан с разделом, в который включена персональная информация, ассоциированная с владельцем. Например, механизм 240 управления может вручную принимать персональную информацию от владельца через пользовательское устройство 105 или может принимать персональную информацию из других источников (например, IoT–устройств, обучающих программ и т.д.). Персональная информация, которая должна быть включена в PHR, может приниматься с использованием ресурсов быстрого взаимодействия в сфере здравоохранения (FHIR) и организовываться в качестве FHIR–представления данных.[0043] The control engine 240 may be configured to update the PHR and organize medical information in the PHR. Initially, control engine 240 may associate the PHR with a universally unique identifier (UUID) corresponding to the owner of the PHR (eg, a user of user device 105). Thus, the information that is received can be associated with a UUID that identifies the owner and a PHR in which the information is to be included. The control engine 240 may structure the PHR into multiple sections. In the first example, sections may include a user-generated data section or a personal section. In particular, a user-generated data section may be associated with a section that includes personal information associated with the owner. For example, the control engine 240 may manually receive personal information from the owner via the user device 105, or may receive personal information from other sources (eg, IoT devices, tutorials, etc.). Personal information to be included in a PHR can be received using Healthcare Rapid Interaction Resources (FHIR) and organized as a FHIR data view.

[0044] Во втором примере, разделы могут включать в себя агрегированный раздел, в котором один или более подразделов, соответственно, могут соответствовать субъекту здравоохранения. Как отмечено выше, подразделы касаемо субъектов здравоохранения могут создаваться на основе вводов с обновлением (от владельца или из субъекта здравоохранения) для различных субъектов здравоохранения (или HCP), которые предоставляют медицинское обслуживание для владельца PHR. Следует отметить, что механизм 240 управления может обеспечивать полный доступ к этим разделам владельцем и предоставлять характеристики считывания и записи для разделов. Таким образом, владелец может просматривать разделы, добавлять/обновлять/удалять персональный раздел, а также информацию, включенную в персональный раздел, и добавлять/обновлять/удалять разделы касаемо субъектов здравоохранения.[0044] In the second example, sections may include an aggregated section in which one or more sections, respectively, may correspond to a health care subject. As noted above, health care entity subsections can be generated based on updated entries (from the owner or from the health care entity) for the various health care entities (or HCPs) that provide care for the PHR owner. It should be noted that the control mechanism 240 can provide full owner access to these partitions and provide read and write characteristics for the partitions. Thus, the owner can view sections, add/update/delete the personal section, as well as information included in the personal section, and add/update/delete sections regarding healthcare subjects.

[0045] Хотя разделы касаемо субъектов здравоохранения находятся в пределах управления владельцем, механизм 240 управления может ограничивать характеристики информации в разделах касаемо субъектов здравоохранения характеристиками только для чтения. Таким образом, владельцу может запрещаться добавление/обновление/удаление информации в разделах касаемо субъектов здравоохранения. В частности, информация, которая включена в раздел касаемо субъектов здравоохранения, может быть основана на EHR, принадлежащей соответствующему субъекту здравоохранения. Например, информация может представлять собой результаты или сводку сеанса владельца с HCP. Владелец может владеть информацией после включения в PHR и осуществлять доступ к информации в режиме только для чтения.[0045] While the health care subject sections are within the control of the owner, the control engine 240 can restrict the characteristics of the information in the health subject sections to read-only characteristics. Thus, the owner may be prohibited from adding/updating/deleting information in sections regarding healthcare subjects. In particular, the information that is included in the section on healthcare entities may be based on the EHR held by the relevant healthcare entity. For example, the information may be results or a summary of the owner's session with the HCP. The owner can own the information after being included in the PHR and access the information in read-only mode.

[0046] Механизм 245 извлечения может быть выполнен с возможностью, для первого механизма, обрабатывать запросы из пользовательского устройства 105, чтобы извлекать информацию медицинского характера из субъектов здравоохранения. Как отмечено выше, механизм 235 пользовательского интерфейса может позволять владельцу предоставлять ввод, чтобы инициировать извлечение информации из субъекта здравоохранения, которая должна быть включена в PHR. В конкретном примере, механизм 245 извлечения может формировать запрос на субъект здравоохранения и передавать в субъект здравоохранения сообщение, включающее в себя запрос. Запрос может включать в себя инструкции касаемо того, как проталкивать запрошенную информацию. Например, если сервер 115 PHR представляет собой услугу на основе приложения браузера, может предоставляться гиперссылка, которая перенаправляет субъект здравоохранения на веб–страницу, на которую может выгружаться текстовый документ. Сервер 115 PHR может использовать API FHIR для запрошенной информации, которая должна предоставляться на сервер 115 PHR из субъекта здравоохранения. Затем, механизм 245 извлечения может включать информацию в PHR в соответствующем разделе касаемо субъектов здравоохранения. В частности, механизм 245 извлечения может взаимодействовать с механизмом 240 управления таким образом, чтобы включать извлеченную информацию в агрегированный раздел PHR, в частности, в подраздел, соответствующий субъекту здравоохранения, в агрегированном разделе PHR, которая предоставляет извлеченную информацию.[0046] The extraction mechanism 245 may be configured, for the first mechanism, to process requests from the user device 105 to retrieve medical information from healthcare subjects. As noted above, the user interface engine 235 may allow the owner to provide input to initiate the retrieval of information from the healthcare subject to be included in the PHR. In a specific example, the retriever 245 may generate a request for the health care subject and send a message including the request to the health care subject. The request may include instructions on how to push the requested information. For example, if the PHR server 115 is a browser application based service, a hyperlink may be provided that redirects the healthcare subject to a web page to which a text document may be uploaded. The PHR server 115 may use the FHIR API for the requested information to be provided to the PHR server 115 from the healthcare subject. Then, the retrieval engine 245 may include information in the PHR in the appropriate section regarding healthcare subjects. In particular, the extraction engine 245 may interact with the control engine 240 to include the extracted information in an aggregated PHR section, in particular, in a subsection corresponding to a healthcare subject in an aggregated PHR section that provides the extracted information.

[0047] Следует отметить, что субъект здравоохранения также может превентивно предоставлять информацию в механизм 245 извлечения. Таким образом, даже если владелец не инициирует извлечение, субъект здравоохранения может использовать услугу сервера 115 PHR. Если субъект здравоохранения также имеет учетную запись в сервере 115 PHR, субъект здравоохранения может предоставлять идентификатор (например, UUID) PHR для владельца (который может быть добровольно предложен владельцем). Соответственно, субъект здравоохранения может выгружать информацию, которая должна быть включена в PHR.[0047] It should be noted that the health care subject may also proactively provide information to the retrieval mechanism 245 . Thus, even if the owner does not initiate the retrieval, the health care subject can use the PHR server 115 service. If the health care subject also has an account with the PHR server 115, the health care subject may provide an identifier (eg, UUID) of the PHR for the owner (which may be voluntarily offered by the owner). Accordingly, the health care subject may upload information to be included in the PHR.

[0048] Также следует отметить, что субъект здравоохранения может предоставлять информацию на основе EHR с различными вариантами. Например, информация может быть выгружена с масками. Соответственно, конкретные клинические данные в загруженной информации могут маскироваться, так что владелец по–прежнему может владеть информацией, но не обязательно иметь все ассоциированные права или доступ. Таким образом, можно предотвращать просмотр, владельцем, конкретных клинических данных. Тем не менее, субъект здравоохранения также может делегировать и совместно использовать выгруженную информацию. Например, можно предотвращать просмотр, владельцем, конкретных клинических данных или любой информации, которая маскируется. Тем не менее, делегирование/совместное использование посредством субъекта здравоохранения может обеспечивать возможность другим субъектам здравоохранения просматривать маскированную информацию. Таким образом, механизм 240 управления дополнительно может использовать избирательно просматриваемый раздел. Если обобщить, избирательно просматриваемый раздел может включать в себя информацию, которая не может просматриваться владельцем, но может обмениваться между HCP, подробные планы мероприятий по уходу, которые являются просматриваемым владельцем, информацию рецептов и т.д. Следует отметить, что информация в избирательно просматриваемом разделе может быть динамической. Например, информация может быть основана на промежуточных приложениях (например, из HCP, команды амбулаторной помощи, обучающего плана, плана с рекомендациями по образу жизни и т.д.).[0048] It should also be noted that the health care subject may provide information based on the EHR with various options. For example, information can be uploaded with masks. Accordingly, specific clinical data in uploaded information may be masked so that the owner may still own the information, but not necessarily have all associated rights or access. Thus, it is possible to prevent the owner from viewing specific clinical data. However, the health care subject can also delegate and share the uploaded information. For example, you can prevent the owner from viewing specific clinical data or any information that is masked. However, delegation/sharing by a health care subject may allow other health care subjects to view the masked information. Thus, the control engine 240 may additionally use a selectively viewed section. More generally, the selectively viewed section may include information that cannot be viewed by the owner but can be exchanged between HCPs, detailed care plans that are owner viewed, prescription information, and so on. It should be noted that the information in the selectively viewed section may be dynamic. For example, information may be based on intermediate attachments (eg, from HCP, ambulatory care team, educational plan, lifestyle plan, etc.).

[0049] Механизм 250 доступа может быть выполнен с возможностью, для второго механизма, обрабатывать запросы из субъектов здравоохранения (или стороннего устройства 160) для получения информации медицинского характера в PHR. Механизм 250 доступа может использовать ввод с заданием из пользовательского устройства 105. Соответственно, механизм 250 доступа может обрабатывать запросы из субъектов здравоохранения на основе ввода с заданием. Если механизм 250 доступа определяет то, что запрос предназначен для конфиденциальной информации, которая является недоступной всем, за исключением владельца PHR, запрос может отклоняться. Если механизм 250 доступа определяет то, что запрос предназначен для доступной информации, механизм 250 доступа может продолжать обрабатывать запрос. Если запрос предназначен для общедоступной информации, запрос может обрабатываться, и информация может предоставляться. Если запрос не предназначен для общедоступной информации, но также и не предназначен для конфиденциальной информации, механизм 250 доступа затем может определять то, исходит или нет запрос из авторизованного субъекта здравоохранения. Если запрос исходит из авторизованного субъекта здравоохранения, запрашиваемая информация затем верифицируется на предмет того, что она находится в выбранных частях, идентифицированных во вводе с заданием. Если ввод с заданием также указывает длительность того, когда выбранная часть информации медицинского характера является доступной посредством указанного субъекта здравоохранения, механизм 250 доступа может выполнять эту дополнительную верификацию до предоставления запрошенной информации. Таким образом, механизм 250 доступа может предоставлять субъекту здравоохранения доступ на то, чтобы просматривать запрошенную информацию (например, с использованием FHIR API, когда идентификационные данные, используемые посредством субъекта здравоохранения, ассоциированы с идентификационными FHIR–данными пациентов и UUID). Следует отметить, что, поскольку информация в PHR принадлежит владельцу, субъекту здравоохранения, осуществляющему доступ к информации, может предоставляться характеристики только для чтения.[0049] The access mechanism 250 may be configured, for the second mechanism, to process requests from health care subjects (or third party device 160) to obtain medical information in the PHR. Access engine 250 may use task input from user device 105. Accordingly, access engine 250 may process requests from health care subjects based on task input. If the access mechanism 250 determines that the request is for sensitive information that is inaccessible to anyone other than the owner of the PHR, the request may be denied. If the access engine 250 determines that the request is for available information, the access engine 250 may continue to process the request. If the request is for public information, the request may be processed and the information may be provided. If the request is not for public information, but also not for private information, the access mechanism 250 can then determine whether or not the request originates from an authorized healthcare subject. If the request originates from an authorized health care subject, the requested information is then verified to be in the selected parts identified in the task input. If the task input also indicates the length of time that the selected piece of health information is available by the specified health care subject, the access mechanism 250 may perform this additional verification prior to providing the requested information. Thus, the access mechanism 250 may grant access to the health care subject to view the requested information (eg, using the FHIR API when the identities used by the health care subject are associated with FHIR patient identities and UUIDs). It should be noted that since the information in the PHR belongs to the owner, the health care provider accessing the information may be given read-only characteristics.

[0050] Механизм 255 разрешения конфликтов может быть выполнен с возможностью определять конфликты в информации медицинского характера PHR. Механизм 255 разрешения конфликтов может представлять собой дополнительный признак, предоставленный посредством услуг сервера 115 PHR. В частности, когда информация в PHR изменяется (например, добавление, обновление, удаление), механизм 255 разрешения конфликтов может определять то, возникает или нет конфликт в наиболее актуальной информации PHR. Например, существующий рецепт может выписываться первым HCP, который включен в раздел касаемо первого субъекта здравоохранения PHR. Последующий рецепт может также выписываться вторым HCP, который включен в раздел касаемо второго субъекта здравоохранения PHR. Механизм 255 разрешения конфликтов может формировать предупреждение для второго HCP, указывающее конфликт, что позволяет предоставлять возможность модификации последующего рецепта. В другом примере, план мероприятий по уходу владельца PHR может включать в себя сброс веса. Тем не менее, ход действий, рекомендуемый посредством HCP, включенный в соответствующий раздел касаемо субъектов здравоохранения PHR, может включать в себя лекарственный препарат, имеющий побочный эффект в виде набора веса. Механизм 255 разрешения конфликтов может формировать предупреждение касаемо того, что ход действий осуществляется вопреки плану мероприятий по уходу владельца PHR.[0050] The conflict resolution mechanism 255 may be configured to detect conflicts in PHR medical information. The conflict resolution mechanism 255 may be an additional feature provided by the services of the PHR server 115 . In particular, when information in the PHR changes (eg, addition, update, deletion), the conflict resolution engine 255 can determine whether or not a conflict occurs in the most current PHR information. For example, an existing prescription may be filled by the first HCP that is included in the first health care subject section of the PHR. A follow-up prescription may also be issued by a second HCP, which is included in the second health care subject section of the PHR. The conflict resolution engine 255 may generate an alert for the second HCP indicating a conflict, allowing modification of a subsequent recipe to be allowed. In another example, the PHR owner's care plan may include weight loss. However, the course of action recommended by the HCP included in the appropriate PHR subject section may include a drug that has the side effect of weight gain. The conflict resolution mechanism 255 may generate an alert that the course of action is contrary to the care plan of the PHR owner.

[0051] Сервер 115 PHR, имеющий признаки и функциональности, описанные выше, предоставляет операционную PHR для владельца. Операционная PHR предоставляет различные решения для потребностей, ассоциированных с владением, управлением, ведением и обновлением PHR. В частности, ведение PHR с персональным разделом, агрегированным разделом, избирательно просматриваемым разделом и т.д. обеспечивает возможность выполнения обмена информацией в PHR управляемым и гибким способом. Например, операционная PHR согласно примерным вариантам осуществления является облачной, чтобы обеспечивать совместное использование информации медицинского характера в PHR для субъектов здравоохранения. В другом примере, сегментация PHR на конкретные разделы, к примеру, на персональный раздел и подразделы касаемо субъектов здравоохранения с ассоциированной авторизацией доступа, предоставляет значительную гибкость относительно типа контента или информации, которая может сохраняться и быть доступной. В дополнительном примере, операционная PHR предоставляет совместное использование информации медицинского характера в PHR для субъектов здравоохранения, причем субъекты здравоохранения могут быть "зарегистрированы" в PHR.[0051] The PHR server 115 having the features and functionality described above provides an operational PHR to the owner. Operational PHR provides a variety of solutions for the needs associated with owning, managing, maintaining and updating PHR. In particular, maintaining a PHR with a personal section, an aggregated section, a selectively viewed section, etc. enables the exchange of information in the PHR in a controlled and flexible manner. For example, the operating PHR of the exemplary embodiments is cloud-based to enable the sharing of medical information in the PHR among healthcare subjects. In another example, segmenting the PHR into specific sections, such as a personal section and subsections for healthcare subjects with associated access authorization, provides considerable flexibility regarding the type of content or information that can be stored and accessed. In a further example, an operating PHR provides for the sharing of medical information in the PHR for healthcare subjects, wherein the healthcare subjects can be "enrolled" in the PHR.

[0052] Фиг. 3 показывает способ 300 для включения информации в PHR согласно примерным вариантам осуществления. В частности, способ 300 может относиться к первому механизму примерных вариантов осуществления, в которых владелец взаимодействует с сервером 115 PHR и информацией медицинского характера PHR. Соответственно, в дальнейшем описывается способ 300 с точки зрения сервера 115 PHR. В дальнейшем также описывается способ 300 относительно системы 100 по фиг. 1 и множества механизмов 235–255 сервера 115 PHR по фиг. 2.[0052] FIG. 3 shows a method 300 for including information in a PHR according to exemplary embodiments. In particular, method 300 may refer to a first mechanism of exemplary embodiments in which the owner interacts with PHR server 115 and PHR medical information. Accordingly, the following describes the method 300 from the perspective of the server 115 PHR. The following also describes method 300 with respect to system 100 of FIG. 1 and the plurality of engines 235-255 of the PHR server 115 of FIG. 2.

[0053] На 305, сервер 115 PHR принимает ввод. Например, ввод может исходить из пользовательского устройства 105 или из субъекта здравоохранения. Можно предполагать, что владелец представляет собой существующего пользователя услуг сервера 115 PHR, и владелец имеет PHR, которая ведется посредством сервера 115 PHR. Также можно предполагать, что субъект здравоохранения может быть выполнен с возможностью взаимодействовать с сервером 115 PHR (например, через учетную запись субъекта здравоохранения для услуг сервера 115 PHR). Как описано выше, ввод от владельца может быть связан с множеством различных операций. Таким образом, на 310, сервер 115 PHR определяет тип ввода, который принят.[0053] At 305, the PHR server 115 receives the input. For example, the input may come from the user device 105 or from a healthcare subject. It can be assumed that the owner is an existing service user of the PHR server 115, and the owner has a PHR maintained by the PHR server 115. It can also be contemplated that the health care subject may be configured to interact with the PHR server 115 (eg, through the health care subject's account for the services of the PHR server 115). As described above, owner input can be associated with many different operations. Thus, at 310, the PHR server 115 determines the type of input that has been received.

[0054] На 315, сервер 115 PHR определяет то, направлен или нет ввод на обновление информации. Если ввод представляет собой ввод на обновление, на 320, сервер 115 PHR определяет способ включения информации. Поскольку ввод на обновление связан с операцией записи PHR, сервер 115 PHR может включать информацию ввода с обновлением с соответствующей операцией в надлежащий раздел. Например, если ввод на обновление представляет собой добавление, изменение или удаление для персонального раздела, имеющего персональную информацию, ассоциированную с владельцем, PHR, на 325, сервер 115 PHR может обновлять PHR соответствующим образом. В другом примере, если ввод на обновление представляет собой добавление, изменение или удаление для подраздела касаемо субъектов здравоохранения, ассоциированного с соответствующим субъектом здравоохранения, на 325, сервер 115 PHR может обновлять PHR соответствующим образом. В дополнительном примере, если ввод на обновление представляет собой информацию, которая должна быть включена в подраздел касаемо субъектов здравоохранения, на 325, сервер 115 PHR может обновлять PHR соответствующим образом.[0054] At 315, the PHR server 115 determines whether or not the input is directed to update information. If the input is an update input, at 320, the PHR server 115 determines how to include the information. Since the update entry is associated with the PHR write operation, the PHR server 115 may include the update entry information with the corresponding operation in the appropriate section. For example, if the update input is an add, change, or delete for a personal section having personal information associated with the owner, PHR, at 325, the PHR server 115 may update the PHR accordingly. In another example, if the update input is an addition, change, or deletion for the health care subject subsection associated with the corresponding health care subject at 325, the PHR server 115 may update the PHR accordingly. In a further example, if the update input is information to be included in the healthcare subjects subsection at 325, the PHR server 115 may update the PHR accordingly.

[0055] Если ввод не представляет собой ввод на обновление, на 330, сервер 115 PHR определяет то, направлен или нет ввод на извлечение информации. Если ввод представляет собой ввод на извлечение, на 335, сервер 115 PHR формирует запрос в субъект здравоохранения, идентифицированный во вводе с извлечением, из которого должна приниматься запрошенная информация. Как описано выше, владелец, возможно, недавно посещал или имел сеанс с HCP, при этом сводка посещения и/или результаты теста и/или процедуры могут отслеживаться (например, храниться в EHR субъекта здравоохранения). Соответственно, ввод на извлечение может указывать посещение HCP, причем идентификационные данные субъекта здравоохранения соответствуют HCP, и т.д. Таким образом, на 340, сервер 115 PHR передает запрос в субъект здравоохранения. Субъект здравоохранения, в который передается запрос, может составлять часть одного или более медицинских специалистов–практиков, касаемо которых владелец PHR имеет опыт взаимодействия или посещения/сеансы. Таким образом, субъект здравоохранения может иметь EHR, сохраняемую для владельца.[0055] If the input is not an update input, at 330, the PHR server 115 determines whether or not the input is directed to retrieve information. If the input is a pull input, at 335, the PHR server 115 generates a request to the health care entity identified in the pull input from which the requested information is to be received. As described above, the owner may have recently attended or had an HCP session, and a summary of the visit and/or test and/or procedure results may be tracked (eg, stored in the EHR of the healthcare subject). Accordingly, the retrieval entry may indicate a visit to an HCP, where the health care subject's identity matches the HCP, and so on. Thus, at 340, the PHR server 115 transmits the request to the healthcare subject. The health care entity to which the request is made may be part of one or more health care practitioners that the PHR holder has experience with interactions or visits/sessions with. Thus, the health care subject may have an EHR stored for the wearer.

[0056] На 345, сервер 115 PHR определяет то, принят или нет ответ на запрос. В частности, сервер 115 PHR определяет то, отвечает или нет субъект здравоохранения посредством выгрузки запрашиваемой информации (например, постклинической информации). Если ответ не принят, сервер 115 PHR может возвращаться на 340 для передачи другого запроса. Тем не менее, если ответ принят, на 325, сервер 115 PHR может обновлять PHR соответствующим образом. В частности, раздел касаемо субъектов здравоохранения может обновляться таким образом, что он включает в себя загруженную информацию.[0056] At 345, the PHR server 115 determines whether or not a response to the request has been received. Specifically, the PHR server 115 determines whether or not the health care subject is responding by downloading the requested information (eg, post-clinical information). If no response is received, PHR server 115 may return to 340 to send another request. However, if a response is received, at 325, the PHR server 115 may update the PHR accordingly. In particular, the section on healthcare subjects can be updated to include uploaded information.

[0057] Следует отметить, что сервер 115 PHR может передавать запрос на основе идентифицированного времени или на основе таймера ожидания. Например, ввод на извлечение может указывать то, когда субъект здравоохранения с большой вероятностью должен иметь подготовленную запрошенную информацию. Соответственно, сервер 115 PHR может передавать запрос в это время или в последующее время. В другом примере, ввод на извлечение может быть посвящен тому, когда указываемый субъект здравоохранения завершает подготовку EHR для идентифицированного посещения/теста/процедуры. Соответственно, сервер 115 PHR может передавать запрос на основе этого таймера ожидания.[0057] It should be noted that the PHR server 115 may transmit the request based on the identified time or based on the wait timer. For example, a pull input may indicate when the health care subject is likely to have the requested information prepared. Accordingly, the PHR server 115 may transmit the request at this time or at a later time. In another example, the retrieval entry may be dedicated to when the designated health care subject completes the preparation of the EHR for the identified visit/test/procedure. Accordingly, PHR server 115 may send a request based on this wait timer.

[0058] Если ввод не представляет собой ввод на извлечение, на 350, сервер 115 PHR определяет то, направлен или нет ввод на доступ к информации владельцем. Если ввод представляет собой ввод для доступа владельцем, на 355, сервер 115 PHR извлекает и предоставляет запрошенную информацию. Поскольку ввод для доступа принимается от владельца PHR, который имеет полный доступ к информации в PHR, может не требоваться процедура верификации. Тем не менее, как отмечено выше, информация в разделах касаемо субъектов здравоохранения может включать в себя маскированные части, которые являются просматриваемыми только посредством субъектов здравоохранения. Таким образом, сервер 115 PHR может скрывать эти маскированные части от просмотра владельцем.[0058] If the input is not a pull input, at 350, the PHR server 115 determines whether or not the input is directed to information access by the owner. If the input is an owner access input, at 355, the PHR server 115 retrieves and provides the requested information. Because the entry for access is received from the owner of the PHR, who has full access to the information in the PHR, no verification procedure may be required. However, as noted above, the information in the health care subject sections may include masked portions that are viewable only by health care subjects. Thus, the PHR server 115 can hide these masked portions from the owner's view.

[0059] Если ввод не представляет собой ввод для доступа, на 360, сервер 115 PHR обрабатывает все запросы, включенные во ввод. Например, ввод может быть не связан с PHR или может быть связан с административным аспектом услуг, предоставляемых посредством сервера 115 PHR. В другом примере, сервер 115 PHR может обеспечивать возможность установления сеанса связи между пользовательским устройством 105 и субъектом здравоохранения.[0059] If the input is not an input for access, at 360, the PHR server 115 processes all requests included in the input. For example, the input may be unrelated to the PHR or may be related to the administrative aspect of the services provided by the PHR server 115 . In another example, the PHR server 115 may allow a communication session to be established between the user device 105 and the health care subject.

[0060] Следует отметить, что способ 300 и вводы связаны только с владельцем PHR. Тем не менее, способ 300 также может включать в себя операции, ассоциированные с первым механизмом, когда принимаются вводы из субъекта здравоохранения. Например, субъект здравоохранения может предоставлять ввод, чтобы создавать соответствующий раздел касаемо субъектов здравоохранения в PHR, если уже не существует. Таким образом, когда ответ на 345 предоставляется, субъект здравоохранения может верифицировать то, что его раздел касаемо субъектов здравоохранения существует в PHR, и предоставлять этот ввод, если еще не представлен.[0060] It should be noted that method 300 and inputs are associated only with the owner of the PHR. However, method 300 may also include operations associated with the first mechanism when inputs are received from a healthcare subject. For example, a health care subject may provide an input to create a corresponding health care subject section in the PHR if it does not already exist. Thus, when a response to 345 is provided, the health care subject can verify that its health care subject section exists in the PHR and provide this input if not already provided.

[0061] Фиг. 4 показывает способ 400 для предоставления информации из PHR согласно примерным вариантам осуществления. В частности, способ 400 может относиться ко второму механизму примерных вариантов осуществления, в которых информация медицинского характера из PHR запрашивается посредством субъекта здравоохранения. Соответственно, в дальнейшем описывается способ 400 с точки зрения сервера 115 PHR. В дальнейшем также описывается способ 400 относительно системы 100 по фиг. 1 и множества механизмов 235–255 сервера 115 PHR по фиг. 2.[0061] FIG. 4 shows a method 400 for providing information from a PHR according to exemplary embodiments. In particular, method 400 may relate to a second mechanism of exemplary embodiments in which health information from a PHR is requested by a healthcare subject. Accordingly, the following describes the method 400 from the perspective of the server 115 PHR. The following also describes method 400 with respect to system 100 of FIG. 1 and the plurality of engines 235-255 of the PHR server 115 of FIG. 2.

[0062] На 405, сервер 115 PHR принимает запрос информации (например, из субъекта здравоохранения или стороннего устройства 160). Как отмечено выше, субъект здравоохранения может представлять собой HCP или HCO, включающую в себя один или более HCP. Субъект здравоохранения также может требовать просмотра части информации медицинского характера в PHR (например, для последующего посещения от владельца, чтобы подготавливать документ к владельцу и т.д.).[0062] At 405, the PHR server 115 receives a request for information (eg, from a health care subject or third party device 160). As noted above, the health care subject may be an HCP or an HCO including one or more HCPs. The health care provider may also require review of some of the health information in the PHR (eg, for a follow-up visit from the owner, to prepare a document for the owner, etc.).

[0063] На 410, сервер 115 PHR определяет то, предназначен или нет запрос из субъекта здравоохранения для получения информации в PHR, которая является, в общем, доступной. Как описано выше, PHR может секционироваться на множество разделов. Владелец PHR может предоставлять ввод с заданием, который задает то, какая из информации медицинского характера в PHR должна поддерживаться конфиденциальной, в которой только владельцу разрешается доступ на то, чтобы выполнять просмотр и/или запись. Если запрос предназначен для недоступной информации, на 415, сервер 115 PHR отклоняет запрос.[0063] At 410, the PHR server 115 determines whether or not the request from the healthcare subject is intended to obtain information in the PHR that is generally available. As described above, the PHR may be partitioned into multiple partitions. The owner of the PHR may provide an input with a task that specifies which of the medical information in the PHR should be kept confidential, in which only the owner is allowed access to view and/or write. If the request is for unavailable information, at 415, the PHR server 115 rejects the request.

[0064] Если запрос предназначен для доступной информации, на 420, сервер 115 PHR определяет то, представляет ли собой запросчик, передающий запрос, разрешенный субъект. Как описано выше, ввод для доступа от владельца может задавать идентификационные данные одного или более субъектов здравоохранения, которые могут осуществлять доступ к соответствующим выбранным частям информации медицинского характера в PHR. Таким образом, сервер 115 PHR может определять то, включены или нет идентификационные данные запрашивающего субъекта здравоохранения во ввод для доступа. Сервер 115 PHR также может использовать другой стандарт. Например, если имеется раздел, соответствующий запрашивающему субъекту здравоохранения, субъекту здравоохранения может всегда разрешаться доступ к этому разделу (и только к этому разделу, если не указывается касаемо дополнительного доступа во вводе для доступа). Если запрос исходит из неавторизованного субъекта, на 415, сервер 115 PHR отклоняет запрос.[0064] If the request is for available information, at 420, the PHR server 115 determines whether the requester making the request is a permitted subject. As described above, the access input from the owner may define the identity of one or more healthcare entities that can access appropriate selected pieces of health information in the PHR. Thus, the PHR server 115 can determine whether or not the identity of the requesting health care subject is included in the access input. The PHR server 115 may also use another standard. For example, if there is a section corresponding to the requesting health care subject, the health care subject may always be allowed to access that section (and only that section, unless specified regarding additional access in the access input). If the request is from an unauthorized subject, at 415, the PHR server 115 rejects the request.

[0065] Если запрос исходит из разрешенного субъекта, на 425, сервер 115 PHR определяет то, разрешается или нет предоставление части запрашиваемой информации в запрашивающий субъект здравоохранения. С другой стороны, объект доступа может задавать то, к каким частям медицинской информации в PHR может осуществляться доступ указанными субъектами здравоохранения. Таким образом, если запрос предназначен для неавторизованной доступной информации, на 415, сервер 115 PHR отклоняет запрос. Тем не менее, если запрос предназначен для авторизованной доступной информации, на 430, сервер 115 PHR передает запрошенную информацию в субъект здравоохранения или разрешает доступ на то, чтобы просматривать запрошенную информацию. Следует отметить, что субъекту здравоохранения могут предоставляться характеристики только для чтения.[0065] If the request is from a permitted subject, at 425, the PHR server 115 determines whether or not provision of a portion of the requested information is permitted to the requesting health care subject. On the other hand, the access object may specify which parts of the health information in the PHR can be accessed by the specified healthcare subjects. Thus, if the request is for unauthorized information available, at 415, the PHR server 115 rejects the request. However, if the request is for authorized available information, at 430, the PHR server 115 transmits the requested information to the health care subject or allows access to view the requested information. It should be noted that the health care subject may be given read-only characteristics.

[0066] Следует отметить, что способ 400 может включать в себя дополнительную операцию верификации. Как описано выше, сервер 115 PHR может использовать функциональность на основе времени, в которой разрешенному субъекту здравоохранения позволяется осуществлять доступ к разрешенным частям медицинской информации в PHR. Таким образом, способ 400 может включать в себя операцию для того, чтобы определять то, принимается или нет запрос в пределах этого заданного периода времени (например, как указано во вводе для доступа). За пределами этого периода времени, запрос может отклоняться. В пределах этого периода времени, запрос может обрабатываться.[0066] It should be noted that method 400 may include an additional verification operation. As described above, the PHR server 115 may use a time-based functionality in which a permitted health care subject is allowed to access authorized portions of health information in the PHR. Thus, method 400 may include an operation for determining whether or not a request is received within that predetermined time period (eg, as indicated in an access input). Outside of this time period, the request may be denied. Within this time period, the request may be processed.

[0067] Примерные варианты осуществления предоставляют устройство, систему и способ создания и предоставления операционной персональной медицинской карты. Персональная медицинская карта может включать в себя информацию медицинского характера владельца карты, которая организуется согласно субъектам здравоохранения. Информация может иметь ассоциированные привилегии или настройки доступа, которые обеспечивают возможность пользователю просматривать всю информацию, тогда как запрашивающим сторонам, к примеру, субъектам здравоохранения, могут предоставляться права просматривать выбранные части информации.[0067] Exemplary embodiments provide an apparatus, system, and method for creating and providing a transactional personal health record. A personal health record may include information of a medical nature of the card holder, which is organized according to the subjects of health care. The information may have associated privileges or access settings that allow the user to view all of the information, while requesters, such as health care subjects, may be granted rights to view selected portions of the information.

[0068] Примерные варианты осуществления используют облачную сегментированную персональную медицинскую карту с информацией медицинского характера, которая может совместно использоваться для авторизованных субъектов, выбранных владельцем. Персональная медицинская карта также может содержать индивидуальные для конкретного субъекта здравоохранения разделы, используемые для того, чтобы регистрировать эти субъекты и сохранять соответствующую информацию медицинского характера из электронных медицинских карт, принадлежащих соответствующему субъекту. Через публично установленный интерфейс прикладного программирования, PHR может регистрировать субъект здравоохранения в персональной медицинской карте для постклинических данных, которые должны быть включены, что предоставляет способ для владельца осуществлять доступ к этим данным в персональной медицинской карте. Интерфейс прикладного программирования также обеспечивает возможность владельцу перечислять доступные субъекты здравоохранения и устанавливать привилегии предоставления разрешений для информации медицинского характера для просмотра.[0068] Exemplary embodiments use a cloud-based segmented personal health record with medical information that can be shared among authorized entities selected by the owner. A personal health record may also contain individual sections for a particular health care subject, used to register these subjects and save relevant medical information from electronic health records belonging to the respective subject. Through a publicly installed application programming interface, PHR can register a health care subject in a personal health record for post-clinical data to be included, which provides a way for the owner to access this data in a personal health record. The application programming interface also allows the owner to enumerate available health subjects and set permissions for viewing medical information.

[0069] Специалисты в данной области техники должны понимать, что вышеописанные примерные варианты осуществления могут реализовываться в любой подходящей программной или аппаратной конфигурации либо в комбинации вышеозначенного. Примерная аппаратная платформа для реализации примерных вариантов осуществления может включать в себя, например, платформу на основе Intel x86 с совместимой операционной системой, платформу Windows, платформу Mac и Mac OS, мобильное устройство, имеющее операционную систему, такую как iOS Android, и т.д. В дополнительном примере, примерные варианты осуществления вышеописанного способа могут быть осуществлены в качестве компьютерного программного продукта, содержащего строки кода, сохраненные на машиночитаемом носителе хранения данных, которые могут выполняться на процессоре или микропроцессоре. Носитель хранения данных, например, может представлять собой локальный или удаленный репозиторий данных, совместимый или отформатированный для использования с вышеуказанными операционными системами с использованием любой операции хранения.[0069] Those skilled in the art will appreciate that the exemplary embodiments described above may be implemented in any suitable software or hardware configuration, or a combination of the foregoing. An exemplary hardware platform for implementing the exemplary embodiments may include, for example, an Intel x86 based platform with a compatible operating system, a Windows platform, a Mac and Mac OS platform, a mobile device having an operating system such as iOS Android, etc. . In a further example, exemplary embodiments of the method described above may be implemented as a computer program product containing lines of code stored on a computer-readable storage medium that may be executed on a processor or microprocessor. The storage medium, for example, may be a local or remote data repository compatible or formatted for use with the above operating systems using any storage operation.

[0070] Специалистам в области техники должно быть очевидным, что различные модификации могут вноситься в настоящее раскрытие, без отступления от сущности и объема раскрытия. Таким образом, настоящее раскрытие имеет намерение охватывать модификации и варьирования этого раскрытия при условии, что они находятся в пределах объема, определяемого прилагаемой формулой изобретения и ее эквивалентами.[0070] Specialists in the field of technology should be obvious that various modifications can be made to the present disclosure, without departing from the essence and scope of the disclosure. Thus, the present disclosure is intended to cover modifications and variations of this disclosure provided that they are within the scope of the appended claims and their equivalents.

Claims

1. A method for managing access to personal health records, comprising the steps of: on a personal health record (PHR) server in which the owner's PHR is maintained, the PHR includes a plurality of sections, wherein one of the sections is an aggregated section including includes many subsections:

receiving a retrieval input from the PHR owner, the retrieval input identifying the health care subject from which the information is to be requested;

form a request for information;

transmitting this request to the health care subject;

receive information from the health care subject;

receiving an update input from one of the PHR owner and the health care subject to update the PHR, wherein the update input instructs the PHR server to create a subsection corresponding to the health care subject in the aggregated section and update the subsection in the PHR corresponding to the health care subject by including said information in the subsection of the aggregated section in the PHR corresponding to the health care subject;

receiving from the PHR owner an access input, the access input requesting the PHR server to display said information for a predetermined period of time to allow the health care subject to access the information in the PHR; And

receiving a task input from the owner of the PHR, wherein the task input specifies an access privilege associated with the subject identities corresponding to the healthcare subject, the access privilege indicating which additional subsection in the aggregated PHR section which additional subsection corresponds to the additional health subject.

2. The method of claim 1, wherein said information includes masked parts while preventing the masked parts from being displayed to the owner of the PHR.

3. The method of claim 1, further comprising associating the PHR with a universally unique identifier corresponding to the owner of the PHR.

4. The method of claim 1, further comprising the steps of:

receiving a subject access request from the health care subject;

determining whether the subject's access request includes the subject's identity;

when the subject's access request includes the subject's identity, determining whether the subject's access request includes an indication for said additional subsection; And

when the subject's access request includes said indication, grant access to that additional subsection in the aggregated PHR section.

5. The method of claim 1, further comprising the steps of:

determining whether a conflict occurs between said information and other PHR information; And

when a conflict is determined, an alert is generated for the health care subject.

6. The method of claim 1, wherein the PHR is stored in a PHR repository, which is a cloud storage structure.

7. The method of claim 1, wherein the healthcare subject is one of a medical practitioner and a healthcare organization including one or more medical practitioners.

8. A personal health record (PHR) server that maintains the owner's PHR, containing:

a transceiver communicating through a communication network, the transceiver being configured to communicate with a user device used by the PHR owner and a healthcare subject's electronic device;

a storage device storing the executable program; And

a processor that executes an executable program that instructs the processor to perform operations while maintaining the PHR, the PHR including a plurality of partitions, wherein the first of the partitions is a personal partition including personal information associated with the owner, the second of the partitions is an aggregated section including a plurality of sub-sections, each of the sub-sections corresponding to a respective health care entity, the sub-sections including relevant health information associated with the owner, based on a respective card maintained by that respective health care entity, with a limited duration is set to view the first and second of the sections, and the operations contain:

receiving an update input from one of the PHR owner and the health care subject to update the PHR, wherein the update input instructs the PHR server to create a subsection corresponding to the health care subject in the second partition and update in the PHR the first subsection and the subsection in the second partition corresponding to the health care subject, And

receiving a task input from the owner of the PHR, wherein the task input specifies an access privilege associated with the subject identity corresponding to the health care subject, the access privilege indicating an additional subkey in the second PHR section which additional subkey corresponds to the additional health care subject.

9. The PHR server of claim 8, wherein the personal information is received from the user device.

10. The PHR server of claim 8, wherein the personal section has a restricted access level to prevent healthcare subjects from viewing personal information.

11. The PHR server of claim 8, wherein the processor performs operations further comprising generating a request for the first health information, the transceiver further transmitting the request to the first health care subject and receiving the health information from the first health care subject.

12. The PHR server of claim 11, wherein the processor performs operations further comprising:

determination of identification data of the first health care subject;

identifying one of the subsections corresponding to that identification; And

inclusion of the first information of a medical nature in the said subsection corresponding to the identification data.

13. The PHR server of claim 8, wherein the third of the partitions is a selectively browseable partition including browseable information for selected subjects.

14. The PHR server of claim 13, while preventing the owner from viewing the viewed information.

15. The PHR server of claim 8, wherein the transceiver receives an access input indicating an identity and a selected subsection of the aggregated section.

16. The PHR server of claim 15, wherein the processor performs operations further comprising:

receiving an access request from the requester;

determining the requesting identity of the requestor;

when the requesting identity of the requestor matches the identity provided in the access input, granting the requestor access to the selected subsection.

17. A personal health record (PHR) server that maintains the owner's PHR, the PHR including a plurality of partitions, one of the partitions being an aggregated partition including a plurality of subsections, the PHR server comprising:

a storage device storing the executable program; And

a processor that executes an executable program that instructs the processor to perform operations comprising:

receiving, from the owner of the PHR, a retrieval input, the retrieval input identifying the healthcare subject from which the information is to be requested;

formation of a request for information;

transfer of this request to the subject of health care;

receiving information from a healthcare subject;

receiving, from the owner of the PHR, an access input, the access input requesting the PHR server to display said information for a predetermined period of time to allow the health care subject to access the information in the PHR; And

receiving, from the owner of the PHR, a task input, wherein the task input specifies an access privilege associated with the subject identities corresponding to the healthcare subject, the access privilege indicating an additional subsection in the PHR aggregate section which additional subkey corresponds to the additional health subject.