ABSTRACT
Abstract
Healthcare transaction validation systems and methods are presented. Healthcare transactions associated with a stakeholder are compiled into a chain of healthcare transaction blocks. The chain can be considered a chronicle of person's healthcare path through life. When a transaction is conducted, the corresponding healthcare parameters (e.g., inputs, outputs, clinical evidence, outcomes, etc.) are sent to one or more validation devices. The devices establish a validity of the transaction and generate a new block via a proof-of-work principle. Once the new block has been calculated it can be appended to the stakeholder's health care blockchain.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims the benefit of U.S. Provisional Application No. 61/992,734, filed May 13, 2014. The entire content of that application is hereby incorporated herein by reference.
FIELD OF THE INVENTION
The field of the invention is transaction validation technologies.
BACKGROUND
The background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
Cryptocurrencies have risen over the last few years. The most famous cryptocurrency is Bitcoin, launched in 2009, as described in the original paper openly published on May 24, 2009, by Nakamoto and titled âBitcoin: A Peer-to-Peer Electronic Cash Systemâ (see URL en.bitcoin.it/wiki/Bitcoin_white_paper).
Cryptocurrencies operate on the principle of applying proof-of-work (POW) principles to process Bitcoin transactions that are bound together in large blocks of data. The device that successfully meets the proof-of-work requirements (i.e., generating a double hash value with a required number of leading zero bits) for the transaction block and has their block accepted by peers receives a reward in the form of Bitcoins.
Although Bitcoin is probably the most famous application of POW, many others have applied POW to other areas of technology. For example, U.S. Pat. No. 7,356,696 to Jakobsson et al. titled âProofs of Work and Bread Pudding Protocolsâ, filed Aug. 1, 2000, describes re-using stale computations of a POW to continue minting digital currency.
Another example of using POW further afield from cryptocurrency includes U.S. Pat. No. 7,600,255 to Baugher titled âPreventing Network Denial of Service Attacks Using an Accumulated Proof-of-work Approachâ, filed Apr. 14, 2004. Baugher requires a computer client to generate a POW to access a service where the POW could include hashing a message until a desired number of leading bit-level zeros is found, similar to the POW of Bitcoin.
In a somewhat similar vein to Baugher, U.S. Pat. No. 8,412,952 to Ramzan et al. titled âSystems and Methods for Authenticating Requests from a Client Running Trialware Through a Proof of Work Protocolâ, filed May 6, 2009, also uses POW to grant access to services. Ramzan describes generating a cryptographic puzzle if no authentication token is included with a service request to run trialware. The client making the request must solve the cryptographic puzzle in order to receive authentication to proceed with running the trialware.
All publications identified herein are incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.
The following description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
In some embodiments, the numbers expressing quantities of ingredients, properties such as concentration, reaction conditions, and so forth, used to describe and claim certain embodiments of the invention are to be understood as being modified in some instances by the term âabout.â Accordingly, in some embodiments, the numerical parameters set forth in the written description and attached claims are approximations that can vary depending upon the desired properties sought to be obtained by a particular embodiment. In some embodiments, the numerical parameters should be construed in light of the number of reported significant digits and by applying ordinary rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of some embodiments of the invention are approximations, the numerical values set forth in the specific examples are reported as precisely as practicable. The numerical values presented in some embodiments of the invention may contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements.
Unless the context dictates the contrary, all ranges set forth herein should be interpreted as being inclusive of their endpoints and open-ended ranges should be interpreted to include only commercially practical values. Similarly, all lists of values should be considered as inclusive of intermediate values unless the context indicates the contrary.
As used in the description herein and throughout the claims that follow, the meaning of âa,â âan,â and âtheâ includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of âinâ includes âinâ and âonâ unless the context clearly dictates otherwise.
The recitation of ranges of values herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range. Unless otherwise indicated herein, each individual value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. âsuch asâ) provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.
Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all Markush groups used in the appended claims.
SUMMARY
Interestingly, the above known proof-of-work (POW) systems have only focused on transaction processing or authentication. It has yet to be appreciated that POW systems could be deployed in other areas. One market that is fraught with issues includes healthcare systems that manage large volumes of electronic medical records (EMR). Example issues include enforcing privacy, standards compliance, interoperability, data format conversion, ensuring proper treatment applied to a patient, and especially the difficulty maintaining a continuity of treatment records for individuals. As a representative example of the state of the art, consider U.S. Pat. No. 8,615,532 to Bessette titled âSystem and Method for Electronically Managing Medical Data Filesâ, filed Sep. 12, 2012. Bessette discusses one of myriad possible ways in which medical records can be updated assuming proper authentication.
Even with the countless healthcare management or EMR systems available, the systems lack the ability to properly construct a history of health transaction across various entities. A more ideal system would create of chain of transactions from various entities where each transaction is validated via a POW approach. Such a validation approach ensures that all entities are held responsible for their transactions by peer review while also preserving a record of healthcare transactions. Thus, there remains a need validating healthcare transactions.
The inventive subject matter provides apparatus, systems and methods in which a proof-of-work system can be employed to track or validate healthcare transactions. One aspect of the inventive subject matter includes a method of validating healthcare transactions. The disclosed methods can include receiving, by one or more validation devices, a healthcare transaction that includes a set of healthcare tokens that represent healthcare actions taken with respect to a stakeholder. For example, the healthcare tokens might include test results for a patient and a corresponding diagnosis from a doctor. The validation device continues executing the method by obtaining a historical block identifier of the stakeholder's healthcare historical blockchain. The healthcare historical blockchain represents a chronicle of healthcare activities in the form of a substantially linear set of healthcare transactions for the particular stakeholder (e.g., patient, doctor, insurance company, hospital, etc.). The method also includes receiving a validity requirement with respect to the healthcare actions indicating criteria that must be met in order for the system to accept a validation event with respect to the transaction. The validation device continues to validate the healthcare actions by obtain a digital signature of a validator, perhaps another healthcare provider's public key or an expert system identifier. In addition, the method includes obtaining a validity token indicating the validity of the healthcare actions (e.g., valid action, invalid action, indeterminate, etc.). Once the various pieces of information has been collected, the validation device calculates a validity block based on the transaction and according the validity requirements as a function of the healthcare action parameters: the validity token, historical block identifier, the set of healthcare tokens, and the digital signature. Should the validity requirements be met, the validation device can cause the healthcare historical blockchain to be updated, possibly by appending the validity block to the chain. In some embodiments, proof-of-work methods are not necessarily employed. In some embodiments, proof-of-stake methods are used to authenticate a validity block to be appended to a stakeholder's healthcare historical blockchain.
Various objects, features, aspects and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic overview of a healthcare transaction ecosystem.
FIG. 2 illustrates a method of validating a healthcare transaction.
FIG. 3 illustrates further details of processing carried out by one of the steps of FIG. 2 .
FIG. 4 shows an example of a computer system (one or more of which may provide the components shown in FIG. 1 ) that may be used to execute instruction code contained in a computer program product in accordance with an embodiment of the present invention.
DETAILED DESCRIPTION
It should be noted that any language directed to a computer should be read to include any suitable combination of computing devices, including servers, interfaces, systems, databases, agents, peers, engines, controllers, or other types of computing devices operating individually or collectively. One should appreciate the computing devices comprise a processor configured to execute software instructions stored on a tangible, non-transitory computer readable storage medium (e.g., hard drive, solid state drive, RAM, flash, ROM, etc.). The software instructions preferably configure the computing device to be operable to provide the roles, responsibilities, or other functionality as discussed below with respect to the disclosed apparatus. Further, the disclosed technologies can be embodied as a computer program product that comprises a non-transitory computer readable medium storing the software instructions that causes a processor to execute the disclosed steps. In especially preferred embodiments, the various servers, systems, databases, or interfaces exchange data using standardized protocols or algorithms, possibly based on HTTP, HTTPS, AES, public-private key exchanges, web service APIs, known financial transaction protocols, or other electronic information exchanging methods. Data exchanges preferably are conducted over a packet-switched network, the Internet, LAN, WAN, VPN, or other type of packet switched network.
One should appreciate that the disclosed techniques provide many advantageous technical effects including construction and storage of a healthcare blockchain representing healthcare transactions of a patient or other healthcare stakeholder. Construction and storage of the healthcare blockchain enables computing devices to quickly and efficient validate or access healthcare data, thereby improving the performance of the computing devices.
The following discussion provides many example embodiments of the inventive subject matter. Although each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly disclosed.
As used herein, and unless the context dictates otherwise, the term âcoupled toâ is intended to include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements). Therefore, the terms âcoupled toâ and âcoupled withâ are used synonymously.
The following discussion presents the inventive subject matter from the perspective of a patient interacting with a doctor. With respect to the disclosed subject matter, the patient's healthcare interactions are chronicled via an associated healthcare historical record represented by a blockchain. As the doctor performs services for the patient, information related to the services (e.g., inputs, outputs, codes, etc.) are packaged in the form of a healthcare transaction. The transactions are analyzed by peers in the ecosystem with respect to validity of the services. Once analyzed the transactions are incorporated into the patient's healthcare historical blockchain. Although the subject matter is presented from the perspective of a patient-doctor interaction, it should be appreciated that the transactions can relate to other types of interactions. Additional interactions could include doctor-insurance transactions, consumer-insurance interactions, patient-psychologist interactions, or other types of transactions.
<div id="p-0030
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims the benefit of U.S. Provisional Application No. 61/992,734, filed May 13, 2014. The entire content of that application is hereby incorporated herein by reference.
FIELD OF THE INVENTION
The field of the invention is transaction validation technologies.
BACKGROUND
The background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
Cryptocurrencies have risen over the last few years. The most famous cryptocurrency is Bitcoin, launched in 2009, as described in the original paper openly published on May 24, 2009, by Nakamoto and titled âBitcoin: A Peer-to-Peer Electronic Cash Systemâ (see URL en.bitcoin.it/wiki/Bitcoin_white_paper).
Cryptocurrencies operate on the principle of applying proof-of-work (POW) principles to process Bitcoin transactions that are bound together in large blocks of data. The device that successfully meets the proof-of-work requirements (i.e., generating a double hash value with a required number of leading zero bits) for the transaction block and has their block accepted by peers receives a reward in the form of Bitcoins.
Although Bitcoin is probably the most famous application of POW, many others have applied POW to other areas of technology. For example, U.S. Pat. No. 7,356,696 to Jakobsson et al. titled âProofs of Work and Bread Pudding Protocolsâ, filed Aug. 1, 2000, describes re-using stale computations of a POW to continue minting digital currency.
Another example of using POW further afield from cryptocurrency includes U.S. Pat. No. 7,600,255 to Baugher titled âPreventing Network Denial of Service Attacks Using an Accumulated Proof-of-work Approachâ, filed Apr. 14, 2004. Baugher requires a computer client to generate a POW to access a service where the POW could include hashing a message until a desired number of leading bit-level zeros is found, similar to the POW of Bitcoin.
In a somewhat similar vein to Baugher, U.S. Pat. No. 8,412,952 to Ramzan et al. titled âSystems and Methods for Authenticating Requests from a Client Running Trialware Through a Proof of Work Protocolâ, filed May 6, 2009, also uses POW to grant access to services. Ramzan describes generating a cryptographic puzzle if no authentication token is included with a service request to run trialware. The client making the request must solve the cryptographic puzzle in order to receive authentication to proceed with running the trialware.
All publications identified herein are incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.
The following description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
In some embodiments, the numbers expressing quantities of ingredients, properties such as concentration, reaction conditions, and so forth, used to describe and claim certain embodiments of the invention are to be understood as being modified in some instances by the term âabout.â Accordingly, in some embodiments, the numerical parameters set forth in the written description and attached claims are approximations that can vary depending upon the desired properties sought to be obtained by a particular embodiment. In some embodiments, the numerical parameters should be construed in light of the number of reported significant digits and by applying ordinary rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of some embodiments of the invention are approximations, the numerical values set forth in the specific examples are reported as precisely as practicable. The numerical values presented in some embodiments of the invention may contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements.
Unless the context dictates the contrary, all ranges set forth herein should be interpreted as being inclusive of their endpoints and open-ended ranges should be interpreted to include only commercially practical values. Similarly, all lists of values should be considered as inclusive of intermediate values unless the context indicates the contrary.
As used in the description herein and throughout the claims that follow, the meaning of âa,â âan,â and âtheâ includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of âinâ includes âinâ and âonâ unless the context clearly dictates otherwise.
The recitation of ranges of values herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range. Unless otherwise indicated herein, each individual value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. âsuch asâ) provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.
Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all Markush groups used in the appended claims.
SUMMARY
Interestingly, the above known proof-of-work (POW) systems have only focused on transaction processing or authentication. It has yet to be appreciated that POW systems could be deployed in other areas. One market that is fraught with issues includes healthcare systems that manage large volumes of electronic medical records (EMR). Example issues include enforcing privacy, standards compliance, interoperability, data format conversion, ensuring proper treatment applied to a patient, and especially the difficulty maintaining a continuity of treatment records for individuals. As a representative example of the state of the art, consider U.S. Pat. No. 8,615,532 to Bessette titled âSystem and Method for Electronically Managing Medical Data Filesâ, filed Sep. 12, 2012. Bessette discusses one of myriad possible ways in which medical records can be updated assuming proper authentication.
Even with the countless healthcare management or EMR systems available, the systems lack the ability to properly construct a history of health transaction across various entities. A more ideal system would create of chain of transactions from various entities where each transaction is validated via a POW approach. Such a validation approach ensures that all entities are held responsible for their transactions by peer review while also preserving a record of healthcare transactions. Thus, there remains a need validating healthcare transactions.
The inventive subject matter provides apparatus, systems and methods in which a proof-of-work system can be employed to track or validate healthcare transactions. One aspect of the inventive subject matter includes a method of validating healthcare transactions. The disclosed methods can include receiving, by one or more validation devices, a healthcare transaction that includes a set of healthcare tokens that represent healthcare actions taken with respect to a stakeholder. For example, the healthcare tokens might include test results for a patient and a corresponding diagnosis from a doctor. The validation device continues executing the method by obtaining a historical block identifier of the stakeholder's healthcare historical blockchain. The healthcare historical blockchain represents a chronicle of healthcare activities in the form of a substantially linear set of healthcare transactions for the particular stakeholder (e.g., patient, doctor, insurance company, hospital, etc.). The method also includes receiving a validity requirement with respect to the healthcare actions indicating criteria that must be met in order for the system to accept a validation event with respect to the transaction. The validation device continues to validate the healthcare actions by obtain a digital signature of a validator, perhaps another healthcare provider's public key or an expert system identifier. In addition, the method includes obtaining a validity token indicating the validity of the healthcare actions (e.g., valid action, invalid action, indeterminate, etc.). Once the various pieces of information has been collected, the validation device calculates a validity block based on the transaction and according the validity requirements as a function of the healthcare action parameters: the validity token, historical block identifier, the set of healthcare tokens, and the digital signature. Should the validity requirements be met, the validation device can cause the healthcare historical blockchain to be updated, possibly by appending the validity block to the chain. In some embodiments, proof-of-work methods are not necessarily employed. In some embodiments, proof-of-stake methods are used to authenticate a validity block to be appended to a stakeholder's healthcare historical blockchain.
Various objects, features, aspects and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic overview of a healthcare transaction ecosystem.
FIG. 2 illustrates a method of validating a healthcare transaction.
FIG. 3 illustrates further details of processing carried out by one of the steps of FIG. 2 .
FIG. 4 shows an example of a computer system (one or more of which may provide the components shown in FIG. 1 ) that may be used to execute instruction code contained in a computer program product in accordance with an embodiment of the present invention.
DETAILED DESCRIPTION
It should be noted that any language directed to a computer should be read to include any suitable combination of computing devices, including servers, interfaces, systems, databases, agents, peers, engines, controllers, or other types of computing devices operating individually or collectively. One should appreciate the computing devices comprise a processor configured to execute software instructions stored on a tangible, non-transitory computer readable storage medium (e.g., hard drive, solid state drive, RAM, flash, ROM, etc.). The software instructions preferably configure the computing device to be operable to provide the roles, responsibilities, or other functionality as discussed below with respect to the disclosed apparatus. Further, the disclosed technologies can be embodied as a computer program product that comprises a non-transitory computer readable medium storing the software instructions that causes a processor to execute the disclosed steps. In especially preferred embodiments, the various servers, systems, databases, or interfaces exchange data using standardized protocols or algorithms, possibly based on HTTP, HTTPS, AES, public-private key exchanges, web service APIs, known financial transaction protocols, or other electronic information exchanging methods. Data exchanges preferably are conducted over a packet-switched network, the Internet, LAN, WAN, VPN, or other type of packet switched network.
One should appreciate that the disclosed techniques provide many advantageous technical effects including construction and storage of a healthcare blockchain representing healthcare transactions of a patient or other healthcare stakeholder. Construction and storage of the healthcare blockchain enables computing devices to quickly and efficient validate or access healthcare data, thereby improving the performance of the computing devices.
The following discussion provides many example embodiments of the inventive subject matter. Although each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly disclosed.
As used herein, and unless the context dictates otherwise, the term âcoupled toâ is intended to include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements). Therefore, the terms âcoupled toâ and âcoupled withâ are used synonymously.
The following discussion presents the inventive subject matter from the perspective of a patient interacting with a doctor. With respect to the disclosed subject matter, the patient's healthcare interactions are chronicled via an associated healthcare historical record represented by a blockchain. As the doctor performs services for the patient, information related to the services (e.g., inputs, outputs, codes, etc.) are packaged in the form of a healthcare transaction. The transactions are analyzed by peers in the ecosystem with respect to validity of the services. Once analyzed the transactions are incorporated into the patient's healthcare historical blockchain. Although the subject matter is presented from the perspective of a patient-doctor interaction, it should be appreciated that the transactions can relate to other types of interactions. Additional interactions could include doctor-insurance transactions, consumer-insurance interactions, patient-psychologist interactions, or other types of transactions.
FIG. 1 presents an overview of healthcare transaction validation system 100 where peers in a healthcare network are configured or programmed to manage healthcare transactions in the form of healthcare historical blockchains 130 . Each block in the chain includes one or more healthcare transactions that further incorporate validation information representing the validity of the transaction as assessed by peer validation devices 120 (e.g., peers 120 A through 120 N), collectively referred to as peers 120 . In some embodiments, peers 120 operate collectively in a peer-to-peer network. Further the device can exist within a clinical operating system ecosystem; possibly based on the cOS⢠services offered by Nanthealth, LLC (see URL nanthealth.com/cos-clinical-operating-system).
Stakeholder 110 represents an entity that has a stake in a healthcare management lifecycle. A shown, stakeholder 110 could be a patient. However, stakeholder 110 could represent other types of entities. In some embodiments, stakeholder 110 could be another person, possibly a doctor, a nurse, a technician, a care provider, a guardian, a parent, a broker, or other individual. Further, stakeholder 110 could also include other types of entities including a company, an affiliation, a hospital, an organization, a demographic, a community, or other type of entity.
Of particular interest with respect to the inventive subject matter is that each stakeholder 110 could have associated healthcare historical blockchain (HHBC) 130 . HHBC 130 represents a chronicle or ledger (e.g., public ledger, private ledger, protected ledger, etc.) of healthcare transactions for stakeholder 110 . With respect to a patient, HHBC 130 might start with an initial block or genesis block created at birth that includes information associated with the patient's birth (e.g., parent information, attending physician, Apgar score, etc.). Each subsequent healthcare transaction for the patient can be combined with HHBC 130 as a new block, possibly until the HHBC becomes terminated at the death of the patient. It should be appreciated that each entity can have its own blockchain in the disclosed ecosystem rather than the complete ecosystem having a single chain covering all transactions as is done with cryptocurrencies.
HHBC 130 could comprise any number of blocks. For a healthy patient, HHBC 130 might only increase in size by one block per year based on annual visits to the doctor. However, when stakeholder 110 comprises a surgeon, the surgeon's HHBC 130 might represent performed surgeries where the surgeon's HHBC might increase in size by several blocks per day. Even further, when stakeholder 110 is a hospital, HHBC 130 could increase by hundreds of blocks per day. Large scale insurance companies might have HHBCs 130 that increase by thousands of blocks per day.
Returning to the example shown where a patient interacts with a doctor; the doctor works to understand the circumstances of the patient. Such information can be considered to represent input information related to the healthcare transaction in progress. Based on the information, the doctor preforms one or more actions; possibly including applying treatment, generating a diagnosis, establishing a prognosis, or other types of actions. The actions taken by the doctor can be considered outputs to or outcomes of the healthcare transaction.
The various attributes or properties of the inputs and outputs can be represented by healthcare tokens 132 . Healthcare tokens 132 represent the information defining the nature of the healthcare transaction associated within stakeholder 110 . In more preferred embodiments, healthcare tokens 132 adhere to a defined, possibly standardized, healthcare namespace. For example, the healthcare namespace might include standardized codes (e.g., ICD 9, ICD 10, CPT, DSM, etc.) that categorize the inputs and outputs.
Use of a common healthcare namespace aids in creating a common reference frame or nomenclature among peers 120 as they process or validate the healthcare transactions. Such an approach ensures all peers 120 or stakeholders 110 represent information according to a common language, which ensures that the transactions are processed in a uniform, repeatable, and verifiable manner. More preferred healthcare namespaces include normalized terms, especially in circumstances where conflicting codes might exist (e.g., ICD-9 codes 290 - 319 for mental disorders versus DSM-IV codes for mental disorder; although some harmonization exists between these two schemes).
Peer 120 A, perhaps the doctor's EMR system, can package healthcare tokens 132 for delivery to one or more validation devices; peers 120 B through 120 M for example. For example, healthcare tokens 132 can be packaged in an XML, JSON, or other formats suitable for exchanging data over network 115 . The phrase âtokensâ herein is used in the broader sense of parsing data into tokens (useful groupings of data) rather than in the narrow data security context. In other words, healthcare tokens and validity tokens referenced herein are not necessarily hashed or otherwise processed to make the underlying data unrecoverable.
In the example shown, peer 120 B obtains healthcare tokens 132 and attempts generate validity block 135 that comprises the healthcare transaction represented by healthcare tokens 132 among other pieces of information. For example, the transaction could include a transaction ID, a time stamp, validator digital signature, or other data. Of especial interest, the transaction validity block 135 also incorporates a validity token that represents the validator's perspective on the validity of the interaction between the patient and the doctor. The validity token could include simple information such as âagreeâ or âdisagreeâ. A more complex validity token could include alternative information such as suggestions or recommendations on improving the transaction; perhaps an alternative diagnosis for example.
Peer 120 B generates validity block 135 according to validity requirement. It should be appreciated that the other peers can, at the same time, also process the same transaction. The validity requirement can be considered a proof-of-work requirement related to the healthcare transactions. Further, the validity requirement can incorporate other criteria that should be satisfied before the transactions are considered properly processed.
Peer 120 B builds validity block 135 from one or more transactions as shown. For a single patient visiting a doctor office, validity block 135 will likely have only a single transaction. For a more active stakeholder 110 (e.g., a hospital, etc.), validity block 135 could comprise multiple transactions.
Validity block 135 is processed by combining previous block information (e.g., a hash of a block header) from HHBC 130 with additional information, thereby linking validity block 135 with the blockchain. As discussed previously, the additional transaction information can include time stamp, healthcare tokens 132 , validator digital signature, and especially the validity token. Peer 120 B can re-calculate a value for validity block 135 , typically a hash of the validity block's header along with hash information from the transactions, until the resulting value satisfies the validity requirement. For example, in embodiments where validity block 135 is processed via a hash function (e.g., SHA256, Scrypt, etc.), peer 120 B can increment a nonce value until a hash is generated having the desired proof-of-work characteristics, perhaps a number of leading zero bits among other factors.
Once validity block 135 has been properly calculated and/or validated by the peers, it can be sent to other peers 120 in ecosystem 100 so that validity block 135 will be appended to HHBC 130 . Thus, validity block 135 becomes part of the chronicled healthcare history of stakeholder 110 . Validity block 135 an be considered accepted as part of the HHBC 130 once other peers 120 pickup and integrate it into their own copies of the HHBC 130 .
FIG. 2 provides a more detailed perspective of method 200 of validating healthcare transactions. Method 200 details the steps of providing validation information with respect to a healthcare transaction represented by healthcare tokens and a validity token among other items. The steps of method 200 are executed by one or more validation devices (e.g., computer clients, computer servers, web servers, mobile devices, clouds service servers, etc.). The validation devices are considered part of healthcare transaction ecosystem. For example, all the devices could be subscribers to a clinical operating system and electronic medical record exchange ecosystem. Although the following steps are described from the perspective of a single validation device, it should be appreciated that multiple devices could be operating together to fulfill the roles or responsibilities described by the steps.
Step 210 includes receiving a healthcare transaction comprising a set of healthcare tokens representative of healthcare actions taken with respect to a healthcare stakeholder. The healthcare tokens can be received over a network, via a web service, through an API call, or other techniques through which data can be exchanged. For example, in a peer-to-peer network, the validation device can receive a broadcast from a peer device where the broadcast comprises serialized healthcare tokens, perhaps in a JSON, XML, or YAML format. The healthcare tokens can represent the inputs or outputs of a healthcare transaction between a stakeholder (e.g., a patient) and another entity (e.g., doctor, insurance company, pharmacy, etc.). Example healthcare tokens could include a test result, a genetic sequence, a diagnosis, a prognosis, a patient identifier, a caregiver identifier, a fee, a payer identifier, or other type of information. More preferred healthcare tokens comprises standardized codes so that all peers can reference healthcare transactions in a uniform manner. Example standardized codes that could be leveraged with the disclosed system include ICD codes, CPT codes, DSM codes, or other known coding standards or those yet to be defined.
Step 220 comprises the validation device obtaining a historical block identifier from a healthcare historical blockchain representative of historical actions taken with respect to the stakeholder. The historical block identifier preferably represents a link to the stakeholder's HHBC. The historical block identifier could comprise a hash value of a previous block header in the HHBC, possibly the last block added to the HHBC. Such an approach is considered advantageous because the hash value incorporates all previously processed blocks, which mitigates the risk of fraud by participants that seek to inject erroneous information to the HHBC. In such cases the block identifier represents a link of continuity across all blocks in the chain.
In view that the validation devices could exist within a peer-to-peer network, a validation device could obtain at least a portion of the HHBC over network as suggested by step 225 . Consider a scenario where a new device has subscribed to the ecosystem or is integrated into a cOS environment. Part of the process could include downloading relevant HHBCs, subject to permissions or authorizations, from other peers in the ecosystem. Alternatively, the new peer could download the HHBC or portions thereof directly from a central database.
In some scenarios, an HHBC might not yet exist. For example, a newly born baby might require creation of a new HHBC, or stakeholders that newly engage with the ecosystem might require creation of a new HHBC. With reference to the birth of a baby, the method could include the step of creating the HHBC (not shown) from the set of healthcare tokens. In such a case, the healthcare tokens could comprise a birth token, where the genesis block from the newly created HHBC depends on the birth token or other information relating to the birth. Additionally, the newly created HHBC could depend on one or more parent tokens in the set of healthcare tokens. The parent tokens might represent identifiers that uniquely identify the parents of the baby (e.g., social security number, GUID, private or public key, etc.). This approach is considered advantageous because it allows for linking one HHBC of a stakeholder to the origin of another HHBC.
Step 230 includes receiving a validity requirement with respect to the healthcare actions. The validity requirement can take on many different forms depending on the nature of the healthcare actions or how difficult the validation is intended to be. The validity requirement could be packaged with the healthcare tokens as discussed previously. Alternatively, the validity requirements could be obtained via a validation pool manager or a central authority service.
The validity requirement can provide a proof-of-work difficulty such as requiring a number of leading zero bits in a hash value generated based on the transaction information. Further, the validity requirement can also include factors beyond proof-of-work. For example, the validity requirement could also include two or more factors that depend on a value of a corresponding validity token. In such cases, the validity token could represent an âagreementâ with the transaction or a âdisagreementâ with the transaction, which could then determine the nature of the validity requirement. If the validator âagreesâ with the transaction, then the validity requirement might have a low threshold proof-of-work requirements, while a âdisagreementâ might require a higher threshold proof-of-work requirement. Thus, the disclosed systems could include asymmetric validity requirements depending on the validity tokens. Still further, the validity requirement might also require presence of additional healthcare tokens should the validity token take on different values. Should the validator disagree, the validator might be required to provide recommendations or suggestions on how to alter or correct the healthcare transaction.
The validity requirement can be considered to comprise rules or criteria that must be satisfied before the validation device is considered to have completed its work in processing a block of transactions. In some embodiments, the validity requirements can be described within a package data structure or a protocol packet having a difficulty code. In other embodiments, the validity requirement could include executable code, which can include software instructions (e.g., hash algorithms, analysis techniques, expert system rules, etc.) or algorithms that should be applied to the healthcare transactions.
Step 240 continues by obtaining a digital signature of a validator. The validator can be considered the entity that processes the healthcare tokens to determine if the healthcare transaction should be perceived as being valid or invalid. The digital signature represents a code indicative of the identity of the validator. Although the digital signature could be secured to protect the identity of the validator, there is no requirement that the digital signature be secured. Example digital signatures could include a public key, a private key, an address of the validator peer (e.g., hash-based address, a transaction address, IPv4 address, IPv6 address, GUID, UUID, etc.), or other type of information that identifies the validator. More preferred validator digital signatures exist within a common signature space; peer network addresses for example.
The validator could comprise a human observer or mechanical turk worker that reviews the content of the healthcare tokens. In other embodiments, the validator could comprise an expert system employing one or more rules sets by which the healthcare tokens should be processed. The expert system executing on one peer validation device can be separately or independently programmed from other peers in the network. Such an approach is considered useful because it is expected that a large number of peers will be able process the healthcare tokens from many different perspectives according to their individual rules. For example, the ecosystem could employ one or more kernel functions by which the expert systems evaluate the healthcare tokens for validity. The kernel functions can be distributed across the peers and separately evaluated. Alternatively, the expert systems could employ trained machine learning algorithms (e.g., neural networks, support vector machines, etc.) that have been trained on separate or disparate data sets. This is considered advantageous because it ensures the peers have different, learned perspectives on the subject matter, which mitigates the risk of all peers possibly generating false negatives or false positive results if they are trained exactly on the same data.
Step 250 includes the validation device obtaining a validity token indicative of the validity of the healthcare actions and based on the set of healthcare tokens. The validity token could be obtained as a code from a validity analysis routine where the code could take on binary value (e.g., valid-invalid; agree-disagree, 0-1, etc.), or could take on a range of values. For example, if an expert system is operating as a validator, the validity token could be a score between â1.0 (invalid) and 1.0 (valid), for example, indicating a confidence score with respect to the validity decision; the confidence score could also be between 0 and 10 as another example.
In other embodiments, the validity token can be obtained via validator interface. Step 255 suggests the method could further include presenting the validator interface via mobile device where the interface accepts a user selected validity token. As an example, consider a scenario where a hospital has subscribed to the disclosed ecosystem. Each subject matter expert (e.g., surgeons, pediatricians, gastroenterologists, oncologists, etc.) could be provisioned with a tablet computer configured to operate as the validation device or as the validator interface. As healthcare transactions are taking place within the hospital, the corresponding healthcare tokens can be routed to the appropriate subject matter experts. The tablet displays the necessary healthcare tokens or healthcare transaction information and requests input from the subject matter expert with respect to the validity of the transaction. The tablet could present a list of validity options to the expert who then selects one or more of the options.
Upon establishing one or more validity tokens representing the opinion of the healthcare transaction, the method continues at step 260 by calculating or otherwise generating a validity block for one or more healthcare transactions according to the validity requirement and as a function of the validity token, historical block identifier, the set of healthcare tokens, the digital signature, or other parameters relevant to the healthcare transactions. Calculating the validity block is consider to comprises generation of a value that depends on the history of the HHBC as well as the current transactions being processed. More specifically, the generated value also depends on the validity token. For example, the function could be a hash function (e.g., SHA, Scrypt, MD5, RIPEMD, WHIRLPOOL, etc.) applied to the concatenation of the various pieces of information in the healthcare transactions, which is then hashed with the validity block's header information. It should be appreciated that step 260 could be iteratively applied until the validity block takes on characteristics that satisfy the validity requirements. For example, in the cases of applying a hash to the healthcare parameters, the hash can also be applied to a nonce and a time-stamp preferably bound within the validity block's header. If the resulting value fails to satisfy the validity requirements, the nonce can be incremented or the time-stamp could be updated and step 260 can be repeated based on the new value.
The resulting validity block comprises more than just the resulting hash value. It also includes the various information elements that gave rise to the hash value. Thus, the validity block represents a chronicle or ledger of the healthcare transactions. Such an approach is advantageous as it ensures the validity block retains a link to other blocks in the HHBC as well as provides a searchable or analyzable data object. Additionally, by providing the information other peers in the network, the peer can validate the proof-of-work.
FIG. 3 is a flow diagram showing processing steps carried out, in one embodiment, by step 260 of FIG. 2 . As will be described further, the disclosed process allows the flexibility to generate validity blocks including one transaction per block or including multiple transactions per block. This flexibility recognizes that, in the healthcare context, in some instances, it might be useful and efficient to process multiple transactions for a single validity block, whereas in other contexts, it might be more useful to process a single transaction. As one example, a patient visit might generate multiple transactions for that patient or might only generate a single transaction for that patient. In the former case, processing all transactions together can be efficient and also provide a basis for linking multiple transactions for a patient to a single visit, thereby providing visit information without necessarily requiring a separate âvisitâ field in a data structure stored in the HHBC. In the latter case, especially if the patient is not expected to generate additional transactions for a significant time period, it might be useful to process validation of the single transaction and generate a validity block to be added to the HHBC for that patient without waiting for additional transactions to accrue. In another example, as previously mentioned, a doctor or other healthcare provider might be associated with many transactions per day and, therefore, it might be more efficient to generate a validity block each day including multiple transactions to be added to that stakeholder's HHBC.
Referring now in detail to FIG. 3 , step 301 assembles a candidate validity block including a nonce and the following healthcare parameters: a historical block identifier, one or more healthcare tokens, one or more validity tokens (generated based on a validator reviewing the healthcare tokens), and one or more digital signatures associated with a validator generating the validity tokens. Step 302 applies a first hash to the candidate validity block. Step 303 determines whether the process should only use one hash. If no, then step 306 applies at least a second hash to the result of the first hash before proceeding to step 304 . Step 306 allows the method to, if desired, increase the processing required to achieve proof-of-work. If the result of 304 is yes, then the method proceeds directly to step 304 . Step 304 determines whether the result of step 302 (if only one hash applied) or step 306 (if multiple hashes applied) has met the validity requirement. One example of a typical proof-of-work validity requirement in this context is that the hash result has a certain number of leading zeros. However, many variations are possible. If the result of step 304 is no, then step 305 increments the nonce in the current candidate validity block and processing returns to step 302 to recalculate a hash using the new nonce value.
If the result of step 304 is yes, then step 307 determines whether multiple transactions will be added to a single validity block. If the result of step 307 is no, then step 308 sets the current validity block as the validity block provided for step 270 of FIG. 2 . If the result of step 307 is yes, then step 309 adds the current validity block to a multi-transaction validity block and step 310 determines whether there are more transactions to process for the multi-transaction validity block. If yes, then the method returns to step 301 to process another transaction. If the result of step 310 is no, then step 311 sets the current multi-transaction validity block as the validity block to be used by step 270 of FIG. 2 .
A multi-transaction validity block could be constructed in a variety of ways. In the illustrated example, one or more hash functions are applied to the data for each transaction individually to meet the proof-of-work or other proof requirement (e.g., identifying a nonce that yields the required result), and then multiple validity blocks are concatenated together to form a multiple transaction validity block prior to broadcasting the validity block to peers on the network. However, in another example, multiple proposed validity blocks could be concatenated together prior to applying the hash function. In this scenario, the proof-of-work is carried out for multiple transactions together.
Other scenarios are possible. For example, the hashes of each transaction be can
CLAIMS
Claims ( 28 )
1 - 41 . (canceled)
42 . A system for validating at least one healthcare transaction, comprising:
a plurality of computers in a computer network, the plurality of computers being configured to store a healthcare historical blockchain comprising one or more blocks comprising historical healthcare transaction data regarding historical actions taken with respect to a healthcare stakeholder; and at least one validation device coupled to the computer network and configured to:
receive new healthcare transaction data corresponding to healthcare actions taken with respect to the healthcare stakeholder;
receive from a first peer or an authority service on the computer network a historical block identifier corresponding to a block in the healthcare historical blockchain;
receive a validity block calculated by one or more peers on the computer network, and;
determine the validity of the validity block according to a validity requirement by calculating the validity block as a function of at least one of the following healthcare parameters: the historical block identifier, the new healthcare transaction data, and a value included in the validity block, the value being determined by the one or more peers on the computer network.
43 . The healthcare validation system of claim 42 , wherein the validity block comprises a pre-authorization score based on one or more of the following: a doctor, a patient, and a treatment associated with the one or more healthcare actions.
44 . The healthcare validation system of claim 42 , wherein the historical healthcare transaction data and the new healthcare transaction data comprises one or more pointers to one or more locations to an electronic medical record system storing an electronic medical record regarding the one or more health care actions.
45 . The healthcare validation system of claim 44 , wherein the electronic medical record comprises at least one of the following: a test result, a genetic code, a diagnosis, a prognosis, a patient identifier, a caregiver identifier, a fee, and a payer identifier.
46 . The healthcare validation system of claim 42 , further comprising creating the healthcare historical blockchain from the historical healthcare transaction data.
47 . The healthcare validation system of claim 46 , wherein the healthcare historical blockchain depends on a birth token.
48 . The healthcare validation system of claim 46 , wherein the validity block comprises at least one parent token and the healthcare historical blockchain depends on the at least one parent token.
49 . The healthcare validation system of claim 42 , wherein the healthcare stakeholder includes at least one of the following: a patient, a physician, a technician, a care provider, a payer, a broker, and a guardian.
50 . The healthcare validation system of claim 42 , wherein the healthcare transaction data comprises standardized codes.
51 . The healthcare validation system of claim 50 , wherein the standardized codes include at least one of the following: an International Statistical Classification of Diseases and Related Health Problems (ICD) code, a Current Procedural Terminology (CPT) code, and a Diagnostic and Statistical Manual of Mental Disorders (DSM) code.
52 . The healthcare validation system of claim 42 , wherein the operation of receiving from the first peer or the authority service on the computer network the historical block identifier includes receiving at least a portion of the healthcare historical blockchain over the computer network.
53 . The healthcare validation system of claim 42 , wherein the validity requirement comprises a proof-of-work difficulty.
54 . The healthcare validation system of claim 42 , wherein the validity block is further calculated as a function of a digital signature of a validator, the digital signature of the validator utilizing at least one of the following: a validator ID, a validator address, a validator public key, and a validator private key.
55 . The healthcare validation system of claim 42 , wherein the operation of calculating the validity block includes applying a first hash as the function to the new healthcare transaction data.
56 . The healthcare validation system of claim 55 , further comprising applying at least a second hash to the results from the first hash.
57 . The healthcare validation system of claim 42 , wherein the first hash is selected from the group consisting of: SHA, Scrypt, MD5, RIPEMD, and WHIRLPOOL.
58 . The healthcare validation system of claim 42 , wherein the historical block identifier comprises a hash of a header of a previous block in the healthcare historical blockchain.
59 . The healthcare validation system of claim 58 , wherein the hash of the header of the previous block is of a last block added to the healthcare historical blockchain.
60 . The healthcare validation system of claim 42 , further comprising updating the healthcare historical blockchain by broadcasting the validity block to one or more peers in the computer network.
61 . The healthcare validation system of claim 42 , further comprising receiving a digital redeemable token in exchange for determining the validity of the validity block according to the validity requirement.
62 . The healthcare validation system of claim 61 , wherein the digital redeemable token includes at least one of the following: a coupon, a virtual currency, a fiat currency, and a service.
63 . A computer program product for validating at least one healthcare transaction, comprising one or more machine-readable instruction stored in a non-transitory computer readable medium, wherein the one or more machine-readable instructions, upon execution by at least one processor, perform:
receiving, by at least one validation device coupled to a computer network comprising a plurality of computers configured to store a healthcare historical blockchain comprising one or more blocks including historical healthcare transaction data regarding historical actions taken with respect to a healthcare stakeholder, new healthcare transaction data corresponding to healthcare actions taken with respect to the healthcare stakeholder; receiving from a first peer or an authority service on the computer network, a historical block identifier corresponding to a block in the healthcare historical blockchain; receiving a validity block calculated by one or more peers on the computer network; and determining a validity of the validity block according to a validity requirement by calculating the validity block as a function of at least one of the following healthcare parameters: the historical block identifier, the new healthcare transaction data, and a value included in the validity block, the value being determined by the one or more peers on the computer network.
64 . The computer program product of claim 63 , wherein the validity block comprises a pre-authorization score based on one or more of the following: a doctor, a patient, and a treatment associated with the one or more healthcare actions.
65 . The computer program product of claim 63 , wherein the historical healthcare transaction data and the new healthcare transaction data comprises one or more pointers to one or more locations to an electronic medical record system storing an electronic medical record regarding the one or more health care actions.
66 . A computer-assisted method for validating at least one healthcare transaction, the method comprising:
receiving, by at least one validation device coupled to a computer network comprising a plurality of computers configured to store a healthcare historical blockchain comprising one or more blocks including historical healthcare transaction data regarding historical actions taken with respect to a healthcare stakeholder, new healthcare transaction data corresponding to healthcare actions taken with respect to the healthcare stakeholder; receiving from a first peer or an authority service on the computer network, a historical block identifier corresponding to a block in the healthcare historical blockchain; receiving a validity block calculated by one or more peers on the computer network; and determining a validity of the validity block according to a validity requirement by calculating the validity block as a function of at least one of the following healthcare parameters: the historical block identifier, the new healthcare transaction data, and a value included in the validity block, the value being determined by the one or more peers on the computer network.
67 . The computer program product of claim 66 , wherein the validity block comprises a pre-authorization score based on one or more of the following: a doctor, a patient, and a treatment associated with the one or more healthcare actions.
68 . The computer program product of claim 66 , wherein the historical healthcare transaction data and the new healthcare transaction data comprises one or more pointers to one or more locations to an electronic medical record system storing an electronic medical record regarding the one or more health care actions.
US18/677,737
2014-05-13
2024-05-29
Healthcare transaction validation via blockchain, systems and methods
Pending
US20240321416A1
( en )
Priority Applications (1)
Application Number
Priority Date
Filing Date
Title
US18/677,737
US20240321416A1
( en )
2014-05-13
2024-05-29
Healthcare transaction validation via blockchain, systems and methods
Applications Claiming Priority (4)
Application Number
Priority Date
Filing Date
Title
US201461992734P
2014-05-13
2014-05-13
US14/711,740
US10340038B2
( en )
2014-05-13
2015-05-13
Healthcare transaction validation via blockchain, systems and methods
US16/451,707
US12027244B2
( en )
2014-05-13
2019-06-25
Healthcare transaction validation via blockchain systems and methods
US18/677,737
US20240321416A1
( en )
2014-05-13
2024-05-29
Healthcare transaction validation via blockchain, systems and methods
Related Parent Applications (1)
Application Number
Title
Priority Date
Filing Date
US16/451,707
Division
US12027244B2
( en )
2014-05-13
2019-06-25
Healthcare transaction validation via blockchain systems and methods
Publications (1)
Publication Number
Publication Date
US20240321416A1
true
US20240321416A1 ( en )
2024-09-26
Family
ID=54480647
Family Applications (5)
Application Number
Title
Priority Date
Filing Date
US14/711,740
Active
2038-04-21
US10340038B2
( en )
2014-05-13
2015-05-13
Healthcare transaction validation via blockchain, systems and methods
US16/410,655
Active
2037-01-12
US11386985B2
( en )
2014-05-13
2019-05-13
Healthcare transaction validation via blockchain systems and methods
US16/451,707
Active
2037-08-29
US12027244B2
( en )
2014-05-13
2019-06-25
Healthcare transaction validation via blockchain systems and methods
US17/726,400
Active
2035-05-13
US12100491B2
( en )
2014-05-13
2022-04-21
Transaction validation via blockchain, systems and methods
US18/677,737
Pending
US20240321416A1
( en )
2014-05-13
2024-05-29
Healthcare transaction validation via blockchain, systems and methods
Family Applications Before (4)
Application Number
Title
Priority Date
Filing Date
US14/711,740
Active
2038-04-21
US10340038B2
( en )
2014-05-13
2015-05-13
Healthcare transaction validation via blockchain, systems and methods
US16/410,655
Active
2037-01-12
US11386985B2
( en )
2014-05-13
2019-05-13
Healthcare transaction validation via blockchain systems and methods
US16/451,707
Active
2037-08-29
US12027244B2
( en )
2014-05-13
2019-06-25
Healthcare transaction validation via blockchain systems and methods
US17/726,400
Active
2035-05-13
US12100491B2
( en )
2014-05-13
2022-04-21
Transaction validation via blockchain, systems and methods
Country Status (2)
Country
Link
US
( 5 )
US10340038B2
( en )
WO
( 1 )
WO2015175722A1
( en )
Families Citing this family (568)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US8874477B2
( en )
2005-10-04
2014-10-28
Steven Mark Hoffberg
Multifactorial optimization system and method
US8706530B2
( en )
2010-09-29
2014-04-22
Dacadoo Ag
Automated health data acquisition, processing and communication system
US10490304B2
( en )
*
2012-01-26
2019-11-26
Netspective Communications Llc
Device-driven non-intermediated blockchain system over a social integrity network
US10984913B2
( en )
*
2012-04-27
2021-04-20
Netspective Communications Llc
Blockchain system for natural language processing
US20230015824A1
( en )
*
2012-05-02
2023-01-19
Imageworks Interactive
Security approach for manufacturing inventory management
US20140108023A1
( en )
*
2012-10-12
2014-04-17
Harold Arkoff
Operating room management system with mobile app
US9727832B2
( en )
*
2013-03-15
2017-08-08
Profit Strategies, Inc.
Methods for generating a work-order in real time and devices thereof
US11282139B1
( en )
2013-06-28
2022-03-22
Gemini Ip, Llc
Systems, methods, and program products for verifying digital assets held in a custodial digital asset wallet
US10269009B1
( en )
2013-06-28
2019-04-23
Winklevoss Ip, Llc
Systems, methods, and program products for a digital math-based asset exchange
US10354325B1
( en )
2013-06-28
2019-07-16
Winklevoss Ip, Llc
Computer-generated graphical user interface
US9898782B1
( en )
2013-06-28
2018-02-20
Winklevoss Ip, Llc
Systems, methods, and program products for operating exchange traded products holding digital math-based assets
US10068228B1
( en )
2013-06-28
2018-09-04
Winklevoss Ip, Llc
Systems and methods for storing digital math-based assets using a secure portal
US20180089374A1
( en )
*
2013-07-05
2018-03-29
Tillata Corlette Gibson
Method and System for Transferring Mammograms with Blockchain Verification
US11341556B2
( en )
2013-08-16
2022-05-24
Mdsave Shared Services Inc.
CPT code search engine for backend bundling of healthcare services and a virtual payment system
US11475499B2
( en )
2013-08-16
2022-10-18
Mdsave Shared Services Inc.
Backend bundled healthcare services payment systems and methods
US11449913B2
( en )
2013-08-16
2022-09-20
Mdsave Shared Services Inc.
Prepaid bundled health, dental, and veterinary services with virtual payment distribution
US11501352B2
( en )
2013-08-16
2022-11-15
Mdsave Shared Services Inc.
Backend bundled healthcare services payment systems and methods
US11915287B2
( en )
2013-08-16
2024-02-27
Mdsave Shared Services Inc.
Backend bundled healthcare services payment systems and methods
US11341555B2
( en )
2013-08-16
2022-05-24
Mdsave Shared Services Inc.
Creating digital health assets
US11475498B2
( en )
2013-08-16
2022-10-18
Mdsave Shared Services Inc.
Prepaid bundled health, dental, and veterinary services with virtual payment distribution
US10991021B2
( en )
2013-08-16
2021-04-27
Mdsave Shared Services Inc.
Provisioning medical resources triggered by a lifecycle event
US11551276B2
( en )
2013-08-16
2023-01-10
Mdsave Shared Services Inc.
Selectively redeemable bundled healthcare services with discreet payment distribution
US10424404B2
( en )
2013-11-13
2019-09-24
Dacadoo Ag
Automated health data acquisition, processing and communication system and method
US11126627B2
( en )
2014-01-14
2021-09-21
Change Healthcare Holdings, Llc
System and method for dynamic transactional data streaming
US10121557B2
( en )
2014-01-21
2018-11-06
PokitDok, Inc.
System and method for dynamic document matching and merging
EP3111613B1
( en )
2014-02-28
2018-04-11
British Telecommunications public limited company
Malicious encrypted traffic inhibitor
US10839020B2
( en )
2014-04-14
2020-11-17
Netspective Communications Llc
Multi-source user generated electronic data integration in a blockchain-based transactional system
WO2015175722A1
( en )
2014-05-13
2015-11-19
Nant Holdings Ip, Llc
Healthcare transaction validation via blockchain proof-of-work, systems and methods
US9608829B2
( en )
*
2014-07-25
2017-03-28
Blockchain Technologies Corporation
System and method for creating a multi-branched blockchain with configurable protocol rules
US9836908B2
( en )
*
2014-07-25
2017-12-05
Blockchain Technologies Corporation
System and method for securely receiving and counting votes in an election
US10007757B2
( en )
2014-09-17
2018-06-26
PokitDok, Inc.
System and method for dynamic schedule aggregation
US20160117471A1
( en )
*
2014-10-22
2016-04-28
Jan Belt
Medical event lifecycle management
WO2016118619A1
( en )
2015-01-20
2016-07-28
PokitDok, Inc.
Health lending system and method using probabilistic graph models
US9853977B1
( en )
2015-01-26
2017-12-26
Winklevoss Ip, Llc
System, method, and program product for processing secure transactions within a cloud computing system
WO2016126665A1
( en )
2015-02-04
2016-08-11
Vatbox, Ltd.
A system and methods for extracting document images from images featuring multiple documents
US20170154385A1
( en )
*
2015-11-29
2017-06-01
Vatbox, Ltd.
System and method for automatic validation
WO2016128491A1
( en )
2015-02-11
2016-08-18
British Telecommunications Public Limited Company
Validating computer resource usage
US11687885B2
( en )
*
2015-02-27
2023-06-27
Visa International Service Association
Transaction signing utilizing asymmetric cryptography
US10158480B1
( en )
2015-03-16
2018-12-18
Winklevoss Ip, Llc
Autonomous devices
US10915891B1
( en )
2015-03-16
2021-02-09
Winklevoss Ip, Llc
Autonomous devices
SI3073670T1
( en )
2015-03-27
2021-07-30
Black Gold Coin, Inc.
System and procedure for personal identification and verification
SG11201708000PA
( en )
2015-03-31
2017-10-30
Nasdaq Inc
Systems and methods of blockchain transaction recordation
US9397985B1
( en )
2015-04-14
2016-07-19
Manifold Technology, Inc.
System and method for providing a cryptographic platform for exchanging information
US20160306999A1
( en )
*
2015-04-17
2016-10-20
Auronexus Llc
Systems, methods, and computer-readable media for de-identifying information
JP2018516030A
( en )
2015-05-05
2018-06-14
ã·ã§ã«ã¼ããã¤ã³ã³ã¼ãã¬ã¤ããã
ID management service using blockchain
US9876646B2
( en )
2015-05-05
2018-01-23
ShoCard, Inc.
User identification management system and method
US10635471B2
( en )
*
2015-05-15
2020-04-28
Joshua Paul Davis
System and method for an autonomous entity
US20160342750A1
( en )
2015-05-18
2016-11-24
PokitDok, Inc.
Dynamic topological system and method for efficient claims processing
US10193696B2
( en )
2015-06-02
2019-01-29
ALTR Solutions, Inc.
Using a tree structure to segment and distribute records across one or more decentralized, acylic graphs of cryptographic hash pointers
US9881176B2
( en )
2015-06-02
2018-01-30
ALTR Solutions, Inc.
Fragmenting data for the purposes of persistent storage across multiple immutable data structures
US10114970B2
( en )
*
2015-06-02
2018-10-30
ALTR Solutions, Inc.
Immutable logging of access requests to distributed file systems
CN107924389B
( en )
2015-07-02
2020-11-13
纳æ¯è¾¾å å ¬å¸
System and method for secure traceability of distributed transaction databases
WO2017006135A1
( en )
*
2015-07-08
2017-01-12
Barclays Bank Plc
Data validation and storage
WO2017010455A1
( en )
*
2015-07-13
2017-01-19
æ¥æ¬é»ä¿¡é»è©±æ ªå¼ä¼ç¤¾
Contract agreement method, agreement verification method, contract agreement system, agreement verification device, contract agreement device, contract agreement program and agreement verification program
US11436598B2
( en )
*
2017-12-15
2022-09-06
Fmr Llc
Social data tracking datastructures, apparatuses, methods and systems
WO2017021155A1
( en )
2015-07-31
2017-02-09
British Telecommunications Public Limited Company
Controlled resource provisioning in distributed computing environments
WO2017021154A1
( en )
2015-07-31
2017-02-09
British Telecommunications Public Limited Company
Access control
EP3125489B1
( en )
*
2015-07-31
2017-08-09
BRITISH TELECOMMUNICATIONS public limited company
Mitigating blockchain attack
US10956614B2
( en )
2015-07-31
2021-03-23
British Telecommunications Public Limited Company
Expendable access control
US10366204B2
( en )
*
2015-08-03
2019-07-30
Change Healthcare Holdings, Llc
System and method for decentralized autonomous healthcare economy platform
HK1249633A1
( en )
*
2015-08-14
2018-11-02
Identitii Limited
A computer implemented method for processing a financial transaction and a system therefor
US11915332B2
( en )
*
2015-10-02
2024-02-27
Loyyal Holdings Incorporated
System and process for tokenization and management of liability
DE202016008801U1
( en )
2015-10-14
2019-11-04
Alok Bhargava
Systems for managing digital identities
CA3002032A1
( en )
2015-10-15
2017-04-20
PokitDok, Inc.
System and method for dynamic metadata persistence and correlation on api transactions
KR101720268B1
( en )
*
2015-10-26
2017-03-27
(주)ìì´ìì
Medical Imaging Cloud Database Building and Reading Method for Protecting Patient Information
JP6358658B2
( en )
*
2015-11-09
2018-07-18
æ¥æ¬é»ä¿¡é»è©±æ ªå¼ä¼ç¤¾
Block chain generation device, block chain generation method, block chain verification device, block chain verification method and program
JP6355168B2
( en )
2015-11-09
2018-07-11
æ¥æ¬é»ä¿¡é»è©±æ ªå¼ä¼ç¤¾
Block chain generation device, block chain generation method, block chain verification device, block chain verification method and program
CN109874340B
( en )
*
2015-11-18
2023-06-13
å ¨çæ ·æ¬è§£å³æ¹æ¡è¡ä»½æéå ¬å¸
A distributed system for secure storage and retrieval of encrypted biological specimen data
CN108352044A
( en )
*
2015-11-24
2018-07-31
ç´¢å°¼å ¬å¸
Information processing device, information processing method, and program
WO2017091530A1
( en )
*
2015-11-24
2017-06-01
Gartland & Mellina Group
Blockchain solutions for financial services and other transaction-based industries
US11562353B2
( en )
*
2015-11-24
2023-01-24
Mastercard International Incorporated
Method and system for gross settlement by use of an opaque blockchain
US10592843B2
( en )
*
2015-11-25
2020-03-17
Walmart Apollo, Llc
Unmanned aerial delivery to secure location
JP6608256B2
( en )
*
2015-11-26
2019-11-20
æ ªå¼ä¼ç¤¾ï½ï½ï½ï¼¦ï½ï½ï½ ï½ ï¼¢ï½ï½ï½ï½ï½ï½ï½ï½ï½
Electronic data existence certification program and existence certification server
US11138372B2
( en )
2015-11-29
2021-10-05
Vatbox, Ltd.
System and method for reporting based on electronic documents
US10387561B2
( en )
2015-11-29
2019-08-20
Vatbox, Ltd.
System and method for obtaining reissues of electronic documents lacking required data
US10509811B2
( en )
2015-11-29
2019-12-17
Vatbox, Ltd.
System and method for improved analysis of travel-indicating unstructured electronic documents
US10558880B2
( en )
2015-11-29
2020-02-11
Vatbox, Ltd.
System and method for finding evidencing electronic documents based on unstructured data
KR101678795B1
( en )
*
2015-11-30
2016-11-22
ì ì¼êµ¬
Iot-basesd things management system and method using block chain authentification
US20220358185A1
( en )
*
2015-12-02
2022-11-10
Wells Fargo Bank, N.A.
Traversing data structures for compliance
CN105573828B
( en )
*
2015-12-17
2019-04-12
å¸æ¯ï¼å京ï¼ç½ç»ææ¯æéå ¬å¸
A kind of operation processing method and device
WO2017109128A1
( en )
2015-12-24
2017-06-29
British Telecommunications Public Limited Company
Detecting malicious software
WO2017109135A1
( en )
2015-12-24
2017-06-29
British Telecommunications Public Limited Company
Malicious network traffic identification
EP3394783B1
( en )
2015-12-24
2020-09-30
British Telecommunications public limited company
Malicious software identification
US11201876B2
( en )
2015-12-24
2021-12-14
British Telecommunications Public Limited Company
Malicious software identification
US10733296B2
( en )
2015-12-24
2020-08-04
British Telecommunications Public Limited Company
Software security
US9894485B2
( en )
2015-12-28
2018-02-13
Keir Finlow-Bates
Peer-to-peer geolocation system
US10262164B2
( en )
2016-01-15
2019-04-16
Blockchain Asics Llc
Cryptographic ASIC including circuitry-encoded transformation function
US10116667B2
( en )
2016-01-26
2018-10-30
Bank Of America Corporation
System for conversion of an instrument from a non-secured instrument to a secured instrument in a process data network
US10108812B2
( en )
2016-01-28
2018-10-23
Nasdaq, Inc.
Systems and methods for securing and disseminating time sensitive information using a blockchain
KR101772554B1
( en )
*
2016-02-02
2017-08-30
주ìíì¬ ì½ì¸íë¬ê·¸
Method and server for providing notary service with respect to file and verifying the recorded file by using the notary service
GB2604540B
( en )
2016-02-03
2023-01-11
Luther Systems
System and method for secure management of digital contracts
WO2017134281A1
( en )
2016-02-04
2017-08-10
Nasdaq Technology Ab
Systems and methods for storing and sharing transactional data using distributed computer systems
US20170228371A1
( en )
*
2016-02-05
2017-08-10
Manifold Technology, Inc.
Blockchain-enhanced database
US10438209B2
( en )
*
2016-02-10
2019-10-08
Bank Of America Corporation
System for secure routing of data to various networks from a process data network
US10129238B2
( en )
2016-02-10
2018-11-13
Bank Of America Corporation
System for control of secure access and communication with different process data networks with separate security features
US10142347B2
( en )
2016-02-10
2018-11-27
Bank Of America Corporation
System for centralized control of secure access to process data network
US11374935B2
( en )
2016-02-11
2022-06-28
Bank Of America Corporation
Block chain alias person-to-person resource allocation
US10715531B2
( en )
2016-02-12
2020-07-14
Visa International Service Association
Network topology
US10693658B2
( en )
2016-02-12
2020-06-23
Visa International Service Association
Methods and systems for using digital signatures to create trusted digital asset transfers
US11108566B2
( en )
2016-02-12
2021-08-31
Visa International Service Association
Methods and systems for using digital signatures to create trusted digital asset transfers
US10387878B2
( en )
2016-02-22
2019-08-20
Bank Of America Corporation
System for tracking transfer of resources in a process data network
US10135870B2
( en )
*
2016-02-22
2018-11-20
Bank Of America Corporation
System for external validation of secure process transactions
US10026118B2
( en )
2016-02-22
2018-07-17
Bank Of America Corporation
System for allowing external validation of data in a process data network
US10142312B2
( en )
2016-02-22
2018-11-27
Bank Of America Corporation
System for establishing secure access for users in a process data network
US10178105B2
( en )
*
2016-02-22
2019-01-08
Bank Of America Corporation
System for providing levels of security access to a process data network
US10762504B2
( en )
2016-02-22
2020-09-01
Bank Of America Corporation
System for external secure access to process data network
US10496989B2
( en )
2016-02-22
2019-12-03
Bank Of America Corporation
System to enable contactless access to a transaction terminal using a process data network
US10679215B2
( en )
2016-02-22
2020-06-09
Bank Of America Corporation
System for control of device identity and usage in a process data network
US10636033B2
( en )
2016-02-22
2020-04-28
Bank Of America Corporation
System for routing of proces