U.S. patent application number 16/906946 was filed with the patent office on 2020-12-24 for electronic healthcare record data blockchain system.
This patent application is currently assigned to Electronic Health Record Data, Inc.. The applicant listed for this patent is Electronic Health Record Data, Inc.. Invention is credited to Ronald Raymond Austring, Brad T. Crosslin, Clinton S. Ferguson, III, Kenneth A. Hill, SR..
Application Number | 20200402624 16/906946 |
Document ID | / |
Family ID | 1000004941928 |
Filed Date | 2020-12-24 |
![](/patent/app/20200402624/US20200402624A1-20201224-D00000.png)
![](/patent/app/20200402624/US20200402624A1-20201224-D00001.png)
![](/patent/app/20200402624/US20200402624A1-20201224-D00002.png)
![](/patent/app/20200402624/US20200402624A1-20201224-D00003.png)
![](/patent/app/20200402624/US20200402624A1-20201224-D00004.png)
![](/patent/app/20200402624/US20200402624A1-20201224-D00005.png)
![](/patent/app/20200402624/US20200402624A1-20201224-D00006.png)
![](/patent/app/20200402624/US20200402624A1-20201224-D00007.png)
![](/patent/app/20200402624/US20200402624A1-20201224-D00008.png)
![](/patent/app/20200402624/US20200402624A1-20201224-D00009.png)
United States Patent
Application |
20200402624 |
Kind Code |
A1 |
Austring; Ronald Raymond ;
et al. |
December 24, 2020 |
Electronic Healthcare Record Data Blockchain System
Abstract
An Electronic Health Record (EHR) data blockchain system
configured to allow multiple entities (e.g., pharmacy industry
entities that can act as data, service, product providers, and
consumers) to connect to an EHR patient transaction blockchain
(e.g., EHR-DATA-BC) and an EHR Data Patient Portal (e.g.,
EHR-Data-PP) to provide a centralized location for messages and
subsequent edits to ensure uniform message data is presented. The
EHR data blockchain system can include an EHR Data API, an EHR
patient transaction blockchain API, and an EHR patient transaction
blockchain. The EHR Data API can access and retrieve patient
identifiable information (PII) and generate a
non-patient-identifiable Single Purpose Patient ID (SPPID) for a
particular patient. The EHR patient transaction blockchain API
(e.g., EHR-DATA-BC-API) can store the SPPID, store particular,
discrete data retrieved from the EHR for a patient, execute smart
contracts, and control the execution of digital currency transfers,
among other functions.
Inventors: |
Austring; Ronald Raymond;
(English Harbour, AG) ; Hill, SR.; Kenneth A.;
(Fort Worth, TX) ; Crosslin; Brad T.; (Keller,
TX) ; Ferguson, III; Clinton S.; (Arlington,
TX) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Electronic Health Record Data, Inc. |
Fort Worth |
TX |
US |
|
|
Assignee: |
Electronic Health Record Data,
Inc.
Fort Worth
TX
|
Family ID: |
1000004941928 |
Appl. No.: |
16/906946 |
Filed: |
June 19, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62863655 |
Jun 19, 2019 |
|
|
|
62863637 |
Jun 19, 2019 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 9/542 20130101;
G06Q 50/265 20130101; G06Q 10/10 20130101; G06Q 2220/00 20130101;
G06Q 40/04 20130101; G06Q 30/0222 20130101; G16H 20/10 20180101;
G16H 10/60 20180101; G06Q 20/385 20130101; G06Q 20/383 20130101;
G06Q 20/065 20130101 |
International
Class: |
G16H 10/60 20060101
G16H010/60; G06Q 10/10 20060101 G06Q010/10; G06Q 20/06 20060101
G06Q020/06; G06Q 40/04 20060101 G06Q040/04; G16H 20/10 20060101
G16H020/10; G06Q 30/02 20060101 G06Q030/02; G06Q 20/38 20060101
G06Q020/38; G06Q 50/26 20060101 G06Q050/26; G06F 9/54 20060101
G06F009/54 |
Claims
1. A system for providing blockchain-based patient transactions,
the system comprising: one or more computer-readable storage media
configured to store a blockchain; a data Application Programming
Interface (API) system comprising one or more processors programmed
to execute computer program instructions that, when executed, cause
the data API system to: receive a request for a new blockchain
transaction related to a patient, initiate a patient lookup query
to determine whether a patient electronic health record exists,
generate a single purpose patient ID (SPPID) associated with the
patient electronic health record; a client computer programmed to
execute computer program instructions that, when executed, cause
the client computer to: receive a patient lookup query related to a
patient from a client to determine whether the patient's electronic
health record exists, receive the SPPID to initiate a new
blockchain transaction related to the patient on the blockchain
without patient-identifying information, determine whether an
entity operating the client computer can provide data, products
and/or services related to a blockchain transaction; and a
blockchain API system comprising one or more processors programmed
to execute computer program instructions that, when executed, cause
the blockchain API system to: generate the blockchain transaction
and read and write records to and from the blockchain, and
associate one or more smart contracts with the blockchain
transaction.
2. The system of claim 1, wherein the smart contract exchanges
digital currency between the parties involved in the smart
contract.
3. The system of claim 2, wherein the digital currency includes
utility tokens or vouchers.
4. The system of claim 1, wherein the SPPID cannot be used to write
information to the blockchain after a patient blockchain
transaction is completed.
5. The system of claim 1, wherein the blockchain API system can
generate a notification when the blockchain transaction is
generated.
6. The system of claim 1, wherein the blockchain API system can
transmit the notification to one or more providers.
7. The system of claim 1, wherein the client computer can provide
information to the blockchain API system regarding data, products
and/or services related to the blockchain transaction.
8. The system of claim 1, wherein the blockchain API system edits
the blockchain transaction on the blockchain.
9. A method of providing blockchain-based electronic health record
data patient transactions, the method being implemented by a server
system comprising one or more processors executing computer program
instructions that, when executed, perform the method, the method
comprising: associating a single purpose patient ID (SPPID) with
the electronic health record; providing the SPPID to the client so
the client can initiate a new blockchain patient transaction
related to the patient on the blockchain without
patient-identifying information; receiving a patient transaction
from a pharmacy; writing the patient transaction to the blockchain;
notifying one or more client devices of the patient transaction;
receiving one or more offers for data, products, or services
related to the patient transaction; generating a smart contract
related to the patient transaction and the one or more offers; and
modifying the patient transaction based on the execution of the
smart contract.
10. The method of claim 9, wherein the smart contract exchanges
digital currency between the parties involved in the smart
contract.
11. The method of claim 10, wherein the digital currency includes
utility tokens or vouchers.
12. The method of claim 9, wherein the SPPID cannot be used to
write information to the blockchain after the patient blockchain
transaction is completed.
13. The method of claim 9, further comprising generating a
notification when the patient transaction is generated.
14. The method of claim 13, further comprising transmitting the
notification to one or more providers.
15. The method of claim 9, wherein the patient transaction is
modified on the blockchain.
16. The method of claim 15, wherein the patient transaction is
modified on the blockchain in real-time.
17. A system for providing electronic health record data for
blockchain-based patient transactions, the system comprising: one
or more computer-readable storage media configured to store a
blockchain; a data Application Programming Interface (API) system
comprising one or more processors programmed to execute computer
program instructions that, when executed, cause the data API system
to: receive a request for a new blockchain transaction related to a
patient, retrieve the patient electronic health record from one or
more databases, and generate a single purpose patient ID (SPPID)
associated with the patient electronic health record; and a
blockchain API system comprising one or more processors programmed
to execute computer program instructions that, when executed, cause
the blockchain API system to: generate the blockchain transaction
and read and write records to and from the blockchain, and
associate one or more smart contracts with the blockchain
transaction.
18. The system of claim 17, wherein the smart contract exchanges
digital currency between the parties involved in the smart
contract.
19. The system of claim 18, wherein the digital currency includes
utility tokens or vouchers.
20. The system of claim 17, wherein the blockchain API system edits
the prescription transaction on the blockchain based on input from
one or more providers.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims priority to U.S. Provisional
Application Ser. No. 62/863,655, filed on Jun. 19, 2019, and
entitled "Electronic Health Record Data Blockchain System," and
U.S. Provisional Application Ser. No. 62/863,637, filed on Jun. 19,
2019, and entitled "Electronic Health Record Data Blockchain System
and Process," the entirety of both applications is incorporated
herein by reference.
TECHNICAL FIELD
[0002] The present disclosure generally relates to
blockchain-enabled patient data systems, and more specifically to
blockchain-enabled patient data systems configured to facilitate
anonymous patient data transactions between multiple entities.
BACKGROUND
[0003] In traditional electronic patient record systems, systems
are configured according to the conventional client-server model,
where a message is sent to a server and the server sends a
response, according to standards and format promulgated by the
National Council for Prescription Drug Programs (NCPDP). Many
times, the client and the server can have inapposite databases,
such as Oracle.RTM. and MS SQL.RTM. databases. Additionally, each
message sent and received is recorded in by the client and the
server. Often times, discrepancies arise between the client and the
server regarding the actual contents of the messages due to system
issues, etc.
[0004] In particular, pharmacy patient information messages can be
edited by multiple entities as they make their way from a pharmacy
to a payer for payment. As each entity in the chain edits the
message, additional complexities are added that can result in
additional message discrepancies. This can result in multiple
databases with a message with varying message integrities. Such
discrepancies result in wasted effort, time, and money directed
toward resolution of the discrepancies.
[0005] Further, the availability of complete patient-identifiable
data stored in databases affords the possibility and increased
likelihood of HIPPA violations and incorrect handling of such data.
Multiple systems may be required to monitor prescriptions, provide
edits, provide offers, determine drug eligibility, identify
fulfillment options, and finalize pricing, wasting precious
resources, adding complexity, and resulting in excess costs.
SUMMARY
[0006] The present disclosure teaches technical advantages as an
Electronic Health Record (EHR) data blockchain system configured to
allow multiple entities (e.g., pharmacy industry entities and
healthcare providers that can act as data, service, or product
providers, and consumers) to connect to an EHR patient transaction
blockchain (e.g., EHR-DATA-BC) and an EHR Data Patient Portal
(EHR-Data-PP) to provide a centralized location for messages and
subsequent edits to ensure uniform message data. All entities can
directly communicate with the EHR patient transaction blockchain
through a predefined blockchain application programming interface
(e.g., EHR-Data-BC-API). The system can facilitate the transfer of
anonymous patient data between multiple entities, including: [0007]
Physicians [0008] Pharmacies [0009] Independent [0010] Chain [0011]
Central Fill Facilities [0012] Mail Order [0013] Drug Manufacturers
[0014] Drug Wholesalers [0015] Prescription editing providers
including those for: [0016] Drug Utilization Review [0017] Genomic
[0018] Pricing [0019] Prescription Benefit Managers [0020] Pharmacy
Software Vendors [0021] National Facilitators [0022] Shipping
Services (Federal Express, DHL, etc.) [0023] Delivery Services
[0024] Prescription Call Centers [0025] Government Agencies [0026]
Others
[0027] The EHR data blockchain system can include an EHR Data API,
an EHR patient to transaction blockchain API, and an EHR patient
transaction blockchain. The EHR Data API can ti be configured to
access and retrieve patient identifiable information (PII) and
generate a non-patient-identifiable Single Purpose Patient ID
(SPPID) for a particular patient for use in a discrete transaction.
The EHR patient transaction blockchain API (e.g., EHR-DATA-BC-API)
can be configured to store the SPPID, store particular, discrete
data retrieved from the EHR for a patient, execute smart contracts,
and control the execution of digital currency transactions (e.g.,
cryptocurrency transactions to occur using each parties' digital
wallet information), among other functions.
[0028] A patient's private information, including the patient's
name, address, phone number, social security number, insurance
information, medical history, clinical information, and other
relevant information, can be stored in an Electronic Health Record
(EHR) database, such as a sometimes called Electronic Patient
Outcome Record ("EPOR"), Solid POD, XML file, or other suitable
data storage element. No patient identifiable information will be
stored in the EHR patient transaction blockchain to thus assure the
anonymity of the patient data. Instead, when a new blockchain
transaction is initiated by an entity for a particular patient, the
EHR database is queried to determine if the patient already has a
record. If the patient has a record in the EHR database, a Single
Purpose Patient ID (SPPID) can be generated and returned, along
with pertinent data, to the requesting entity. The SPPID can be
used for the transaction instead of any patient identifiable
information. The SPPID can be used only until the transaction for
the query is completed. The next time a blockchain transaction
related to the patient is submitted, the patient will be issued a
new SPPID, thereby ensuring that an SPPID is not indefinitely
associated with the patient for all future transactions. This
technique insures that even if a single SPPID is compromised, such
that a patient's identifiable information (PII) can be determined,
the compromise will only be limited to one transaction.
[0029] Once a transaction is completed, the SPPID can only be used
to read information, associated with the transaction, from the
block-chain. Based on permissions granted by the patient, EHR Data
may group the transaction data, with other transactions, medical
de-vice data, etc. associated with the patient, for reporting,
analytics, drug research, etc. For example, a drug company may wish
to understand how a specific drug affected patients' heart rates.
The report sent to the drug manufacturer from EHR Data would
include all of a patient's transactions, for the specified drug,
along with heart rate device data accumulated for the patient while
the patient was taking the specified drug.
[0030] The EHR patient transaction blockchain can be used as a
workflow space to process the transaction until the transaction
completes, is signed, and is distributed for consensus. Smart
contracts can be implemented to determine and define workflow
processes, drug interactions, fulfillment, expected outcomes,
triggering events, and pricing, among other data elements.
[0031] In one exemplary embodiment, a system for providing
blockchain-based patient transactions, can include: one or more
computer-readable storage media configured to store a blockchain; a
data Application Programming Interface (API) system comprising one
or more processors programmed to execute computer program
instructions that, when executed, cause the data API system to:
receive a request for a new blockchain transaction related to a
patient, initiate a patient lookup query to determine whether a
patient electronic health record exists, generate a single purpose
patient ID (SPPID) associated with the patient electronic health
record; a client computer programmed to execute computer program
instructions that, when executed, cause the client computer to:
receive a patient lookup query related to a patient from a client
to determine whether the patient's electronic health record exists,
receive the SPPID to initiate a new blockchain transaction related
to the patient on the blockchain without patient-identifying
information, determine whether an entity operating the client
computer can provide data, products and/or services related to a
blockchain transaction; and a blockchain API system comprising one
or more processors programmed to execute computer program
instructions that, when executed, cause the blockchain API system
to: generate the blockchain transaction and read and write records
to and from the blockchain, and associate one or more smart
contracts with the blockchain transaction. The smart contract
exchanges digital currency between the parties involved in the
smart contract. The digital currency includes utility tokens or
vouchers. The SPPID cannot be used to write information to the
blockchain after a patient blockchain transaction is completed. The
blockchain API system can generate a notification when the
blockchain transaction is generated. The blockchain API system can
transmit the notification to one or more providers. The client
computer can provide information to the blockchain API system
regarding data, products and/or services related to the blockchain
transaction. The blockchain API system can edit the blockchain
transaction on the blockchain.
[0032] In another exemplary embodiment, a method of providing
blockchain-based electronic health record data patient
transactions, the method being implemented by a server system
comprising one or more processors executing computer program
instructions that, when executed, perform the method, can include:
associating a single purpose patient ID (SPPID) with the electronic
health record; providing the SPPID to the client so the client can
initiate a new blockchain patient transaction related to the
patient on the blockchain without patient-identifying information;
receiving a patient transaction from a pharmacy; writing the
patient transaction to the blockchain; notifying one or more client
devices of the patient transaction; receiving one or more offers
for data, products, or services related to the patient transaction;
generating a smart contract related to the patient transaction and
the one or more offers; and modifying the patient transaction based
on the execution of the smart contract. The smart contract
exchanges digital currency between the parties involved in the
smart contract. The digital currency includes utility tokens or
vouchers. The SPPID cannot be used to write information to the
blockchain after the patient blockchain transaction is completed.
Further comprising generating a notification when the patient
transaction is generated. Further comprising transmitting the
notification to one or more providers. The patient transaction is
modified on the blockchain. The patient transaction can be modified
on the blockchain in real-time.
[0033] In another exemplary embodiment, a system for providing
electronic health record data for blockchain-based patient
transactions, can include: one or more computer-readable storage
media configured to store a blockchain; a data Application
Programming Interface (API) system comprising one or more
processors programmed to execute computer program instructions
that, when executed, cause the data API system to: receive a
request for a new blockchain transaction related to a patient,
initiate a patient lookup query to determine whether a patient
electronic health record exists, retrieve the patient electronic
health record from one or more databases, and generate a single
purpose patient ID (SPPID) associated with the patient electronic
health record; and a blockchain API system comprising one or more
processors programmed to execute computer to program instructions
that, when executed, cause the blockchain API system to: generate
the blockchain transaction and read and write records to and from
the blockchain, and associate one or more smart contracts with the
blockchain transaction. The smart contract exchanges digital
currency between the parties involved in the smart contract. The
digital currency includes utility tokens or vouchers. The
blockchain API system edits the prescription transaction on the
blockchain based on input from one or more providers.
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] FIG. 1 shows a schematic view of an electronic health record
data blockchain system, in accordance with one or more exemplary
embodiments of the present disclosure;
[0035] FIG. 2 shows a schematic illustrating the types of
third-parties that can access the blockchain system, in accordance
with one or more exemplary embodiments of the present
disclosure;
[0036] FIG. 3 shows a block diagram of an electronic health record
data blockchain system transaction, to in accordance with one or
more exemplary embodiments of the present disclosure;
[0037] FIG. 4A-4E shows a block diagram of an electronic health
record data blockchain system RxNew transaction, in accordance with
one or more exemplary embodiments of the present disclosure;
and
[0038] FIG. 5 shows a block diagram of an electronic health record
data blockchain system process flow 500, in accordance with one or
more exemplary embodiments of the present disclosure.
DETAILED DESCRIPTION
[0039] The preferred version of 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, which follows.
Descriptions of well-known components have been omitted so to not
unnecessarily obscure the principle 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. Accordingly, these examples should
not be construed as limiting the scope of the claims.
[0040] FIG. 1 illustrates an Electronic Health Record (EHR) data
blockchain (EHR-DATA-BC) system 100, in accordance with one or more
exemplary embodiments of the present disclosure. The EHRR-DATA-BC
system 100 can include a server 102, third party databases 106, a
distributed ledger 125, a network 130, and external systems
140.
[0041] The server 102 can include one or more processors (or cores)
104, a memory 106, and machine-readable instructions 108. In one
exemplary embodiment, the machine-readable instructions 108 can
include an EHR Data API 110, a transaction blockchain API 112, a
pre- and post-edit module 114, an interaction analysis module 116,
an eligibility analysis module 118, and a payment module 120.
Additionally, the server 102 can host an EHR Data Patient Portal
(EHR-Data-PP) that can provide a patient with access to the system
100 after an authenticated login. The server 102 can 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 processors,
with access to memory. Server(s) can include electronic storage,
one or more processors, and/or other components. Server(s) can
include communication lines, or ports to enable the exchange of
information with a network and/or other computing platforms.
Server(s) can also include a plurality of hardware, software,
and/or firmware components operating together to provide the
functionality attributed herein to server(s). For example,
server(s) can be implemented by a cloud of computing platforms
operating together as server(s). Additionally, the server can
include memory 106.
[0042] Server(s) can include electronic storage, one or more
processors, and/or other components. Server(s) can include
communication lines, or ports to enable the exchange of information
with a network and/or other computing platforms. Server(s) can also
include a plurality of hardware, software, and/or firmware
components operating together to provide the functionality
attributed herein to server(s). For example, server(s) can be
implemented by a cloud of computing platforms operating together as
server(s).
[0043] Memory 106 can comprise electronic storage that can include
non-transitory storage media that electronically stores
information. The electronic storage media of electronic storage may
include one or both of system storage that can be provided
integrally (i.e., substantially non-removable) with server(s)
and/or removable storage that can be removably connectable to
server(s) via, 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 can
include one or more virtual storage resources (e.g., cloud storage,
a virtual private network, and/or other virtual storage resources).
Electronic storage can store machine-readable instructions,
software algorithms, information determined by processor(s),
information received from server(s), information received from
computing platform(s), and/or other information that enables
server(s) to function as described herein. The electronic storage
can also be accessible via a network connection.
[0044] Processor(s) 104 can be configured to provide information
processing capabilities in server(s). As such, processor(s) can
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) can be a single entity or include a
plurality of processing units. These processing units can be
physically located within the same device or represent the
processing functionality of a plurality of devices operating in
coordination or software functionality.
[0045] The processor(s) 104 can be configured to execute
machine-readable instructions 108 or learning modules by software,
hardware, firmware, some combination of software, hardware,
firmware, and/or other mechanisms for configuring processing
capabilities on processor(s). As used herein, the term
"machine-readable instruction" may refer to any component or set of
components that perform the functionality attributed to the
machine-readable instruction component. This can include one or
more physical processors during execution of processor readable
instructions, the processor readable instructions, circuitry,
hardware, storage media, or any other components.
[0046] The server 102 can be configured with machine-readable
instructions 108 having one or more functional modules. The
machine-readable instructions can be implemented on one or more
servers, having one or more processors, with access to memory. The
machine-readable instructions can be a single networked node, or a
machine cluster, which can include a distributed architecture of a
plurality of networked nodes. The machine-readable instructions can
include control logic for implementing various functionality, as
described in more detail below. The machine-readable instructions
can include certain functionality associated with an EHR Data
Patient Portal (EHR-Data-PP), EHR Data API (first server-side
computer system) 110, EHR patient transaction blockchain API
(second server-side computer system), pre- and post-edit module
114, interaction analysis module 116, eligibility analysis module
118, and payment module 120. External databases 106 and external
systems 140, as well as an EHR Data Blockchain client (client
computer system) can also be implemented on one or more servers
102, having one or more processors 104, with access to memory
106.
[0047] In one exemplary embodiment, the EHR Data API 110 can
provide an interface that defines interactions between multiple
software components. For example, EHR Data API 110 can 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. In another exemplary embodiment, the
EHR Data API 110 can access and retrieve patient identifiable
information (PII) and generate a non-patient-identifiable Single
Purpose Patient ID (SPPID) for a particular patient.
[0048] In one exemplary embodiment, the EHR patient transaction
blockchain API 112 (e.g., EHR-DATA-BC-API) can provide an interface
that defines interactions between multiple software components. For
example, EHR patient transaction blockchain API 112 can 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. In another exemplary embodiment, the
transaction blockchain API 112 can be configured to store the
SPPID, as well as particular, discrete data retrieved from the EHR
for a patient, execute smart contracts, and control the execution
of digital currency transfers, among other functions.
[0049] In one exemplary embodiment, a pre- and post-edit module 114
can edit received distributed ledger transactions according to
input received from eternal systems 140, third-party databases 106,
or other suitable systems. In another exemplary embodiment, the
transactions can be processed in real-time while a pharmacy is
filling a prescription. For example, "pre-edit" and post-edit"
processing can be used by pharmacies and payers in the industry to
examine prescription claims for accuracy and consistency using
predetermined data and rules for processing claims. In another
exemplary embodiment, the pre- and post-edit module 114 can analyze
the patient clinical data in the context of the submitted
prescription and information about the prescribed pharmaceuticals
and complete the pre-editing process. For example, the module 114
can receive patient clinical data from third party databases 106
and correlate the prescription information with the patient
clinical data to determine whether the incorrect dosage or timing
is prescribed, given the patient's height, weight, or other patient
factors. In another exemplary embodiment, the EHR Data API 110 can
be operably coupled to the pre- and post-edit module 114 to provide
relevant patient information related to the transaction to the pre-
and post-edit module 114. In another exemplary embodiment, the EHR
patient transaction blockchain API 112 can be operably coupled to
the pre- and post-edit module 114 to store the particular, discrete
data retrieved from the EHR for a patient related to the
transaction.
[0050] In one exemplary embodiment, an interaction analysis module
116 can receive information related to potential drug interactions
and read and write that data to the distributed ledger 125. For
example, the interaction analysis module 116 can analyze
transaction information with patient clinical data extracted from
the third-party databases 106, including at least one or more of
information about potential drug interactions with other drugs and
patient risk factors, including information selected from the group
consisting of patient laboratory data, genomic data, immunizations,
and allergies. In one exemplary embodiment, an eligibility analysis
module 118 can make patient eligibility determinations related to
the transaction. For example, the eligibility analysis module 118
can receive a patient's insurance information and correlate that
information with the transaction data to determine eligibility for
discounts, and other relevant content.
[0051] In one exemplary embodiment, the payment module 120 can
determine if a smart contract was utilized during prescription
filling and may result in the exchange of digital currency (e.g.,
EHRCash.TM., Bitcoin.RTM., etc.), utility tokens, vouchers, or
other suitable notes, between the parties involved in the smart
contract. For example, the exchange of EHRCash.TM. tokens can be
immediate (sub-millisecond delay) and can eliminate the need for
standard accounting processes (i.e. invoicing, statements, accounts
receivable and accounts payable) in order to collect money from
trading partners. In another exemplary embodiment, a Utility Token
called EHRCash.TM., and a smart contract platform can be used to
streamline payments between stakeholders and patients, eliminating
the need for accounts receivable and accounts payable systems.
EHRCash.TM. can exist in multiple forms, but a specific form can be
used for a specific transaction. In another exemplary embodiment,
EHRCash.TM. can be native to an underlying payment blockchain (BSV)
or based on a FIAT Stable coin (e.g., USD, EUR, GBP, etc). In
another exemplary embodiment, the payment module 120 can utilize
stored digital wallet information to effect the digital currency
transactions. The modules described herein can be executed, called,
or otherwise implemented via server, control logic, API, or other
suitable means.
[0052] The distributed ledger 125 can be one or more EHR Data
blockchains implemented on one or more platforms, including
BigChainDB, nChain, Ethereum, Hyperledger, R3, Ripple, EOS, or
other suitable blockchain platform. The EHR Data blockchain can be
a public blockchain, accessible to the general public, or a private
blockchain, accessible only by those parties credentialed for
access. In another exemplary embodiment, all data can be stored on
the blockchain as a graph/hierarchy structure. Each node can
contain specific information (e.g., patient name, address,
medication, etc.) in the graph/hierarchy that can be encrypted with
its own encryption key. This graph/hierarchy structure may not be
visible on the blockchain and thereby provide an obfuscation of the
data structure. In another exemplary embodiment, only the master
private key for the patient/user can understand the structure.
[0053] The aforementioned system components, APIs, and modules, can
be communicably coupled to each other via the Internet, intranet,
system bus, or other suitable network 130. The communication can be
encrypted, unencrypted, over a VPN tunnel, or other suitable
communication means. The network 130 can be a WAN, LAN, PAN, or
other suitable network. The network communication between the
system components 102, 104, 106, 108, 110, and 112, can be
encrypted using PGP, Blowfish, AES, 3DES, HTTPS, or other suitable
encryption. The network communication can occur via application
programming interface (API), health level 7 (HL7) standard,
ANSI-X12, Ethernet, PCI, PCIe, InfiniBand, Wi-Fi, Bluetooth, or
other suitable communication protocol.
[0054] Third party databases 106 can be operably coupled to the
system components via the network 130. In one exemplary embodiment,
the third-party databases 106 can include an electronic medical
record system (EMR), an Electronic Patient Outcome Record (EPOR)
database, pharmacy databases, a plurality of patient databases, a
clinical database, a genomic database, a laboratory database, a
disease database, a standardized drug database, a research
database, and other suitable databases. In another exemplary
embodiment, the third-party databases can function as archival
nodes. The archival nodes can keep a real-time (sub-millisecond)
encrypted copy of the distributed ledger 125. The archival node can
provide fault tolerance and makes the contents of the distributed
ledger 125 readily available to a host so that additional data
processing, reporting, and analytics can be achieved. Instead of
having to traverse the EHR Data API 110, the host can query its own
machines to acquire the data. Any third party can host a drug
archival node. In another exemplary embodiment, the archival node
can provide data restoration to the distributed ledger 125. In
another exemplary embodiment, the archival node can keep the older
distributed ledger data accessible in a non-production system, so
that the production distributed ledger can direct its full
capabilities toward current transactions. In another exemplary
embodiment, the distributed ledger can be transferred to the
archival node once a distributed ledger transaction closes.
[0055] External systems 140 can be operably coupled to the system
components via the network 130. External systems 140 can include
patient devices, pharmacy devices, payer devices, financial
institution devices, insurance devices, medical devices, IoT
devices, or other suitable systems or devices. Such systems and
devices can include smart phones, tablets, wearable devices,
laptops, desktops, servers, appliances, or other suitable devices.
In one exemplary embodiment, an external system 140 can be
EHR-Data-BC-Client.
[0056] FIG. 2 shows a schematic 200 illustrating the types of
third-parties that can access the blockchain system 100, in
accordance with one or more exemplary embodiments of the present to
disclosure. The EHR Data blockchain system 100 can allow pharmacy
industry entities (which act as data, service, product providers)
and consumers to connect to the EHR-DATA-BC 125 and the EHR Data
Patient Portal (EHR-Data-PP) hosted on the server 102 using the ERR
Data API (a predefined application programming interface) 202. An
example of the types of entities that can connect include: [0057]
Physicians 216; [0058] Pharmacies 218, including: [0059]
Independent, [0060] Chain, [0061] Central Fill, and [0062] Mail
Order; [0063] Drug Manufacturers 214; [0064] Drug Wholesalers;
[0065] Prescription editing providers 210, including: [0066] Drug
Utilization Review, [0067] Genomic, and [0068] Pricing; [0069]
Prescription Benefit Managers 212; [0070] Pharmacy Software
Vendors; [0071] National Facilitators; [0072] Shipping Services
(Federal Express.RTM., DHL.RTM., etc.); [0073] Delivery Services
206; [0074] Prescription Call Centers; [0075] Government Agencies;
and [0076] Other relevant entities 208.
Blockchain Operations
[0077] In one exemplary embodiment, when interacting with the
EHR-Data-BC 125 the entities can use EHR Data blockchain clients
(EHR-Data-BC-Client) to initiate operations using the
EHR-Data-BC-API. Such operations can include: [0078] Creating a new
Transaction, such as: [0079] RxNew--a transaction to indicate a new
prescription, [0080] RxRefill--a transaction to indicate that a
prescription is being filled, [0081] RxTransfer--a transaction to
indicate that a prescription has been transferred to a different
store, [0082] RxComplete--a transaction to indicate a prescription
has been finalized, [0083] RxDeactivate--a transaction to indicate
that a prescription has been deactivated, and [0084] RxUpdate--a
transaction to indicate a prescription has been updated; [0085]
Attaching a Smart Contract to an existing Transaction; [0086]
Attaching a Parent Smart Contract to an existing Smart Contract;
[0087] Attach a Child Smart Contract to an existing Smart Contract;
[0088] Attaching Meta-Data to an existing Transaction, such
meta-data can be used to modify the original transaction or add new
data elements to the existing transaction. The specifics of the
meta-data can be unique to the type of the original transaction and
can be controlled by the API; and [0089] Closing an existing
contract.
Process Flow
[0090] FIG. 5 shows a block diagram of an electronic health record
data blockchain system process flow 500, in accordance with one or
more exemplary embodiments of the present disclosure. In one
exemplary embodiment, before a new transaction can be placed on the
ERR Data Blockchain (EHR-Data-BC) 125 it may be necessary to
associate the transaction with a patient. In another exemplary
embodiment, the EHR-Data-BC-Client 902 can be an external device
140. In another exemplary embodiment, the EHR-Data-BC-API 110 is
operably coupled to the EHR-Data-BC 125 to access, store, and
process data on and relate to the EHR-Data-BC 125. The
EHR-Data-BC-API 110 can access the EHR-Data-BC 125 through network
130, as in a public blockchain, or directly via server 102, as in a
private blockchain. In another exemplary embodiment, ER-Data-PP-API
906 can provide a user interface to the EHR-Dat-BC-Client 902, by
which the EHR-Data-BC-Client 902 can send and receive data to and
from server 102, the EHR-Data-PP-API 906, the EHR-Data-BC-API 110,
and the EHR-Data-BC 125.
Determine Single Purpose Patient ID (SPPID)
[0091] In another exemplary embodiment, the EHR-Data-BC 125 can be
publicly viewable. Accordingly, no patient identifiable information
(PII) may be stored in the EHR-Data-BC 125. In another exemplary
embodiment, storage of PII can be avoided by the issuance of an API
call via EHR-Data-BC-Client 902 to EHR-Data-PP-API 906 to determine
the identity of a patient. This API call can include general query
data 904 about the patient (e.g., first name, last name, phone
numbers, address, identification numbers, etc.) and can be used to
determine if the patient has a record stored in the system. If the
patient has a record in the system, pertinent patient data can be
returned along with a `single purpose patient ID` (SPPID) 912. As
its name indicates, the SPPID 912 can be a temporary II) associated
with the patient. In one exemplary embodiment, the SPPID 912 can be
a decimal, hexadecimal, text value, or other suitable ID, randomly
generated by the server 102 or the EHR-Data-PP-API 906. In another
exemplary embodiment, a new SPPID 912 can be generated per session.
In another exemplary embodiment, a new SPPID 912 can be generated
periodically (hourly, daily, weekly, or other suitable period). In
another exemplary embodiment, a new SPPID 912 can be generated
based on the satisfaction of a metric associated with the patient
(the number of queries, the number of transactions, or other
suitable metric). The SPPID 912 can be stored in the EHR-Data-BC
125 with or associated with a transaction. Once an SPPID 912 has
been generated and stored in the transaction, EHR-DATA-BC-Client
902 can use the SPPID 912 to retrieve information about the patient
(e.g., genomic information, allergy information, prescription
profile, etc.) without revealing the identity of the patient.
[0092] New Patient Record
[0093] In one exemplary embodiment, if the server 102 determines
that the patient does not have a data record, the
EHR-Data-BC-Client 902 can request that the server 102 generate a
new patient record. For example, a new patient record can be
created by the server 102 via the EHR-Data-PP-API 906, and an SPPID
912 can be returned to the EHR-Data-BC-Client 902 for that
patient.
[0094] In one exemplary embodiment, the EHR-Data-BC-Client 902 can
generate and submit a query 904 to the EHR-Data-PP-API 906, the
EHR-Data-PP-API 906 can request and/or generate an SPPID 912 and
return SPPID 912 to EHR-Data-BC-Client 902. The EHR-Data-PP-API 906
can retrieve a patient record stored in the memory 106 of server
102 or retrieve a record in a third-party database 106 via the
network 130. In another exemplary embodiment, the EHR-Data-PP-API
906 can provide the SPPID 912 to the EHR-Data-BC-API 110 to store
the SPPID 912 in the EHR-Data-BC 125. In another exemplary
embodiment, the EHR-Data-BC-Client 902 can provide a transaction
generated by the EHR-Data-BC-Client 902 to the EHR-Data-BC-API 110
to store the transaction in the EHR-Data-BC 125.
Patient Information
[0095] The patient record can contain various types of information
related to the patient. In one exemplary embodiment, the patient
record can include: First Name. Last Name, Middle Name(s),
Address(s), Date of Birth, Physical Attributes, Identification
Numbers, Phone Numbers, Allergy Information, Genomic Information,
Prescription Profile, Prescription History, Prescription
Transaction History, Physician(s) Information, Address History,
among other relevant information.
[0096] FIG. 3 illustrates a flow chart diagram 300 exemplifying
control logic embodying features of an electronic health record
data blockchain system transaction, in accordance with one or more
exemplary embodiments of the present disclosure. The transaction
control logic 306 can be implemented as an algorithm on a server, a
machine learning module, or other suitable system or component. The
transaction control logic 306 can be implemented 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 suitable
combinations thereof. Transaction-related data can flow between one
or more EHR-Data-BC-Clients and the EHR-Data-BC 302 via
EHR-Data-BC-API 306. In one exemplary embodiment, the server 102
can permission and authenticate one or more EHR-Data-BC-Client to
access the EHR-Data-BC 302. For example, the server 102 can
establish and verify a username/password, or other suitable means
for authenticating a user or device. The server can also grant
read/write/execute permissions to a user or device for one or more
functions described herein. In one exemplary embodiment, each
entity can have a portal which can allow the entity to grant
permission to a third party to use a specific data item or range of
data items contained in the blockchain. In another exemplary
embodiment, an `Authorization Token` (e.g., authToken) can be
created on behalf of the user/entity, after the user/entity has
granted permission for read and/or write access to specific data
elements of their EHR Data. For example, the `authToken` can have a
specific lifespan (or Time-to-Live) and can only be renewed with
authorization from the user/entity.
[0097] The transaction control logic 306 can leverage the ability
of a computer platform to spawn multiple processes and threads by
processing data simultaneously. The speed and efficiency of the
transaction control logic 300 is greatly improved by instantiating
more than one process to generate and process a transaction having
a patient's data. 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 invention. In one
exemplary embodiment, the transaction control logic 306 can be the
EHR-Data-BC-API 306. In another exemplary embodiment, the
transaction control logic 306 can instantiate various modules of
the server 102.
BC-Transaction Add
[0098] The transaction control logic 306 process flow of the
present embodiment begins when the control logic 306 receives a new
BC-Transaction 304. In one exemplary embodiment, a first
EHR-Data-BC-Client 308 has permission to add a new BC-Transaction
304 to the EHR-Data-BC 302. In another exemplary embodiment, a
BC-Transaction 302 can be transmitted to the control logic 306 by a
Physician's Practice Management Software, an eScripts Software
Agent, or a Pharmacy's Prescription Filling Software. In another
exemplary embodiment, the first EHR-Data-BC-Client 308 can generate
a new BC-Transaction 304, such as a new e-prescription, and
transmit the BC-Transaction 304 to the control logic 306 via the
network 130. The control logic 306 can then store the
BC-Transaction 304 on the EHR-Data-BC 302.
BC-Transaction Defection
[0099] The transaction control logic 306 can detect and generate a
notification of a new BC-Transaction 304 on the EHR-Data-BC 302. In
one exemplary embodiment, various pharmacy industry entities can
receive a notification from the EHR-Data-BC 302 upon the occurrence
of an event, such as a new BC-Transaction 304 being stored on the
EHR-Data-BC 302. The control logic 306 can notify one or more
EHR-Data-BC-Clients 310 when a BC-Transaction 304, BC-MetaData, a
BC-SmartContract, or a BC-Close has been added or linked to the
EHR-Data-BC 302. In another exemplary embodiment, when a
notification is received, the EHR-Data-BC-Clients 310 can determine
whether the transaction type qualifies for any data, products,
and/or services in which the vendor can provide. The
EHR-Data-BC-Clients 310 can correlate the transaction information
with previously stored offerings to determine whether there is a
match. In one exemplary embodiment, the transaction information can
have information such as drug type, insurance information, or other
suitable data. In another exemplary embodiment, the transaction
information can include codes representative of the information
related to the transaction, such that the codes can be quickly
correlated by the EHR-Data-BC-Clients 310 to determine whether
there is a product/service match. The notification can be an
e-mail, text message, software alert, or other suitable
notification.
Add Smart Contract
[0100] The transaction control logic 306 can generate a smart
contract related to the BC-Transaction 304. In one exemplary
embodiment, if one of the EHR-Data-BC-Clients 310 receiving a
notification of a new BC-Transaction 304 determines that it (a
second EHR-Data-BC-Client 312) has data, products, and/or services
that the second EHR-Data-BC-Client 312 can provide related to the
BC-Transaction 304, the second EHR-Data-BC-Client 312 can transmit
information to the control logic 306 so that the control logic 306
can generate a BC-SmartContract 314 for the BC-Transaction 304.
[0101] In one exemplary embodiment, the BC-SmartContract 314 can be
operably coupled to the BC-Transaction 304 and can specify (in
programmatic terms and also in human-readable summary) the data,
product, or service that it can provide along with a specified
price. In another exemplary embodiment, the BC-SmartContract 314
can be a computer program or a transaction protocol, respectively,
that can be intended to automatically execute, control, or document
respectively legally relevant events and actions according to the
terms of a contract, of an agreement, or of a negotiation. In
another exemplary embodiment, the BC-SmartContract 314 can be a
computer program or a transaction protocol, respectively, that can
execute, control, or document based on user input (or multi-user
input). In another exemplary embodiment, the BC-SmartContract 314
can trigger the exchange of digital currency 320 (e.g., EHR Cash)
between parties.
[0102] Smart contract types can include: [0103]
SC_DrugOfferPatient--a smart contract to offer a coupon to patient
for selecting the drug. [0104] SC_EditDUR--a smart contract to
indicate that a Drug Utilization Review edit has determined that
the patient has some form of interaction with the drug selected.
[0105] SC_EditClinical--a smart contract to indicate that a
Clinical edit has determined that the patient has some form of
interaction with the drug selected. (e.g., patient can't metabolize
the drug selected, etc.). [0106] SC_FillCentral--a smart contract
to indicate that the prescription can be centrally filled.
Add Meta Data
[0107] The transaction control logic 306 can memorialize the terms
of the BC-SmartContract 314, if accepted. In one exemplary
embodiment, the first EHR-Data-Client 308 can transmit a
determination of whether or not to accept the offer from the second
EHR-Data-Client 312 to utilize the data, product, or service
offered by the second EHR-Data-Client 312. In another exemplary
embodiment, a plurality of BC-SmartContract 314 can be accepted by
the first EHR-Data-Client 308. In another exemplary embodiment, the
control logic can send a notification to the first EHR-Data-Client
308 via the network 130 to accept or decline the BC-SmartContract
314. In another exemplary embodiment, the control logic 306 can
received pre-determined decisions based upon the patient's
preferences (stored in the patient's record or transmitted with the
determination). In another exemplary embodiment, the control logic
306 can add Meta-Data (BC-MetaData 316) to the EHR-Data-BC and
associate it with the original BC-Transaction 304.
[0108] Meta-Data types can include: [0109] MD_DrugDetermine--a
prescription is ready for drug determination. A physician's
software can add this MetaData type to solicit drug recommendations
from drug manufacturers. [0110] MD_DrugRecommend--added to
recommend a drug for a prescription. A physician's software can add
this MetaData type to solicit drug dosage recommendations. [0111]
MD_DosageDetermine--a prescription is ready for dosage
determination. [0112] MD_DosageRecommend--added to recommend a
dosage for a prescription. [0113] MD_Eligible--added by a payer to
indicate that a patient is eligible to receive the selected drug or
a recommended drug. [0114] MD_Acquired--added by a pharmacy to
indicate that it has acquired the prescription.
Add BC-Close
[0115] The transaction control logic 306 can finalize and close the
BC-Transaction 304, in one exemplary embodiment, when the first
EHR-Data-BC-Client 308 determines to close the BC-Transaction 304
it can trigger the control logic to write a BC-Close 318 statement
to the EHR-Data-BC 302. The BC-Close 318 statement can prevent any
additional actions from occurring for the BC-Transaction 304 and
can trigger the control logic 305 to execute the BC-SmartContract
314.
Contract Execution
[0116] The transaction control logic 306 can determine which
BC-Smart Contracts 314 should be executed and can cause a digital
currency transaction to occur between the first EHR-Data-Client 308
and the second EHR-Data-Client 312. In one exemplary embodiment,
when the first EHR-Data-BC-Client 308 closes the BC-Transaction 304
by writing a BC-Close 318 to the EHR-Data-BC 302, the control logic
306 can determine whether any contracts associated with the
BC-Transaction 304 can be executed by checking the automatic or
user-received input. In another exemplary embodiment, if a BC-Smart
Contract 314 is to be executed, the control logic 306 can cause a
digital currency transaction to occur using each parties' digital
wallet information. In another exemplary embodiment, the EHR Data
Patient Portal (EHR-Data-PP) can maintain a patient's digital
currency account, for use in association with the system 100.
EXAMPLES
[0117] This following embodiments illustrate examples of typical
EHR Data Blockchain (EHR-DATA-BC) RxNew Transaction workflows.
RxNew Process Flow
[0118] New prescriptions can be created by physicians by one of the
following:
[0119] 1) Physicians through their Practice Management Software.
This software can contain EHR-Data-BC-Client software which can
operably couple it with the EHR-Data-BC.
[0120] 2) An eScripts agent, which can retrieve the prescription
from the eScripts network and using the EHR-Data-BC-Client
software, add a BC-Transaction (RxNew) to the EHR-Data-BC.
[0121] FIGS. 4A-4E illustrate a flow chart diagram 400 exemplifying
control logic embodying features of an electronic health record
data blockchain system RxNew transaction, in accordance with one or
more exemplary embodiments of the present disclosure. The RxNew
transaction control logic 306 can be implemented as an algorithm on
a server, a machine learning module, or other suitable system or
component. The RxNew transaction control logic 306 can be
implemented 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 suitable combinations thereof. Transaction-related
data can flow between one or more EHR-Data-BC-Clients and the
EHR-Data-BC 302 via control logic 306. In one exemplary embodiment,
the server 102 can permission and authenticate one or more
EHR-Data-BC-Client to access the EHR-Data-BC 302. For example, the
server 102 can establish and verify a username/password, or other
suitable means for authenticating a user or device. The server can
also grant read/write/execute permissions to a user or device for
one or more functions described herein.
BC-Transaction Add
[0122] As shown in FIG. 4A, the RxNew transaction control logic 306
process flow of the present embodiment begins when the control
logic 306 receives a new BC-Transaction 404 for a new prescription.
In one exemplary embodiment, a BC-Transaction 404 can be
transmitted to the control logic 306 by a Physician's Practice
Management Software, an eScripts Software Agent, a Pharmacy's
Prescription Filling Software, or other suitable software. In
another exemplary embodiment, the first EHR-Data-BC-Client 402 can
generate a new BC-Transaction 404, such as a new e-prescription,
and transmit the BC-Transaction 404 to the control logic 306 via
the network 130. The control logic 306 can then store the
BC-Transaction 404 on the EHR-Data-BC 302.
Physician--Adds New Transaction
[0123] In one exemplary embodiment, a Physician can generate a new
prescription, using their Practice Management Software (PMS). The
PMS can utilize the EHR-Data-BC-Client 402 to add a BC-Transaction
(RxNew) 404 to the EHR-Data-BC 302. In another exemplary
embodiment, the EHR-Data-BC-Client 402 can be integrated into the
PMS. In another exemplary embodiment, the EHR-Data-BC-Client 402
can be standalone software.
Add Smart Contracts
[0124] The RxNew transaction control logic 306 can receive one or
more BC-SmartContracts from one or more EHR-Data-BC-Clients that
have determined that they can supply data, product, or service
related to the RxNew Transaction 404. In one exemplary embodiment,
a plurality of pharmacy industry entities can monitor the
EHR-Data-BC 302 using ERR-Data-BC-Clients 406 and can provide data,
product, or service related to the RxNew Transaction 404. To
indicate such capability, each entity can create a BC-SmartContract
to describe their product/service, terms/conditions, and an
execution price. In one exemplary embodiment, a drug code (e.g.,
NDC-G-1) can be included in the RxNew Transaction 404. For example:
[0125] a generic drug manufacturer (e.g., DM-1) can provide a
generic drug (e.g., NIX-G-1) that is equivalent to the brand drug
(e.g., NDC-B-1) written in the prescription, and can initiate a
BC-SmartContract 410 that can indicate in programmatic terms the
generic drug code (e.g., NDC-G-1) and a coupon value (e.g., $5) if
the drug is substituted for the brand drug (e.g., NDC-B-1) when the
prescription has been filled via EHR-Data-BC-Client 408. [0126] a
generic drug manufacturer (e.g., DM-2) can provide a generic drug
(e.g., NDC-G-2) that is equivalent to the brand drug (e.g.,
NDC-B-1) written in the prescription, and can initiate a
BC-SmartContract 414 that can indicate in programmatic terms the
generic drug code (e.g., NDC-G-2) and a coupon value (e.g., $4) if
the drug is substituted for the brand drug (e.g., NDC-B-1) when the
prescription has been filled via EHR-Data-BC-Client 412. [0127] A
DUR Edit Service (e.g., DURES-1) can detect that the patient is
allergic to the generic drug (e.g., NDC-G-1) offered by DM-1 and
can initiate a BC-SmartContract 418 that can indicate in
programmatic terms the details of this interaction via
EHR-Data-BC-Client 416. [0128] A Clinical Edit Service (CES-1) can
detect that the patient cannot metabolize the brand drug (NDC-B-1)
and can initiate a BC-SmartContract 422 that can indicate in
programmatic terms the details of this interaction via
EHR-Data-BC-Client 420. The payer can be informed that the patient
can't metabolize the generic drug, which can be on the payer
formulary. [0129] A Central Fill (CF-1) can detect that they stock
the indicated drugs and can fill the prescription at a central
facility and ship the filled prescription to the pharmacy or
directly to the patient, and can initiate a BC-SmartContract 426
that can indicate in programmatic terms the details of this
fulfillment via EHR-Data-BC-Client 424.
[0130] In another exemplary embodiment, the control logic 306 can
generate the BC-SmartContracts that are initiated by the respective
EHR-Data-BC-Clients.
Prescription Benefit Manager--Adds Patient Eligibility Mea Data
[0131] As shown in FIG. 41 (continuing from FIG. 4A), in one
exemplary embodiment, a Prescription Benefit Manager (PBM) has
detected that it can supply prescription benefits to the patient
indicated in RxNew Transaction 404 and can initiate a BC-MetaData
508 transaction to the EHR-Data-BC 302 to indicate that the patient
is eligible for certain benefits, via the EHR-Data-BC-Client 502.
In another exemplary embodiment, the control logic 306 can generate
the BC-MetaData 508 transaction initiated by the EHR-Data-BC-Client
502 and write it to the EHR-Data-BC 302.
Pharmacy--Acquires Prescription
[0132] In one exemplary embodiment, the patient can enter a
pharmacy and indicate that they would like to have their
prescription filled. Using its EHR-Data-BC-Client 506, the pharmacy
can initiate a BC-MetaData 508 transaction to the EHR-Data-BC 302
indicating that it has acquired the prescription and started the
fill process. In another exemplary embodiment, the pharmacy can
indicate in the EHR-Data-BC-Client 502 that it has verified the
identity of the individual to satisfy any legal requirements.
Pharmacy--Selects Drug and Prices Prescription
[0133] In one exemplary embodiment, based on the DUR
BC-SmartContract 418 outcome and the Clinical BC-SmartContract 422
edit output, the pharmacy can select a generic drug (e.g., NDC-G-2)
from Drug Manufacturer 2 (DM-2), price the prescription (e.g.,
$22), and initiate a BC-MetaData 512 transaction to the EHR-Data-BC
302, via EHR-Data-BC-Client 510. In one exemplary embodiment,
alternative equivalent drugs can be selected instead.
PricingEdit--Adds Smart Contract
[0134] In one exemplary embodiment, a prescription drug pricing
service (PE-1) has detected that the pharmacy has priced the
prescription incorrectly ($22) and has initiated a BC-SmartContract
516 to the EHR-Data-BC 302 that can indicate, in programmatic
terms, the reason for the pricing error, the correct price (e.g.,
$48), and the contract execution price ($0.05), if the recommended
price is used, via EHR-Data-BC-Client 514.
Pharmacy--Fixes Price--Adds Meta Data
[0135] In one exemplary embodiment, the pharmacy fixed the pricing
issue, changed the price of the prescription, and initiated a
BC-MetaData 520 transaction to the EHR-Data-BC 302, via
EHR-Data-BC-Client 518.
Pharmacy--Ready for Adjudication
[0136] As shown in FIG. 4C (continuing from FIG. 4B), in one
exemplary embodiment, the pharmacy can initiate a new BC-MetaData
604 transaction to the EHR-Data-BC indicating that it is ready for
adjudication, via EHR-Data-BC-Client 602.
Pharmacy Benefit Manager--Adjudicates--Adds Smart Contract
[0137] In one exemplary embodiment, the Pharmacy Benefit Manager
(PBM) can adjudicate the prescription and initiate a
BC-SmartContract 608 indicating that it is willing to pay an amount
(e.g., $46) for the prescription, via EHR-Data-BC-Client 606.
Pharmacy--Accepts Adjudication--Adds Meta Data
[0138] In one exemplary embodiment, the pharmacy can initiate a
BC-MetaData 612 transaction to the EHR-Data-BC indicating that it
has accepted the adjudicated price (e.g., $46), via
EHR-Data-BC-Client 610.
Pharmacy--Ready for Dispensing--Adds Meta Data
[0139] In one exemplary embodiment, the pharmacy can initiate a
BC-MetaData 616 transaction to the EHR-Data-BC 302 indicating that
it is ready for dispensing, via EHR-Data-BC-Client 614.
Pharmacy Pill Counter--Dispensing Complete--Add Meta Data
[0140] In one exemplary embodiment, the pharmacy can incorporate an
automated pill counter that automatically dispenses the
prescription. When complete the pharmacy can initiate a BC-MetaData
620 transaction to the EHR-Data-BC 302, via EHR-Data-BC-Client
618.
Pharmacy--Ready for Quality Control--Adds Meta Data
[0141] As shown in FIG. 4C (continuing from FIG. 4B), in one
exemplary embodiment, the pharmacy can initiate a BC-MetaData 704
transaction to the EHR-Data-BC 302 indicating that the prescription
is ready for quality control review, via EHR-Data-BC-Client
702.
Pharmacy--Quality Control Complete--Adds Meta Data
[0142] In one exemplary embodiment, the pharmacy can initiate a
BC-MetaData 708 transaction to the EHR-Data-BC 302 indicating that
the quality control review is complete, accepted, and signed for by
a pharmacist, via EHR-Data-BC-Client 706.
Pharmacy--Ready for Pickup--Adds Meta Data
[0143] In one exemplary embodiment, the pharmacy can initiate a
BC-MetaData 712 transaction to the EHR-Data-BC 302 indicating that
the prescription is ready for pickup, via EHR-Data-BC-Client
710.
Patient--Will Pick Up--Adds Meta Data
[0144] In one exemplary embodiment, the application patient's
electronic device, such as a smart phone, tablet, laptop, or other
suitable device can receive a notification that the prescription is
ready for pickup. In another exemplary embodiment, the patient can
transmit an acknowledgement that they will pick up the prescription
via a user device (e.g., smartphone). The user device can then
initiate a BC-MetaData 716 transaction, indicating that the patient
will pick up prescription, via EHR-Data-BC-Client 714.
Patient--Crypto Checkout--Adds Smart Contract
[0145] In one exemplary embodiment, the patient can choose to pay
for the copay associated with the prescription using the balance in
their EHR Data Patient Portal (EHR-Data-PP) digital currency
account. The patient can use their smart phone to complete the
transaction, via EHR-Data-BC-Client 718. The patient's smart phone
can initiate a BC-SmartContract 720 related to the EHR-Data-BC
302.
Pharmacy--Patient Picked Up Prescription--Adds Meta Data
[0146] As shown in FIG. 4C (continuing from FIG. 4B), in one
exemplary embodiment, after the patient has paid for the
prescription using their crypto currency account, the pharmacy can
initiate a BC-MetaData 804 transaction on the EHR-Data-BC 302
indicating that the patient has picked up the prescription, via
EHR-Data-BC-Client 802.
Pharmacy--Closes Prescription--Adds BC-MetaData
[0147] In one exemplary embodiment, the patient can pick up the
prescription, and thus the pharmacy can initiate a BC-MetaData 808
transaction indicating that the prescription is now closed and the
prescription filling process is complete, via EHR-Data-BC-Client
806.
Contract Execution
[0148] In one exemplary embodiment, following the close of the
BC-Transaction 404 the control logic 306 can initiate crypto
currency payments 812 for the executed SmartContracts 810. The
system thus generates an immutable record of the transaction for
subsequent review and auditing.
[0149] The present disclosure achieves at least the following
advantages: [0150] 1. improves the performance of traditional
systems by utilizing the EHR patient transaction blockchain as a
workflow space to process a transaction until the transaction
completes, is signed, and is distributed for consensus. [0151] 2.
implements smart contracts to determine and define workflow
processes, drug interactions, fulfillment, expected outcomes,
triggering events, and pricing, among other data elements; [0152]
3. reduces the utilization of additional processing resources and
network utilization from computationally-expensive data storage,
data bottlenecks, and system queries; [0153] 4. generates an
immutable record of the transaction for subsequent review and
auditing; [0154] 5. provides a platform for providing easy and
efficacious prescription editing, processing, and payment,
leveraging cryptocurrencies and APIs to facilitate transactions;
and [0155] 6. accesses and retrieves patient identifiable
information (PII) and generates a non-patient-identifiable Single
Purpose Patient ID (SPPID) for a particular patient for use in a
discrete transaction.
[0156] Persons skilled in the art will readily understand that
these advantages (as well as the advantages indicated in the
summary) and objectives of this system 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. It will be further understood that a
variety of programming tools, known to persons skilled in the art,
are available for implementing the control of the features and
operations described in the foregoing material. Moreover, the
particular choice of programming tool(s) may be governed by the
specific objectives and constraints placed on the implementation
plan selected for realizing the concepts set forth herein and in
the appended claims. In particular, the integration of
commercial-off-the-shelf (COTS) equipment may be utilized in the
new and unconventional manner described herein to achieve one or
more aspects of the claims.
[0157] 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.
.sctn. 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. .sctn. 112(f).
[0158] 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.
* * * * *