Patent ID: 12242499

DETAILED DESCRIPTION

The disclosure presented in the following written description and the various features and advantageous details thereof, are explained more fully with reference to the non-limiting examples included in the accompanying drawings and as detailed in the description. Descriptions of well-known components have been omitted to not unnecessarily obscure the principal features described herein. The examples used in the following description are intended to facilitate an understanding of the ways in which the disclosure can be implemented and practiced. A person of ordinary skill in the art would read this disclosure to mean that any suitable combination of the functionality or exemplary embodiments below could be combined to achieve the subject matter claimed. The disclosure includes either a representative number of species falling within the scope of the genus or structural features common to the members of the genus so that one of ordinary skill in the art can recognize the members of the genus. Accordingly, these examples should not be construed as limiting the scope of the claims.

A person of ordinary skill in the art would understand that any system claims presented herein encompass all of the elements and limitations disclosed therein, and as such, require that each system claim be viewed as a whole. Any reasonably foreseeable items functionally related to the claims are also relevant. Pursuant to Section 904 of the Manual of Patent Examination Procedure, the Examiner, after having obtained a thorough understanding of the invention disclosed and claimed in the nonprovisional application has searched the prior art as disclosed in patents and other published documents, i.e., nonpatent literature. Therefore, as evidenced by the issuance of this patent, the prior art fails to disclose or teach the elements and limitations presented in the claims as enabled by the specification and drawings, such that the presented claims are patentable under 35 U.S.C. §§ 101, 102, 103, and 112.

FIG.1illustrates an electronic health record permissioning and monetization system100schematic, in accordance with one or more exemplary embodiments of the present disclosure. The system100can include one or more servers102having one or more processors104, a memory130, machine readable instructions106, including transaction blockchain API110, a wallet module112, and a permissioning module114, among other relevant modules. The server102can be operably coupled to one or more clients150via a network140. The clients can be a physical device (e.g., mobile phone, laptop, tablet, desktop computer, wearable device, or other suitable device), program, or application. In another exemplary embodiment, a client can include a mobile phone having a mobile application configured to communicate with the server102over the network140.

In one embodiment, a transaction blockchain API110can be provided by the system100for accessing the blockchain, the transaction blockchain API110having an interface that defines interactions between multiple components. For example, the blockchain API110can define the kinds of calls or requests that can be made, how to make them, the data formats that should be used, the conventions to follow, and other suitable functionality related to a blockchain. In another embodiment, the blockchain API110can access and retrieve Property Collections.

In one embodiment, a wallet module112can be a service or program that allows one party to make electronic transactions with another party bartering digital currency units for goods and services. This can include purchasing items on-line with a computer or using a smartphone to purchase something at a store. Money can be deposited in the digital wallet prior to any transactions or, in other cases, an individual's bank account can be linked to the digital wallet. Users might also have their driver's license, health card, loyalty card(s), and other ID documents stored within the wallet. The wallet module112can receive data from a client to effect an electronic funds transfer via ACH, bank wire, PayPal®, Venmo®, crypto currency (e.g., Bitcoin®, Doge®, Litecoin®, etc.). In another embodiment, the wallet module112can receive data related to a user's cryptocurrency address, or the holder's credentials. For example, the wallet module112could store a public-private key pair, or just a private key for a user of the system. See description related toFIG.2, below. In another embodiment, the wallet module112can provide for a plurality of encryption standard or interfaces. For example, a Private Key (PK) interface allows the Data-Client to be in charge of their own Private Keys; a Token Key (TK) interface could use a simple client-specific access token (GUID); and a Client Certificate (CC) interface could rely on the fact that the client installed a client certificate. In another embodiment, the wallet module112can be configured to facilitate an electronic financial transaction over the encrypted network140.

In one embodiment, the permissioning module114can provide control logic to allow a patient the ability to: ‘grant,’ ‘update,’ and ‘revoke’ permission to read data for a specific entity (e.g., Data-Client), and specific properties within that entity, from their personal data records, as detailed below.

The aforementioned systems, components, and modules can be communicably coupled to each other via the network140, such that data can be transmitted therebetween. The network140can be the Internet, intranet, computer bus, or other suitable network. The data transmission can be encrypted, unencrypted, over a VPN tunnel, or other suitable communication means. The network140can be a WAN, LAN, PAN, or other suitable network type. The network communication can be encrypted using PGP, Blowfish, Twofish, AES, 3DES, HTTPS, or other suitable encryption. The system100can be configured to provide communication via the various systems, components, and modules disclosed herein via an application programming interface (API), PCI, PCI-Express, ANSI-X12, Ethernet, Fiber, Wi-Fi, Bluetooth, or other suitable communication protocol or medium. Additionally, third party systems and databases160can be operably coupled to the system components via the network140.

The data transmitted to and from the components of system100(e.g., the server102, memory130, and clients150), can include any format, including the XPP format disclosed herein, JavaScript Object Notation (JSON), TCP/IP, XML, HTML, ASCII, SMS, CSV, representational state transfer (REST), or other suitable format. The data transmission can include a message, flag, header, header properties, metadata, and/or a body, or be encapsulated and packetized by any suitable format having same.

The server(s)102can be implemented in hardware, software, or a suitable combination of hardware and software therefor, and may comprise one or more software systems operating on one or more servers, having one or more processors104, with access to memory130. Server(s)102can include electronic storage, one or more processors, and/or other components. Server(s)102can include communication lines, connections, and/or ports to enable the exchange of information via a network140and/or other computing platforms. Server(s)102can also include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to server(s)102. For example, server(s)102can be implemented by a cloud of computing platforms operating together as server(s)102, including Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) functionality. Additionally, the server(s)102can include memory130, locally attached, network attached, or both.

Memory130can comprise electronic storage that can include non-transitory storage media that electronically stores information. The electronic storage media of electronic storage can include one or both of system storage that can be provided integrally (e.g., substantially non-removable) with server(s)102and/or removable storage that can be removably connectable to server(s)102via, for example, a port (e.g., a USB port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and/or other electronically readable storage media. Electronic storage may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources). The electronic storage can include a database, or public or private distributed ledger (e.g., blockchain). In one embodiment, memory130can be a blockchain implemented on one or more platforms, including BigChainDB, nChain, Ethereum, Hyperledger, R3, Ripple, EOS, or other suitable blockchain platform. The blockchain can be a public blockchain (accessible to the general public) or a private blockchain (accessible only by those parties credentialed for access). Electronic storage can store machine-readable instructions106, software algorithms, control logic, data generated by processor(s), data received from server(s), data received from computing platform(s), and/or other data that can enable server(s) to function as described herein. The electronic storage can also include third-party databases accessible via the network140.

Processor(s)104can be configured to provide data processing capabilities in server(s)102. As such, processor(s)104can include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information, such as FPGAs or ASICs. The processor(s)104can be a single entity or include a plurality of processing units. These processing units can be physically located within the same device, or processor(s)104can represent processing functionality of a plurality of devices or software functionality operating alone, or in concert.

The processor(s)104can be configured to execute machine-readable instructions106or machine learning modules via software, hardware, firmware, some combination of software, hardware, and/or firmware, and/or other mechanisms for configuring processing capabilities on processor(s)104. As used herein, the term “machine-readable instructions” can refer to any component or set of components that perform the functionality attributed to the machine-readable instructions component106. This can include one or more physical processors104during execution of processor-readable instructions, the processor-readable instructions, circuitry, hardware, storage media, or any other components.

The server(s)102can be configured with machine-readable instructions having one or more functional modules. The machine-readable instructions106can be implemented on one or more servers102, having one or more processors104, with access to memory130. The machine-readable instructions106can be a single networked node, or a machine cluster, which can include a distributed architecture of a plurality of networked nodes. The machine-readable instructions106can include control logic for implementing various functionality, as described in more detail below. The machine-readable instructions106can include certain functionality associated with the system100. Additionally, the machine-readable instructions106can include a smart contract or multi-signature contract that can process, read, and write data to the memory130, 3rd party database160, including a database, distributed ledger, or blockchain. In another embodiment, the Utility can be implemented via the one or more server(s)102.

FIG.2illustrates a table200listing Global Patient Record Property Path mapping examples, in accordance with one or more exemplary embodiments of the present disclosure. The table200lists a GPP example202, an associated derivation path204, and a description206. In one embodiment, a GPR Entity can be data, encapsulated within a Property Collection, within a Patient's GPR. The address to the entity can be described by a Global Patient Record Property Path (GPP). This path can be relative to a specific patient. In another embodiment, a hierarchical deterministic (HD) wallet can use derivation paths to specify an address to a keypair within the hierarchy. An HD wallet can be patient specific and used to manage a patient's public and private keys. As its name suggests there is one root key that can have child keys, with each child key having their own children. This can keep repeating into a large hierarchy. In one embodiment, an HD Wallet can automatically generate a hierarchical tree-like structure of private/public addresses (or keys), thereby addressing the problem of the user having to generate them on their own. In another embodiment, a GPP can be mapped to a derivation path. This mapping can associate a GPP with a keypair. As shown in table200, the GPP202can be mapped to an HD Wallet Derivation Path204.

In another embodiment, the Utility can implement a hierarchical deterministic wallet, in combination with Metanet technology to create the structure and storage for a Patient's GPR. For example, a Metanet can be a global protocol and framework for structuring and facilitating the on-chain internet for a BitcoinSV blockchain. In particular, the Metanet can be a protocol for creating transactions that allow on-chain data to form a graph structure, which can be interpreted and used off-chain by wallets, browsers, and applications. This metanet, coupled with a built-in permissioning system according to the present disclosure, can use the stable, underlying protocol of a BSV blockchain to ensure users and content creators are in complete control and own their data.

FIG.3illustrates a data request-grant-accept schematic300, in accordance with one or more exemplary embodiments of the present disclosure. In one embodiment, the Patient has the ability to ‘grant’ permission to read data for a specific entity, and specific properties within that entity, from their GPR. For example, if the Patient decides to grant the permission, the permissioning module can process data as follows: generation of a Data-Client Request Permission blockchain transaction (TX1)302having an Output-1.1 and Output-1.2; generation of a Patient Grant Permission blockchain transaction (TX2)304having an Output-2.1 and Output-2.2; and generation of a Data-Client Accept Permission blockchain transaction (TX3)306having an Output-3.1.

In another embodiment, a Data-Read-Permission request can be a ‘Property Collection’ (PC) containing specific properties that describe the read permission rights and an amount the Data-Client is willing to offer for the Data-Read-Permission rights. This PC can be written as part of a Data-Client Request Permission blockchain transaction (TX1)302, which can be issued by the Data-Client, as Output-1.1. The TX1 transaction302can have a second output (Output-1.2) that can pays an enticement to consider offer amount to the blockchain address of the Patient, from which the Data-Client is seeking permission. In another embodiment, if the Patient decides to grant the permission, the permissioning module can issue another blockchain transaction (TX2)304, with two outputs, that spends Output-1.2 of TX1302and pays a nominal amount to the Data-Client or Utility through Output-2.2 of TX2304. The Output-2.1 can be a data output, which contains a Property Collection (PC) with property values that specify that the permission has been granted. The TX2 transaction304can also send money to another blockchain address of the Patient (e.g., spending the enticement to consider amount). The Data-Client can then write another blockchain transaction (TX3)306, which can spend Ouput-2.2 of TX2 and pay the Patient the offer amount for the Data-Read-Permission. In another embodiment, the transaction TX3 can verify a contract granting access and paying the enticement amount. For example, these blockchain transactions can represent the Data-Read-Permission Contract between the Data-Client and the Patient. This contract will be verified when the Data-Client issues a request for the data (via Output-3.1) for which the Data-Read-Permission was granted. In another embodiment, one or more of the following ReadPermission Property Collection attributes can be used during this process:

NameTypeDescriptionRIDStringA GUID that will be used as the read permission ID.TypeString“r”-ReadPublicKeybyte arrayA public key representing an ID for the patient. Thepatient's root public key is not exposed.GPPstringThe GPP of the entity in which the permission applies.GPP_PropertiesPropertyA collection of PropertyPermission structures thatCollectiondefine the specific properties of an entity that areArrayaccessible.GPP_ChildrenBooleanA Boolean value that indicates if the permission is beinggranted to all child nodes of the GPP.FromDateTimeDateTimeA DateTime value used to indicate the minimum Dateand Time of when the data starts. If this field is notpresent, then all data from beginning of data untilToDateTime will be used.ToDateTimeDateTimeA DateTime value used to indicate the maximum Dateand Time of the data of when the date ends. If thisproperty is not present, then all data FromDateTime willbe used.ReadDataFunctionStringThe name of a data retrieval function used to extract theGPR Entity(s) and package it for the Data-Client.ReadDataQualifierStringThe name of a qualifier used to filter data as it isretrieved by the DataFunction.DurationUnitsstringA code that indicates what the duration unit is. Forexample: ‘day’, ‘single event’, etc.DurationIntegerThe number of units the permission is being granted for.DescriptionStringA detailed description of the permission.

In another embodiment, one or more of the following PropertyPermission Property Collection attributes can be used during this process:

NameTypeDescriptionIncludeBooleanA Boolean value, which indicates if the propertyshould be included (True) or excluded (False)GPPstringThe GPP of a property within the Entity to whichthe permissions apply.
READ PERMISSION EXAMPLE: Drug XYZ and Heart Rate Data

In one exemplary embodiment, a patient grants the following read access to Drug Company XYZ for Drug XYZ:1. Patients birthdate2. Patients zip3. Patients gender4. Patients allergies5. Patients genomics6. Patients Prescriptions/transactions for Drug XYZa. Once the transactions for Drug XYZ are known, the ReadDataFunction can determine the While_On_Drug_XYZ (Date range), which will be used within other GPP data queries.7. Patients Exercise Dataa. While_On_Drug_XYZ (+/−X Days)b. Datai. Start Date/Timeii. End Date/Timeiii. Description (i.e. running, walking, lifting, yoga)8. Patients Apple watch Heart Rate dataa. While_On_Drug_XYZ (+/−X Days)b. Data (i.e. predefined function)i. 10-minute intervalsii. Meaniii. Lowiv. High

Such permissioning can be more than just giving access to data items. It can be giving access to different types of data based on the date range of prescription transactions. Because of the complexity of defining the sub queries (e.g., heart rate data, etc.) as independent queries, a set of predefined functions that understand how to retrieve the data of interest can be implemented. Once a specific function is instantiated, the system can reference the function as part of the permission. These functions can be stored on the blockchain (e.g., in a catalog) with a description of what they do.

FIG.4illustrates a data request-deny schematic400, in accordance with one or more exemplary embodiments of the present disclosure. In one embodiment, the Patient has the ability to ‘deny’ permission to read data for a specific entity, and specific properties within that entity, from their GPR. For example, if the Patient decides to deny the permission, the permissioning module can process data as follows: generation of a Data-Client Request Permission blockchain transaction (TX1)302having an Output-1.1 and Output-1.2; and generation of a Patient Deny Permission blockchain transaction (TX2)402having an Output-2.1 and Output-2.2.

In another embodiment, if the Patient decides to deny the permission, the permissioning module can issue another blockchain transaction (TX2)402, with two outputs, which spends Output-1.2 of TX1302. The Output-2.1 can be a data output, which contains a Property Collection (PC) with property values that specify that the permission has been denied. The Output-2.2 can send the change of the transaction or a notification thereof to the Patient.

FIG.5illustrates a flowchart exemplifying permission request process flow control logic500, in accordance with one or more exemplary embodiments of the present disclosure. The request process flow control logic500can be implemented as an algorithm on a server102, a machine learning module, a client150, a memory130, a combination of one or more of the aforementioned components, or other suitable system. The request process flow control logic500can be achieved with software, hardware, an application programming interface (API), a network connection, a network transfer protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

The request process flow control logic500can leverage the ability of a computer platform to spawn multiple processes and threads by processing data simultaneously. The speed and efficiency of the request process flow control logic500can be greatly improved by instantiating more than one process to implement a permission request. However, one skilled in the art of programming will appreciate that use of a single processing thread may also be utilized and is within the scope of the present disclosure.

Since patients may not interact directly with companies interested in acquiring their data, there can be a mechanism that can allow a request to be sent to the patient with a clear understanding of the following:What the data will be used for.The date range, if applicable, for the request.The data elements for which permission is being requested.The process of collecting the data.The date range, the permission will be valid.

When a company such as Drug Company XYZ, wants to gain access to data, they can submit a request, provide a description, and determine if a predefined Permission Template already exists for the type of request.

The request process flow control logic500of the present embodiment begins at step502, where the control logic500can generate or receive a patient data access request. In one embodiment, the request can be from a client. In another embodiment, the request can include request data having one or more fields, parameters, characteristics, or metadata. For example, the patient access request can include healthcare parameters, pharmaceutical parameters, clinical parameters, demographic parameters, time parameters, volume parameters, frequency parameters, or other relevant parameters. In another exemplary embodiment, the request can include a command such as upload, download, save, retrieve, or other suitable command. The control logic500then proceeds to step504.

At step504, the control logic500can determine whether a request template exists. In one embodiment, the request template can be retrieved from the blockchain. For example, the request template can be stored in a catalog of templates (e.g., Read Permission Request Catalog) stored in the blockchain. If a request template exists, the control logic500proceeds to step508. If the request template does not exist, the control logic proceeds to step506.

At step506, the control logic500can generate a permission template including at least a portion of the data from the request. In one embodiment, the template can have a standardized set of fields or parameters based upon the request. In another embodiment, the template can transform the request into a standardized format processable by the system. In another embodiment, a permission template can be generated listing the requirements of the request. In another embodiment, the requirements can be written and packaged as a data retrieval function and installed on a decrypt server. This function can be added to the new template. The finalized permission request template can be stored in a request catalog (e.g., on the blockchain). The control logic500then proceeds to step508.

At step508, the control logic500can populate request template with request parameters. In one embodiment, the control logic500can parse the request to populate one or more corresponding fields in the template. For example, the template can have a standardized set of fields or parameters based upon the request. In another embodiment, the control logic can use the template to transform the request into a standardized format processable by the system. The control logic500then proceeds to step510.

At step510, control logic500can query a database for patients matching the request parameters. In one embodiment the control logic500can generate a query response with a listing of patients matching the query. The control logic500then proceeds to step512.

At step512, the control logic500can filter a database query response to identify patients matching additional parameters or narrow the list of patients according to the additional parameters. In one embodiment, not enough patients are returned matching the query so the control logic500can widen the search by adding additional parameters to the query. For example the thresholds for the number of query returns and the additional parameters can be included in the request. In another embodiment, too many patients are returned matching the query so the control logic500can narrow the search by adding additional parameters to the query. The control logic500then proceeds to step514.

At step514, the control logic500can populate a request template having a matching patient unique ID (e.g., public key). In one embodiment, The template can be populated with the relevant properties for the request. The GPR Database (e.g., BC RAW DB) can be queried to identify the patients that match the requirements of the request. In another embodiment, for each patient that qualifies: The template will be populated with the Public Key of the patient and the ‘ReadPermissionRequest’ can be transmitted to the patient. The control logic then proceeds to step516.

At step516, the control logic500can transmit a populated request template to matching patients. In one embodiment, the request template can identify the types of data for which access is requested. In another embodiment, the request template can indicate an offer amount for access to the requested data. The control logic500then terminates or awaits a new request and can repeat the aforementioned steps.

In one embodiment, a GPR data read permission request can include:

Property NameTypeDescriptionRIDStringA GUID that will be used as the ID for theread permission request.DescriptionStringA Description of the data that is beingrequested.Duration_UnitStringA code that indicates the requested durationunit. For example: ‘day’, ‘single event’, etc.DurationUnitsstringA code that indicates what the duration unitis. For example: ‘day’, ‘single event’, etc.

In one embodiment, a GPR data read permission response can include:

PropertyExample ValueGPPPatient.PrescriptionsGrant read access to thepatient's prescriptions.GPP_FilterDrug_XYZThe name of a ‘filter’that limits the ‘result set’of the GPP to only beprescriptions that werewritten for Drug XYZ.GPP_Filter_Result_Setdrug_xyz_rsThe name of the resultset

In one embodiment, the control logic500can have built-in functions. For example, the control logic500can assign a name to the ‘result set,’ having the ‘drug_xyz_rs.values,’ which can be the collections of RxTx collections and the drug. In another embodiment, control logic500can execute a collection of functions that can determine, for example, the date range—given a list of prescription transactions. The result set can be a predefined or dynamic PC. The control logic can execute SQL commands to filter the results set, for example: select min(date_of_service) from ‘result set’ and select max(date_of_service) from ‘result set.’ For example, the GPP can be the address of the data; the GPP_Filter can be a predefined filter that can consider all PCs of GPP and produce a result set. The result set functions can be a collection of filter creation functions. Given a result set, the control logic500can run a function that can create a Filter, that can be used to ‘filter’ other data sets. In another embodiment, the control logic500can define functions that return a dynamic filter and store them on the blockchain. For example, Filter While_On_Drug_XYZ=DetermineMinMax(result_set).

FIG.6illustrates a flowchart exemplifying data write request process flow control logic600, in accordance with one or more exemplary embodiments of the present disclosure. The data write request process flow control logic600can be implemented as an algorithm on a server102, a machine learning module, a client150, a memory130, a combination of one or more of the aforementioned components, or other suitable system. The data write request process flow control logic600can be achieved with software, hardware, an application programming interface (API), a network connection, a network transfer protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

The data write request process flow control logic600can leverage the ability of a computer platform to spawn multiple processes and threads by processing data simultaneously. The speed and efficiency of the data write request process flow control logic600can be greatly improved by instantiating more than one process to implement a data write request. However, one skilled in the art of programming will appreciate that use of a single processing thread may also be utilized and is within the scope of the present disclosure.

In one embodiment, a Data-Write-Permission request can be a ‘Property Collection’ (PC) containing specific properties that describe the write permission rights and an amount the Data-Client is willing to offer for the Data-write-Permission rights. In one embodiment, this PC can be written as part of a blockchain transaction (TX1) (e.g., Bitcoin-SV), which can be issued by the Data-Client, as Output-1.1. The TX1 transaction can have a second output (Output-1.2) that can pay an enticement to consider offer amount to the blockchain address of the Patient, from which the Data-Client is seeking permission. If the Patient decides to grant the permission, the Patient can issue another blockchain transaction (TX2) that can spend Output-1.2 of TX1 and pay a nominal amount to the Data-Client through Output-2.2. The TX2 transaction can also send money to another blockchain address of the Patient (e.g., spending the enticement to consider amount). The Data-Client can then write another blockchain transaction (TX3), which can spend Ouput-2.2 of TX2 and pay the Patient the offer amount for the Data-Read-Permission. These blockchain transactions can represent the Data-Write-Permission Contract between the Data-Client and the Patient. This contract can be verified when the Data-Client issues a data write request associated with the Data-Write-Permission.

The request process flow control logic600of the present embodiment begins at step602, where the control logic600can receive a write permission request indicating an offer amount. In one embodiment, the request can be from a client. In another embodiment, the request can include request data having one or more fields, parameters, characteristics, or metadata. For example, the patient access request can include healthcare parameters, pharmaceutical parameters, clinical parameters, demographic parameters, time parameters, volume parameters, frequency parameters, or other relevant parameters. In another exemplary embodiment, the request can include a command such as upload, download, save, retrieve, or other suitable command. The control logic600then proceeds to step604.

Add step604, the control logic600can instantiate a first blockchain transaction for requesting permission. The control logic600. Then proceeds to step606.

At step606, the control logic600can write the write permission request to a blockchain as part of the first blockchain transaction. The control logic then proceeds to step608.

Add steps608, the control logic600can transfer the offer amount to a first blockchain address associated with the patient as part of the first blockchain transaction. In one embodiment, a patient can have one or more blockchain addresses associated with the patient. For example, each blockchain entry having a unique ID associated with the patient can have an address, that address can be associated with the patient via the unique ID. The control logic600then proceeds to step610.

At step610, the control logic600can determine whether permission was granted. If permission was not granted, the control logic600proceeds to step612. If permission was granted, the control logic600proceeds to step614.

At step612, the control logic600can terminate the first blockchain transaction. The control logic600can then terminate or await a new request and repeat the aforementioned steps.

At step614, the control logic600can instantiate a second blockchain transaction for granting permission. The control logic600then proceeds to step616.

At step616, the control logic600can transfer the transferred offer amount to a second blockchain address associated with the patient as part. Of the second blockchain transaction. The control logic600then proceeds to step618.

At step618, the control logic600can transfer a utility amount to a blockchain address associated with a data client or utility as part of the second blockchain transaction. The control logic600then proceeds to Step620.

At step620, control logic600can instantiate a third blockchain transaction for accepting permission. The control logic600then proceeds to step622.

At step622, the control logic600can pay the data client or the utility the utility amount and pay the patient the offer amount less the utility amount. The control logic600can then terminate or await a new request and repeat the aforementioned steps.

In another embodiment, a Write Permission Property Collection can include the following:

NameTypeDescriptionTypeString“w”-ReadPublicKeybyte arrayA public key representing an ID forthe patient. The patient's root publickey is not exposed.GPPstringThe GPP of the entity in which thepermission applies.GPP_ChildrenBooleanA Boolean value that indicates if thepermission is being granted to all childnodes of the GPP.FromDateTimeDateTimeA DateTime value used to indicate theminimum Date and Time of when thewrite permission starts. If this fieldis not present, then write permissionstarts immediately.ToDateTimeDateTimeA DateTime value used to indicate themaximum Date and Time of the writepermission is effective. If this propertyis not present the write permission isindefinite.DurationUnitsstringA code that indicates what the durationunit is. For example: ‘day’, ‘singleevent’, etc.DurationIntegerThe number of units the permission isbeing granted for.DescriptionStringA detailed description of the permission.

FIG.7illustrates an electronic health record data read system700schematic, in accordance with one or more exemplary embodiments of the present disclosure. The electronic health record data read system700can include a data client702, a decrypt server706, a GPR database708, a blockchain reader712, and a blockchain710. In one embodiment, the data client702can be a client150, the decrypt server can be a server102, the GPR database can be a memory130, the block chain reader712can be a transaction blockchain API110, and the blockchain can be a memory130. For example, a Data-Client can be a software component that requests data to be queried and returned based on a preexisting and valid read permission contract; a Read Request can be a message that can request GPR entity data to be queried and returned; a Read Response can be the requested GPR decrypted data; a Decrypt Server can be responsible for looking up the predefined permission request by querying the BC-RAW DB for the entities covered by a preexisting and valid read permission contract; a BC-RAW DB can be a database that contains GPR Entity data—the data within this database can be encrypted; a BC-Reader can read blocks from the Blockchain, processes each transaction within the block and determine if the transaction contains GPR data—if the transaction does contain GPR data, the data can be loaded into the BC-Raw DB; and a BSV BC can be the Blockchain.

Since at least a portion of the data within the GPR can be encrypted it can remain encrypted until it is requested. The decrypt server can be used to decrypt data from the GPR database (e.g., BC-Raw DB). The decrypt server can be encrypt and decrypt data using PGP, Blowfish, Twofish, AES, 3DES, HTTPS, or other suitable encryption standards. The data in the BC-Raw DB708may have been previously read from the Blockchain710(e.g., BSV BC).

In another embodiment, when the Decrypt Server706receives a Read Request704, it determines if the sender is authorized to submit the request. For example, the authorization can be performed by checking a digital signature that may be provided with the request. In another embodiment, once the request has been authorized, the Decrypt Server706queries the BC-RAW DB708for the GPR entities that were defined by a preexisting and valid permission contract. In another embodiment, once the entities have been retrieved, each entity can be decrypted using the Private Key of the node where it was stored in the blockchain710(e.g., Metanet Tree within the Bitcoin SV blockchain). Once the entity has been decrypted, the serialized byte array can be returned to the client in the Decrypt Response.

Although one or more embodiments may reference a patient, the present disclosure applies to any type of entity, whether a person, patient, customer, company, or other suitable entity capable of having data stored in a record associated with that entity. Similarly, although certain embodiments may reference electronic health records, the systems, methods, and concepts disclosed herein are equally applicable to any storage system or record type.

Persons skilled in the art will readily understand that advantages and objectives described above would not be possible without the particular combination of computer hardware and other structural components and mechanisms assembled in this inventive system and described herein. Additionally, the algorithms, methods, and processes disclosed herein improve and transform any general-purpose computer or processor disclosed in this specification and drawings into a special purpose computer programmed to perform the disclosed algorithms, methods, and processes to achieve the aforementioned functionality, advantages, and objectives. It will be further understood that a variety of programming tools, known to persons skilled in the art, are available for generating and implementing the features and operations described in the foregoing. Moreover, the particular choice of programming tool(s) may be governed by the specific objectives and constraints placed on the implementation selected for realizing the concepts set forth herein and in the appended claims.

The description in this patent document should not be read as implying that any particular element, step, or function can be an essential or critical element that must be included in the claim scope. Also, none of the claims can be intended to invoke 35 U.S.C. § 112(f) with respect to any of the appended claims or claim elements unless the exact words “means for” or “step for” are explicitly used in the particular claim, followed by a participle phrase identifying a function. Use of terms such as (but not limited to) “mechanism,” “module,” “device,” “unit,” “component,” “element,” “member,” “apparatus,” “machine,” “system,” “processor,” “processing device,” or “controller” within a claim can be understood and intended to refer to structures known to those skilled in the relevant art, as further modified or enhanced by the features of the claims themselves, and can be not intended to invoke 35 U.S.C. § 112(f). Even under the broadest reasonable interpretation, in light of this paragraph of this specification, the claims are not intended to invoke 35 U.S.C. § 112(f) absent the specific language described above.

The disclosure may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. For example, each of the new structures described herein, may be modified to suit particular local variations or requirements while retaining their basic configurations or structural relationships with each other or while performing the same or similar functions described herein. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive. Accordingly, the scope of the inventions can be established by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Further, the individual elements of the claims are not well-understood, routine, or conventional. Instead, the claims are directed to the unconventional inventive concept described in the specification.