Manager for retrieving secure user information and granting restricted access.

Abstract

The embodiment allows restricted access to a user's secure information using blockchain-backed authentication credentials. Users can register with a secure information manager and control the scope to which their secure information is shared. For example, a user can allow an authorized entity to access their secure information via a portable access point. Users can select scope definitions to control how their secure information is shared. An authorized entity can scan a user's portable access point and request authentication credentials. The authorized entity can then use the credentials to issue a data access request. The secure information manager can grant authorized entities restricted access to a user's secure information corresponding to the access privileges assigned to the credentials. Secure user information managed by the secure information manager can be received or retrieved from multiple sources and ingested / organized according to a multidimensional data scheme.

Description

Technical Field

[0001] Field Embodiments of the present disclosure generally relate to a secure storage system that captures secure user information and permits restricted access to the captured secure user information.

Background Art

[0002] Background The rapid increase in connected computing devices has generated a vast amount of data that requires management. As the size of the data increases, the technical challenges associated with efficiently managing the data are becoming increasingly complex. For example, sharing secure data among multiple parties has been an age-old problem in the field of data management. Security techniques that enable users to manage secure information, such as authentication, verification, and authorization workflows, can be cumbersome and, in some situations, may be difficult to implement. A security protocol that achieves practical secure data sharing in situations that cause friction with conventional data sharing protocols can provide significant value.

Summary of the Invention

[0003] Summary Embodiments of this disclosure generally relate to a system and method for granting a user restricted access to secure information using authentication of credentials and verification of user information. An authentication request for one or more credentials that grant a user access to secure information may be received in a secure information manager from a requesting system, the authentication request including user identification information, entity identification information, and a scope definition, and the requesting system generates the authentication request in response to scanning the user's portable access point. The user identification information and entity identification information may be verified in the secure information manager. Blockchain credentials with access rights corresponding to the scope definition may be assigned to an entity in response to verification, and the blockchain credentials assignment is recorded on a private blockchain managing blockchain credentials. In response to one or more access requests from an entity containing the assigned blockchain credentials, access to the user's secure information may be granted, restricted to the access rights of the blockchain credentials.

[0004] Features and advantages of the embodiments are described in the following description, or become apparent from the description, or can be learned by practicing the present disclosure.

[0005] Further embodiments, details, advantages, and modifications will become apparent from the following detailed description of preferred embodiments, which are taken into account in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0006] [Figure 1] This figure shows a system for granting limited access to a user's secure information using a non-fungible token according to an exemplary embodiment. [Figure 2] This is a block diagram of computing devices operably coupled to a predictive system according to an exemplary embodiment. [Figure 3]This figure shows a system for registering users for secure information management according to an exemplary embodiment. [Figure 4A] This figure shows a system having a secure information manager that allows limited access to a user's secure information using blockchain authentication information according to an exemplary embodiment. [Figure 4B] This figure shows a system having a secure information manager that allows limited access to a user's secure information using blockchain authentication information according to an exemplary embodiment. [Figure 4C] This figure shows a system having a secure information manager that allows limited access to a user's secure information using blockchain authentication information according to an exemplary embodiment. [Figure 4D] This figure shows a system for capturing secure user information according to an exemplary embodiment. [Figure 5A] This figure shows a user interface including a portable access point according to an exemplary embodiment. [Figure 5B] This figure shows a user interface for viewing a segment of secure user information according to an exemplary embodiment. [Figure 5C] This figure shows a user interface for creating a new category of secure user information according to an exemplary embodiment. [Figure 5D] This figure shows a user interface for sharing selected portions of secure user information according to an exemplary embodiment. [Figure 5E] This figure shows a user interface for auditing access to secure user information according to an exemplary embodiment. [Figure 6] This is a flowchart for capturing data elements of secure user information according to an exemplary embodiment. [Figure 7] This flowchart illustrates how to grant restricted access to a user's secure information using authentication of credentials and user verification according to an exemplary embodiment. [Figure 8A] This is a flowchart for defining access restrictions for sharing user-secure information according to an exemplary embodiment. [Figure 8B] This is a flowchart for defining access restrictions for sharing user-secure information according to an exemplary embodiment. [Figure 9] This flowchart illustrates an exemplary embodiment for retrieving scope-limited user information from a secure data store and logging access. [Modes for carrying out the invention]

[0007] Detailed explanation The embodiment uses blockchain-backed credentials to ingest secure user information and grants restricted access to the user's secure information. Users can register with a secure information manager and control the scope to which their secure information is shared. For example, a user can allow authorized entities (e.g., service providers, healthcare providers, other individuals, etc.) to access their secure information via a portable access point. Users can select scope definitions to control how their secure information is shared with authorized entities. Authorized entities can scan (or communicate with) the user's portable access point and request credentials to grant access to the user's secure information through the scan. For example, the credentials can be blockchain-backed credentials that are assigned access permissions corresponding to the user's selection.

[0008] Subsequently, the authorized entity can issue one or more data access requests using the credentials. For example, data access requests can be authenticated and verified by the Secure Information Manager. The Secure Information Manager can grant the authorized entity limited access to the user's secure information corresponding to the access privileges assigned to the credentials (based on the authenticated and verified data access requests). A user can revoke the credentials and / or the access privileges assigned to the authorized entity at any time. The access privileges assigned to the credentials may include an expiration timer, after which the credentials can no longer be authenticated by the Secure Information Manager.

[0009] The ingestion manager can receive and / or retrieve data elements containing user secure information, and can transform, expand, and / or tag the data elements. For example, a secure information manager can store secure user information in a secure data store that includes a multidimensional data scheme. The ingestion manager can tag data elements with segment dimensional values ​​according to the multidimensional data scheme. The tagged data elements can be stored in the secure data store according to that data scheme. Once stored in the secure data store, the secure information manager can, for example, grant limited access to the data elements as secure user information in response to data access requests from authorized entities that include authentication information.

[0010] The embodiments achieve efficient and secure, granular user-controlled access to a user's secure information. For example, a user's portable access point is configured to efficiently define the conditions for sharing the user's secure information. In addition, issued credentials and a secure information manager enforce the user's sharing conditions in a trusted manner. In embodiments where credentials are blockchain-backed, blockchain-based management ensures that the credentials are authentic and mitigates fraudulent attempts to access the user's secure information.

[0011] Blockchain-backed credentials can be issued to certified entities. For example, certified entities can be individuals, organizations, or groups of individuals. Certified entities can undergo a certification workflow, after which they can receive credentials to access users' secure information. The certification workflow can include one or more of the following: identity verification, credential verification (e.g., government credentials, medical credentials, financial advisor credentials), cybersecurity verification, and any other appropriate certifications. Certified entities can generate credential requests seeking access to users' secure information by scanning users' portable access points (via computing systems and scanning components).

[0012] In some embodiments, the portable access point can be a visual access point that, when scanned, can grant access to the user's secure information (e.g., stored and managed via a secure information manager). For example, the visual access point may include a visual representation of the user (e.g., a facial image) linked to the portable access point, which encodes information relating to the user's secure information and / or the scope of permitted access.

[0013] The user can configure the portable access point and the encoded information presented. For example, the portable access point can be presented via an application running on the user's wireless device (e.g., smartphone, tablet, etc.), and the user can interact with the application to select the scope of sharing of the user's secure information. Embodiments of the portable access point are dynamic such that the user's selection via the application generates different versions of the portable access point with different encoded information presentations. For example, the user can define a sharing scope that identifies data points of the user's secure information that can be shared with an authenticated entity via scanning of the portable access point. The user can also define a sharing scope of the time period during which the user's secure information can be shared with an authenticated entity via scanning of the portable access point.

[0014] One or more scan elements of the authenticated entity can scan the portable access point and use the information from the portable access point to generate an authentication information request. For example, the authentication information request can include one or more entity authentication information, user identification information, a scope definition defining the access rights to the requested authentication information regarding the user's secure information, and / or an authentication information type. The entity authentication information can include authentication information issued to the entity after the entity has been authenticated by an authentication workflow (e.g., issued to an identity associated with one or more users and / or entities). Exemplary entity authentication information can include an access token (e.g., Security Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys or signatures, etc. The secure information manager can authenticate the entity authentication information provided in the request before issuing the access authentication information to the authenticated entity.

[0015] The authentication information request can also include user identification information. Exemplary user identification information can be one or more of user data identifying the user (e.g., full name, date of birth, home city, state, and / or postal code, physical appearance, etc.), an image of a government-issued document identifying the user (e.g., driver's license, passport, etc.), biometric information (e.g., fingerprints, eye scans, DNA information, etc.), and other suitable identification information of the user.

[0016] Embodiments of the user's secure information can be electronic health data segmented based on segments and segment dimension value parameters, and the scope definition defining the access rights to the required authentication information regarding the user's secure information can correspond to a restricted portion of the user's electronic health data. For example, the segments can include the issuer doctor and / or medical institution (e.g., entity identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, doctor-patient communication, doctor's findings, vaccine information, allergies, etc.), related medical fields (e.g., cardiology, primary care, neurology, oncology, etc.), images (e.g., radiology scans, X-rays, ultrasound images, MRI images, etc.), information issue date and time, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other suitable health data parameters. In some embodiments, the segments can include structured and unstructured data. The user can define which portions of the user's electronic health data are to be shared via the user's portable access point by providing the segment dimension values defining the scope.

[0017] In some embodiments, a portable access point can be a software access point that provides information for authentication requests (e.g., user's secure information and / or the scope of permitted access) to components of a certified entity's computing system via wireless communication (e.g., near-field communication (NFC)). For example, a client device associated with a user (e.g., the user's smartphone) may have an NFC-enabled chip that can communicate information for authentication requests to a device associated with a certified entity, which may also have an NFC-enabled chip. The information provided may include one or more of the following: the user's secure information, a scope definition defining the access rights to the requested authentication information relating to the user's secure information, and timing constraints on the authentication information.

[0018] A secure information manager can verify and authenticate authentication requests and retrieve authentication information from a blockchain service in response to the request. For example, the secure information manager can send the retrieved authentication information to the computing system of an authorized entity. The authentication information can be an NFT managed by a blockchain service, and the computing system of the authorized entity can include a token wallet belonging to the authorized entity that stores the NFT. In other examples, the authentication information can be any other suitable blockchain-based authentication information and can be stored in any suitable storage location by the computing system of the authorized entity. Exemplary blockchain-backed authentication information can include access tokens managed via the blockchain (e.g., Security Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys managed via the blockchain, etc.

[0019] After authentication credentials are issued to an authorized entity, the authorized entity's computing system can use the credentials to issue data access requests. For example, a data access request containing the issued credentials, the identifier of the authorized entity that issued the request, and user identification information can be sent to a secure information manager. The secure information manager can verify and authenticate the data access request, retrieve scope-limited secure user information in response to the data access request, and return the scope-limited secure user information to the authorized entity's computing system.

[0020] A data access request can define one or more data points of a user's secure information. For example, a user's secure information may be electronic health data segmented based on segments and segment dimensions. A data access request may include specific segment dimensions that define the scope of the requested user's secure information. The secure information manager can retrieve secure user information corresponding to the requested data points included in the data access request. For example, the secure information manager can retrieve secure user information corresponding to a portion of the requested data points included in the data access request. When a data access request includes user data points outside the scope of the authorized entity / provided credentials set, the secure information manager may retrieve only the portion of the user data points covered by the scope of the set.

[0021] A certified entity can include any suitable entity that performs services for a user, such as home services (e.g., home construction, repair, etc.), automotive services (e.g., repairing a user's car), medical services (e.g., medical services related to a doctor's office, hospital, emergency room, first responder, etc.), financial services (e.g., accounting, trust services, financial advice, etc.), or technical services (e.g., system administrator services, web hosting, etc.). In one example, the user's secure information could be an electronic health record, and the certified entity could be a healthcare provider requesting access to the user's electronic health record. In this example, the healthcare provider can scan the user's portable access point (e.g., via the user's wireless device) and / or communicate with the user's portable access point (e.g., via NFC communication with the user's wireless device). The healthcare provider can then request authentication credentials from the secure information manager and the blockchain service. Once the authentication credentials request from the healthcare provider is authenticated and verified, the blockchain service can issue authentication credentials to the healthcare provider, granting the certified entity limited access to the user's electronic health record.

[0022] A user can define the type of credentials they issue to a healthcare provider via their application running on their wireless device. For example, a user can choose one of three types of credentials: a first (e.g., extinct credentials), a second (e.g., episodic credentials), and / or a third (e.g., persistent credentials), and the application can display a version of the user's portable access point corresponding to the selection. The version of the user's portable access point can encode the type of credentials selected by the user to the healthcare provider. The healthcare provider can scan the portable access point and issue an credentials request, which includes the type of credentials selected by the user to the healthcare provider. In another example, the user selection can be stored by the portable access point (e.g., a software component), and the healthcare provider can communicate with the portable access point / user's wireless device via NFC to generate / issue credentials requests.

[0023] Users can also use an application to define access rights to authentication information requested via scanning the portable access point and / or wireless communication with the portable access point / user's wireless device. For example, a user can choose secure user information data points, segments of data points, segment dimension values ​​used to group data points, or any other appropriate definition for segmenting the user's secure information. The user's portable access point version can encode the user-defined access rights to authentication information for the healthcare provider. The healthcare provider can scan the portable access point and issue authentication request, which includes the access rights defined by the user for the healthcare provider. In another example, the user-defined access rights can be stored by the portable access point (e.g., a software component), and the healthcare provider can communicate with the portable access point / user's wireless device via NFC to generate / issue authentication requests.

[0024] The blockchain service and / or secure information manager can then issue blockchain-backed credentials to the healthcare provider, corresponding to the user-selected credential type and / or including user-defined access permissions. Upon receiving the issued credentials, the healthcare provider's computing system can issue a data access request to the secure information manager to access the user's electronic health records. To grant access, the secure information manager can authenticate the credentials via a smart contract call to the blockchain service. Once the credentials are authenticated, the secure information manager can grant the healthcare provider's system limited access to the user's electronic health records, such as access restricted to the permissions assigned to the credentials.

[0025] Access by healthcare providers using authentication credentials issued to them can be logged. For example, a blockchain service can log a user's access history to their electronic health records across one or more private blockchains. Through these private blockchains that store the logs, healthcare providers' access to electronic health records can be audited.

[0026] Herein, we refer in detail to embodiments of the present disclosure, which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are given in order to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure can be put into practice without these specific details. In other instances, well-known methods, procedures, components, and circuits are not described in detail so as not to unnecessarily obscure the aspects of the embodiments. Wherever possible, similar reference numerals are used for similar elements.

[0027] Figure 1 illustrates a system for granting limited access to a user's secure information using a non-fungible token according to an exemplary embodiment. Figure 100 includes a user 102, an authorized entity 104, an authenticator and data controller 106, an authentication information service 108, and a secure data store 120. The authorized entity 104 can issue a request to the authenticator and verifier 106 for access to the user's secure information stored in the secure data store 108. The authorized entity 104 can be any appropriate person, group of people, institution or company that undergoes the authorization workflow.

[0028] The certified entity 104 includes a computing system associated with the certified entity. For example, an application on the computing system may authorize the registered identity of the certified entity 104 to log in to the application. The certified entity 104 and one or more registered identities of the certified entity can be registered with the authenticator and data controller 106. For example, the authenticator and data controller 106 may be part of a secure information manager that manages access to the secure data store 110.

[0029] User 102 may be in the same location (at the same physical location) as the computing system of the certified entity 104. For example, the computing system may obtain user information from user 102 by scanning user 102's portable access point. The portable access point may be a visual access point for user 102's secure information. For example, the portable access point may include a depiction of user 102, such as a facial image, as well as encoded information such as a QR code®, barcode, a series of symbols (e.g., alphanumeric characters, hexadecimal, etc.), and any other appropriate encoded information. The encoded information may represent user 102's identification information, a range definition corresponding to user 102's secure information, a time limit for user 102's access to the secure information, and other appropriate information.

[0030] The authorized entity 104 can scan user 102's portable access point to generate authentication information requests for accessing the user's secure information stored in the secure data store 110. For example, user 102 and authorized entity 104 (e.g., the authorized entity's computing system) may be in the same location, and the user's portable access point may be carried by user 102 (e.g., accessible via the user's wireless device). In other examples, user 102 and authorized entity 104 may be located far apart from each other.

[0031] When user 102's portable access point is scanned, the computing system of the certified entity 104 can issue an authentication request to the authenticator and data controller 106 for authentication credentials that will grant access to the user's secure information stored in the secure data store 110. For example, the authentication request may include user identification information obtained from scanning the user's portable access point. The authenticator and data controller 106 can authenticate that the authentication request is being issued via scanning user 102's portable access point. For example, embedded information from the portable access point may be included in the request and authenticated by the authenticator and data controller 106. The authenticator and data controller 106 can also authenticate that the requesting system corresponds to a certified entity, such as certified entity 104.

[0032] The authentication information request may also include a scope definition of the scope of the requested access (to the user's secure information). For example, embedded information from a portable access point may include these scope definitions. After authenticating the authentication information request, the authenticator and data controller 106 may request authentication information from the authentication information service 108. The requested authentication information can be assigned access rights corresponding to the scope definitions provided in the authentication information request. The authentication information service 108 may issue authentication information to the certified entity 104, such as authentication information backed by a private blockchain managed by the authentication information service 108. The private blockchain can record the issuance of authentication information to the certified entity 104 (e.g., an identifier representing the certified entity 104). The authenticator and data controller 106 can receive authentication information from the authentication information service 108 and provide the authentication information to the certified entity 104.

[0033] After receiving authentication information, the system of the authorized entity 104 can issue a data access request to the authenticator and data controller 106 to access the secure information of user 102 stored in the secure data store 110. For example, the data access request may include the issued authentication information, the user 102's identification information (e.g., obtained via a portable access point, or any other appropriate identification information), and the identifier of the authorized entity 104.

[0034] The authenticator and data controller 106 can authenticate the authentication information contained in the data access request and verify the user's identity. For example, the authenticator and data controller 106 can authenticate that the data access request corresponds to one or more pieces of authentication information issued to the authorized entity 104. The authenticator and data controller 106 can verify the authentication information via the authentication information service 108. For example, the authentication information service 108 may include a private blockchain service that manages permissions for access to authentication information associated with user 102 and secure information of user 102 stored in the secure data store 110. The authenticator and data controller 106 can issue one or more application programming interface (API) calls (e.g., smart contract calls) to the authentication information service 108.

[0035] In response to these API calls, the credential information service 108 can authenticate that the provided credential information is assigned to an authorized entity 104 and corresponds to a defined range of permissions for user 102's secure information. A private blockchain managed by the credential information service 108 may include a tamper-proof ledger that records information about the assigned credential information. For example, the private blockchain may record the identification information of a user (e.g., user 102) whose secure information is scoped by a given credential, the range definition corresponding to the given credential, the entity to which the given credential is assigned, and changes to the entity assignment of the given credential.

[0036] The authentication information service 108 can authenticate the provided authentication information against the private blockchain to confirm that the authorized entity 104 has been assigned the authentication information. The authentication information service 108 can also provide the authenticator and data controller 106 with a range definition recorded on the private blockchain that corresponds to the authentication information provided in the data access request. For example, the range definition may define the portion of the user's secure information that the provided authentication information and the authorized entity 104 are authorized to access.

[0037] The authenticator and data controller 106 can also verify that the user's identification information from a data access request corresponds to a registered person who has secure information stored in the secure data store 108. For example, a user can register with the authenticator and data controller 106, and the registered user's secure information may be stored in the secure data store 110. An application service can provide a portable access point for the registered user, and as a result, an authorized entity 104 can scan the portable access point to request access to the registered user's secure information stored in the secure data store 110.

[0038] In response to the authentication of the provided credentials and the authentication of the authorized entity 104 and the verification of the user's identity, the authenticator and data controller 106 may grant the authorized entity 104 limited scope and time access to the user's secure information stored in the secure data store 110. For example, the scope and time limitations may be controlled by the scope permission granted to the provided credentials. The scope of the user's secure information may be limited to the relationship between the authorized entity 104 and the user 102, or to other appropriate characteristics of the authorized entity 104. In another example, access may be limited to a certain duration (e.g., several days, several weeks, several months), after which the authenticator and data controller 106 will no longer grant access to the authorized entity 104 unless another request containing credentials to be authenticated via the credentials service 108 is issued.

[0039] Figure 2 is a block diagram of a computer server / system 210 according to an embodiment. As shown in Figure 2, the system 210 may include a bus device 212 and / or other communication mechanisms configured to communicate information between various components of the system 210, such as a processor 222 and memory 214. In addition, a communication device 220 may enable connectivity between the processor 222 and other devices by encoding data to be sent from the processor 222 to another device over a network (not shown) and decoding data received from another system over the network for the processor 222.

[0040] For example, the communication device 220 may include a network interface card configured to provide wireless network communication. Various wireless communication techniques may be used, including infrared, radio, Bluetooth®, Wi-Fi®, and / or cellular communication. Alternatively, the communication device 220 may be configured to provide a wired network connection, such as an Ethernet® connection.

[0041] The processor 222 may include one or more general-purpose or dedicated processors for performing calculations and controlling the functions of the system 210. The processor 222 may include a single integrated circuit, such as a microprocessing device, or it may include multiple integrated circuit devices and / or circuit boards that work together to achieve the functions of the processor 222. In addition, the processor 222 may run computer programs, such as an operating system 215, a motion prediction component 216, and other applications 218, which are stored in memory 214.

[0042] System 210 may include memory 214 for storing information and instructions for execution by processor 222. Memory 214 may contain various components for retrieving, presenting, modifying, and storing data. For example, memory 214 may store software modules that provide functionality when executed by processor 222. The modules may include an operating system 215 that provides the operating system functionality of system 210. The modules may include the operating system 215, a data access manager 216, and other application modules 218. The operating system 215 provides the operating system functionality of system 210. The data access manager 216 may provide system functionality for granting authorized entities limited access to a user's secure information, or it may further provide any other functionality of this disclosure. In some cases, the data access manager 216 may be implemented as an in-memory configuration.

[0043] The non-temporary memory 214 may include various computer-readable media that can be accessed by the processor 222. For example, the memory 214 may include any combination of random access memory ("RAM"), dynamic RAM ("DRAM"), static RAM ("SRAM"), read-only memory ("ROM"), flash memory, cache memory, and / or any other type of non-temporary computer-readable media.

[0044] The processor 222 is further coupled to a display 224, such as a liquid crystal display ("LCD"), via a bus 212. A cursor control device 228, such as a keyboard 226 and a computer mouse, is further coupled to a communication device 212 to allow the user to interface with the system 210.

[0045] In some embodiments, system 210 can be part of a larger system. Therefore, system 210 may include one or more additional functional modules 218 to include additional functionality. Other application modules 218 may include, for example, Oracle® Data Integrator, Oracle® Cloud Infrastructure, Oracle® Autonomous Database, Oracle® Cerner®, Oracle® Cerner® Millennium, Oracle® Cerner® HealththeIntent, Oracle® Cerner® Seamless Exchange, Oracle® Cerner® HealththeCare, Oracle® Blockchain and Oracle® Cerner® HealththeLife and representative products across the Oracle® Health & Artificial Intelligence platform. Database 217 is coupled to bus 212 to provide centralized storage for modules 216 and 218, storing, for example, verification information for registered persons, certified entity information, authentication and verification-related information, etc. Database 217 can store data in an integrated collection of logically related records or files. Database 217 can be an operational database, analytical database, data warehouse, distributed database, end-user database, external database, navigational database, in-memory database, document-oriented database, real-time database, relational database, object-oriented database, Hadoop Distributed File System ("HFDS"), disaster recovery database, backup database, or any other database known in the industry.

[0046] Although presented as a single system, the functions of system 210 may be implemented as a distributed system. For example, memory 214 and processor 222 may be distributed across multiple different computers that collectively represent system 210. In one embodiment, system 210 may be part of a device (e.g., a smartphone, tablet, or computer).

[0047] In one embodiment, system 210 may be separate from the device and may remotely provide the described functions of the device. Furthermore, one or more components of system 210 may be omitted. For example, to function as a user or consumer device, system 210 may include a processor, memory, and a display, but may not include one or more of the other components shown in Figure 2, and may include additional components not shown in Figure 2, such as a smartphone or other wireless device.

[0048] Users can perform a registration workflow for secure information management. For example, a user can register with the secure information manager. Registered users can share their secure information via a portable access point that grants authorized entities limited access to the registered user's secure information. Figure 3 shows a system for registering users for secure information management according to an exemplary embodiment.

[0049] Figure 300 includes a user system 302, an application server 304, a broker 306, and a secure information service 308. The user system 302 can be any suitable user client device, such as a smartphone, laptop, or tablet. The application server 304 can be any suitable computing device that hosts applications, such as applications displayed to the user via the user system 302. The applications can be web applications, native applications, any combination thereof, or any other suitable applications.

[0050] Users can interact with the application to register an account via the user system 302. By creating a registered account, the user authorizes the secure information service 308 to store and manage the user's secure information. For example, registration can constitute a user account linked to the user, as well as the user's secure information to be stored and managed by the secure information service 308.

[0051] The user system 302 can interact with the application server 304 and / or the broker 306 to carry out the registration workflow. For example, the application server 304 and / or the broker 306 can be separated from the secure information service 308 in some embodiments. User registration through a separate third-party entity (e.g., the application server 304 and / or the broker 306) can increase the level of integrity and reliability of the registration workflow.

[0052] User secure information may include electronic health records. In this example, the third-party entity could be a government entity, a non-profit entity, a coalition entity consisting of several individual entities, or any other suitable entity that links electronic health records to users and supports the secure storage of such electronic health records by Secure Information Service 308, supporting transparent and reliable registration. In these examples, the third-party entity can act as an intermediary to verify the user's identity, the scope of the user's electronic health records stored by Secure Information Service 308, and any other suitable aspects of the user's identity and secure information. The third-party entity can also support connections between multiple different Secure Information Services to ensure that the user's electronic health records are available for user examinations and available to the user's healthcare providers.

[0053] The application server 304 can generate a unique link or registration code for each user (for example, delivered to the user system 302). Using the unique link or code, the user can access applications hosted by the application server 304 via the user system 302 and perform the registration workflow. The user system 302 can receive a public key for registering the user's account. The registration workflow may include the user generating a private key. For example, the private key can be used to manage the user's account and secure information. Any other appropriate authentication information (e.g., username and password, two-factor authentication address, shared secret, etc.) can be issued to the user.

[0054] The registration workflow may include providing user identification information such as first name, middle name, last name, date of birth, home address, telephone number, photograph (e.g., facial image), work history, city of birth, social security number, user identifier for one or more electronic health records (e.g., master patient index identifier), social gender, social gender identity, ethnicity, and other appropriate user information. Users may also provide their biometric information (e.g., thumbprint, eye scan) via a biometric scanner to improve the security measures and reliability of the registration workflow and the management of user secure information.

[0055] Broker 306 can verify user identification information and link registered accounts created for the user to the user's verified entities. For example, Broker 306 can verify that a registered account is authorized to store the electronic health records of a person verified as the user identity. This verification can prevent malicious attempts to access another person's secure information.

[0056] Once the application server 304 and / or broker 306 have performed the first part of the registration workflow (e.g., receiving user identification information and verifying the user's identity), the secure information service 308 can generate the user's account components. The account components may include one or more portable access points for the user's secure information, user relationship definitions (e.g., defined relationships with other registered users or individuals), and any other appropriate account components.

[0057] The secure information service 308 can aggregate user secure information as part of (or after) the registration workflow. For example, the secure information service 308 can retrieve, acquire, or otherwise aggregate secure information that the user has authorized the secure information service 308 to manage, such as the user's electronic health record.

[0058] A user's registered account can correspond to one or more portable access points. For example, a portable access point may include a visual representation of the user (e.g., an image) and encoded information relating to the user's secure information, such as a scope definition for sharing the user's secure information. Figure 5A shows a portable access point according to an embodiment. In another example, the portable access point may be a software access point that provides the user's secure information (e.g., a scope definition for sharing the user's secure information) to components of a certified entity's computing system via NFC or the like.

[0059] Once the registration workflow is complete, the user can log in to the generated account via the user system 302 and the application server 304. The application can allow the user to define the scope for sharing their secure information via the generated portable access point. For example, the user can select one or more data points of their secure information, one or more default secure information data profiles, or define the scope for sharing their secure information in any other appropriate format.

[0060] The application can generate a portable access point corresponding to a defined scope and display the portable access point in the user system 302. A computing system for an external entity, such as an authorized entity, can scan the portable access point and configure access to the user's secure information according to the defined scope. In another example, the application can store the defined scope in the portable access point / user system 302. A computing system for an authorized entity can communicate with the portable access point (e.g., via NFC) to configure access to the user's secure information according to the defined scope. Figures 4A, 4B, and 4C show a system having a secure information manager that allows scope-restricted access to the user's secure information using non-fungible tokens according to an exemplary embodiment.

[0061] Figure 400A includes a source 402, a requesting system 404, a secure information manager 406, secure user information 408, a scanning module 410, a requester 412, a blockchain manager 414, a blockchain 416, and a smart contract 418. The requesting system 404 can be a system of certified entities, such as entities that have performed a certified workflow by the secure information manager 406. The source 402 may include sources of user information, such as the user's physical body, user identification documents (e.g., driver's license, passport, etc.), the user's wireless device (e.g., smartphone), the user's portable access point, and other appropriate sources of user information.

[0062] The requesting system 404 can obtain user information from the source 402. For example, the scanning module 410 of the requesting system 404 can scan the user's portable access point. The user's portable access point can be displayed via the user's wireless device. For example, an application running on the user's wireless device (e.g., a native application, a web application, etc.) may allow the user to configure the portable access point to share the user's secure information. Figure 5A shows a definition of the portable access point and the scope limitation of the portable access point via an application according to an embodiment. The user's portable access point can be displayed by the user's wireless device on the lock screen (e.g., before entering a password), in the background of the wireless device, as a stored image in the wireless device's photo library, or via any other suitable display means.

[0063] The scanning module 410 can be a dedicated device configured to scan a requesting portable access point and obtain user identification information for the request, such as a wireless device running an application configured to decode the portable access point and include an image capture component (e.g., a camera). The scanning module 410 can obtain user identification information from any other suitable element of source 402. For example, the user's portable access point can be a software element, and the scanning module 410 can communicate with the user's portable access point / user's wireless device.

[0064] Source 402 may include a person's wireless device that includes a predetermined relationship with the user. For example, a user may be a registered person whose secure user information 408 is managed by the secure information manager 406. The user may also register predetermined relationships with the secure information manager 406, such as personal relationships (e.g., parent, spouse, child, friend, etc.), work relationships (e.g., co-administrator of a corporate application, etc.), or other appropriate relationships.

[0065] A person with a predetermined relationship to the user may possess a wireless device that can provide the user's identification information to the requesting system 404. For example, any appropriate user identification information provided by the user's wireless device (e.g., the user's portable access point) can be provided to the scanning module 410 via the wireless device of the person with a predetermined relationship to the user. The wireless device of the related person is registered with the secure information manager 406 and includes an application that provides user identification information.

[0066] After scanning source 402, the requesting system 404 and requester 412 can issue an authentication request to the secure information manager 406 for one or more access authentication credentials that will grant access to the user's secure information. For example, the requested authentication credentials may be limited to users identified by user identification information (e.g., obtained via source 402). The requested authentication credentials can then grant the requesting system 404 access to the secure information 408 via the secure information manager 406.

[0067] The authentication information request may also include user identification information obtained via the scanning module 412 (e.g., via scanning / communication with the user's portable access point), and any other appropriate information. User identification information may include full name, date of birth, social security number, local address and / or postal code, medical information (e.g., attending physician), biometric information (e.g., fingerprint, eye scan, etc.), identifiers of the user's medical health record (e.g., master patient index identifier, medical record number, insurance claim identifier, etc.), vehicle manufacturer, model, and / or license plate, representation of government-issued identification information (e.g., driver's license photo), and an image of the user's face.

[0068] User identification information can be an identifier (e.g., an alphanumeric string) decoded / obtained from the user's portable access point (e.g., by the scanning module 410), and any other appropriate user identification information obtained by scanning the user's portable access point or communicating with the user's portable access point. An authentication request can include an authentication information type. For example, a user can select an authentication information type (e.g., an authentication information type including a corresponding expiration timer) (via an application running on the user's wireless device), and the application can generate a portable access point that encodes / stores the authentication information type. The scanning module 410 can then decode the authentication information type, and the requester 412 can include the authentication information type in the authentication request.

[0069] In some embodiments, the user may be prompted by the requesting system 404 to enter a username and password, passcode, key, PIN, or any other appropriate secure user code in order for the requesting system 404 and the requester 412 to generate an authentication information request. For example, during a registration workflow, the user may establish a username and password, passcode, key, PIN, etc. An application in the requesting system 404 may be linked to a secure information manager 406, an honest broker, or any other appropriate entity that can verify the user's username and password, passcode, key, PIN, etc. Once the application in the requesting system 404 has confirmed that the secure user code is valid, the application may authorize the requesting system 404 and the requester 412 to generate an authentication information request.

[0070] To approve an authentication credentials request from the requesting system 404, the secure information manager 406 can authenticate that the requesting system 404 contains an authorized entity. For example, an authentication credentials request from requester 412 may include one or more entity credentials issued to an authorized entity associated with the requesting system 404. Entity credentials may include an access token (e.g., Security Assertion Markup Language (SAML), Open Authorization (OAuth), etc.), one or more cryptographic keys, or a signature. The secure information manager 406 can authenticate the entity credentials included in the authentication credentials request and verify the user identification information included in the authentication credentials request. For example, the secure information manager 406 can authenticate that the entity credentials from the request are authenticated as credentials issued to an authorized entity.

[0071] The secure information manager 406 can verify the user identification information provided in the authentication information request. For example, the secure information manager 406 can verify that the authentication information request was generated by scanning / communicating with the user's portable access point. Verification may include comparing an identifier decoded / obtained from the portable access point with a stored identifier for a registered user, verifying that any additional user identification information provided in the request is valid against the stored user identification information for the matched registered user, verifying the type of authentication information included in the authentication information request, and / or any other appropriate verification.

[0072] Once entity authentication information is authenticated and user identification information is verified, the secure information manager 406 can issue a software call to the blockchain manager 414 on behalf of the requesting system 404 (associated with the authenticated entity) to request access authentication information. For example, the blockchain manager 414 can manage authentication information, including access rights to the user's secure information.

[0073] Blockchain manager 414 can manage blockchain 416 for secure information manager 406. For example, access credentials provided to authorized entities (in response to authenticated and verified credential requests) may include credentials managed by blockchain manager 414. Credentials may be linked to a user's secure information and may be assigned varying levels of scope permissions to access the user's secure information. Blockchain 416 may include a blockchain ledger that records credential transactions.

[0074] A blockchain is a list of records, each called a block, which can be linked through cryptography. In some blockchain embodiments, each block contains a timestamp, the hash of the preceding block, and transaction data. The timestamp verifies that the transaction data was present when the block was added to obtain its hash. Each block designates the block that precedes it, so a set of blocks forms a chain, and each new block augments the set of blocks that precede it in the chain. Therefore, a blockchain can be difficult to alter because data, once added to the blockchain, cannot be altered without altering subsequent blocks.

[0075] The credentials managed by the blockchain manager 414 may include blockchain-backed identifiers that specify unique or non-unique items, including access rights to a user's secure information. The assignment or ownership of the credentials can be tracked and verified through a distributed ledger (e.g., a blockchain). The blockchain manager 418 may include smart contracts 418 that manage and run in conjunction with blockchain 416. Blockchain 416 can be a hyperledger blockchain or any other suitable blockchain.

[0076] The blockchain manager 414 can manage multiple different credentials that grant varying levels of access privileges to a user's secure information. For example, to ensure that the credentials are managed by the blockchain manager 414, that the credentials are issued to the authorized entity that submitted the data access request, and / or that the credentials have not expired, a data access request from an authorized entity may be authenticated to the blockchain 416 via the blockchain manager 414 and the smart contract 418. Diagram 400B of Figure 4B includes an exemplary data access request 430 that includes credentials issued by the blockchain manager 414.

[0077] The blockchain manager 414 may include a generating component that generates credentials that grant varying levels of access to a user's secure information. Each generated credential includes a unique or non-unique long string identifier that identifies the credential. The generated credential may include information that links the credential to the secure information of the user to whom access to the credential has been assigned. The generated credential may include any appropriate user identification information described herein. Some exemplary credentials include blockchain-based tokens such as non-fungible tokens, semi-fungible tokens, tokens that can be made into several copies, non-unique tokens, or any other appropriate credentials.

[0078] The blockchain manager 414 can issue one or more credentials to an authorized entity in response to a smart contract call from the secure information manager 406. For example, a first credential (e.g., an expiring credential) may provide access to a user's secure information for a limited duration (e.g., several hours, several days, several weeks, etc.). In this example, once the limited duration expires, the first credential no longer authenticates through the blockchain manager 414 and blockchain 416. A user can define an expiration timer (e.g., via an application loaded on the user's wireless device), and the definition may be included in the user's portable access point. This defined timer may be included in a credential request issued by the requesting system 404 via scanning the user's portable access point and / or communication with the user's portable access point. The secure information manager 406 can then include the defined timer in a smart contract call to the blockchain manager 414.

[0079] In another example, a second set of credentials (e.g., episodic credentials) may provide access to a user's secure information for a predetermined duration (e.g., several hours, several days, several weeks, etc.). In this example, once the predetermined duration has expired, the second set of credentials no longer authenticates through the blockchain manager 414 and blockchain 416. In yet another example, a third set of credentials (e.g., persistent credentials) may provide access to a user's secure information permanently or until the credentials are explicitly revoked.

[0080] For example, a user's secure information could be an electronic health record, and an authorized entity could be a healthcare provider requesting access to the user's electronic health record. In this example, the healthcare provider can scan and / or communicate with the user's portable access point (e.g., via the user's wireless device) and request authentication credentials from the blockchain manager 414. Once the authentication credentials request from the healthcare provider is authenticated and verified, the blockchain manager can issue authentication credentials to the healthcare provider.

[0081] A user can define authentication credentials to issue to a healthcare provider via their application running on their wireless device. For example, a user can select one of a first, second, and / or third set of authentication credentials, and the application can display a version of the user's portable access point corresponding to the selection. The version of the user's portable access point can encode the authentication credentials selected by the user for the healthcare provider. The healthcare provider can scan the portable access point and issue an authentication request, which includes the authentication credentials selected by the user for the healthcare provider. In another example, the user's portable access point can be a software element, and the healthcare provider's system can communicate with the portable access point / user's wireless device (e.g., via NFC) to issue an authentication request.

[0082] In this example, the user may choose a first set of credentials (and define a timer) when the user anticipates that a healthcare provider will need limited access to the user's electronic health record for a short period, such as when the user visits an emergency medical facility. In another example, the user may choose a second set of credentials when the user anticipates that a healthcare provider will need access to the user's electronic health record for a moderate period, such as during surgery at a hospital the user does not frequently visit, or during a specialist appointment the user anticipates will not return to. In yet another example, the user may choose a third set of credentials when the user anticipates that a healthcare provider will need access to the user's electronic health record for a long period or an indefinite period, such as when the healthcare provider is the user's primary care physician or a specialist designated for a long-term health problem.

[0083] The above example describes a certified entity that is a healthcare provider, but the certified entity could be another individual, such as an individual with a predetermined relationship to the user that has been previously verified by the user (e.g., a family member, a close friend, etc.). The individual with the predetermined relationship may include a separate account connected to the user's account once the predetermined relationship is verified. In this example, the user may select a third set of credentials to ensure that the individual retains access to the user's electronic health records. After the secure information manager 406 issues one or more smart contract calls, the blockchain manager 414 may issue one or more sets of credentials to the certified entity based on the smart contract calls.

[0084] The blockchain manager 414 can generate authentication credentials on request and / or store multiple pre-generated authentication credentials related to a user. For example, authentication credentials may be generated on request in response to an authentication request that includes user identification information, scope permissions corresponding to the authentication request, timing constraints and / or authentication credentials versions (e.g., extinct, episodic, and / or persistent), or any other appropriate information from the authentication request. The generated authentication credentials may then be assigned to an authorized entity identifier from the authentication request, and this assignment may be recorded in the blockchain 416. Authentication credentials generated on request may be created to match specific parameters of the authentication request. For example, an authentication request may be generated in response to user selection and / or scanning of a user's portable access point in an information management application.

[0085] In another example, the blockchain manager 414 can assign pre-generated credentials to entities identified in a credential request. For example, pre-generated credentials may include predetermined scope privileges, correspond to specific credential versions (e.g., extinct, episodic, and / or persistent), include user identification information linking the credentials to a user, and / or include any other appropriate information. The blockchain manager 414 can pre-generate multiple credentials for a given user, each having different combinations of parameters. For example, multiple credentials for each credential version (e.g., extinct, episodic, and / or persistent) can be pre-generated, where different predetermined scope privileges can be assigned to the multiple credentials for a given credential version. Since pre-generated credentials are not tailored to the details of a given credential request, many different versions of pre-generated credentials can correspond to many different credential requests.

[0086] For example, different predefined scope permissions could correspond to different scope templates defined by the user for the user's secure information (e.g., a predetermined grouping or segmentation of the user's electronic health data), different templates based on feedback from certified entities regarding which parts of the user's secure information the entity needs, a global scope granting broad access to the user's secure information, or any other appropriate predefined scope permission. The secure information manager 406 and / or blockchain manager 414 can match these pre-generated credentials with credential requests and assign matching pre-generated credentials to the certified entities identified in the credential requests.

[0087] The pre-generated authentication credentials may also include a blank set of range permissions, and the secure information manager 406 can, upon request, assign range permissions to authentication credentials that match the authentication credentials request. Thus, the pre-generated authentication credentials can be matched against the authentication credentials request using the authentication credentials version, and matching authentication credentials may be assigned range permissions that are specifically tailored to the authentication credentials request. The secure information manager 406 can communicate the permission assignment to the blockchain manager 414, and the blockchain manager 414 can append the permission assignment to the blockchain 416.

[0088] Several authentication information requests from the requesting system 404 may be generated by scanning and / or communicating with the user's portable access point, such as a portable access point controlled by an information management application on the user's wireless device. The information management application can generate portable access points corresponding to pre-generated authentication information. For example, the information management application may present the user with a limited set of range restrictions and / or a limited set of timing constraints (e.g., authentication information versions), where each combination of range restrictions and timing constraints corresponds to one of the pre-generated authentication information in the blockchain manager 414. In this example, the secure information manager 406 and / or the blockchain manager 414 can match each authentication information request against the pre-generated authentication information corresponding to the authentication information request.

[0089] Upon receiving a user selection and displaying the user's portable access point, the information management application on the user's wireless device may also provide the Secure Information Manager 406 with indicators that identify a specific portable access point (e.g., a particular combination of range and timing constraints) and the point in time when the portable access point was displayed. The Secure Information Manager 406 and / or Blockchain Manager 414 can then generate credentials corresponding to the portable access point definition on request and / or select pre-generated credentials that match the portable access point definition. In this example, the Secure Information Manager 406 has already selected credentials for the portable access point definition before receiving the credentials request from the requesting system 404. Once the credentials request is received, the selected credentials can simply be assigned to the authorized entity identified in the credentials request.

[0090] In this example, any misuse of this version of the user's portable access point at a later point in time can be traced back to the time this version of the user's portable access point was first displayed, and to the authorized entity that scanned this version of the user's portable access point (and subsequently requested credentials using information decrypted from this version of the user's portable access point). Such a misuse attempt could exploit a still image of the user's portable access point. A misuser could take a photograph of the user's portable access point and use that photograph to later attempt to request credentials that would provide access to the user's secure information. The version of the user's portable access point can identify the time when the portable access point was scanned and the authorized entity, allowing for the tracking and holding of the misuser accountable.

[0091] In another example, the requesting system 404 may be a user's wireless device, while the source information 402 may relate to a certified entity. The certified entity may display the source information 402 via any suitable display means such as a computing system (e.g., a wireless device, computer monitor, television, etc.), printed on a physical item (e.g., paper, wood, cardboard, etc.), or via any other suitable display. The source information 402 may include an access point of the certified entity, such as a QR code or other suitable visual code related to the certified entity. The access point of the certified entity may be similar to a user's portable access point, such as the portable access point disclosed in Figure 5A.

[0092] In this example, the access point of the certified entity may contain encoded information about the certified entity, and the user's wireless device, as the requesting system 404, can scan the certified entity's portable access point to decrypt the information. An information management application on the user's wireless device, which the user interacts with to select the scope of the requested credentials, the timing of the requested credentials, and / or the version of the credentials, can be configured to decrypt the certified entity's portable access point. For example, the information management application can act as a scanning module 410. The encoded information of the certified entity may include an identifier that identifies the certified entity to the secure information manager 406, encoded information representing identity credentials issued to the certified entity (e.g., a signature using an encryption key), or other appropriate certified entity identification information. Using the certified entity information decrypted from the certified entity's access point, the user's wireless device can generate a credential request and send the credential request to the secure information manager 406.

[0093] For example, an authentication request generated by a user's wireless device as the requesting system 404 may include user identification information (e.g., stored on the user's wireless device), scope definition information for the requested authentication information (e.g., selected via an information management application), timing and / or version of the requested authentication information (e.g., selected via an information management application), certified entity identification information decoded from the entity's access point, and other appropriate authentication request information.

[0094] In response to an authentication request from a user's wireless device, the secure information manager 406 can provide access authentication information corresponding to the authentication request to the system of the authorized entity. For example, through interaction with the blockchain manager 414, the secure information manager 406 can provide authentication information with scope authorization corresponding to the authentication request.

[0095] The blockchain manager 414 can generate credentials in response to a credential request from a user's wireless device, and these generated credentials can be provided to the computing system of an authorized entity. In another example, the blockchain manager 414 may include existing credentials, and the blockchain manager 414 (and / or secure information manager 406) can configure these existing credentials in response to a credential request. Configuring existing credentials may include one or more of the following: assigning the existing credentials to an authorized entity (e.g., the authorized entity's token wallet), or assigning scope permissions to the existing credentials corresponding to a credential request.

[0096] Using the authentication credentials issued to the authorized entity's computing system via the user's wireless device authentication credentials request as the requesting system 404, the authorized entity's computing system can issue one or more data access requests to the secure information manager 406. For example, a data access request may include the scope of the user secure information being requested, the authentication credentials to be issued, and / or any other appropriate information.

[0097] When the requesting system 404 receives authentication information issued via the blockchain manager 414, the requesting system 404 can issue a data request to the secure information manager 406 requesting access to the user's secure information using the issued authentication information. Diagram 400B includes the requesting system 404, the secure information manager 406, secure user information 408, the blockchain manager 414, the blockchain 416, the smart contract 418, the audit log 424, the transaction log 426, the access request 430, and the authentication information 432. Similar to Diagram 400A, an embodiment of the requesting system 404 can be a system of certified entities, such as entities that have performed a certification workflow by the secure information manager 406.

[0098] The requesting system 404 may issue an access request 430 containing authentication credentials 432, which may be one or more authentication credentials issued to the requesting system 404 (and authorized entities) by the blockchain manager 414. The access request 430 may include identification information obtained through scanning and / or communication with the user's portable access point, as well as / or user identification information such as the user's full name, date of birth, social security number, local address and / or postal code, medical information (e.g., primary care physician), biometric information (e.g., fingerprints, eye scans, etc.), identifiers of the user's medical health record (e.g., master patient index identifier, medical record number, insurance claim identifier, etc.), vehicle manufacturer, model and / or license plate, representation of government-issued identification information (e.g., driver's license photo), and an image of the user's face.

[0099] When an access request 430 is received by the secure information manager 406, the authentication information authenticator 420 can authenticate the authentication information 432 via one or more smart contracts 418 of the blockchain manager 418. The secure information manager 406 can also verify the user's identity against registered users to confirm that the request identifies a user that matches the authentication information for which it was issued. Once the authentication information 432 is authenticated and the user's identity is verified, the data access controller 422 can issue one or more queries to secure the user information 408 in order to retrieve secure user information with a limited scope.

[0100] The secure information manager 408 can log requests, restricted-scope information accessed through the requests, timestamps, and other appropriate data related to the access request 430 and the restricted-scope secure user information accessed. The secure information manager 408 may include application logs and / or audit logs. For example, an application log may log application transactions and activities that grant restricted-scope access in response to data access requests (e.g., access request 430). An audit log may log similar data to the application log, for example, to support audits such as user audits.

[0101] User access to secure information can be logged in any appropriate data structure. The blockchain manager 414 can also store audit logs in a blockchain data structure to support auditing. For example, the secure information manager 408 can invoke one or more smart contracts 418 to write log information to the audit log 424. Each instance of a user's request for and / or authorized access to secure information can be logged as a block on the blockchain. The blockchain manager 414 can also store application logs within the blockchain data structure.

[0102] The Secure Information Manager 408 and / or Blockchain Manager 414 may provide a portion of the log in response to an audit request. A user (or any other appropriate entity or person) may be permitted to audit the user's access to Secure Information. Logged information, including the request, the scope of information accessed through the request, the timestamp, and other appropriate data related to the received request and scope of data, may be provided to the user or other appropriate auditing entity.

[0103] Figure 4C's diagram 400C includes the requesting system 404, the secure information manager 406, the secure user information 408, the access request 430, the authentication information 432, the data query 434, the user information 436, the scope-restricted user information 438, and the restricted user information 440. Similar to diagrams 400A and 400B, the requesting system 404 can be a system of certified entities, such as entities that have performed a certified workflow by the secure information manager 406.

[0104] Access requests 430 and authentication information 432 can be authenticated and verified via the secure information manager 406. Data queries 434 can be issued to retrieve scope-restricted secure user information, such as user information corresponding to the scope permissions of authentication information 432. Secure user information 408 may contain secure information for multiple registered individuals, and user information 436 may represent stored secure information for users verified against the identification information contained in access requests 430 and / or users linked to authentication information 432. The secure information manager 406 can structure data queries 434 to retrieve portions of user information 436.

[0105] User information 436 may include a set of user data points, and scope-restricted user information 438 may include a subset of data points. In an example where secure user information 408 includes electronic health records and user health data, the set of data points in user information 438 may include an aggregation of the user's electronic health record data, and the subset of data points in scope-restricted user information 438 may include a portion of the aggregated electronic health data, such as components of the aggregated electronic health record data, a predetermined subset of the electronic health record (defined, for example, by the user, the secure information manager 406, etc.), or metadata and / or summary data covering any other appropriate subset of the data.

[0106] For example, scope-restricted user information 438 may be a predetermined health data point designated by the user as accessible by any appropriate authorized entity, including authenticated credentials. In another example, scope-restricted user information 438 may include health data points based on a predetermined template, such as data points coordinated for patient registration. Exemplary scope-restricted user information 438 may include the user's blood type, medical history, previous surgical history, allergies, medications currently being taken, or any other appropriate user health data.

[0107] User information 436 may be a segmented health record, and the data points included by the scope-limited user information 436 can be any appropriate segment of the segmented health record. For example, user information 436 may be electronic health data segmented based on segments and segment dimensional values. Exemplary segments may include the issuing physician and / or healthcare institution (e.g., entity identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), images (e.g., radiographs, X-rays, ultrasound images, MRI images, etc.), date and time of information generation, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. In some embodiments, segments may include structured and unstructured data. The user can define which parts of their electronic health data are shared via their portable access point by providing a parameter value that defines a range (e.g., a segment dimension value). In this case, the permissions for the authentication information 432 can be defined based on the user-defined segment dimension value, and the secure information manager 406 can restrict data queries 434 based on the permissions for the authentication information 432.

[0108] In response to an authenticated and verified access request 430, the secure information manager 406 may issue a data query 434 to secure user information 408. The secure information manager 406 may then receive restricted user information 440, which may be limited in scope based on the scope privileges defined for the authentication information 432. The data query 434 may be generated in response to the data requested by the access request 430, and the secure information manager 406 may then limit the data query 434 based on the privileges of the authentication information 432. In another example, the data requested by the access request 430 may be limited in scope according to the privileges of the authentication information 432, and the data query 434 may be generated to retrieve the limited-scope data. The restricted user information 440 may then be provided to the requesting system 404.

[0109] Role-based access control can also be applied to secure user information 408 to limit and restrict the functionality and scope of information for authentication credentials 432 and identities associated with authentication credentials (e.g., users, authorized entities, registered users of authorized entities, etc.). Each identity associated with authentication credentials 432 can correspond to a role in the context of role-based access control. For example, an administrator role may have full permission to view all information and perform all tasks, while a general clerk role may only be able to view limited information about a particular consumer or patient, in which case attributes of protected medical information (PHI) or personally identifiable information (PII) would be hidden from that individual. Role-based access control can also be applied to data queries 434 so that restricted user information 440 can be retrieved by the query. In another example, a childcare role (e.g., teacher, public health officer, childcare worker, nurse, etc.) may be able to read selective segments of secure information about children, such as vaccination information regarding a limited number of vaccines that allow a child to participate in certain activities or institutions (e.g., enrollment in school).

[0110] Role-based access control can be applied to one or more registered identities of an accredited entity. For example, an accredited entity may be an institution, and a registered identity may be a person who is a member of that institution. In some embodiments, the accredited entity may be a hospital, emergency room institution, or first-responder institution, and the registered identity may be an emergency room staff member and / or paramedic. Other suitable accredited entities include schools, daycare centers, public health or government-related institutions, pharmacies, emergency medical facilities, clinics, same-day clinics, free clinics, surgical centers, event organizers, academic societies, and shelters.

[0111] Request 430 may be issued by the registered identity of the authorized entity. For example, Request 430 may include indicators of the authorized and registered entities, such as credentials 432 that identify the registered identity and the authorized entity when authenticated. Any other appropriate indicators may be included in Request 430.

[0112] The restricted user information 440 may be scope-defined for a registered identity associated with the authenticated identity that issued the request, and / or for the authentication information 432 of the authenticated entity or registered identity. For example, the registered identity of an emergency medical technician may not provide the same level of care as an emergency room provider, and therefore different levels of information may be required depending on the circumstances of the care. Thus, a request from the registered identity of an emergency medical technician may correspond to a first version of the restricted user information 440, while a request from an emergency room personnel may correspond to a second version of the restricted user information 440, the first version being different from the second version. For example, the second version may include data points relevant to a particular level and care activities not included in the first version.

[0113] The requesting system 404 can issue multiple requests over time to access the user's secure information using the authentication credentials 432. For example, as long as the authentication credentials 432 have not expired and / or been revoked, the secure information manager 406 can authenticate the credentials and grant access to the user's secure information (limited to the scope of the permissions of the authentication credentials 432).

[0114] A user can edit the permissions assigned to credentials 432 via an application running on the user's wireless device. For example, the application may link to a secure information manager 406, and the user can edit data points, secure user information segments, and / or segment dimension values ​​that group the secure user information that credentials 432 is authorized to access. These edits can be stored in the secure information manager 406 and / or provided to the blockchain service via a software call. The blockchain service can add permission edits to the blockchain ledger that defines the access permissions for credentials 432. Edits may include revoking the access permissions assigned to credentials 432. If credentials 432 expires or the access permissions for credentials are revoked, the requesting system 404 may send the credentials back to the blockchain service that issued them, for example, to be assigned to the same or another authorized entity.

[0115] Secure user information 408 and user information 436 can be stored by aggregating secure user information of a user from multiple sources. For example, a user's secure information may be received and ingested so that the information is stored according to the data format of secure user information 408. Once ingested, user information 436 can be accessed by an authorized entity via a data access request that includes appropriate authentication information 432.

[0116] Figure 4D, diagram 400D, includes a secure information manager 406, secure user information 408, user information 436, an ingestion manager 450, a data tagger 452, a tag extractor 454, a data converter 456, a data write controller 458, and a data source 460. Similar to diagrams 400A, 400B, and 400C, the secure information manager 406 can manage the secure user information 408 and user information 436. The ingestion manager 450 can receive / retrieve secure user information from the source 460, ingest the retrieved / received secure user information, and store the ingested secure user information in the secure user information 408.

[0117] Source 460 can be any suitable source for storing secure user information. In an example where the secure user information includes electronic health records, Source 460 may include a hospital data system, an electronic health record data system, a master patient index system, a computing system associated with the user, a medical device, a wearable device, and any other suitable source of electronic health records or user health data.

[0118] A user can authorize the secure information manager 408 to store data from one or more of the sources 460. For example, a user can provide permission to aggregate secure user information from various different sources 460 through their information management application. In some embodiments, a user can authorize access to portions of secure user information stored in the sources 460. Illustrative permissions include permission for all (ALL) secure user information stored by the electronic health record system A, restricted permission for [SEGMENT A: VALUES A1-A5; ALL OF SEGMENT C; etc.], all (ALL) secure user information from hospital system A, and permission for hourly data from wearable device A. Wearable device A may detect biometric information from the user, and the user may authorize permission to aggregate portions of this data, such as summary data at an hourly granularity.

[0119] Based on the user's provided permissions, the secure information manager 406 can aggregate user information 436 (for example, the secure user information of a particular user) in the secure user information 408. For example, source 460 can be instructed to send the user's secure information to the ingestion manager 450, the ingestion manager 450 may be granted access to retrieve the user's secure information from source 460, the user can perform a portion of the aggregation of the secure user information from source 460 and provide this portion of the secure user information to the ingestion manager 450, and the aggregation can be performed through any other appropriate function or any combination thereof.

[0120] The ingestion manager 450 can retrieve and / or receive secure user information authorized for aggregation (by the user). In some embodiments, the secure user information 408 may include a multidimensional data scheme, such as multiple segment dimensions corresponding to different aspects of the user's secure information. For example, if the secure user information includes an electronic health record, the segment dimensions may correspond to segments of the electronic health record. Exemplary segment dimensions include the issuing or affiliated physician and / or healthcare institution (e.g., entity name or identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), images (e.g., radiographs, X-rays, ultrasound images, MRI images, etc.), date and time of information generation, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. In some embodiments, segments may include structured and unstructured data.

[0121] Each element of Secure User Information 408 (e.g., a data element) may include segment dimensional values ​​that define how the individual data elements are organized within Secure User Information 408. For example, a given data element (e.g., a laboratory report for a medical test) may be tagged with the following segment dimensional values: [Laboratory Name or Hospital Name], 'Test Result', [Name of Relevant Health Practices], [Date of Test Collection / Completion], [Electronic Health Record Format Type], or any other appropriate parameter values ​​for other appropriate electronic health record parameters. Data access requests submitted to Secure Information Manager 406 and / or authentication authorizations assigned by Secure Information Manager 406 can be scope-defined according to these segment definitions and segment dimensional values.

[0122] Secure user information can be received / retrieved by the ingest manager 450 as one or more data elements (e.g., individual secure user information fragments). The ingest manager 450 can perform one or more of the following functions on the received data elements: tagging the secure user information using segment dimension values ​​spanning the multidimensional data scheme of the secure user information 408; deriving one or more of the segment dimension value tags; and / or converting the format of the secure user information to one or more formats compatible with the secure user information 408.

[0123] For example, the data tagger 452 can tag a given received / retrieved data element using segment dimension values ​​that span the segment dimensions of the data format of secure user information 408. The data tagger 452 may include one or more rules, such as rules that convert existing metadata of a given data element into segment dimension values, and rules that convert the original tags (or other appropriate organized data) of a given data element into segment dimension values.

[0124] In some examples, the data tagger 452 can receive segment dimensional values ​​derived by the tag derivator 454. For example, the tag derivator 454 can process the contents of a given data element to derive one or more segment dimensional values. Exemplary processing techniques include optical character recognition (OCR), computer vision processing using one or more trained machine learning models, and natural language processing. Using OCR techniques, the tag derivator 454 can explore the OCRed contents of a given data element regarding key metrics corresponding to segment dimensional values ​​such as date, doctor's name, hospital, etc., and data describing the type of health data represented within the data element (e.g., laboratory test, biometric information, etc.). These key metrics can be extracted and provided to the data tagger 452.

[0125] Using computer vision processing techniques, one or more machine learning models can be trained to extract segment dimensional values ​​from visual data of the content of a given data element. For example, training data for a computer vision machine learning model may include visual descriptions of electronic health records (e.g., images) including dates, doctor's names, hospitals, etc., and data describing the type of health data being represented (e.g., laboratory tests, biometric information, etc.). Computer vision processing techniques can also perform optical character recognition, and one or more natural language processing models can be applied to the recognized text to derive segment dimensional values. The outputs from the computer vision models and / or natural language processing models can be provided to the data tagger 452.

[0126] The data converter 456 can convert the format of a given data element from its original format to a format compatible with the data scheme of the secure user information 408. For example, the metadata portion describing the content of a given data element can be converted into segment dimension values ​​consistent with the data scheme of the secure user information 408. Other appropriate formatting of a given data element (e.g., document type, image type, document object model, etc.) can similarly be converted via the data converter 456. The converted data, including segment dimension values, can be provided to the data tagger 452.

[0127] In some embodiments, the ingestion manager 450 may apply additional verification steps when segment dimensional values ​​are derived and / or transformed. For example, an additional verification workflow (e.g., a machine learning model-based workflow, a user-based workflow, etc.) may verify the derived / transformed segment dimensional values ​​of a data element before storing them in the secure user information 408.

[0128] The data write controller 458 can write aggregated data elements to the secure user information 408 according to its data scheme. For example, data elements can be stored and / or organized using segment dimension values ​​tagged via the data tagger 452. Once stored in the secure user information 408, the data elements may be accessible to authorized entities, such as data access requests and authentication information that grants access.

[0129] The secure information manager 406 can restrict the types of access to the secure user information 408. For example, a given authorized entity may be permitted access to user information 436 (e.g., a particular user's secure user information) via data access requests and authenticated credentials. A user may also define the types of access permitted to a given authorized entity. For example, a first type of access may allow the authorized entity to retrieve portions of a user's secure information so that the authorized entity can store those portions locally within the authorized entity's data storage system (e.g., an electronic health record system). A second type of access may allow the authorized entity to view portions of a user's secure information via software that displays the document content but does not store this information locally.

[0130] In an example where a user's secure information includes an electronic health record, the user may authorize a first type of access when they anticipate repeated visits to a healthcare provider, and a second type of access when they anticipate one, several, or limited visits to a healthcare provider. In some embodiments, the type of access can be linked to the type of credentials provided in the data access request. For example, credentials that allow access to a user's secure information for a period less than a threshold time (e.g., less than a week or a month) may be granted a second type of access, and credentials that allow access to a user's secure information for a period exceeding a threshold time (e.g., more than a week or a month) may be granted a first type of access.

[0131] Users can define access types to authorized entities / credentials using their information management application. For example, when a user provides input defining the scope of secure user information that a given credential is permitted to access, the user can also define what types of access (e.g., read-only, or read and download) the credential is permitted to.

[0132] The secure information manager 406 can also support users instructing authorized entities to grant authorized access to their secure information, such as instructions to retain and / or destroy information about secure user information accessed through the secure information manager 406. Once an authorized entity is granted access to retrieve a given user's secure user information (from user information 436) and store it locally, the secure information manager 406 can log the retrieved and locally stored secure user information for purposes such as auditing.

[0133] A user can view secure user information retrieved from secure user information 408 by a given authorized entity through their information management application. The user can provide user instructions to the secure information manager 406 that define how the authorized entity should maintain this retrieved information. For example, the user can provide specific instructions regarding each part of the retrieved secure user information. These instructions may define that the authorized entity should delete parts of the retrieved secure user information, retain a local copy of the retrieved secure user information, or retain a local copy of the retrieved secure user information for a limited time period (e.g., 30 days, 6 months, 1 year, 5 years, etc.).

[0134] The user can provide instructions to the secure information manager 406 through any appropriate means. For example, the user's information management application may include a user interface that allows the user to 1) select a portion of the user's secure user information to be retrieved by a given authorized entity, and 2) provide instructions regarding the selected portion. In some contexts, the user may be prompted to provide a signed document confirming the instructions. For example, the secure information manager 406 may remotely send a document to the user (e.g., via a secure document service), and the user may provide a digital signature on the document. In this example, the remotely sent document may be generated via the information management application based on the user's selection. For example, the remotely sent document may reflect user instructions as defined through the user's interaction with the user's information management application.

[0135] Subsequently, the secure information manager 406 can provide user instructions to the authorized entity. For example, the secure information manager 406 can send a signed user document to the authorized entity. In some examples, since the instructions are provided via a signed document, the authorized entity may be compelled to follow the user instructions to comply with data privacy requirements (e.g., delete the retrieved secure user information from the authorized entity's local data storage system).

[0136] Figure 5A shows a user interface including a portable access point according to an exemplary embodiment. Figure 500 includes a wireless device 502, a portable access point 504, an image 506, coded information 508, and a coded range sequence 510. An application running on the wireless device 502 can display the portable access point 504. For example, a certified entity's system can be configured to scan the portable access point 504 from the wireless device 502. The wireless device 502 can display the portable access point 504 in any other suitable format.

[0137] The portable access point 504 may include an image 506, or a user's facial image, and encoded information 508. The encoded information 508 may include a unique QR code or other appropriate visual or symbolic (e.g., alphanumeric) code embedded in (e.g., on top of) the image 506, such as an encoded range sequence 510. In some embodiments, the QR and / or symbolic code may utilize one or more of the following: a holographic image, a stereoscopic holographic image, a pixelated code, a stereoscopic textured code, etc. For example, the encoded information 508 may be displayed on top of the image 506 as an embossed QR code having a unique encrypted length string identifier generated using an algorithm.

[0138] The encoding algorithm 508 may include a unique cryptographic length string identifier generated via a cryptographic length string identifier algorithm. The cryptographic length string identifier may be unique at least due to the cryptographic length string identifier algorithm that generates it. For example, if a rogue version of the portable access point 504 attempts to replicate a unique cryptographic length string identifier, the scan of image 506 and cryptographic information 508 will not match due to the unique algorithm used.

[0139] The unique encrypted string identifiers generated via the encrypted string identifier algorithm may be dynamic, such that a new identifier is generated for each version of the portable access point 504, or over a predetermined period (e.g., every two hours, every four hours, every six hours, every twelve hours, daily, etc.), or at any other appropriate time. In this example, a secure information manager that manages a user's secure information can receive the dynamically generated identifiers for that version of the portable access point. For example, the identifier can be dynamically generated via an information management application on a wireless device 502 that manages the user's portable access point, and the application can send the dynamically generated identifiers to the secure information manager. In another example, the identifier can be dynamically generated via a cloud service, and the cloud service can send the dynamically generated identifiers to both the application that manages the user's portable access point and the secure information manager.

[0140] To mitigate malicious attempts to request credentials through older versions of a user's portable access point, the Secure Information Manager can record one or more active long-string identifiers for a given user. When the Secure Information Manager receives a credential request containing an inactive identifier, the request may be rejected, and the malicious attempt may be reported to support enhanced security measures.

[0141] A system of a certified entity, such as the scanning module 410 and the requesting system 404 in Figure 4A, can be configured to scan the portable access point 504. When the scanning module 410 scans the portable access point 504, the requesting system 404 (e.g., an application configured to decode the portable access point 504) can decode the coded information 508, the coded range sequence 510, and / or the image 506. For example, an application in the requesting system 404 can decode a unique long sequence of digits (e.g., generated by a unique algorithm), as described with reference to diagram 400A in Figure 4A, and can include the decoded number in the authentication information request.

[0142] The wireless device 502 can also display the portable access point 504 while the wireless device is offline, such as when the wireless device 502 lacks a connection to the Internet, a server hosting application components that display the portable access point 504, a cellular network and / or a wireless local area network, or any other suitable network connection. In this example, application components operating locally on the wireless device 502 can display the portable access point 504. The portable access point 504 can be displayed on the application's login screen, for example, before a user logs into the application. This can support the display of the portable access point 504 without a network connection. A scanning component of an authorized entity (e.g., scanning module 410) can then scan the displayed portable access point 504, and the authorized entity's system can use a network connection (e.g., a connection to the Internet) to perform authentication information requests and / or data access requests.

[0143] The encoded range sequence 510 can be an encoded string that maps to a portion of the user's secure information. For example, a user can define which portions of their secure information should be shared through interaction with the wireless device 502 and the launched application, and the launched application can generate an encoded range sequence 510 that represents an encoded version of the user-defined portion. In some embodiments, a predefined mapping can map that portion of the user's secure information to the encoded range sequence 510.

[0144] Secure user information of a user linked to the portable access point 504 can be electronic health data segmented based on segment dimensions and segment dimensional values. For example, a segment may include the issuing or affiliated physician and / or healthcare institution (e.g., entity name or identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), images (e.g., radiographic scans, X-rays, ultrasound images, MRI images, etc.), date and time of information generation, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. In some embodiments, a segment may include structured and unstructured data. By providing segment dimensions that define the range, users can define which parts of their electronic health data will be shared via the portable access point 504.

[0145] For example, through interaction with an application running on the user's wireless device, the user can specify the following segment dimensions: namely, issuing physician and / or medical institution - ALL; type - medication, tests and results, medical history, family history, biometrics, vaccine information, and allergies; relevant medical field - cardiology, primary care physician, and neurology; date of information occurrence - ALL; and electronic health record format - ALL. Other exemplary segment dimensions for the date of information include the past two years, last year, since age 18, and a custom time range (e.g., January 1-31, 2023). The user's electronic health data matching the segment dimensions specified by the user can be scope-defined for sharing via portable access point 504 and any issued credentials corresponding to portable access point 504.

[0146] A predefined mapping allows a user's health data segment to be mapped to an encoded range sequence 510. In one example, the sequence formatting can define which strings map to a segment dimension and which strings map to a value in that segment dimension. A sample encoded range sequence 510 includes [A:XYX, C:1C3B, X:1456, etc.]. In the exemplary predefined mapping, the first symbol of the encoded range sequence can be mapped to one of the electronic health data segments (e.g., issuing or affiliated physician and / or healthcare institution, type of information, relevant medical practice, date of information generation, electronic health record format, etc.). In the predefined mapping in this example, the symbols after the ":" value can be mapped to segment dimension values.

[0147] In an example where the letter "A" maps to the date of information origin in a predefined mapping, the symbol "XYX" can map to the segment dimension value "Information from the last 5 years." Other symbols can map to other segment dimensions of the date of information origin, such as "ALL," "18 years or older," or a custom date range. In an example where the letter "C" maps to the type of information in a predefined mapping, the symbol "1C3B" can map to a subset of information types (e.g., medication, tests and results, medical history, family history, biometrics, vaccine information, and allergies). Other symbols can map to other subsets of information types.

[0148] In an example where the letter "X" maps to a relevant medical practice in a predefined mapping, the symbol "1456" can map to a subset of medical practices (e.g., cardiology, primary care, neurology, and oncology). Other symbols can map to other subsets of medical practices. In this example, the coded range sequence 510 can define segments of a user's electronic health data and the segment dimensions of those segments. When the portable access point 504 is scanned by an authorized entity such as the scanning module 410 and the requesting system 404 in Figure 4A, the requesting system 404 (e.g., an application configured to decode the portable access point 504) can decode the coded range sequence 510. For example, an application in the requesting system 404 can decode the coded range sequence 510 as described with reference to diagram 400A in Figure 4A and include the decoded symbol sequence (e.g., [A:XYX, C:1C3B, X:1456, etc.]) in an authentication information request. Users can specify any other appropriate segment dimensional values, such as a restricted list of current year's vaccine records (e.g., influenza vaccines). Predefined mappings can similarly map these user health data segment selections to encoded range sequences.

[0149] The secure information manager can issue authentication information with the authority corresponding to the symbol sequence to the requesting system 404 (via the blockchain service). For example, the secure information manager 406 and the blockchain manager 414 in Figure 4A can communicate to issue blockchain-backed authentication information that includes the authority defined by the symbol sequence. The secure information manager 406 can store the authority, and / or the blockchain manager 414 can store the authority for the issued authentication information as part of the blockchain 416.

[0150] The secure information manager 406 may also receive data access requests containing authentication information issued from the requesting system 404, which include the requested segment / segment dimension values ​​of the user's electronic health record. For example, the requesting system 404 may issue an access request 430 containing authentication information 432, as shown in Figure 4B. The access request 430 may also include a range of requested data, such as a defined portion of the user's electronic health record (e.g., segments and segment dimension values). The range of requested data can be defined using a symbol sequence corresponding to a predefined mapping (similar to the coded range sequence 510). For example, the secure information manager 406 may interpret the symbol sequence using a predefined mapping to determine the requested portion of the user's electronic health data (e.g., segments limited by segment dimension values).

[0151] The secure information manager 406 can compare the access rights of the authentication information 432 (e.g., a sequence of symbols interpreted through a predefined mapping) with the range of data being requested (e.g., another sequence of symbols interpreted through the same or another predefined mapping) to determine which segments of the user's electronic health data and which parts of each segment (defined by dimensional values) to retrieve for the access request 430. For example, the access rights of the authentication information 432 may grant access to only a subset of the range of data being requested.

[0152] The audit log 424 of the blockchain manager 414 may establish one or more predefined mappings in the private blockchain of blockchain 416 that map symbol sequences to segments of a user's electronic health record and the segment dimension values ​​of those segments. For example, the secure information manager 406 may access the established predefined mappings to interpret authentication credentials and / or data access requests. In another example, an application loaded on a user's wireless device that manages the user's portable access point may access the established predefined mappings to encode the user's portable access point.

[0153] Predefined mappings can be updated, for example, based on a change in the format of the electronic health record, a change in the user's electronic health record, or any other appropriate cause. The blockchain manager 414 can append a new block to the private blockchain storing the predefined mappings so that the updated mapping is stored as the latest block and the historical mapping is stored as the previous block. In this example, the computer systems involved can access the current predefined mappings via the latest block. In addition, the audit log 424 can store one or more symbolic sequences for the data access request, as well as the data access request, such as the data access request, the scope of the data being requested, the authority of the credentials used to access the user's electronic health record, and the actual electronic health record segment accessed via the data access request.

[0154] Users can manage the organization / segmentation of their secure information, define access restrictions for sharing their secure information, and / or audit their access to their secure information through an information management application or any other appropriate application. For example, users can perform these functions by interacting with one or more user interface displays.

[0155] Figure 5B shows a user interface for viewing segments of secure user information according to an exemplary embodiment. Figure 500B includes interfaces 520 and 522, segment 524, and vaccination elements 526, 528, and 530. Figure 500B represents a user workflow for viewing secure user information, such as a portion of an electronic health record. Interface 520 can display categories or segments of secure user information, and the user can select one of the displayed categories, such as segment 524. In response to the selection, interface 522 can display electronic health record information under that segment / category. For example, segment 524 may correspond to vaccinations, and interface 522 can display vaccination elements 526, 528, and 530, each of which can list details about a specific one of the user's past vaccinations.

[0156] The user workflow can also define new categories or segments used to manage a user's electronic health records. Figure 5C shows a user interface for creating a new category of secure user information according to an exemplary embodiment. Figure 500C includes interfaces 540 and 542, segment 544, button 546, name input 548, and button 550.

[0157] Interface 540 can display categories or segments of secure user information, and the user can select two or more of the displayed categories / segments, such as segment 544. Once selected, the user can proceed from interface 540 to interface 542 via button 546. Interface 542 can, in response to the selection, create a logical join of the two segments / categories of the user's electronic health record, and the user can provide a name for the logical join via name input 548 and execute the logical join via button 550.

[0158] Logical joins can be used to manage, selectively share, and / or audit user secure information. For example, a user might choose a logical join to efficiently share two joined segments / categories via a dynamic portable access point (as described in Figures 5A and 5D). A user might also choose a logical join to view two joined segments / categories of their secure information (as described in Figure 5B). In another example, an audit log might log a user's access to secure information using the identifier (name) of the logical join (as described in Figure 5E).

[0159] Figure 5D shows a user interface for sharing selected portions of secure user information according to an exemplary embodiment. Figure 5D includes interfaces 560, 562, 564, 566, and 568, segment 570, button 572, name 574, button 576, established connection component 578, new connection component 580, button 582, selected connection component 584, and button 586. User workflows via interfaces 560, 562, 564, 566, and 568 can constitute a portable access point that provides information about credentials already assigned / issued to certified entities. For example, one or more credentials can be assigned / issued to multiple certified entities, granting them restricted access to a user's secure information. The user can edit the scope definitions for these assigned / issued credentials to change the certified entities' access to the user's secure information.

[0160] The user can select one or more segments / categories of their electronic health record, such as segment 570, via interface 560. Once selected, the user can proceed to interface 562 via button 572. The user can then confirm the selected segment, as indicated by name 574, via interface 562. Once the selected segment is confirmed, the user can proceed to interface 564 via button 576.

[0161] The user can select entities that share a selected segment, such as certified entities, via interface 564. The user can select known certified entities (e.g., certified entities with existing relationships with the user) using established connection component 578, and / or enter new entities using new entity component 580. For example, the user may include connections with known certified entities (e.g., certified entities to which credentials have been assigned that have permission to access the user's secure information, certified entities previously visited and / or selected by the user), and established connection component 578 may include a dropdown list from which the user can select one of the known certified entities.

[0162] The new entity component 580 may include fields into which identification information about a certified entity (e.g., email address, entity identifier, etc.) can be entered. In some embodiments, the entered identification information can be used to search a database of certified entities, and if a match is found, the user can select the matching certified entity. Once a certified entity is selected, the user can proceed to interface 566 using button 582.

[0163] The user can view the selected authorized entities via interface 566. In the illustrated example, the user has selected an existing connection displayed via the selected connection component 584. The selected authorized entities are entities that have already been assigned credentials that grant them restricted access to the user's secure information. The selected segment can revise the permissions of these assigned credentials. For example, the selected segment can override existing permissions or add additional permissions to existing permissions. The selected authorized entities do not necessarily have credentials already assigned, and the workflow for granting the selected authorized entities access to the selected segment may predefine these scope permissions of the authorized entities so that the credentials later issued to the authorized entities include scope permissions. These authorized entities can access the user's secure information using the assigned credentials, as further described herein.

[0164] Once the user has confirmed the selected authorized entities via the selected connection component 584, the user can proceed to interface 568 using button 586. Interface 568 can display to the user a segment of user secure information to be shared, and success indicators regarding the authorized entities to which these selected segments are shared.

[0165] Figure 5E shows a user interface for auditing access to secure user information according to an exemplary embodiment. Figure 5E includes interfaces 570, 572, and 574, providers 576, 578, and 580, and access instances 582, 584, and 586. For example, a user can audit instances via interfaces 570, 572, and 574 when an authorized entity accesses the user's secure information.

[0166] The user can select authorized entities to audit via interface 570. For example, providers 576, 578, and 580 can each correspond to healthcare providers (known authorized entities) that have previously accessed the user's secure information. In the illustrated example, the user selects provider 576. In response to the selection, interface 572 can display instances of the selected authorized entity accessing the user's secure information.

[0167] Access instances 582, 584, and 586 each represent instances in which the selected authorized entity accessed the user's secure information. Each access instance is identified by the access date and time. The user can select one of the access instances to further examine details about the access. In the illustrated example, the user selects access instance 586. In response to the selection, interface 574 can display details about access instance 586.

[0168] For example, additional details may include the registered identity associated with the authorized entity that performed the access, details about the credentials used to achieve the access (e.g., timing parameters, credential type, credential authority, assignment / issuance date, etc.), and the scope of the user's secure information being accessed (e.g., segment identifier, segment identifier and specific segment data values, or value ranges defining each segment portion being accessed, etc.). Users can visually inspect the access instance and its details to determine whether the authorized entity accessed their secure information illegally and / or unknowingly. Users can audit access instances from multiple authorized entities to ensure the integrity of their secure information.

[0169] In some embodiments, entities other than the user can audit instances of authorized entities accessing a user's secure information. For example, an auditing entity, a privacy enforcement entity, or any other appropriate entity with auditing authority can perform workflows via interfaces 570, 572, and 574 to audit authorized entities accessing a user's secure information to ensure compliance with privacy policies, regulations, and / or laws.

[0170] Figure 6 shows a flowchart for the aggregation and storage of secure user information according to an exemplary embodiment. In one embodiment, the functions of Figure 6 (and below in Figures 7, 8A, 8B, and 9) are implemented by software stored in memory or other computer-readable or tangible media and executed by a processor. In other embodiments, each function may be implemented by hardware (e.g., through the use of application-specific integrated circuits ("ASICs"), programmable gate arrays ("PGAs"), field-programmable gate arrays ("FPGAs"), etc.) or by any combination of hardware and software. Process 600 can be implemented by a secure information manager (e.g., a cloud computing system or any other suitable computing system) that manages the user's secure information.

[0171] In block 602, process 600 can receive data elements of secure user information for a specific user. For example, an ingestion manager can receive data elements of secure user information related to a specific user from multiple secure user information sources. A secure user information source can be any suitable source for storing secure user information. In an example where secure user information includes electronic health records, the sources can include hospital data systems, electronic health record data systems, master patient index systems, user-related computing systems, medical devices, wearable devices, and any other suitable sources of electronic health records or user health data. The ingestion manager can be part of a secure information manager that manages secure information for multiple users in a secure data store.

[0172] A secure data store can include a multidimensional data format for secure user information. In an example where secure user information includes electronic health records, the dimensions of the data format can be segments (e.g., segments of the electronic health record), and segment dimensions spanning these segments can organize the secure user information.

[0173] In block 604, process 600 can transform one or more data elements of the secure user information. For example, one or more original formats of the data elements (e.g., the original electronic health record format) may be transformed into a format compatible with the data scheme of the secure data store. In another example, the metadata portion describing the content of a given data element may be transformed into segment dimension values ​​consistent with the data scheme of the secure data store. Other appropriate formatting of a given data element (e.g., document type, image type, document object model, etc.) may be transformed in a similar manner.

[0174] In one embodiment, data elements of secure user information include biometric data detected via a wearable device (e.g., pulse rate, activity level, heart information, steps, sleep data, etc.). The ingestion manager can convert the biometric data into data elements compatible with the data format of the secure data store. For example, the ingestion manager can generate a file or document containing the biometric data, supplement the file / document with metadata, generate segment dimensional values ​​used to organize the generated file / document in relation to the data format of the secure data store, or perform any other appropriate function for converting the biometric data.

[0175] In block 606, process 600 can derive one or more tag information from the data elements of the secure user information. For example, the content of a given data element (e.g., the document contained by the given data element) can be processed to derive one or more segment dimensional values. Exemplary processing techniques include optical character recognition (OCR), computer vision processing using one or more trained machine learning models, and natural language processing.

[0176] The content of a given data element can be explored after optical character recognition for key indicators corresponding to segment dimensional values ​​such as date, doctor / hospital name, and data describing the type of health data represented within the data element (e.g., laboratory test results, biometric information, etc.). The recognized text can also be provided to one or more natural language processing models trained / configured to derive segment dimensional values ​​from electronic health record text.

[0177] In some cases, one or more machine learning models can be trained to extract segment dimensionalities from visual data of the content of a given data element. For example, training data for a computer vision machine learning model could include visual descriptions (e.g., images) of electronic health record documents containing dates, doctor's names, hospitals, etc., and data describing the type of health data being represented (e.g., laboratory tests, biometric information, etc.). Computer vision processing techniques can also perform optical character recognition, and one or more natural language processing models can be applied to the recognized text to derive segment dimensionalities.

[0178] In block 608, process 600 can tag the received / retrieved data elements using segment dimensions. For example, the received / retrieved data elements can be tagged using derived segment dimensions, transformed segment dimensions, or segment dimensions generated through any other appropriate technique. One or more rules can be defined for tagging a given data element, such as rules for converting existing metadata of a given data element to segment dimensions, or rules for converting the original tags (or other appropriate organized data) of a given data element to segment dimensions. A given received / retrieved data element can be tagged using segment dimensions that span the segment dimensions of the data scheme of the secure data store.

[0179] In block 610, process 600 can store tagged data elements of secure user information in a secure data store. For example, tagged data elements can be stored in the secure data store according to their data scheme. Tagged data elements are stored / organized using the tagged segment dimension values ​​during data element ingestion. Once stored in the secure data store, the data elements may be accessible to authorized entities, such as data access requests and authentication credentials that grant access.

[0180] Figure 7 shows a flowchart for granting restricted access to a user's secure information using user authentication credentials and user verification according to an exemplary embodiment. Process 700 can be performed by a requesting computing system, such as a computing system associated with an authorized entity that issues requests (e.g., authentication credentials requests and / or data access requests) to a secure information manager. Process 702 can be performed by a secure information manager (e.g., a cloud computing system or any other suitable computing system) that manages the user's secure information.

[0181] In block 704, process 700 can scan a portable access point. For example, the requesting system may include a scanning component configured to scan and decode a user's portable access point. The scanning component may be a portable device comprising a camera and software configured to decode user identification information from the user's portable access point.

[0182] A portable access point can be a visual access point that, when scanned, can grant access to a user's secure information (e.g., stored and managed via a secure information manager). For example, a visual access point may include a visual representation of the user linked to the portable access point (e.g., a facial image), as well as encoded information related to the user's secure information and / or the scope of permitted access. The requesting system and scanning components may be associated with certified entities, such as entities that have performed a certified workflow. Exemplary certified entities may include service providers (e.g., system administrators, healthcare providers, hospitals, etc.), joint venture partners, individuals registered with a secure information manager, or any other appropriate certified entities.

[0183] Users can configure portable access points and the encoded information they display. For example, a portable access point can be displayed via an application running on a user's wireless device (e.g., a smartphone or tablet), and the user can interact with the application and select the scope of sharing their secure information. The portable access point can be dynamic so that user selections via the application generate different versions of the portable access point with different encoded information displays. For example, a user can define a sharing scope that identifies data points of their secure information that can be shared with authorized entities via scanning the portable access point. The user can also define a sharing scope for the time period during which their secure information can be shared with authorized entities via scanning the portable access point.

[0184] In block 706, process 700 can generate an authentication credentials request in response to scanning a portable access point. For example, a requesting system can decode a user's portable access point and use the decoded information to generate a request for one or more authentication credentials. Encoded information displayed by the portable access point can be decoded and included in the authentication credentials request. Information decoded from a user's portable access point may include user identification information such as full name, date of birth, social security number, local address and / or zip code, medical information (e.g., primary care physician), biometric information (e.g., fingerprints, eye scans, etc.), identifier of the user's medical health record (e.g., master patient index identifier), vehicle manufacturer, model, and / or license plate, representation of government-issued identification information (e.g., driver's license photo), and an image of the user's face.

[0185] The decrypted information from the user's portable access point may also include scope definitions corresponding to the user's secure information. For example, the scope definitions may correspond to credential types such as expiring credentials (limited time range), episodic credentials (specified time range), or persistent credentials (valid until revoked). In another example, the scope definitions may correspond to the restricted scope permissions of the requested credentials.

[0186] User secure information can be segmented electronic health data based on segments and segment dimensions, and the restricted scope of permissions for requested authentication information can correspond to restricted portions of the user's electronic health data. For example, a segment may include the issuing physician and / or healthcare institution (e.g., entity identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), images (e.g., radiographs, X-rays, ultrasound images, MRI images, etc.), date and time of information generation, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. In some embodiments, a segment may include structured and unstructured data. Users can define which parts of their electronic health data are shared via their portable access point by providing segment dimensions that define the range.

[0187] In block 708, process 700 can send an authentication request. For example, a requesting system can send an authentication request to a secure information manager. The authentication request from the requesting system may be for authentication credentials that grant the requesting system access to the user's secure information, which can be managed by the secure information manager. For example, the details of the request (e.g., user identification information, authentication credentials type, secure user information permissions with defined scope) may be provided by the user's portable access point, which allows the user to control how their secure information is shared with the requesting system.

[0188] The secure information manager can verify and authenticate authentication information requests and retrieve authentication information from blockchain services in response to requests. The authentication and verification of authentication information requests, as well as subsequent retrieval, are described with reference to blocks 718 and 720 of process 702. In block 710, process 700 can receive the authentication information. For example, the secure information manager can send the retrieved authentication information to the requesting system.

[0189] In block 712, process 700 can send a data access request containing the received authentication information. For example, a data access request containing the received authentication information, the identifier of the authorized entity that issued the request, and user identification information can be sent to the secure information manager. The secure information manager can verify and authenticate the data access request and retrieve limited scope secure user information in response to the data access request.

[0190] A data access request can define one or more data points of a user's secure information. For example, a user's secure information may be electronic health data segmented based on a segment dimensional value. A data access request may include a specific segment dimensional value that defines the scope of the user's secure information being requested. In some embodiments, the authentication information issued to an authorized entity and provided in the data access request includes scope permissions to the user's secure information. Authentication and verification of the data access request and the subsequent retrieval of scope-restricted secure user information are described with reference to blocks 726 and 728 of process 702.

[0191] In block 714, process 700 can receive scope-restricted secure user information in response to a data access request. For example, the secure information manager can send scope-restricted user information to the requesting system. The received scope-restricted user information can correspond to the requested data points included in the data access request. The received scope-restricted user information can also correspond to a portion of the requested data points included in the data access request. For example, if the data access request includes user data points outside the set of scope permissions for authorized entities / provided credentials, the secure information manager can extract and return only the portion of the user data points covered by the set of scope permissions.

[0192] In block 716, process 702 can receive an authentication information request. For example, the secure information manager can receive an authentication information request from the requesting system, as described with reference to block 708 of process 700. The authentication information request may include user identification information, an identifier and / or authentication information of an authorized entity, an authentication information type definition, a scope definition for secure user information, and any other appropriate information.

[0193] The Secure Information Manager can verify user identification information and authenticate certified entity identifiers / credentials. In this example, the Secure Information Manager can obtain credentials that grant restricted access to the user's secure information (e.g., from blockchain services) within the scope of certified entities. The obtained credentials can correspond to the credential type definition from the credential request, and the access rights assigned to the obtained credentials can correspond to the scope definition from the credential request.

[0194] In block 718, process 702 can authenticate and verify the authentication information request. For example, the authentication information request may include user identification information that the secure information manager verifies. The secure information manager can manage the secure information of multiple registered individuals. Verification can compare the user identification information provided in the authentication information request with that of one of the registered individuals.

[0195] A credentials request may include an identifier and / or identifying credentials of an authorized entity, and the secure information manager can authenticate such identifier and / or identifying credentials. For example, the identifier and / or identifying credentials included in a credentials request (from a requesting system related to an authorized entity) may include a unique identifier assigned to the authorized entity, a cryptographic key assigned to the authorized entity and / or a digital signature generated via the cryptographic key, a unique token assigned to the authorized entity, or any other suitable data that can be used to authenticate the authorized entity.

[0196] In block 720, process 702 can obtain the credentials corresponding to the credentials request. User identity verification can match registered users against the credentials request, and identifier / credential authentication can match authorized entities against the credentials request. The secure information manager can then issue a software call to the blockchain service for credentials with scope privileges that grants restricted access to the secure information of the matching registered user within the scope of the matching authorized entity. For example, the software call may include the identifier of the registered user, the identifier of the authorized entity, and the credentials type included in the credentials request from the requesting system.

[0197] A blockchain service can respond to a software call by returning blockchain-backed credentials to a secure information manager. For example, a blockchain service can host one or more blockchains that manage credentials and issue credentials to authorized entities to serve as credentials that grant authorized entities access to secure user information. The issued credentials can match the credentials type included in the software call. Transactions issuing credentials to authorized entities can be appended to the blockchain so that the assignment record is maintained as an immutable ledger.

[0198] A software call by the secure manager can be a smart contract call, and a blockchain service can execute one or more smart contracts to return authentication credentials in response to a smart contract call. For example, a smart contract execution can issue authentication credentials to a token well identifier (or any other appropriate entity identifier) ​​associated with a certified entity, and that transaction can be attached to the blockchain managing it. The attached transaction may include additional information such as an expiration timer for issuing tokens to the certified entity (defined by the authentication credentials type), identification information about the certified entity, identification information about the user, or any other appropriate information.

[0199] The Secure Information Manager can assign scope-sharing permissions (e.g., scopes of secure user information data points) included in the authentication credentials request to the credentials. For example, data points, secure information segments, or other appropriate parts of a user's secure information defined via a scope-sharing definition can be assigned as permissions to the credentials returned by the blockchain service, and these permission assignments can be stored by the Secure Information Manager.

[0200] A software call from a secure information manager for authentication credentials to a blockchain service may include a scope sharing definition, and the blockchain service can assign the corresponding permissions to the credentials to access the user's secure information. For example, the blockchain service may attach the scope sharing definition to the blockchain as part of the recorded transaction (via the execution of a smart contract).

[0201] In block 722, process 702 can send an authentication information request. For example, a secure information manager can send the acquired authentication information to the requesting system. The blockchain service can also send the authentication information directly to the requesting system via a separate communication channel.

[0202] In block 724, process 702 can receive a data access request. For example, the secure information manager can receive a data access request from a requesting system having one or more authentication credentials, as described with reference to block 712 of process 700. The data access request may include authentication credentials, an identifier of the authorized entity that issued the request, user identification information, one or more requested data points of the user's secure information, and any other appropriate information.

[0203] In block 726, process 702 can authenticate and verify a data access request. For example, a data access request may include authentication credentials. The secure information manager can authenticate the authentication credentials via a software call to a blockchain service. For example, the blockchain service may return trusted information about the credentials from the blockchain that records the transaction of the credentials, such as the authorized entity to which the credentials have been assigned, the registered user to whom the credentials authority applies, the expiration time of the credentials, the data points to which the credentials are authorized to access, or any other transaction information stored by the blockchain. The secure information manager can authenticate a data access request if the expiration timer has not expired and the authorized entity to which the credentials have been assigned matches the identifier of the authorized entity that issued the request.

[0204] A data access request may include an identifier of the authorized entity that issued the request, and the secure information manager can verify that the identifier of the authorized entity included in the data access request matches an authorized entity returned by the blockchain service. A data access request may also include user identification information that identifies a user, and the secure information manager can verify that the user information matches one of the registered persons managed by the secure information manager, a user associated with the authentication information returned by the blockchain service, or any combination thereof.

[0205] In block 728, process 702 can retrieve limited scope secure information in response to a data access request. For example, a secure information manager can query a secure data store that stores a user's secure information regarding the user information requested in the data access request.

[0206] In response to authenticated and verified data access requests, a secure information manager can generate data queries to retrieve scope-restricted secure user information from a secure data store. For example, a data query may be scope-restricted based on the scope permissions assigned to the authenticated credentials. In some embodiments, a data query may be generated in response to the data requested by the access request, and the secure information manager can then restrict the data query based on the permissions of the provided credentials. In another example, the secure user data requested by the data access request may be scope-restricted according to the permissions of the provided credentials, and a data query may be generated to retrieve scope-restricted data. The secure data store can then return scope-restricted secure user information in response to the data query.

[0207] In block 730, process 702 can provide the requesting system with restricted scope secure user information. For example, the secure information manager can return the secure user information requested by the data access request, or, if the provided credentials do not have access to the entirety of the secure user information requested by the data access request, it can return a further restricted version of the secure user information requested by the data access request.

[0208] Figure 8A shows a flowchart for defining access restrictions for sharing user secure information according to an exemplary embodiment. Process 800 can be performed by a user system, such as a wireless device (e.g., a smartphone, tablet, etc.). Process 802 can be performed by a requesting system, such as a system of an authorized entity that issues an authentication information request to a secure information manager. Process 800 may be triggered when a user launches an information management application in a user system that manages the scope definition for sharing user secure information. Process 802 may be triggered when a requesting system scans the user system's display, such as a portable access point displayed through the user system.

[0209] In block 804, process 800 can receive timing parameters for sharing user secure information. For example, a user can provide timing parameters through a user system and applications launched within that user system. Users can define timing parameters by selecting the type of authentication information, such as perishable, episodic, and / or persistent, which corresponds to the type of timing parameter each user has. Users can define any other appropriate timing parameters.

[0210] In block 806, process 800 can receive range parameters for sharing user secure information. For example, a user can provide range parameters through a user system and an information management application launched within the user system. The range parameters can define portions of the user's secure information. The user's secure information may include electronic health records, and the range parameters can define segments and segment dimensions of the user's electronic health records.

[0211] For example, a segment of a user's electronic health record may include the issuing physician and / or healthcare institution (e.g., entity identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), images (e.g., radiographs, X-rays, ultrasound images, MRI images, etc.), date and time of information generation, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. In some embodiments, segments may include structured and unstructured data. One or more of these electronic health record segments may be further scope-defined according to segment dimensional values ​​(e.g., date, subset of information type, subset of relevant medical practice, etc.). Users can define which parts of their electronic health data are shared through the information management application by providing segment dimensions that define the range.

[0212] One or more segments selected by a user for sharing may include a combined segment identifier. For example, a user can generate a combined segment identifier by selecting two or more segments from their electronic health record and providing instructions for generating a combined segment identifier for the two or more selected segments. The combined segment identifier can then be used to efficiently share the two or more segments.

[0213] A join segment identifier can represent a custom logical join of segments selected / defined by the user. In some examples, the user can also range-define each selected segment that participates in the custom logical join by providing a segment dimension value that restricts each selected segment. In this case, the join segment identifier can represent a custom logical join of selected segments that is range-defined according to the user-defined segment dimension value of each selected segment.

[0214] In block 808, process 800 can generate encoded information based on timing and range parameters. For example, the encoded information can encode the authentication information type (representing the timing of the authentication information) and the range parameter (representing a portion of the user's secure information). Predefined mappings can map user health data segments (e.g., segments and segment dimensions) to encoded character / symbol sequences. In one example, sequence formatting can define which strings map to segments and which strings map to the segment dimensions of those segments.

[0215] In block 810, process 800 can display a portable access point containing encoded information. For example, the displayed portable access point may include a user image, user identification information (some or all of which can be encoded), and generated encoded information representing authentication information type and range parameters.

[0216] In block 812, process 802 can scan a portable access point. For example, a scanning module of a requesting system (e.g., a computing system having an application configured to decode a camera and a portable access point) can scan a portable access point displayed via a user system. In block 814, process 802 can decode encoded information from a portable access point. For example, a scanning module of a requesting system can be configured to decode a portable access point, such as by extracting information displayed by the portable access point and / or decode the encoded information displayed by the portable access point. The decoded information may include user identification information, timing parameters, and / or range parameters defined by the user via an information management application.

[0217] In block 816, process 802 can generate an authentication credentials request using the extracted and / or decoded information. For example, an authentication credentials request may request credentials related to one or more pieces of information extracted and / or decoded from scanning a portable access point. An authentication credentials request may include user identification information, authentication credentials type and / or timing parameters, range parameters (e.g., a string of characters / symbols to map to a portion of the user's electronic health record), and other appropriate information (e.g., entity identification information).

[0218] In block 818, process 802 can send an authentication request to a secure information manager that manages the user's secure information. For example, the secure information manager can authenticate and / or verify the authentication request and, in response to the authentication request, issue authentication credentials to the requesting system (via interaction with the blockchain service).

[0219] Figure 8B shows a flowchart for defining access restrictions for sharing user secure information according to an exemplary embodiment. Process 820 can be performed by a user system, such as a wireless device (e.g., a smartphone or tablet). Process 820 may be triggered when a user launches an information management application in a user system that manages the scope definition for sharing user secure information.

[0220] In block 822, process 820 can scan visual data related to the certified entity. For example, a user system (e.g., a camera and an application configured to decode a portable access point) can scan the portable access point of the certified entity (e.g., display the computing system of the certified entity or any other suitable display means).

[0221] In block 824, process 820 can decode encoded information from scanned visual data. For example, a user system may be configured to decode a portable access point of a certified entity, such as by extracting information displayed by the portable access point and / or decode the encoded information displayed by the portable access point. The information to be decoded may include at least a certified entity identifier.

[0222] In block 826, process 820 can use the decoded information to configure a user interface. For example, the interface of a user information management application may be configured using a certified entity identifier and any other appropriate information decoded from a certified entity's portable access point.

[0223] In block 828, process 820 can receive timing parameters for sharing user secure information. For example, a user can provide timing parameters through a configured interface. Users can define timing parameters by selecting the type of authentication information, such as extinct, episodic, and / or persistent, which corresponds to the type of timing parameter each user has. Users can define any other appropriate timing parameters.

[0224] In block 830, process 820 can receive range parameters for sharing user secure information. For example, a user can provide range parameters through a configured interface. The range parameters can define portions of the user's secure information. The user's secure information may include electronic health records, and the range parameters can define segments and segment dimensions of the user's electronic health records.

[0225] For example, a segment of a user's electronic health record may include the issuing physician and / or healthcare institution (e.g., entity identifier), type of information (e.g., medication, tests and results, medical history, family history, biometrics, physician-patient communication, physician's findings, vaccine information, allergies, etc.), relevant medical field (e.g., cardiology, primary care, neurology, oncology, etc.), images (e.g., radiographs, X-rays, ultrasound images, MRI images, etc.), date and time of information generation, electronic health record format, other Health Level Seven (HL7), Fast Healthcare Interoperability Resource (FHIR), and / or Substitute Medical Applications and Reusable Technologies (SMART) for FHIR data parameters or any other appropriate health data parameters. In some embodiments, segments may include structured and unstructured data. One or more of these electronic health record segments may be further scope-defined according to segment dimensional values ​​(e.g., date, subset of information type, subset of relevant medical practice, etc.). Users can define which parts of their electronic health data are shared through the information management application by providing segment dimensions that define the range.

[0226] One or more segments selected by a user for sharing may include a combined segment identifier. For example, a user can generate a combined segment identifier by selecting two or more segments from their electronic health record and providing instructions for generating a combined segment identifier for the two or more selected segments. The combined segment identifier can then be used to efficiently share the two or more segments.

[0227] A join segment identifier can represent a custom logical join of segments selected / defined by the user. In some examples, the user can also range-define each selected segment that participates in the custom logical join by providing a segment dimension value that restricts each selected segment. In this case, the join segment identifier can represent a custom logical join of selected segments that is range-defined according to the user-defined segment dimension value of each selected segment.

[0228] In block 832, process 820 can generate an authentication request using an authorized entity identifier, defined timing parameters, and defined range parameters. For example, an authentication request may include user identification information, entity identification information, authentication type and / or timing parameters, range parameters (e.g., a string of characters / symbols to map to a portion of the user's electronic health record), and other appropriate information.

[0229] In block 834, process 820 may send an authentication request to a secure information manager that manages the user's secure information on behalf of the authorized entity. For example, the secure information manager may authenticate and / or verify the authentication request and, in response to the authentication request, issue authentication credentials to the authorized entity's system (via interaction with blockchain services).

[0230] In some embodiments, an authentication information request transmitted through a user system may constitute the first part of a two-part authentication information request. For example, the user system may also display a portable access point configured according to user input (e.g., timing parameters, range definitions, etc.), and the system of the authorized entity may scan the user's portable access point to generate the second part of a two-part authentication information request.

[0231] The displayed portable access point may include encoded information, such as user identification information, timing parameters defined via user input, and range parameters defined via user input. The certified entity's system can decode the encoded information and provide the decoded information in the second part of the two-part authentication information request. The certified entity's system can then send the second part of the two-part authentication information request to a secure information manager. The secure information manager can provide the requested authentication information to the certified entity's system once both parts of the two-part authentication information request have been received, and, in some embodiments, once received and authenticated. For example, the secure information manager can compare the information contained in the two parts of the two-part request and determine whether the two parts contain matching (e.g., identical) information.

[0232] Users can edit the credentials provided / assigned to certified entities in response to two-part credential requests via the information management application. For example, users can edit one or more of the following: scope definitions (e.g., segment identifiers and / or segment dimension values), timing parameters, etc. The information management application can provide these edits to the secure information manager, which can then revise the credentials assigned / provided to the system for certified entities.

[0233] Figure 9 shows a flowchart for retrieving scope-restricted user information from a secure data store and logging access, according to an exemplary embodiment. Process 900 can be performed, for example, by a secure information manager that, in response to a request from the computing system of an authorized entity, grants the authorized entity access to the user's secure information. Process 900 can be performed by one or more components of the secure data store. In another example, process 900 can be performed by one or more components of a blockchain service. In various embodiments, process 900 can be performed in a secure information manager, a secure data store, a blockchain service, or any combination thereof.

[0234] In block 902, process 900 can query the secure data store for user secure information. For example, an authorized entity may request a set of data points for its user secure information. It can generate a data store query (e.g., SQL, or any other appropriate database query) to query all or part of the requested data points for the authorized entity's user secure information. For example, the data store query may be restricted to the authorized entity's privileges (e.g., credentials assigned to the authorized entity).

[0235] In block 904, process 900 can receive scope-restricted user information from the secure datastore. For example, scope-restricted user information can be restricted by a formulated datastore query or by the datastore itself. The generated query is restricted to request secure information of a restricted range of users to which the authorized entity is permitted access. The datastore can return scope-restricted data points of secure information for users restricted to data points to which the authorized entity is permitted access.

[0236] In block 906, process 900 can provide scope-limited user information to the requesting system of the authorized entity. For example, the scope-limited data points of the user's secure information that are returned can be sent to the computing system of the authorized entity that issued the request.

[0237] In block 908, process 900 may log the request, authentication information, the scope of information accessed via the request, a timestamp, and other appropriate data related to the received request and scope of data. For example, a user's access to secure information may be logged in any appropriate data structure. The storage structure may be a blockchain, and each instance of a request and / or authorized access to a user's secure information is logged as a block in the blockchain. Exemplary logged information may include the scope of the requested data access (e.g., the segment and segment dimensions of the user's secure information requested, such as a string of characters / symbols representing such segment dimensions), the authentication information and authorization provided (e.g., timing parameters, scope parameters, such as the secure information segment and segment dimensions, and / or a string of characters / symbols representing such segment and segment dimensions), a timestamp, an entity identifier (and, optionally, an identifier of a person associated with that entity), user identification information, secure user information provided in response to the request (e.g., the segment and segment dimensions defining the portion of the accessed data), and any other appropriate information.

[0238] One or more predefined mappings may be associated with data access request logs. For example, a predefined mapping could map character / symbol sequences to parts of a user's secure information (e.g., segments and segment dimensions of electronic health data). The predefined mappings can be exposed to a private blockchain so that the mappings can be used to interpret credential authorization and / or data access requests that include the character / symbol sequences associated with the mapping.

[0239] Predefined mappings can be updated, for example, based on changes to user secure information (e.g., a change in the format of a user's electronic health record, a new user electronic health record, etc.). In response to the update, a new block can be appended to the private blockchain storing the predefined mappings, such that the updated mapping is stored as the latest block and the historical mapping is stored as the previous block. In this example, the computer systems involved can access the current predefined mappings via the latest block.

[0240] In block 910, process 900 may provide logged data in response to an audit request. A user (or any other appropriate entity or person) may be permitted to audit the user's access to secure information. Logged information, including the request, the limited scope of information accessed through the request, timestamps, and other appropriate data related to the received request and limited scope of data, may be provided to the user or other appropriate audit entity.

[0241] In an example where logged data for an access request includes a string of characters / symbols, a private blockchain managing a predefined mapping may be accessed to interpret the string. Once interpreted, the portion of the user's secure information represented by the string (e.g., a segment of the user's electronic health data and its dimensional values) may be provided in response to an audit request. For example, a given access request's timestamp can be used to determine a given predefined mapping that was active during the given access request. This determined predefined mapping may be accessed via the private blockchain to interpret any string of characters / symbols logged for a given access request.

[0242] (With respect to a determined predefined mapping) the portion of a user's secure information represented by a string of characters / symbols may be provided in response to an audit request covering a given access request. For example, logged data provided for a given access request in response to an audit may include the scope of the requested data access (e.g., the segment and segment dimensions of the requested user's secure information), the credentials and permissions provided (e.g., timing parameters, scope parameters, e.g., secure information segment and segment dimensions), a timestamp, an entity identifier (and, if applicable, an identifier of a person associated with that entity), user identification information, secure user information provided upon request (e.g., the segment and segment dimensions defining the portion of the accessed data), and any other appropriate information.

[0243] User auditing of logged access to a user's secure user information via a secure information manager can be achieved using an information management application (e.g., a smartphone application, a web application, etc.). For example, the information management application can sort and display logged access by authorized entity, access date and time, etc. The information management application can list "instances" of access by date, etc., and the user can select an instance of access to expand on specific details of the access (e.g., authorized entity / registered identity, scope of access, etc.). In some embodiments, the information management application can log instances / versions of a user's portable access point and associate a given instance / version of the portable access point with each logged access by an authorized entity. This can assist in user inspection for unauthorized access attempts.

[0244] Privacy enforcement entities can also audit logs for individual users, individual certified entities, groups of users, and / or groups of certified entities. For example, a secure information manager (or any other privacy enforcement entity) can periodically review logged access by certified entities to a user's secure user information. If a user reports unauthorized access by a given certified entity, the privacy enforcement entity can audit the certified entity's access across multiple users to uncover other instances of unauthorized access by that entity. For example, if a pattern of unauthorized access is detected, the secure information manager can revoke the "certified" status of a certified entity.

[0245] The embodiment allows restricted access to a user's secure information using blockchain-backed credentials. Users can register with a secure information manager and control the scope to which their secure information is shared. For example, a user can allow authorized entities (e.g., service providers, healthcare providers, other individuals) to access their secure information via a portable access point. Users can select scope definitions to control how their secure information is shared with authorized entities. Authorized entities can scan the user's portable access point and request credentials to grant access to the user's secure information through the scan. For example, the credentials can be blockchain-backed credentials assigned access permissions corresponding to the user's selection.

[0246] Subsequently, the authorized entity can issue one or more data access requests using the credentials. For example, data access requests can be authenticated and verified by the Secure Information Manager. The Secure Information Manager can grant the authorized entity limited access to the user's secure information corresponding to the access privileges assigned to the credentials (based on the authenticated and verified data access requests). A user can revoke the credentials and / or the access privileges assigned to the authorized entity at any time. The access privileges assigned to the credentials may include an expiration timer, after which the credentials can no longer be authenticated by the Secure Information Manager.

[0247] The embodiments achieve efficient and secure, granular user-controlled access to a user's secure information. For example, a user's portable access point is configured to efficiently define the conditions for sharing the user's secure information. In addition, issued credentials and a secure information manager enforce the user's sharing conditions in a trusted manner. In embodiments where credentials are blockchain-backed, blockchain-based management ensures that the credentials are authentic and mitigates fraudulent attempts to access the user's secure information.

[0248] The features, structures, or characteristics described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the use of “one embodiment,” “several embodiments,” “a particular embodiment,” “a number of particular embodiments,” or other similar phrases throughout this specification refers to the fact that a particular feature, structure, or characteristic described in relation to that embodiment may be included in at least one embodiment of this disclosure. Thus, the occurrence of the phrases “one embodiment,” “several embodiments,” “a particular embodiment,” “a number of particular embodiments,” or other similar phrases throughout this specification does not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0249] It will be readily apparent to those skilled in the art that the embodiments described above may be implemented by steps in a different order and / or by elements of a configuration different from those disclosed. Therefore, while this disclosure considers the embodiments outlined, it will be apparent to those skilled in the art that certain modifications, variations, and alternative structures will become apparent while remaining within the spirit and scope of this disclosure. Accordingly, the appended claims should be referenced to determine the scope and boundaries of this disclosure.

Claims

1. A method for allowing restricted access to segmented secure information, This includes storing multidimensional secure user information organized according to segment dimensions and segment dimension values ​​in a secure data store. One or more data elements of the secure user information are received from multiple secure user information data sources and imported via an import manager. The import manager stores the received data elements along with segment dimension values ​​that span multiple segment dimensions. The aforementioned method, The secure information manager further includes receiving an authentication information request from a requesting entity, the range definition including a specific segment dimension value spanning a specific segment dimension, The aforementioned method, The secure information manager verifies the authentication information request, In response to the verification, authentication information including access rights corresponding to the scope definition is assigned to the requesting entity, In response to one or more access requests including the aforementioned assigned authentication information, granting limited access to the user's secure information to a limited set of data elements, It further includes, A method wherein the restricted set of data elements matches at least a portion of the values ​​of the particular segment dimension with respect to the particular segment dimension.

2. Storing the aforementioned multidimensional secure user information means The capture manager includes converting at least a portion of the received data elements from a second electronic record format to a first electronic record format. The method according to claim 1, wherein the first electronic record format is formatted according to the multidimensional data scheme of the secure data store.

3. Receiving authorization from the user who possesses the secure user information to store new data elements of the user's secure user information, The process involves importing the new data element by tagging it with segment dimension values ​​spanning multiple segment dimensions via the import manager, and storing the new data element in accordance with the multidimensional data scheme of the secure data store. The method according to claim 2, further comprising:

4. The method according to claim 3, wherein the new data element is retrieved and stored via a master patient index that links the new data element to one or more identifiers of the user.

5. Tagging the new data element using segment dimension values ​​that span multiple segment dimensions is, To derive at least one segment dimension value from the content of at least one of the aforementioned new data elements, Tagging the at least one new data element using the at least one derived segment dimension, The method according to claim 3, further comprising:

6. The method according to claim 3, wherein the new data element includes user biometric data acquired via a wearable device.

7. Importing the new data elements via the aforementioned import manager is: The method according to claim 6, comprising converting the biometric data acquired via the wearable device into one or more of the new data elements formatted according to the multidimensional data scheme of the secure data store.

8. The method according to claim 1, wherein the requesting entity generates the authentication information request in response to scanning the user's portable access point.

9. The user's portable access point includes encoded information, The method according to claim 8, wherein, in response to scanning of the portable access point, the requesting entity is configured to decode the range definition from the encoded information.

10. The user provides a selection via input on a portable device. The portable device is configured to generate the portable access point in response to the user selection. The method according to claim 9, wherein the requesting entity scans the portable access point from the portable device.

11. The user selection corresponds to segment dimension values ​​spanning the segment dimension of the user's secure information selected by the user for sharing with the requesting entity, The encoded information of the portable access point includes an encoded representation of the segment dimension value, The requesting system is configured to decode the encoded representation of the segment dimension value in response to scanning the portable access point. The method according to claim 10, wherein the range definition provided in the authentication information request includes the decoded segment dimension value.

12. A method for dynamically generating portable access points, This includes displaying the interface, The user provides, via the interface, a range definition for the user's secure information and a selection input that defines one or more timing parameters. The aforementioned method, The method further includes dynamically generating a display of the portable access point configured by the aforementioned selection inputs, The generated portable access point display includes coded information representing the range definition and one or more timing parameters, The certified entity's system is configured to scan the portable access point and, in response to the scan, obtain authentication information from the secure information manager, the authentication information including access rights corresponding to the range definition and one or more timing parameters. A method by which the system of the certified entity is permitted limited access to the user's secure information via the acquired authentication information.

13. The selection input includes a segment identifier and a segment dimension value that define a segment of the user's secure information. The method according to claim 12, wherein the encoded information of the portable access point includes an encoded representation of the segment identifier and the segment dimension value.

14. The requesting system is configured to decode the encoded representation of the segment identifier in response to scanning the portable access point. The method according to claim 13, wherein the range definition provided in the authentication information request includes the decoded segment identifier.

15. The segment input received from the user includes at least two selected segment identifiers and instructions for combining the selected segment identifiers. The selected segment identifier is, in response to the instruction, joined to a logical join that includes a join identifier. The method according to claim 13, wherein the selection input includes at least the combined identifier.

16. The interface receives audit requests from the user regarding the certified entity, In response to the audit request, display instances of the authorized entity accessing the user's secure information, The method according to claim 12, further comprising:

17. Receiving a user selection regarding one or more of the aforementioned access instances, In response to the user selection, detailed information regarding one or more instances of access is displayed. The method according to claim 16, further comprising:

18. The method according to claim 17, wherein the detailed information relating to one or more instances of access includes applicable authentication information used to obtain access to the user's secure information, the access rights of the applicable authentication information, one or more segment identifiers of the user's secure information accessed during one or more instances of access, one or more timestamps for one or more instances of access, or any combination thereof.

19. The aforementioned method, The interface receives input that modifies the scope definition regarding the user's secure information, The modification to the scope definition is transmitted to the secure information manager, It further includes, The method according to claim 12, wherein the secure information manager dynamically modifies the access rights of the authentication information in response to the modification of the range definition.

20. A non-temporary computer-readable medium storing instructions, wherein, when executed by a processor, the instructions cause the processor to grant the processor restricted access to segmented secure information, and when executed, the instructions cause the processor to In a secure data store, store multidimensional secure user information organized according to segment dimensions and segment dimension values. One or more data elements of the secure user information are received from multiple secure user information data sources and imported via an import manager. The import manager stores the received data elements along with segment dimension values ​​that span multiple segment dimensions. The aforementioned instruction is given to the processor, The secure information manager further receives an authentication information request from the requesting entity, the range definition including a specific segment dimension value that spans a specific segment dimension. The aforementioned instruction is given to the processor, The secure information manager verifies the authentication information request, In response to the verification, authentication information including access rights corresponding to the scope definition is assigned to the requesting entity, In response to one or more access requests including the aforementioned assigned authentication information, granting limited access to the user's secure information to a limited set of data elements, Let them do it further, The restricted set of data elements is a non-temporary computer-readable medium that matches at least a portion of the values ​​of the particular segment dimension with respect to the particular segment dimension.

Images