Systems and methods for prescription and administration of therapeutic stimuli using recorded warranties

Abstract

Systems and methods for managing a distributed ledger containing prescription information are disclosed. An exemplary apparatus includes a processor and logical data structures for configuring a device with an electronic prescription that defines actions for a patient, the electronic prescription organized as a record in the distributed ledger and processable by the device to apply the actions to the patient. The electronic prescription configures the device to, at a minimum, apply the actions to the patient, validates the actions for the patient using the distributed ledger, and reflects a record of the action on the distributed ledger.

Description

Technical Field

[0001] This disclosure generally relates to improved prescription management, and more particularly to improved systems and methods for decentralized ledger management of prescriptions and administrations.

Background Art

[0002] Prescription management is an important area essential for public health and patient treatment, but fraud and abuse, as well as lack of consistency and transparency, are rampant. Prescription errors, lack of accountability or audibility, etc. afflict the healthcare system, and the inability of third parties to evaluate prescription information has contributed to social problems such as the opioid epidemic. Furthermore, in the current system, pharmacies play an important role in the collection of funds and the dispensing of prescriptions to recipients. Without pharmacies, the system would collapse and prescriptions could not be provided to patients.

Summary of the Invention

[0003] Certain examples provide systems and methods for tracking and managing a decentralized ledger containing electronic prescription information.

[0004] Certain examples provide an apparatus including an energy application device, a pulse generator, a controller, and a memory including a logical data structure for configuring the apparatus according to an electronic prescription defining an action for a patient, the electronic prescription being compiled as one or more records within a decentralized ledger and processable by the controller to apply an action to the patient. When processed by the controller, the electronic prescription causes the controller to configure at least the energy application device and the pulse generator to apply an action to the patient, verify the action for the patient using the decentralized ledger, and reflect a record of the action in the decentralized ledger.

[0005] At least one computer-readable storage medium including a logical data structure for configuring a device according to an electronic prescription defining actions for a patient, the electronic prescription being compiled as one or more records of a distributed ledger and processable by a device to apply the actions to the patient, and when executed, causing at least one processor to configure the device to apply the actions to the patient, verify the actions for the patient using the distributed ledger, and propagate a record of the actions to the distributed ledger.

[0006] A computer-implemented method provides for configuring a device by an electronic prescription defining actions for a patient, the electronic prescription being compiled as one or more records within a distributed ledger and processable by a controller to apply the actions to the patient. An exemplary method includes configuring, by at least one processor using the electronic prescription, the device to apply the actions to the patient. An exemplary method includes verifying, by at least one processor using the electronic prescription, the actions of the patient using the distributed ledger. An exemplary method includes propagating, by at least one processor using the electronic prescription, a record of the actions to the distributed ledger.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

[0008] In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and which show by way of illustration specific examples in which the subject matter may be practiced. These examples are described in sufficient detail to enable those skilled in the art to practice the subject matter, and it is to be understood that other examples may be utilized and that logical, mechanical, electrical, and other changes may be made without departing from the scope of the subject matter of this disclosure. Accordingly, the following detailed description is presented for purposes of illustration and should not be construed as limiting the scope of the subject matter described herein. Specific features from different aspects of the following description may be combined to form further new aspects of the subject matter described below.

[0009] When introducing elements of various embodiments of this disclosure, the articles “a,” “an,” “the,” and “said” are intended to mean that one or more of the elements are present. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements. I. Overview

[0010] A prescription can be used to order, prepare, and adjust treatment materials and / or treatment protocols for a patient according to a treatment plan, protocol, etc. Such treatment materials can include pharmaceuticals, energy dosages, exercise programs, nutritional supplements, and the like. Using an electronic prescription, the ordering, payment, administration, and tracking of treatment materials can be dynamically managed and enhanced beyond existing prescription management features.

[0011] For example, the methods and systems disclosed and described herein provide a secure record of the energy dosage administered to a patient for therapeutic purposes using a secure method for verifying a given dosage. In a particular example, an energy device that applies an energy stimulus to the internal / external tissue of a patient can modify an electronic document (e.g., an entry or record in a blockchain or other distributed ledger) and transmit the modification via a network to one or more participating / connected systems (e.g., an electronic medical record system, a health information system, a hospital information system, a prescription management system, a radiation information system, a corporate archive, etc.), which can update and / or store the updated electronic document. For example, a dosage log chain that exists on a network and is shared among all nodes (e.g., devices, servers, other systems, etc.) on the network stores dosage information. Nodes on the network can verify changes to dosages administered and / or outputs of other treatments made by other nodes and can add new blocks to the chain using, for example, a one-way hash to make the chain resistant to tampering. If an invalid block is detected, the system can send an audit warning to the network. The audit log is highly resistant to tampering and can provide reliable evidence for use, for example, in auditing patient compliance, treatment effectiveness, the functionality of treatment devices, or the maintenance of patient / dosage records.

[0012] Specific examples encourage the use of blockchains and / or other distributed ledgers (e.g., "dosage coins") to ensure information in the handling between healthcare providers and users of patient / non-invasive (or invasive) energy-driven treatment machines and / or other treatment devices. For example, blockchains and / or other distributed ledgers can be used to ensure that dosages from treatment devices are communicated to other participants within the healthcare ecosystem.

[0013] In certain examples, data is stored and verified in relation to energy delivery to a patient (e.g., a home system for delivering energy to a patient). Verification of the person receiving the administration can be done, for example, using biometric data (e.g., biometric data obtained for each dosage, etc.). For example, a patient's digital pharmacy log as well as the associated numbers and / or other dosages of prescriptions can be tracked using biometric data (including various biometric data such as images obtained from a "dosage" device that verifies quantity, type, time, recipient, etc.). Verification of the number of administrations of a given prescription substance taken by an individual can be tracked for purposes such as diagnosis and treatment, insurance / claims, poison management, (e.g., without developing dependency), etc. The data can be recorded, for example, in a distributed ledger or stored as blocks. The ledger can be accessible and / or held by an electronic medical record system including a patient's record, a physician's monitoring application, an insurance company's system, and / or other payer / provider systems, a pharmaceutical system, etc.

[0014] Using the records of the distributed ledger, patient compliance data such as which patients are most closely following a "dosage" regimen can be stored. The records can cooperate with an electronic medical record system to, for example, compare monitored data to prescriptions and guidelines and compare compliance with protocols. The records of the distributed ledger can be used to store a physician's prescription data such as which physicians are prescribing most effectively. The records of the distributed ledger can be used to store effectiveness data such as the physiological effects of a particular dosage. The records of the distributed ledger can be used to store hardware / therapy effectiveness indications such as how well a machine functioned when administering a dosage to a patient. The records of the distributed ledger can be used, for example, to store dynamic dosing data to enable changes to prescriptions based on measurements of physiological feedback.

[0015] In certain examples, additional verification of handling and / or dosing can be performed based on the sender and recipient, such as treatment dosage information and / or other prescription information. For example, additional verification can include using image recognition (e.g., recognition of the patient's internal / external tissues) to verify the dosage based on the patient, location, etc. Additional verification can include, for example, utilizing tissue and / or physiological responses to verify the amplitude or dosage of energy applied by a treatment device. Additional verification can include, for example, using feedback from one or more internal and / or external sensors that measure the energy being applied to the patient. In certain examples, other characteristics, such as changes in blood flow and / or other physiological responses, can be used as verification of dosing. Some or all of these measurements can also be used, for example, in a consensus algorithm (including, for example, individual image recognition, etc.) to verify the people involved in the dosing. In certain examples, the treatment hardware can be coupled to another electronic device, such as a mobile phone, tablet computer, smartwatch, etc., to use global position data and / or other biometric data to associate a person with the device and verify the dosing.

[0016] In certain examples, a distributed ledger prescription system can face internally to store information so that the treating company can know how its system is being used. Alternatively or additionally, the distributed ledger prescription system can face externally, such that the treating company can provide dosing data to other healthcare practitioners, such as insurance companies, to enable them to derive value from the dosing information. For example, this value can drive the determination of insurance premiums for various patients based on compliance with the prescribed treatment regimen, correct application of energy, or different insurance payments for hospital systems that function better in the diagnosis of the dosing regimen.

[0017] In certain examples, participants in such blockchains and / or other distributed ledgers can include patients, primary healthcare providers, treatment providers, hospitals / healthcare systems, diagnostic / therapeutic equipment providers, insurance carriers, insurance claim administrators / auditors, government / regulatory agencies, consumer enterprises that can affect a patient's health through the provision of related or unrelated products, other parties within the healthcare space, etc. In certain examples, a pharmacy system can be involved in the verification process, but the pharmacy system is not required to play a role. Instead, a hospital and / or other patient health system can interact with suppliers to provide treatment materials to a patient and track their dosage, use, replenishment, etc.

[0018] Therapeutic energy sources and / or other neuromodulatory materials, chemicals, other drugs, etc. can be prescribed and applied to a patient as normalizing factors for the treatment of the patient's condition such as epilepsy, pain, sensory disorders, organ control (e.g., bladder, bowel, and / or respiratory control, etc.), depression, Alzheimer's disease, stroke, other neurological conditions, etc. In certain examples, multiple systems are involved in the prescription, distribution, payment, and application of such factors.

[0019] For example, FIG. 1 shows an exemplary prescription ecosystem 100 that provides treatment materials and / or other drugs and services for the treatment of patients in exchange for funds. As shown in the example of FIG. 1, manufacturer systems 110, such as a radiopharmaceutical manufacturer's system, a pharmaceutical manufacturer's system, a medical device manufacturer's system, and / or a sensor manufacturer's system, can supply products such as radiopharmaceuticals, pharmaceuticals, medical devices, and / or sensors to a wholesaler's system 120. For example, the manufacturer's system 110 can track the supply of manufactured goods and update a record indicating that the goods have been passed to a wholesaler associated with the wholesaler's system 120. For example, energy therapy devices and / or related materials (e.g., chemical agents, radiopharmaceutical materials, energy sources, other drugs, etc.) can be produced by the manufacturer's system 110 and provided to the wholesaler's system 120 to be sold and / or distributed to one or more recipients 140 via the pharmacy's system 130. For example, the exchange of goods and the payment of consideration for those goods are facilitated between the manufacturer's system 110 and the wholesaler's system 120, and between the wholesaler's system 120 and the pharmacy's system 130.

[0020] However, in certain examples, one or both of the pharmacy's system 130 and the wholesaler's system 120 can be excluded by instead operating directly between the manufacturer's system 110 and the recipient device 140. A benefits administrator system 150 that extracts information from a health plan data structure 160 having one or more plan sponsors 170 can cause, for example, the dispensing of prescriptions to the recipient system 140, as well as payments, rebates, etc. to the manufacturer's system 110, regardless of the presence or absence of the wholesaler's system 120 and / or the pharmacy's system 130. Records such as blockchains and / or other distributed ledgers can be used to track and verify prescription information, payments, administered / used dosages, remaining / unused dosages, administrative monitor chains, and related approvals. Distributed ledger

[0021] A blockchain is a list of records or blocks that are linked and grow to track the history of transactions and / or other developments of information. The blocks within a blockchain provide a history of transactions and / or other information states. A blockchain can be public (e.g., readable by anyone) or private (e.g., encrypted so that it can only be read by those with the key). A blockchain and / or other distributed ledger technology can be used as a digital tool to manage physical assets that are transacted between multiple entities. Blockchains and other distributed ledgers provide technical advantages, such as transparency and traceability of asset tracking and the validation of transactions.

[0022] Blockchain technology is a distributed computing mechanism designed to provide a degree of fairness such that one entity is not advantaged and another disadvantaged. A blockchain is a distributed public ledger of transactions (e.g., financial transactions, data transactions, etc.) where the transactions are publicly and chronologically recorded and can be verified by participants without a central authority. A blockchain applies encryption algorithms to a shared or distributed database to enable any user to read from and add to the database, and to prevent a single user from controlling what is written to the distributed database. Any blockchain user can view all transactions related to the distributed database. Blockchain technology provides disintermediation, for example, to reduce the intermediation in the communication between data producers and data consumers. That is, instead of involving an intermediary to facilitate a transaction, two entities (e.g., a data consumer and a data provider) can connect directly and participate in the transaction. Since other entities can view the transactions, the blockchain functions as a distributed consensus engine for entities to verify the existence of transactions and / or otherwise reach agreement.

[0023] Figure 2 shows an exemplary blockchain 200 that includes a plurality of records or blocks 210, 220, 230. Each record 210, 220, 230 includes a hash value 212, 222, 232 (e.g., the hash value or other address of the previous block in the chain 200), a timestamp 214, 224, 234 of the record 210, 220, 230, and an address of the root 216, 226, 236 of the blockchain 200. Further, each record 210, 220, 230 includes transaction engines 218 - 219, 228 - 229, 238 - 239 associated with their respective records 210, 220, 230. Thus, the blockchain 200 is a cryptographically protected, immutable chain of timestamped, consensus - verified data. The chain or ledger 200 exists at multiple locations with multiple users, for example, as a series of synchronized copies.

[0024] In certain examples, transaction engines 218 - 219, 228 - 229, 238 - 239 (e.g., prescription, approval, use, payment, remainder, etc.) can be incorporated into blocks 210 - 230 of the blockchain 200. In certain examples, the first block 210 has a header having a hash 212 of the data stored in block 210. The second block 220 has a header having a hash 222 of the header information of the first block 210 and a hash of the data of the second block 220. The third block 230 has, for example, a header having a hash 232 of the header information of the second block 220 and a hash of the data of the third block 230. Thus, blocks 210 - 230 are connected and / or associated with each other and can be used to verify each other, verify associated transaction engines 218 - 219, 228 - 229, 238 - 239, confirm usage, reorder, and / or trigger other instructions, such as via hashes 212 - 232. II. Examples of Prescription Management Systems and Related Methods

[0025] Figure 3 shows an exemplary prescription and device management system 300 for ensuring and recording dosages and / or other prescription information. As shown in the example of Figure 3, a blockchain and / or other distributed ledger network 310 communicates (e.g., via wired and / or wireless communication) with a prescription computer system 320 and an insurance company / primary care server 330. The blockchain network 310 records, for example, the handling between the prescription computer system 320 and the care server 330. The insurance carrier and / or primary care server 330 communicates (e.g., via wired and / or wireless communication) with a treatment or diagnostic supervision system 340. The insurance carrier / primary care server 330 and the prescription computer system 320 also communicate (e.g., via wired and / or wireless communication) with a healthcare network 350. The healthcare network 350 provides a conduit for instructions, configuration, reporting, etc. An energy control system 360 can also communicate with the prescription computer system 320 and the insurance company / primary care server 330 via the blockchain network 310 and the healthcare network 350.

[0026] Accordingly, instructions for prescriptions, device configuration, other handling, etc. can be sent between the prescription computer system 320, the insurance company / primary care server 330, and / or the energy control system 360 via the healthcare network 350, and a record of the handling is generated via the blockchain network 310 where both the prescription computer system 320 and the insurance company / primary care server 330 maintain a copy of the record. Since both the prescription computer system 320 and the insurance company / primary care server 330 have a copy of the distributed ledger, each system 320, 330 can verify the blocks added claiming to correspond to the handling between the computers 320, 330, 360. If the handling is not verified (e.g., by using a hash function, comparing to another record, etc.), the block is, for example, removed from the blockchain.

[0027] The energy control system 360 collaborates with an energy application device 370 (such as a transducer probe, etc.) to apply energy to treat a patient 380. For example, the energy control system 360 outputs a modulated stimulus (such as neuromodulation, ultrasound, etc.) to a target area of the patient tissue based on a prescription from a prescription computer system 320 verified by an insurance carrier / primary care server 330. The instructions can be transmitted via a healthcare network 350, and the records of the prescription, dosage, and configuration of the energy control system 360 and its energy application device 370 can be maintained and verified by comparison via a blockchain network 310. Physical and / or physiological feedback, stimuli, and / or effects 390 can be captured by the energy control system 360 after application by, for example, the energy application device 370 and provided to a treatment / diagnostic monitoring system 340. Alternatively or additionally, the treatment / diagnostic monitoring system 340 can provide stimulus configuration information 390 to the energy control system 360, for example, for delivery via the energy application device 370.

[0028] In some examples of neuromodulation, direct and focused modulation of a target region of interest is provided to elicit a desired physiological result as a result of the modulation. One or more target regions of interest can include any tissue or structure in the body that has axonal terminals that synapse with non-neuronal cells or fluids. For example, the region of interest can be within an organ or structure such as the spleen, liver, pancreas, or gastrointestinal tissue. In another example, the region of interest can be within lymphatic tissue. Neuromodulation of the region of interest enables energy to be applied locally, restrictively, and irresectably to only the target region of interest without applying energy outside of the region of interest. The energy application can cause downstream effects outside of the target region of interest, such as in the same organ, tissue, or structure that includes the region of interest, or in other organs and structures that do not include the target region of interest. In certain examples, downstream effects can be induced in regions of the hypothalamus. The energy application can also induce effects along the target nerve upstream of the energy application site. In certain examples, effects outside of the target region of interest can be achieved without directly applying energy to regions outside of the region of interest for which the downstream or upstream effects are induced. Thus, local energy application can be used to achieve or accomplish systemic effects that can include local effects, downstream effects, and / or upstream effects.

[0029] Furthermore, the stimulation can facilitate bidirectional control of complex physiological processes. For example, to avoid excessive activation of one pathway and excessive changes in physiological outcomes as a result of energy application in a particular region of interest, energy can be applied to different regions of interest associated with competing or deactivated pathways to induce changes in physiological outcomes in the opposite direction and maintain a dynamic balance of physiological outcomes to achieve the desired physiological outcome. In the example, energy is applied to a region of interest that causes a decrease in circulating glucose concentration to achieve a desired circulating glucose concentration or concentration range in hyperglycemic subjects. However, to avoid overcorrection of glucose and resulting hypoglycemia, energy that causes an increase in circulating glucose concentration can also be applied to a second region of interest to maintain the dynamic balance of circulating glucose concentration and stabilize the circulating glucose concentration at the desired level. For example, if direct energy application to the liver causes a decrease in glucose beyond a clinically acceptable level, energy can also be applied to the pancreas to increase glucagon production to compensate. The bidirectional stimulation can be provided to a first region of interest of a first organ and a second region of interest of a second organ. In another example, multi-site neuromodulation can be neuromodulation performed at different sites that enhance the same pathway. The energy application to the first region of interest and the second region of interest can be performed simultaneously or at different times (e.g., separated by seconds, minutes, days, or hours, etc.) and can be performed, for example, by the same or different energy application devices 370.

[0030] Certain examples can be used to exert external control over the physiological processes of the body to cause a targeted physiological result in a subject. For example, physiological processes can be altered, slowed, stopped, or reversed through neuromodulation of a target area of interest. Certain examples can be applied to a subject to promote the homeostasis or constancy of physiological processes such as glucose regulation. Targeted neuromodulation can function against an ongoing etiology or disease progression, provide treatment, and improve outcomes compared to a control (e.g., compared to an untreated subject). In some examples, targeted neuromodulation can be prophylactic and can be initiated prior to a particular event. For example, targeted neuromodulation can be used to prevent anorexia associated with a particular medical treatment or condition and / or can be applied before or during a meal to alter the body's response to the meal.

[0031] Neuromodulation of a target area of interest can effect changes in physiological processes, interrupt, reduce, or enhance one or more physiological pathways in a subject to yield a desired physiological result. Further, since local energy application can result in systemic changes, different physiological pathways can be altered in different ways at different locations in the body to affect the overall characteristic profile of the physiological changes in a subject caused by targeted neuromodulation for a particular subject and the characteristics that cause those characteristics. These changes are complex, but this neuromodulation technology provides one or more measurable target physiological results for the subject being treated that are the result of neuromodulation and that may not be achievable without the application of energy or other intervention to the target area of the subject. Further, other types of interventions (e.g., drug treatment, etc.) can result in a subset of the physiological changes caused by neuromodulation, but in certain examples, the profile of the physiological changes induced as a result of neuromodulation can be specific to the neuromodulation in the target area of interest (and its associated adjustment parameters) and can vary from patient to patient.

[0032] Using the neuromodulation techniques discussed herein, it is possible to cause a physiologically targeted outcome of a change (e.g., increase, decrease) in the concentration of a molecule and / or a change in the properties of a molecule in a subject. That is, selective modulation of one or more molecules in a subject (e.g., a first molecule of the subject, a second molecule of the subject, etc.) can refer to modulating or affecting the concentration (circulating, tissue) and / or properties (covalent modification) of the molecule as a result of the application of energy to one or more regions of interest (e.g., a first region of interest, a second region of interest, etc.) of one or more tissues (e.g., a first tissue, a second tissue, etc.). Modulation of a molecule in a subject can include changes in the properties of the molecule such as direct changes in activity based on ion channel effects resulting from expression, secretion, translocation of proteins, and from the application of energy itself, or as a result of the molecule directly affecting an ion channel. Modulation of a molecule in a subject may also refer to maintaining the desired concentration of the molecule so that changes or fluctuations in concentration that would be expected as a result of neuromodulation do not occur. Modulation of a molecule in a subject may indicate causing a change in the properties of the molecule such as covalent modification via an enzyme (changes such as phosphorylation, acetylation, ribosylation, etc.). That is, it should be understood that selective modulation of a molecule in a subject can refer to molecular concentration and / or molecular properties. The molecule in a subject can be a biomolecule such as one or more of a carbohydrate (monosaccharide, polysaccharide), lipid, nucleic acid (DNA, RNA), or protein. In a specific example, the molecule of interest can be a signaling molecule such as a hormone (amine hormone, peptide hormone, steroid hormone, etc.).

[0033] The specific examples described herein record, track, and verify neuromodulation techniques that elicit targeted physiological outcomes for the treatment of glucose metabolism and related disorders. Glucose regulation is complex and involves various local and systemic metabolic pathways. Application of energy to a target region of interest causes changes characteristic of these metabolic pathways that improve glucose regulation. In some examples, modulation at one or more regions of interest is used to treat disorders including, but not limited to, diabetes (e.g., type 1 or type 2 diabetes), hyperglycemia, sepsis, trauma, infection, physiological stress, diabetes-related dementia, obesity, other eating disorders, or metabolic disorders. In some examples, neuromodulation can be used to promote weight loss, control appetite, treat cachexia, or increase appetite. In an example, physiological stress can be medically defined to include various acute medical conditions (e.g., infection, severe injury / trauma, heart attack, bypass) as well as surgical examples presenting with hyperglycemia. For example, direct pancreatic stimulation can result in increased appetite, while direct liver stimulation can cause a decrease in NPY, which in turn promotes a satiety signal. The targeted physiological outcome can include adjusting the circulating (e.g., blood) glucose concentration in a subject to be within a desired concentration range associated with normal glucose levels and avoiding hyperglycemia or hypoglycemia. Thus, selective modulation of the molecule of interest can be achieved. The adjustment can be, for example, the result of an induced change in a glucose-regulating hormone in blood or tissue via targeted neuromodulation to cause a desired glucose concentration (e.g., a desired glucose endpoint). Further, glucose regulation can be beneficial for healthy patients who have not received a diagnosis of a disease but who, for example, are prediabetic or desire to maintain a healthy weight.

[0034] Using the exemplary system 300, the networks of blockchain 310 and healthcare 350 can be used to facilitate dosage recording and the reliability / assurance of dosage information. The supervisor's system 340 can, for example, verify the stimulation 390 (e.g., neuromodulation stimulation, ultrasonic stimulation, etc.), assist the energy control system 360 and the energy application device 370 in generating the stimulation 390, and / or process the feedback from the stimulation 390. On the other hand, the prescription computer system 320 gives instructions for the energy control system 360 to apply the stimulation 390, and the insurance carrier / primary care server 330 verifies the coverage and / or payment for the stimulation delivery to the patient 380. Instructions, commands, feedback, reports, etc. can be exchanged via the healthcare network 350, and the distributed ledger is constructed, maintained, and verified via the blockchain network 310.

[0035] Accordingly, the healthcare communication infrastructure 300 provides secure management and recording of the dosage of energy administered to a patient for therapeutic purposes using a secure method for verifying a given dosage via the distributed ledger of the blockchain network 310. The energy device 370 can apply the energy stimulation 390 to the internal / external tissue of the patient 380, make changes to an electronic document, and transmit those changes to the blockchain network 310. The dosage log chain that exists on the network 310 and is shared among all nodes on the network stores the dosage information. Nodes on the network 310 can verify changes to an administered or treatment output made by other nodes and can add new blocks to the chain, for example, using a one-way hash that makes the chain resistant to tampering. If an invalid block is detected, the system can send an audit warning to the network 310. The audit log is highly resistant to tampering and can provide reliable evidence, for example, for use in auditing patient compliance, treatment effectiveness, the functionality of the treatment device, and / or the maintenance of the patient / dosage record.

[0036] Figure 4 shows an exemplary ecosystem 400 of parties and attributes for delivering a prescription and dosage to a patient device. As shown in the example of Figure 4, system actors such as the care provider system 320, the pharmacy system 410, the payer / insurance system 330, the patient device 420, and related attributes such as treatment 332 and prescription 334 facilitate the immediate (or substantially instantaneous given communication and processing latency, etc.) prescription and administration of treatment stimuli by automating the delivery to the user's device 420 of the prescribed treatment. For example, the care provider system 320 includes a data structure defining treatment 332 that includes device identifiers, dosage information, monitoring protocols, etc., and a data structure defining prescription 334 that includes patient identifiers, treatment identifiers, prescriber identifiers, insurance identifiers, etc. The prescription is accessed 412 by the pharmacy system 410 and used to generate an order entry 414 that is approved or rejected by the payer / insurance system 330 that processes the prescription order in comparison to insurance contracts and / or other coverage. The approved order will fulfill a prescription contract 416 that includes patient identifiers, delivery device identifiers, dosage, and duration, etc. The fulfilled prescription contract can be accessed as an electronic prescription contract 425 by the user's computing device 420 (e.g., a mobile phone, a tablet computer, other handheld or mobile computing devices, etc.). In a particular example, the user's device 420 can function as an energy control system 360 for driving / controlling an energy application device 370 according to the approved prescription 425.

[0037] FIG. 5 shows an exemplary treatment schedule or workflow 500 for prescription, delivery, and auditing of dosages. At block 510, before treatment is applied to a patient, the exemplary system 400 approves a prescription and prepares a user device 420 for treatment via an electronic prescription 425. At block 520, treatment is administered. The treatment can include the application of a stimulus 390 to the patient 380, and the user device 420 can control an energy application device 370 and / or capture data related to the treatment. For example, the device 420 can capture a signal 522 related to the stimulus 390 and store the captured signal 524 for analysis, further control of the treatment, updating of a distributed ledger, etc. The data captured can include the position of the probe 370, inertial measurement unit (IMU) data, imaging data, patient identification information, dosage information, device identification information, biological metrics (e.g., blood, electricity, etc.), elastography (e.g., mechanical response of tissue, etc.), local blood flow, etc. At block 530, the post-treatment phase includes retrieving treatment information 532, stored signals 524, etc. for further analysis, reconfiguration of the device, etc.

[0038] FIG. 6 shows an exemplary data flow diagram 600 for prescription management that represents actors within a treatment workflow and includes a plurality of data structure constructs that characterize those actors to provide executable / executable instructions to drive prescription management including filling, verification, delivery, updating, etc. The executable code constructs that drive the exemplary data and instruction flow 600 include initialization 601, factory 603, device 605, prescriber 607, patient 609, insurance 611, ultrasound prescription 613, and device service provider 615. Each construct 601 - 615 and its interaction with other constructs 601 - 615 can generate, for example, updates and related verifications in a distributed ledger.

[0039] Upon initialization at 602, an instruction is sent to the factory 603 (e.g., the instruction is sent to a software factory that includes software assets for generating computer software applications and / or other software components, etc.) to create or instantiate the prescription 607 as software and / or data structures (e.g., machine learning and / or other artificial intelligence models, software applications, etc.), thereby creating the prescription and related software and / or data structures. At 604, the factory 603 generates the prescriber 607 (e.g., the software and / or data structures forming the prescriber 607 are encoded and / or formed by the factory 603 and deployed for use / execution, etc.).

[0040] Initialization 601 also triggers, at 606, the creation of device software and / or data structures representing devices 605 such as the energy application device 370 to be included in the prescription. At 608, the factory 603 generates the device structure 605.

[0041] Initialization 601 also triggers, at 610, the creation of patient software and / or data structures representing patients 609 such as the patient 380 to be the subject of the prescription. At 612, the factory 603 generates the patient structure 609.

[0042] Initialization 601 also triggers, at 614, the creation of insurance software and / or data structures representing the insurance 611 to be associated with the prescription. At 616, the factory 603 generates the insurance structure 611.

[0043] Initialization 601 also triggers, at 618, the creation of prescription software and / or data structures representing a prescription 613, such as an ultrasound prescription. At 620, the factory 603 generates a prescription structure 613 for the insurance structure 611. The definition of the prescription provided to the prescription structure 613 is compared with rules, constraints, data related to the patient structure 609, etc., and a prescription (e.g., an ultrasound prescription 613, etc.) is created at 622 based on the requirements of the device and the patient, insurance constraints, etc. At 624, benefits are deposited from the insurance structure 611 to the prescription 613, and at 626, a copay cost is provided from the insurance structure 611 to the patient structure 609. In addition to the benefits from the insurance structure 611, at 628, the patient structure 609 can trigger a copay deposit with the prescription 613.

[0044] The prescription structure 613 (e.g., an ultrasound prescription, other medical device prescriptions, other energy prescriptions, pharmaceutical prescriptions, etc.) here includes funds deposited from insurance benefits and patient copays, and at 630, the device 605 can fulfill the prescription. For example, the prescription structure 613 can instruct and / or otherwise configure the device structure 605 according to an ultrasound prescription for an energy application device 370 modeled by and / or otherwise associated with the device structure 605. The device 605 can then execute according to the prescription 613, such as instructing / configuring the device 370 to treat the patient 380 according to a specific energy dosage, settings, etc. Thus, at 632, the prescription 613 is consumed (e.g., by the device 370 for the patient 380, etc.). At 634, the device service provider 615 collects payment for the consumption of the prescription 613, such as from the funds stored in the prescription structure 613 (e.g., insurance benefits and / or copays, etc.).

[0045] For example, each of the structures 601 - 615 and / or its associated transaction engines 602 - 634 can be modeled as records 210 - 230 in the distributed ledger 200. Each of the creation / initialization transaction engines 602 - 622 for creating devices 605, prescribers 607, patients 609, insurances 611, prescriptions 613, etc. can be associated with records 210 - 230 in the ledger 200. Each of the parties such as the prescription computer system 320, insurance / primary care server 330, supervisor's system 340, energy control system 360, etc. can maintain a copy of the ledger 200 and verify the accuracy of its records 210 - 230 and changes to those records 210 - 230 (e.g., via hashing, proof - of - work, other matching / verification, etc.). Updates 624 - 628, 634 of the prescription 613 with added funds and / or subtracted payments can be, for example, updates to records 210 - 230 representing the prescription 613, patient 609, insurance 611, etc., and / or new records 210 - 230 added to the distributed ledger 200 representing the transaction engines 624 - 628, 634. The filling and consumption of prescriptions 630 - 632 can also be communicated, for example, as updates to new records 210 - 230 added to the distributed ledger 200 representing the record 210 - 230 of the prescription 613 and / or the transaction engines 630 - 632.

[0046] The example of FIG. 6 shows one data flow for prescription management, but other data flows can also be implemented. For example, another entity such as insurance 611 can create prescribers 607 and patients 609, and the manufacturing of devices can create devices 605, etc.

[0047] Figure 7 shows a combination 700 of exemplary data structures, data structures, class definitions, software executable structures, etc. 702 - 724 that drive the data and instruction flow 600 of the example of FIG. 6. FIG. 7 shows a logical data model for presenting a class diagram showing definitions of data and functions. As shown in the example of FIG. 7, the prescriber information factory 702 includes a function to create a prescriber information structure 607 that includes a prescriber name, prescriber address, etc. The prescriber information factory function 120 creates a prescriber structure 704 that includes prescription functions such as a prescription therapy function that utilizes the patient's address and prescription information to generate prescription information.

[0048] Furthermore, the patient information factory 706 defines a patient creation function using the patient's address, insurance address, etc. to create a patient information structure 708 that includes a function to provide the patient's insurance information and related insurance information. Further, the insurance information factory 710 defines an insurance creation function using the patient address, provider address, terms, etc. to create an insurance information structure 712 that includes adding prescription information such as patient address, insurance terms, and known prescribers, and adding prescribers, etc. The device information factory 714 defines a device creation function using the device address, manufacturer, model, etc. to create a device information structure 712 that includes functions to obtain the manufacturer, model, valid prescription (accompanied by, for example, the address of the prescription), and related functions such as adding the manufacturer, model, and prescription.

[0049] The entity 718 can be formed from the prescriber model 704, patient model 708, insurance model 712, and device model 716. The entity model or structure 718 can include functions such as name information, address information, etc., and information search functions (e.g., getInfo(), etc.), address search functions (e.g., getAddress(), etc.), name search functions (e.g., getName(), etc.).

[0050] As shown in the example of FIG. 7, the ultrasonic prescription factory 720 provides a function to create an ultrasonic prescription based on a patient information structure address, a device information structure address, a payment collector address, a dosage (e.g., a triple such as power, duration, price), payable, etc. The ultrasonic prescription factory 720 creates an ultrasonic prescription slip 722 that includes related functions such as obtaining a dosage (e.g., a triple such as power, duration, price), a net dosage pointer, a monitor, and adding a monitor for the next dosage. An exemplary ultrasonic prescription slip 722 can be provided to a device prescription 724 that includes a patient information address (e.g., including an owner, a refundable indicator, etc.), a device information address (e.g., including a consumer identifier, etc.), an insurance information address (e.g., including a returnable indicator, etc.), a payment collector address, etc. The device prescription 724 can also include functions such as obtaining patient information, paying a copayment deposit to be paid, paying a deposit benefit, refunding a deposit, collecting a payment, allocating a device, etc.

[0051] Using entity 718, ultrasonic prescription 722, and device prescription 724, data can be stored and verified for energy delivery to a patient. For example, the entity and prescription information 718, 722, 724 can include and / or be used to verify the person receiving the dosage. For example, the structures 718, 722, 724 can be formatted as records 210 - 230 of the distributed ledger 200 and / or associated therewith to form a digital pharmacy log of the patient and associated dosages (e.g., for each dosage). Verification of the patient and dosage can be determined using biometric data such as images obtained from the patient, device, materials, etc. by the patient's smartphone and / or other electronic device 420, dosing machine (e.g., energy device 370, etc.). The number of administrations obtained by the patient can be verified based on image data, patient samples, other biometric analyses, etc. (e.g., to prevent overdose or addiction) and stored as corresponding records 210 - 230 in a blockchain 200, etc. as part of the prescription and / or entity structures 718, 722, 724.

[0052] For example, image recognition of the patient's internal and / or external tissues can be used to verify the patient's dosage, location, intensity, etc. Processing the tissue and / or other physiological responses can verify the amplitude or dosage of the energy applied, for example, according to the ultrasonic prescription 722. Feedback from internal and / or external sensors can be used to measure the energy applied according to the device prescription 724 and verified according to the ultrasonic prescription 722. Alternatively or additionally, other features such as changes in blood flow and / or other physiological responses can be used as verification of the administration via the structures 718, 722, 724 and associated distributed ledger.

[0053] For example, using records 210-230 of ledger 200, compliance data can be stored and verified through operations and comparison proofs across devices 320-360, 420, etc., while maintaining a copy of the distributed ledger 200. The comparison of copies of ledger records 210-230 can be used to verify the accuracy of the measured data and compliance with device configuration, prescription information, patient status, treatment protocol, etc.

[0054] For example, a distributed prescription ledger 800, such as shown in the example of FIG. 8, can include a plurality of records 810-820 characterizing handling including patients, devices, insurance coverage, related prescription information, and handling including patient, device, insurance coverage, prescription delivery and update, etc. The exemplary ledger 800 is similar to the exemplary blockchain 200 and includes records 810, 820, 830 corresponding to data structures, software code, and handling including patients, related treatment devices, patient insurance coverage and finance, prescription formation, prescription delivery, prescription update, etc.

[0055] As shown in the exemplary ledger 800 of FIG. 8, records 810 are created when patients 609, 708, 718 are instantiated in the system, when devices 605, 716 such as energy application device 370, smartphone and / or other portable computing devices 420 are configured for use, when prescription structures 324, 613, 722, 724 are instantiated, when funds are provided to a prescription, when a prescription is administered, and so on. Additional records 820, 830 are created to reflect new handling and / or other updates / adjustments to patients, devices, insurance, prescriptions, etc. Exemplary records 810-830 include identifiers 811, 821, 831 associated with records 810, 820, 380, timestamps 812, 822, 832 corresponding to the creation and / or update of records 810-830, and types 813, 823, 833 of records 810-830 (e.g., patient record, device record, insurance carrier record, prescription record, entity record, dosage record, etc.). Exemplary records 810-830 also include prescriber information 814, 824, 834, patient information 815, 825, 835, insurance information 816, 826, 836, device information 817, 827, 838, handling information 818, 828, 838, etc. Types 813-833, prescribers 814-834, patients 815-835, insurance 816-836, devices 817-837, transaction engines 818-838, etc. can be used to form a representation of an entity (e.g., entity structure 718, etc.), for example. Entity record 810 can be updated by changing record 810 in transaction engine 818 and / or adding subsequent records 820, 830 to a distributed ledger 800 indicating new transaction engines 828, 838 for tracking progress and / or other changes such as patient treatment, insurance coverage / payment information, device configuration / usage, etc.

[0056] Multiple systems 320 - 360, 420, etc. maintain copies of records 810 - 830 of the distributed ledger 800 and can verify the content of records 810 - 820, transaction engines 818 - 838, etc. Changed, incorrect, or fraudulent records 810 - 830 can be identified and repaired, replaced, etc. using, for example, another copy of the distributed ledger 800. For example, each system that maintains a copy of the ledger 800 can verify the items within records 810 - 830, calculate the hash of the information in records 810 - 830, and solve the proof of work function for applicable records 81 - 830, etc.

[0057] FIG. 9 shows another exemplary distributed ledger 900 that provides management of a patient's prescription. In the example of FIG. 9, records 910 - 930 identify, monitor, and update the prescriptions applied by the device to the patient. Records 910 - 930 include identifiers 911, 921, 931 such as a number unique to the ledger 900 that identifies the record, the hash of the identifier of the previous record, and an identifier associated with the patient. Records 910 - 930 include timestamps 912, 922, 932 associated with the creation and / or update of records 910 - 390. Records 910 - 930 include types 913, 923, 933 to identify whether records 910 - 930 are new prescriptions, prescription updates or changes, handling or contracts related to prescriptions, etc. Records 910 - 930 include patient identifiers 914, 924, 934, device identifiers 915, 925, 935, insurance identifiers 916, 926, 936, payment indicators 917, 927, 937, dosage counters 918, 928, 938, handling identifiers 919, 929, 939, etc.

[0058] Using the distributed ledger 900 of records 910-930, patient compliance data can be stored. For example, patients 914-934, dosages 918-938, and transaction engines 919-939 can be compared across records 910-930 to determine whether a patient is strictly following a "dosage" regimen. Compliance can be compared among patients, for example, to determine which patient is most strictly following the dosage regimen. Information on dosages 918-938, devices 915-935, patients 914-934, types 913-933, insurance 916-936, payments 917-937, and transaction engines 919-939 can be used to store physician prescription data and can be compared over time across the ledger 900, for example, to determine which physician is prescribing most effectively.

[0059] In certain examples, handling data 919-939 can be compared with dosage information 918-938 to determine and store the physiological effect of a given dosage on patients 914-934. In certain examples, handling data 919-939, dosage information 918-938, device data 915-935, etc. can be compared to determine the performance of the device, hardware, and / or the effectiveness of the treatment in providing dosage and storage, tracking, etc. In certain examples, the information in records 910-930 enables changes to the prescription based on the effectiveness determined by physiological feedback. Thus, dynamic dosage data can be stored in fields 918-938 of records 910-930.

[0060] Records 910 - 930 of the distributed ledger 900 can be used, for example, to process handling including patient treatment by administering an energy amount according to a prescription. Depending on where the treatment dosage information is transmitted and stored, additional handling / dosage verification can be provided, such as using image recognition (e.g., internal / external tissues of the patient) to verify the patient's dosage, location, etc. For example, tissue and / or physiological response information can be used to verify the amplitude and / or dosage of the energy applied to the patient by the device. Feedback from internal and / or external sensors that measure the applied energy can be processed, for example, for treatment verification. Other features such as changes in blood flow and / or other physiological responses can be tracked by records 910 - 930 and used, for example, as verification of administration. In a specific example, a consensus algorithm (e.g., individual image recognition, etc.) can be used with the measured values to verify the patient and dosage. The treatment hardware can also be linked to another device, such as a mobile phone, and use global position and / or other biometric data to link a person to the device and verify dosing, for example, via transaction engines 919 - 939 associated with records 910 - 930 within the ledger 900. The ledger 900 can be internal (e.g., for a treatment company to use to evaluate the use of its device / system, etc.) and / or external (e.g., a treatment company can provide dosing data to other healthcare players such as insurance companies to enable, for example, deriving value from dosing information. For example, values derived from dosing data can include different patient insurance premiums based on compliance with a prescribed treatment regimen, etc. The values can include, for example, different insurance payments for hospital systems that function better in the diagnosis of correct energy application and / or dosing regimen. These operations 919 - 939 can be added, for example, as records 910 - 930 and / or used to adjust existing records 910 - 930 of the blockchain or other distributed ledger 900.Participants in the decentralized ledger 900 can include, for example, patients, primary healthcare providers, treatment providers, hospitals and / or healthcare systems, diagnostic and / or treatment device providers, insurers, insurance claim administrators / auditors, government / guidance agencies, consumer enterprises that can affect a patient's health through the provision of related or unrelated products, and / or other parties within healthcare.

[0061] Figure 10 shows an exemplary handling flow 1000 of an exemplary prescription blockchain 1002 (for example, the steps of implementing the exemplary decentralized ledgers 800, 900 of FIGS. 8 and / or 9). As shown in the example of FIG. 10, at 1, the prescription system 320 forms block 0 of the blockchain 1002 and creates a record that defines a patient (such as patient structure 609). At 2, the prescription system 320 activates the prescription smart contract 1003. The invocation of the smart contract 1003 is stored as handling in block 1 of the blockchain 1002. At 3, the prescription system 320 adds the information of the prescription 613 as block 2 of the blockchain 1002. At 4, the prescription system 320 adds the information of the device 605 in block 3 of the blockchain 1002. The handling of the device 605 can also include, for example, filling the prescription at a pharmacy / prescription system 410. At 5, the insurance company's system 330 adds insurance information such as insurance coverage and the patient's copay in block 4 of the blockchain 1002. At 6, the device 370 (using, for example, the control system 360, etc.), 605 gives the prescription to the patient, which is recorded as the handling in block 5 of the blockchain 1002. At 7, the prescription can be refilled and / or updated by the pharmacy's system 410, which stores it as handling in block 6 of the blockchain 1002. The blockchain 1002 can continue to be updated with additional handling, for example, in block N.

[0062] FIG. 11 shows an exemplary smart contract 1100 for a prescription for delivering an energy therapy to a patient that can be tracked, for example, via distributed ledgers 800, 900. The exemplary smart contract 1100 can be stored, for example, as records 810-830, 910-930 in ledgers 800, 900. As shown in the example of FIG. 11, the contract 1100 includes a value 1110 (e.g., amount of material, cost, timing, etc.) and a status 1120 (e.g., available, complete, executed, executing, delivered, remaining material, etc.). In a particular example, the contract 1100 can apply to multiple patients who are all subject to the same contract terms. Further, in a particular example, the current state of the contract can be derived from the value 1110 without explicitly storing the status 1120. The contract 1100 can also include one or more functions 1130 executable with respect to the contract 1100. Thus, the contract 100 can specify its terms 1110 and the status 1120 of the execution of those terms, for example, using one or more of the functions 1130. For example, as shown in the exemplary prescription contract 1003 of FIG. 10, the functions 1130 can include request, generate, fund, deliver, receive, replenish, update, etc. The contract record 1100 can receive transaction information 1140 and event information 1150, and can also provide transaction information 1160 and event information 1170 to ledgers 800, 900 and / or other records 810-830, 910-930 in the system, etc.

[0063] For example, transaction 1140 can provide value 1110 to contract 1100, such as by the amount of energy to be associated with a prescription and / or other terms / conditions to contract 1100. Event 1150 can affect the state 1120 of contract 1100, such as the time to manage a prescription, identification of related devices, etc. When a prescription is funded, paid, managed, replenished, etc., handling information 1160 and event information 1170 can propagate, for example, as separate records 810-830, 910-930 in the handling of ledgers 800, 900. Thus, smart contract 1100 can be used to track handling including electronic prescriptions for energy delivery, pharmaceuticals, treatments, etc.

[0064] Smart contract 1100 can be implemented as computer program code that enables / facilitates the execution of contracts / agreements (e.g., those made between a hospital or clinician, pharmacy, and / or insurance company, etc.) using ledgers 800, 900. The terms and / or updates of contract 1100 can be implemented as processor-executable instructions executed by a processor such as a prescription computer system 320, insurance company / primary care server 330, supervisor's system 340, energy control system 360, mobile computing device 420, and / or another processor to perform and / or track the execution of contract 1100. The terms of contract 1100 can be encoded as logical statements that manage the conditions and consequences of contract 1100 and related materials. Contract 1100 can be fully automated to execute itself with respect to distributed ledgers 800, 900, for example, to execute contract 1100, and / or can be made executable by a processor / device (e.g., prescription computer system 320, insurance carrier / primary care server 330, supervisor's system 340, energy control system 360, mobile computing device 420, and / or another processor, etc.). Thus, contract 1100 can be fully formulated in executable code, for example, and / or can include additional elements interpreted by a processor. Contract 1100 can be executed within ledgers 800, 900 (e.g., the code forming contract 1100 is encoded in blocks of a blockchain and / or other distributed ledgers 800, 900), for example, and / or can be executed outside of ledgers 800, 900, returning information (e.g., new and / or updated records 310 - 330, etc.) to ledger 300. In certain examples, anyone can add contract 500 and / or change records 310 - 330 of ledger 300. In other examples, access to ledger 300 and related records 310 - 330, contract 500, etc. is restricted based on processor authorization (e.g., authorized nodes), user authorization, etc.

[0065] FIG. 12 shows an exemplary prescription management processor 1200 for managing distributed ledgers (e.g., distributed ledgers 800, 900, 1002) and facilitating processing, tracking, and updating of prescription information, patient treatment progress, orders, updates, etc. via the distributed ledgers. The exemplary processor 1200 includes a ledger recording processor 1210, a contract generator 1220, a status monitor 1230, a data communication interface 1240, and a data storage 1250.

[0066] The exemplary ledger recording processor 1210 processes the handling including records 810-830, 910-930 in the distributed ledgers 800, 900, 1002. The exemplary processor 1210 can update the ledgers 800, 900, 1002 in the data storage 1250 based on, for example, patients, devices, new prescriptions, prescription activities, etc. The exemplary contract generator 1220 can generate smart contracts (such as smart contract 1100, etc.) for prescription fulfillment, payment, management, etc. The exemplary generator 1220 can, for example, interact with the ledger recording processor 1210 to add the handling including the smart contract 1100 and / or smart contracts to the distributed ledgers 800, 900, 1002. The exemplary status monitor 1230 monitors the management of prescriptions for patients and / or other prescription statuses (such as remaining quantity, insurance approval, copay status, financing status / amount, refill times, frequency, etc.), and can cooperate with the ledger recording processor 1210 to update the ledgers 800, 900, 1002, for example, based on changes in the prescription status. Information can be transmitted from the management processing unit 1200 to the management processing unit 1200 via the data communication interface 1240 (for example, a wired data communication interface and / or a wireless data communication interface such as a cellular communication interface, a Wi-Fi communication interface, a Bluetooth (registered trademark) communication interface, a short-range communication interface, etc.). Data including copies of the distributed ledgers 800, 900, 1002 can be stored in the data storage 1250 together with, for example, instructions, parameters, etc. for execution by the components of the processor 1200.

[0067] Accordingly, using the exemplary prescription management processor 1200, it can be separately implemented and / or included in one or more of the blockchain network 310, prescription computer system 320, insurer / primary care system 330, treatment / diagnosis monitoring system 340, energy control system 360, pharmacy system 410, mobile computing device 420, etc., to generate, manage, update, maintain, etc., the prescription blockchain and / or other distributed ledgers 800, 900, 1002, and related handling to help ensure accuracy, security, processability, and compliance with clinical protocols.

[0068] FIG. 13 shows an exemplary network 1300 (e.g., blockchain network 310, etc.) in which a prescription management processor 1200 communicates with a prescriber system 320, an insurer's system 330, a supervisor's system 340, and a pharmacy system 410 to exchange updates to a distributed ledger 900. In the example of FIG. 13, each system includes a copy of the ledger 900, and updates to records 910 - 930 within the ledger 900 are propagated to each copy of the distributed ledger 900. Next, handling and / or other updates can be verified against multiple copies of the ledger 900 (e.g., automatically for each update, periodically after a certain period and / or number of updates, manually upon user / system request, etc.). If an update is isolated to only one copy of the ledger 900, the update can be excluded and / or further investigated, for example, as potentially fraudulent / erroneous. Thus, in the example of FIG. 13, the peer systems can provide feedback regarding record content, record updates, and handling including records. In a particular example, the prescription management processor 1200 can be incorporated into one or more of the systems 320, 330, 340, 410 instead of or in addition to a separate processor.

[0069] Exemplary implementations are shown in relation to FIGS. 1 - 13. However, the elements, processes, and / or devices shown in relation to FIGS. 1 - 13 may be combined, divided, rearranged, omitted, excluded, and / or implemented in any other way. Further, the components disclosed and described herein can be implemented by hardware, machine-readable instructions, software, firmware, and / or any combination of hardware, machine-readable instructions, software, and / or firmware. Thus, for example, the components disclosed and described herein can be implemented by analog and / or digital circuits, logic circuits, programmable processors, application specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field programmable logic devices (FPLDs). To cover purely software and / or firmware implementations, when reading any of the apparatus or system claims of this patent, at least one of the components is explicitly defined herein to include a tangible computer-readable storage device or memory disk such as a memory storing software and / or firmware, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc.

[0070] Flowcharts and / or data flows representing exemplary machine-readable instructions for implementing the components disclosed and described herein are shown in conjunction with at least FIGS. 1-13 and are shown in the examples of FIGS. 6, 10, and 14-15. In the examples, the machine-readable instructions include a program for execution by a processor such as processor 1612 shown in exemplary processor platform 1600 described below in connection with FIG. 16. The program can be implemented with machine-readable instructions stored on a tangible computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, digital versatile disk (DVD), Blu-ray disk, or memory associated with processor 1612, or alternatively, the entire program and / or portions thereof can be executed by a device other than processor 1612 and / or implemented with firmware or dedicated hardware. Further, the exemplary program is described with reference to the flowcharts shown in connection with at least FIGS. 6, 10, and 14-15, but many other ways of implementing the components disclosed and described herein may alternatively be used. For example, the order of execution of the blocks can be changed and / or some of the blocks described can be changed, deleted, or combined. The flowcharts and / or data flows of at least FIGS. 6, 10, and 14-15 show the exemplary operations in the order illustrated, but these operations are not exhaustive and are not limited to the order illustrated. Further, various changes and modifications can be made by those skilled in the art within the spirit and scope of the present disclosure. For example, the blocks shown in the flowchart can be executed in other orders or in parallel.

[0071] As described above, at least the exemplary processes of FIGS. 6, 10, and 14-15 can be implemented using encoded instructions (e.g., computer and / or machine-readable instructions) stored on a tangible computer-readable storage medium such as a hard disk drive, flash memory, read-only memory (ROM), compact disk (CD), digital versatile disk (DVD), cache, random access memory (RAM), and / or any other storage device or storage disk where information is stored for any period of time (e.g., for long-term, permanently, short-term, temporarily buffering, and / or caching information). As used herein, the term tangible computer-readable storage medium is clearly defined to include any type of computer-readable storage device and / or storage disk, excluding propagating signals and excluding transmission media. As used herein, the terms "tangible computer-readable storage medium" and "tangible machine-readable storage medium" are used interchangeably. Additionally or alternatively, at least the exemplary processes of FIGS. 6, 10, and 14-15 can be implemented using encoded instructions stored in encoded instructions (e.g., computer and / or machine-readable instructions) stored on a non-transitory computer and / or machine-readable medium such as a hard disk drive, flash memory, read-only memory, compact disk, digital versatile disk, cache, random access memory, and / or any other storage device or storage disk where information is stored for any period of time (e.g., for long-term, permanently, short-term, temporarily buffering, and / or caching information). As used herein, the term non-transitory computer-readable medium is clearly defined to include any type of computer-readable storage device and / or storage disk, excluding propagating signals and excluding transmission media. As used herein, when the phrase "at least" is used as a transitional term in the preamble of a claim, the term "comprising" is open-ended in the same manner as an open-ended term.Furthermore, the term "including" is open-ended in the same way as the term "comprising".

[0072] FIG. 14 shows a flowchart of an exemplary method 1400 for managing an electronic prescription that defines actions for a patient. The electronic prescription can be a logical data structure such as one or more records, such as a blockchain and / or other distributed ledger, for configuring a device to apply an action (e.g., energy therapy, ultrasound imaging, medication administration, other stimuli, etc.) to a patient according to the prescription. In block 1402, a prescription is configured for the patient. For example, a device (e.g., an energy application device 370 and / or other devices represented by device structure 605, etc.) is configured within a device prescription to apply an action (e.g., application of energy, ultrasound imaging, administration of pharmaceuticals, etc.) to the patient. Further, for example, payment information related to the action, including insurance coverage, patient copay, etc., can be determined as part of the prescription. Parameters and / or settings of the action and / or related device, such as quantity, frequency, strength / intensity / dosage, verification, etc., can be set according to clinical guidelines, treatment and / or diagnostic protocols, clinician input, etc.

[0073] In block 1404, the configured prescription is recorded in distributed ledgers 800, 900, 1002. For example, the configured prescription is added as records 910 - 930 within distributed ledger 900, added as an update to existing records 910 - 930 within distributed ledger 900, etc. Thus, the logical data structure of the configured prescription structure functions as a node within a distributed ledger network across multiple devices / systems that maintain and distribute it, for example, via a copy of distributed ledgers 800, 900, 1002 stored at participating nodes.

[0074] In block 1406, the administration of prescriptions is tracked / monitored. For example, the prescription management processor 1200 is executed on a separate processor and / or implemented in cooperation with the prescriber system 320, the insurer system 330, the supervisor's system 340, the pharmacy system 410, the mobile device 420, etc., and can monitor the administration of prescriptions to the patient 380, such as the delivery of energy therapy to the patient 380 via the energy device 370, the administration of pharmaceuticals to the patient (e.g., via a needle, catheter, other delivery device, etc.), the administration of radioactive pharmaceutical materials to the patient, etc. Tracking the administration of prescriptions can also include tracking the dispensing of payments to the pharmacy system 410 and / or other providers when the prescription material is being administered to the patient. Thus, the patient can make payments dynamically according to the dosage, make payments at the start of administration, make payments at the end of administration, etc., and the provider can receive payments without delay or delay time for further insurance approval, billing, etc.

[0075] In block 1408, there are distributed ledgers 800, 900, 10002 with updated and / or new records 810 - 830, 910 - 930 to reflect prescription management, other changes in prescription status, etc. For example, the prescription management processor 1200 can update the ledgers 800, 900, 1002 and propagate the changes to the copies of the distributed ledgers 800, 900, 1002 maintained by multiple devices / systems 320 - 420. In a specific example, updating the ledgers 800, 900, 1002 includes verifying the update by comparing multiple copies of the distributed ledgers 800, 900, 1002 distributed among multiple systems 320 - 420, and executing hash and / or other proof-of-work algorithms to verify that the devices / systems 320 - 420 are permitted to add to the distributed ledgers 800, 900, 1002, etc.

[0076] In block 1410, the status or state of the prescription is evaluated to determine whether the prescription has been exhausted, whether it has not been exhausted yet, and / or whether it should be refilled. If the prescription has been exhausted and / or completed, in block 1412, the ledgers 800, 900, 1002 are updated to reflect the completion of the prescription, and the program ends / returns. However, if material remains on the prescription, or if the prescription is empty but a refill has been ordered / triggered / added, etc., control transfers to block 1414. In block 1414, the continuation of the prescription is evaluated to determine whether the prescription should be refilled or whether administration should continue with the current prescription. If the administration of the current prescription material is to continue (e.g., more material / instructions remain, no replenishment is guaranteed, etc.), control returns to block 1406 to continue monitoring the prescription administration. If a prescription refill is guaranteed (e.g., more material, new instructions for action, etc.), control returns to block 1402 to adjust / configure / manage the prescription for refill. For example, new approvals, payments, settings, etc. can be involved in updating one or more records 810 - 830, 910 - 930b of the distributed ledgers 800, 900, 1002 such as prescription replenishment and verification.

[0077] Accordingly, the prescription can be a device prescription for configuring a device for applying an action to a patient, a pharmaceutical prescription for a specific drug / material to be administered to the patient, a monitoring prescription for configuring a device for monitoring the patient (e.g., using sensors, imaging, electrocardiogram, etc.), and / or an examination prescription for configuring a device for examining the patient (e.g., using sensors, imaging, electrocardiogram, computer-aided detection, etc.).

[0078] FIG. 15 shows an exemplary implementation 1500 of an exemplary process 1400 for prescription management. An electronic prescription can be a logical data structure such as one or more records, such as a blockchain and / or other distributed ledger, for configuring a device to apply an action (e.g., energy therapy, ultrasound imaging, medication administration, other stimulations, etc.) to a patient according to the prescription. In block 1502, the electronic prescription is configured to be executed on a patient by configuring a device (e.g., a device prescription that configures other devices represented by the energy application device 370 and / or the device structure 605) to apply an action (e.g., application of energy, ultrasound imaging, administration of pharmaceuticals, etc.) to the patient. Actions and / or parameters and / or settings of related devices, such as quantity, frequency, strength / intensity / dosage, verification, etc., can be set according to clinical guidelines, treatment and / or diagnostic protocols, clinician input, etc. In block 1504, the distributed ledgers 800, 900, 1002 are updated with device configuration information. For example, new records 810-830, 910-930 can be added and / or existing records 810-830, 910-930 can be updated in the handling that provides device configuration information for the prescription. In block 1506, payment information associated with the action, including insurance coverage, patient copay, etc., is determined, for example, as part of the prescription. In block 1508, the payment information is recorded as an associated handling with new and / or updated records 810-830, 910-930 in the distributed ledgers 800, 900, 1002.

[0079] In block 1510, the actions applied to the patient through the prescription are verified using the distributed ledgers 800, 900, 1002. For example, one or more systems 320-420, 1200 that store and / or access copies of the distributed ledgers 800, 900, 1002 can compare the information in records 810-830, 910-930 to verify the content of the prescription and its related actions. The comparison of values can help ensure accuracy / consistency, and / or the proof of hashing and / or other work functions can verify that systems 320-420, 1200 are authorized to add / adjust records 810-830, 910-930 in the distributed ledgers 800, 900, 1002. Thus, the logical data structure of the configured prescription structure is maintained and distributed across multiple devices / systems that function as nodes within the distributed ledger network, for example, via copies of the distributed ledgers 800, 900, 1002 stored at participating nodes.

[0080] In block 1512, when the action is verified, the payment for the action is processed using the payment information within the prescription. For example, when an electronic prescription is processed by a device to apply an action to the patient, payments including insurance payment information, the patient's copay, etc. can be applied. In block 1514, the distributed ledgers 800, 900, 1002 are updated to reflect the payment and / or the action. For example, one or more systems / devices 320-420, 1200 can propagate at least one record 810-830, 910-939 of i) the payment or ii) the action to the distributed ledgers 800, 900, 1002.

[0081] In block 1516, the prescription administration is tracked / monitored. For example, the prescription management processor 1200 is executed on a separate processor and / or implemented in cooperation with the prescriber system 320, the insurer system 330, the supervisor's system 340, the pharmacy system 410, the mobile device 420, etc., and can monitor the administration of prescriptions to the patient 380, such as the delivery of energy therapy to the patient 380 via the energy device 370, the administration of pharmaceuticals to the patient (e.g., via needles, catheters, other delivery devices, etc.), the administration of radiopharmaceutical materials to the patient. Tracking the prescription administration can also include tracking the dispensing of payments to the pharmacy system 410 and / or other providers when the prescription material is being administered to the patient. Thus, the patient can make payments dynamically based on the dosage, at the start of administration, at the end of administration, etc., and the provider can receive payments without delay or latency for further insurance approvals, claims, etc.

[0082] In block 1518, there are distributed ledgers 800, 900, 10002 with updated and / or new records 810 - 830, 910 - 930 to reflect prescription management, other changes in the prescription status, etc. For example, the prescription management processor 1200 can update the ledgers 800, 900, 1002 and propagate the changes to the copies of the distributed ledgers 800, 900, 1002 maintained by the multiple devices / systems 320 - 420. In a specific example, updating the ledgers 800, 900, 1002 includes verifying the update by comparing multiple copies of the distributed ledgers 800, 900, 1002 distributed among the multiple systems 320 - 420, and executing hash and / or other proof-of-work algorithms to verify that the devices / systems 320 - 420 are permitted to add to the distributed ledgers 800, 900, 1002.

[0083] In block 1520, the status or state of the prescription is evaluated to determine whether the prescription has been exhausted, has not yet been exhausted, and / or should be refilled. If the prescription has been exhausted and / or completed, in block 1522, the ledgers 800, 900, 1002 are updated to reflect the completion of the prescription, and the program ends / returns. However, if material remains on the prescription, or if the prescription is empty but a refill has been ordered / triggered / added, etc., control transfers to block 1524. In block 1524, the continuation of the prescription is evaluated to determine whether the prescription should be refilled or whether administration should continue with the current prescription. If administration of the current prescription material continues (e.g., more material / instructions remain, replenishment is not guaranteed, etc.), control returns to block 1526 to continue monitoring prescription administration. If prescription refill is guaranteed (e.g., more material, new instructions for action, etc.), control returns to block 1502 to adjust / configure / manage the prescription for refill. For example, new authorizations, payments, settings, etc. can be involved in updating one or more records 810 - 830, 910 - 930b of the distributed ledgers 800, 900, 1002 such as prescription replenishment and verification.

[0084] While specific exemplary records, systems, and related methods have been disclosed above, other record formats and related systems and methods can be used for prescription and related device management. For example, FIG. 16 shows an exemplary table 1600 representing stored electronic prescription information for processing by exemplary systems 300, 400, etc. Table 1600 can include entries that identify electronic prescriptions and associated handling related to the prescriptions. The exemplary table 1600 can define a plurality of fields including product identifier 1602, transaction identifier 1604, prescription information 1606, status 1608, blockchain result 1610, and data 1612. The exemplary table 1600 can be used to track digital prescription information for one or more patients, users, devices, etc. The exemplary product identifier 1602 can be used, for example, using a unique alphanumeric code, to identify the patient, user, device, and / or other record in question, and the handling identifier 1604 can be used, for example, to record handling, events, and / or other stages of prescription generation, approval, delivery, and refill. The prescription information 1606 can be used to identify some or all of the information related to the prescription (e.g., device, dosage, other settings, etc.). The status 1608 can be used to indicate whether the prescription has been approved, rejected, is pending approval, has been delivered / administered, is expired / empty, has been refilled, etc., and the blockchain result 1610 can be used to indicate whether some or all of the digital prescription information has been verified via a distributed ledger (e.g., by comparing values between copies of the distributed ledger, performing a proof of work related to the distributed ledger, etc.). The data 1612 can include, for example, bits of information for defining the related prescription information 1606. Thus, prescriptions and related states, events, etc. can be tracked, for example, via the table or container 1600.

[0085] In some examples, information related to digital prescriptions is recorded via a secure distributed ledger (e.g., related to blockchain technology). For example, FIG. 17 is a system 1700 incorporating a secure distributed ledger. The system includes a digital transaction engine 1710 having a communication port for exchanging information between a client 1720 and a blockchain 1730. For example, the digital transaction engine 1710 and / or other elements of the system 1700 can use the blockchain 1730 and / or other secure distributed ledgers 1730 (e.g., via a blockchain verification process) to record handling related to the client and / or information related to the associated digital prescription. For example, the digital transaction engine 1710 can record order date and time, price, entry date, approval, replenishment, distribution / delivery, compressed product definition file, etc. via the secure distributed ledger 1730 according to any of the examples described herein. According to some examples, the distributed ledger 1730 can be associated with a HYLEDGER (registered trademark) blockchain verification system. Note that the digital transaction engine 1710 can be decentralized and / or associated with a third party such as a vendor that performs services for enterprises, for example. The handling can be encoded into one or more segments, and according to some examples, information related to the handling can be recorded using blockchain technology.

[0086] In a specific example as shown in the system 1700 of FIG. 17, the cloud-based integrity monitor 1740 provides handling integrity data via a web browser and can exchange information with the blockchain 1730 and the digital transaction engine 1710 via a Representational State Transfer (REST) web service. The REST web service can provide interoperability, for example, between computer systems on the Internet (e.g., by enabling the requesting system to access and operate on the textual representation of a web resource using a uniform pre-defined set of stateless operations). In some examples, a part of the digital transaction engine 1710 can be associated with a MySQL database. In this way, the digital transaction engine 1710 and the blockchain 1730 can be used to provide handling-level verification for the client 1720. FIG. 17 shows an exemplary system 1700 having a single blockchain 1730, a client 1720, and a digital transaction engine 1710, but it should be noted that other examples can use other topologies. For example, FIG. 18 shows a system 1800 that implements digital prescription management incorporating multiple digital transaction engines 1810-1815. In particular, the additional blockchain 1835 and the digital transaction engine 1815 can provide protection for the additional client 1825. As shown in the example of FIG. 18, each digital transaction engine 1810, 1815 can be associated with multiple blockchains 1830, 1835 that provide additional protection to the system 1800 (e.g., by storing information in multiple geographically dispersed nodes that make an attack unrealistic). That is, each verifier (e.g., the digital transaction engines 1810-1815) can commit a simple summary to an independent data store and, once recorded, cannot change the information without detection to provide a record tampering prevention system (SoR).

[0087] It should be noted that various types and / or amounts of information can be recorded in a secure distributed ledger. For example, data can be stored per prescription, per event, base prescription, and changes to all related and dependent prescriptions. Further, information regarding specific medical devices, other devices, dosages, materials, customers, patients, platforms, payments, quality review processes or results, etc. can be stored via a secure distributed ledger (e.g., using blockchain technology, etc.).

[0088] The examples disclosed herein can be associated with any type of distributed ledger having, for example, smart contracts, digital assets, record repositories, and / or a distributed consensus-based network that supports cryptographic security. For example, FIG. 19 is a distributed ledger reference architecture 1900. An exemplary architecture 1900 can include a ledger service and an event stream 1910 that can include network security service information (e.g., from a first entity device). A membership service 1920 (e.g., including processes such as registration, identity management, and / or auditability) can manage the identity, privacy, and confidentiality of the membership 1950 of the network security service.

[0089] A blockchain service 1930 (e.g., including a consensus manager, a peer-to-peer (“P2P”) protocol, a distributed ledger, and / or ledger storage) can manage a distributed ledger via the P2P protocol to maintain a single state replicated at many nodes to support a blockchain 1960 and a transaction engine 1970. A chain code service 1940 (e.g., a secure container and / or secure registry associated with a smart contract) can be used to compartmentalize the execution of a smart contract (or chain code 1980) at a verification node. Note that the environment can be a “locked down” secure container having a set of signed base images including a secure operating system and programming language. In a particular example, an application programming interface (API), a software development kit (SDK), and / or a command line interface (CLI) can be utilized to support network security services via a reference architecture 1900.

[0090] FIG. 20 is a block diagram of an exemplary processor platform 2000 configured to execute at least the instructions of FIGS. 6, 10, and 14 - 15 to implement the exemplary components disclosed and described herein with respect to FIGS. 1 - 19. The processor platform 2000 can be, for example, a server, a personal computer, a mobile device (e.g., a tablet such as a cellular phone, a smartphone, an iPad®), a personal digital assistant (PDA), an Internet appliance, or any other type of computing device.

[0091] The illustrated example of the processor platform 2000 includes a processor 2012. The illustrated example of the processor 2012 is hardware. For example, the processor 2012 can be implemented by an integrated circuit, a logic circuit, a microprocessor, or a controller from any desired family or manufacturer.

[0092] The illustrated example of processor 2012 includes local memory 2013 (e.g., a cache). The illustrated example of processor 2012 executes at least the instructions of FIGS. 6, 10, and 14 - 15 to implement the systems and infrastructure of FIGS. 1 - 19 and related methods, such as the exemplary prescriber system 320, the exemplary insurer's system 330, the exemplary supervisor's system 340, the exemplary pharmacy system 410, the exemplary mobile computing device 420, the exemplary distributed ledgers 800, 900, 1002, the exemplary smart contract 1100, the exemplary prescription management processor 1200, and the exemplary systems / architectures 1700 - 1900. The illustrated example of processor 2012 communicates with main memory including volatile memory 2014 and non - volatile memory 2016 via bus 2018. Volatile memory 2014 can be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device. Non - volatile memory 2016 may be implemented by flash memory and / or any other desired type of memory device. Access to main memory 2014, 2016 is controlled by a clock controller.

[0093] The illustrated example of processor platform 2000 also includes interface circuit 2020. Interface circuit 2020 can be implemented by any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB), and / or a PCI Express interface.

[0094] In the illustrated example, one or more input devices 2022 are connected to the interface circuit 2020. The input device 2022 enables a user to input data and commands to the processor 2012. The input device can be implemented, for example, by a sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touch screen, a track pad, a track ball, an isopoint, and / or a voice recognition system.

[0095] In the illustrated example of the interface circuit 2020, one or more output devices 2024 are also connected. The output device 2024 can be implemented, for example, by a display device (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touch screen, a tactile output device, and / or a speaker). Thus, the interface circuit 2020 in the illustrated example typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

[0096] The interface circuit 2020 in the illustrated example also includes communication devices such as a transmitter, a receiver, a transceiver, a modem, and / or a network interface card to facilitate data exchange with external devices (e.g., any type of computing device) via a network 2026 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, a coaxial cable, a cellular phone system, etc.).

[0097] The processor platform 2000 in the illustrated example also includes one or more mass storage devices 2028 for storing software and / or data. Examples of such mass storage devices 2028 include a floppy disk drive, a hard disk drive, a compact disk drive, a Blu-ray disk drive, a RAID system, and a digital versatile disk (DVD) drive.

[0098] The encoded instruction 2032 of FIG. 20 can be stored in a mass storage device 2028, volatile memory 2014, non-volatile memory 2016, and / or a removable tangible computer-readable storage medium such as a CD or DVD.

[0099] In certain examples, the processor platform 2000 can be implemented in an ultrasonic imaging system and / or a neuromodulation device. FIG. 21 shows an exemplary ultrasonic neuromodulation system 10 for delivering focused ultrasound to a patient according to a digital prescription. For that purpose, the disclosed distributed ledger system and method can be used with the neuromodulation system 10.

[0100] FIG. 21 is a schematic diagram of a system 10 for neuromodulation to achieve the release of neurotransmitters according to a digital prescription maintained using a distributed ledger. The exemplary system 10 includes a pulse generator 14 coupled to an energy application device 12 (e.g., an ultrasonic transducer). The energy application device 12 is configured to receive energy pulses that are directed, during use, via a lead or wireless connection, etc., towards a region of interest of the internal tissue or organ of the subject, resulting in sequentially targeted physiological outcomes. In certain examples, the pulse generator 14 and / or the energy application device 12 can be implanted and / or otherwise disposed at a biocompatible site (e.g., the abdomen), and one or more leads internally couple the energy application device 12 and the pulse generator 14. For example, the energy application device 12 can be a MEMS transducer such as a capacitive microfabricated ultrasonic transducer.

[0101] In certain examples, the energy application device 12 and / or the pulse generator 14 can communicate wirelessly, for example, with a controller 16 that sequentially commands the pulse generator 14. In other examples, the pulse generator 14 can be an external device (e.g., it can operate to apply energy transcutaneously or non-invasively from a location external to the subject) and, in certain examples, can be integrated within the controller 16. In an example where the pulse generator 14 is external, the energy application device 12 can be operated by a caregiver and can be placed at a spot on or above the subject's skin, for example, so that an energy pulse is delivered transcutaneously to the desired internal tissue. When arranged to apply an energy pulse to a desired site, the system 10 can initiate neuromodulation (e.g., according to a dosage, duration, or interval specified, for example, by a digital prescription) to achieve a targeted physiological outcome or clinical effect.

[0102] In certain examples, the system 10 can include an evaluation device 20 coupled to the controller 16 that evaluates a characteristic indicating whether modulation of a targeted physiological outcome has been achieved. In an example, the targeted physiological outcome can be local. For example, the modulation can result in local tissue or functional changes such as a change in tissue structure, a local increase in the concentration of a particular molecule, tissue displacement, an increase in fluid movement. The modulation can result in systemic or non-local changes and the targeted physiological outcome can be related to, for example, a change in the concentration of circulating molecules or a change in the properties of tissue not including the region of interest where the energy is directly applied. In an example, displacement is a surrogate measure of successful modulation and a measurement of displacement that is less than the expected value of displacement can result in a modification of the modulation parameters until the expected value of displacement is observed.

[0103] The system 10 provided herein can supply energy pulses according to various modulation parameters. For example, the modulation parameters can include various patterns of stimulation times ranging from continuous to intermittent. In intermittent stimulation, energy is supplied at a specific frequency for a certain period of time when the signal is on. After the time when the signal is on, there follows a period during which no energy is supplied, referred to as the time when the signal is off. The modulation parameters can also include the frequency and duration of the application of the stimulation. The frequency of application can be continuous or can be delivered over various periods, such as within one day or within one week. The treatment period can continue over various periods including but not limited to from a few minutes to a few hours. In a particular example, the treatment period according to a specified stimulation pattern can continue at specific intervals (such as one hour, etc.) and can be repeated at specific intervals (such as 72 - hour intervals, etc.). In a particular example, treatment can be delivered at a higher frequency (such as every three hours, etc.) with a shorter duration (such as 30 minutes, 45 minutes, etc.). The treatment period and frequency can be controllably adjusted to achieve the desired result.

[0104] FIG. 22 is a block diagram of certain components of the system 10. As provided herein, the system 10 for neuromodulation includes a pulse generator 14 adapted to generate a plurality of energy pulses for application to a subject's tissue. The pulse generator 14 can be separate and / or can be integrated into an external device such as a controller 16. The controller 16 includes a processor 30 for controlling the device. Software code or instructions are stored in the memory 32 of the controller 16 for execution by the processor 30 to control the various components of the device. Copies of the blockchain and / or other distributed ledgers 800, 900, 1730, 1830, 1835 can be stored, for example, in the memory 32 and can also be updated by the controller 16. The controller 16 and / or the pulse generator 14 can be connected, for example, via one or more leads 33 or to the energy application device 12.

[0105] The controller 16 also includes a user interface with an input / output circuit 34 and a display 36 adapted to enable a clinician to present selection inputs or modulation parameters to the modulation program. Each modulation program can include one or more sets of modulation parameters including pulse amplitude, pulse width, pulse frequency, and the like. The pulse generator 14 changes its internal parameters in response to control signals from the controller device 16 to vary the stimulation characteristics of the energy pulses transmitted to the subject via the lead wire 33. Any suitable type of pulse generation circuit can be used, including constant current, constant voltage, multiple independent current or voltage sources, and the like. The energy applied is, for example, a function of the current amplitude and the pulse width duration.

[0106] In an example, the memory 32 stores different operating modes selectable by an operator. For example, the stored operating modes can include instructions for executing a series of modulation parameters related to a particular treatment site. If the site is different, the related modulation parameters can also be different. Instead of having the operator manually enter the mode, the controller 16 can be configured to execute appropriate instructions based on selections from the blockchain and / or prescription information, and the like. In another example, the memory 32 stores operating modes for different types of treatments (e.g., according to one or more records / entries in the blockchain, etc.). For example, activation can be related to different stimulation pressures or frequency ranges compared to those related to the suppression or blocking of tissue function. In a particular example, when the energy application device is an ultrasonic transducer, the time-averaged power and the peak positive pressure are in the ranges of 1 mW / cm2 to 30,000 mW / cm2 and 0.1 MPa to 7 MPa. In another particular example, when the energy application device is a mechanical actuator, the amplitude of vibration is in the range of 0.1 to 10 mm. The frequency selected can depend on the mode of energy application, e.g., ultrasonic or mechanical actuator.

[0107] In another example, the memory 32 stores a calibration or setup mode that enables adjustment or modification of the modulation parameters to achieve a desired result. In one example, the stimulation begins with lower energy parameters and increases gradually, either automatically or upon receipt of an operator input. Thus, the operator can observe the effect when the modulation parameters are being changed.

[0108] System 10 may also include an imaging device that facilitates focusing of the energy application device 12. In an example, the imaging device can be integrated with the energy application device 12 or implemented as the same device such that different ultrasonic parameters (e.g., frequency, aperture, or energy) are targeted and then applied to neuromodulation. In another example, the memory 32 stores a targeting or focusing mode that is used to spatially select a region of interest within an organ or tissue structure. For example, the energy application device 12 can be configured to first operate in a targeting mode and apply energy used to capture image data used to identify the region of interest. The energy in the targeting mode is not at a level suitable for preferential activation and / or is not applied with modulation parameters. However, once the region of interest is identified, the controller 16 can operate in a treatment mode according to the modulation parameters associated with preferential activation.

[0109] The controller 16 can also be configured to receive inputs related to a targeted physiological outcome as inputs to the selection of modulation parameters. For example, if an imaging modality is used to evaluate tissue characteristics, the controller 16 can be configured to receive the calculated index or parameter of the characteristics. Based on whether the index or parameter is above or below a threshold, the modulation parameter can be modified. In the example, the parameter can be a measurement of tissue displacement of the affected tissue or a measurement of the depth of the affected tissue. Further, the energy application device 12 (e.g., an ultrasonic transducer) can operate under the control of the controller 16 to a) acquire image data to spatially select a region of interest within the target tissue, b) apply energy modulation to the region of interest, and c) acquire an image to determine that a targeted physiological outcome has occurred (e.g., via displacement measurement). In such an example, the imaging device, the evaluation device 20, and the energy application device 12 can be the same device.

[0110] In another example, a successful set of modulation parameters can also be stored by the controller 16 (e.g., as an entry or record in a blockchain and / or other distributed ledger). Thus, parameters specific to the subject can be determined. Further, the effectiveness of such parameters can be evaluated over time. If a particular set of parameters is not effective over time, the subject may be developing insensitivity to the activated pathway. If the system 10 includes the evaluation device 20, the evaluation device 20 can provide feedback to the controller 16. In a particular example, the feedback can be received from a user or the evaluation device 20 indicating characteristics of the targeted physiological outcome. The controller 16 can be configured to cause the energy application device 12 to apply energy according to the modulation parameters and to dynamically change the modulation parameters based on the feedback. For example, based on the feedback, the processor 16 can automatically change the modulation parameters (e.g., the frequency, amplitude, or pulse width of an ultrasonic beam or mechanical vibration).

[0111] From the above, it will be understood that the methods, apparatuses, and products disclosed above are disclosed and described for implementing a distributed ledger for managing electronic prescriptions including device prescriptions, pharmaceutical prescriptions, monitoring prescriptions, inspection prescriptions, and the like. The disclosed methods, apparatuses, and products improve the operation of medical information systems, insurance systems, pharmaceutical systems, and / or other computing devices by enabling the quantification, tracking, payment, and manipulation of an electronic prescription structure that includes patient, device, and operation information. Accordingly, the disclosed methods, apparatuses, and products are directed to one or more improvements in the functionality of a computer and / or computing device including a management processor and the like. Such improvements are not achievable by manual human performance and are certainly not mental steps performed within the human mind.

[0112] Specific examples provide for the storage of patient compliance data (e.g., which patients are most closely following a "dosage" regimen, etc.) via one or more logical data structures within the distributed ledger. Specific examples provide for the storage of physician prescription data (e.g., which physicians are prescribing most effectively, etc.) via one or more logical data structures within the distributed ledger. Specific examples provide for the storage of efficacy data (e.g., what was the physiological effect of each given dosage, etc.) via one or more logical data structures within the distributed ledger. Specific examples provide for the storage of hardware / therapy efficacy (e.g., how well the machine functioned in delivering a dosage, etc.) via one or more logical data structures within the distributed ledger. Specific examples provide for the storage of dynamic dosing data (e.g., enabling changes to prescriptions based on efficacy, physiological feedback, etc.) via one or more logical data structures within the distributed ledger.

[0113] Specific examples facilitate the handling process via a distributed ledger. For example, depending on where the treatment dosage information is sent and stored, specific examples use a distributed ledger to provide handling / dosage verification. The verification can include using image recognition (e.g., the internal / external tissues of the patient) to verify the dosage for the patient, location, etc. The verification can include using tissue and / or physiological responses to verify, for example, the amplitude or dosage of the applied energy. The verification can include using feedback from internal and / or external sensors that measure the energy being applied for verification purposes. The verification can include using other characteristics such as changes in blood flow or other physiological responses as verification of administration. In a specific example, the verification can include a consensus algorithm (e.g., including the use of personal image recognition, etc.) to verify the patient associated with the administration. It is also possible to connect a treatment hardware (e.g., an energy application device 370, etc.) to another device (e.g., a mobile phone and / or other mobile device 420, etc.) and associate a person with the device and verify the dosage using global positioning and / or other biometric data.

[0114] Associated blockchain and / or other distributed ledger systems can be internal (e.g., available to companies related to therapeutic devices or other medical devices, pharmaceutical companies, healthcare companies, etc. for providing evidence and understanding of use, etc.) and / or external (e.g., a treatment company can provide dosing data to other healthcare stakeholders such as insurance companies, healthcare companies, etc. via a distributed ledger to enable deriving value from dosing information, etc.). For example, external value can include driving different patient insurance premiums based on compliance to a prescribed treatment regimen, etc. Another value can include different insurance payments for a hospital system that functions better in diagnosing correct energy application or dosing regimen. These operations / transactions can be added, for example, as records and / or used to adjust existing records in a blockchain or other distributed ledger.

[0115] Specific exemplary methods, apparatuses, and products are described herein, but the scope of this patent is not limited thereto. On the contrary, this patent encompasses all methods, apparatuses, and products that are properly included within the scope of the claims of this patent.

Claims

**Claim 1** An apparatus comprising: an energy application device; a pulse generator; a controller; and a memory including a logical data structure for configuring the apparatus according to an electronic prescription defining an action for a patient, the memory including the electronic prescription, the electronic prescription being compiled as one or more records in a distributed ledger, processable by the controller to apply the action to the patient, and when processed by the controller, causing the controller to, at least, configure the energy application device and the pulse generator to apply the action to the patient using the electronic prescription, verify the action for the patient using a replicated record of the action from the distributed ledger, and propagate a record of the action to the distributed ledger. **Claim 2** The controller is configured to determine payment information associated with the action of the patient; and execute payment processing for the action using the payment information when the electronic prescription is processed by the device to apply the action to the patient upon verification of the action. The apparatus according to claim 1. **Claim 3** The electronic prescription includes prescription information specifying the action to be applied to the patient by the device using at least one device setting. The apparatus according to claim 2. **Claim 4** The electronic prescription is a prescription capable of causing payment processing to be executed when the action occurs to the patient by the device. The apparatus according to claim 3. **Claim 5** When processed by the controller, the electronic prescription causes the controller to verify a dosage within the electronic prescription. The apparatus according to claim 1. **Claim 6** The device is a first device including at least one of an imaging device, a reading workstation, an electronic medical record system, an image archive, or a laboratory information system. The apparatus according to claim 1. **Claim 7** Modification of the electronic prescription by at least one of the first device or a second device generates an additional record associated with the electronic prescription in the distributed ledger. The apparatus according to claim 6. **Claim 8** At least one computer-readable storage medium including a logical data structure for configuring a device according to an electronic prescription defining operations for a patient, wherein the electronic prescription is compiled as one or more records of a distributed ledger and is processable by the device to apply the operations to the patient, and when executed, causes at least one processor to, at least, configure the device to apply the operations to the patient, verify the operations for the patient using a replicated record of the operations from the distributed ledger, and propagate a record of the operations to the distributed ledger. The at least one computer-readable storage medium includes instructions. **Claim 9** When executed, the instructions cause the at least one processor to determine payment information associated with the operations of the patient and, when the operations are verified, execute processing of payment for the operations using the payment information when the electronic prescription is processed by the device to apply the operations to the patient. The at least one computer-readable storage medium according to claim 8. **Claim 10** The electronic prescription includes prescription information that specifies, using at least one device setting, the operations to be applied to the patient by the device. The at least one computer-readable storage medium according to claim 9. **Claim 11** The electronic prescription is a prescription that can cause payment processing to be executed when the operations occur for the patient by the device. The at least one computer-readable storage medium according to claim 10. **Claim 12** The electronic prescription is a prescription that can cause payment processing to be executed when the operations occur for the patient by the device. The at least one computer-readable storage medium according to claim 8. **Claim 13** The device is a first device including at least one of an imaging device, a reading workstation, an electronic medical record system, an image archive, or a laboratory information system. The at least one computer-readable storage medium according to claim 8. **Claim 14** The at least one computer-readable storage medium according to claim 13, wherein a correction of the electronic prescription by at least one of the first device or the second device generates an additional record associated with the electronic prescription in the distributed ledger.

15. The at least one computer-readable storage medium according to claim 14, wherein the second device verifies the operation using a replicated record of the operation from the distributed ledger.

16. A computer-implemented method for configuring a device according to an electronic prescription that defines an action for a patient, the electronic prescription being compiled as one or more records in a distributed ledger and processable by the device to apply the action to the patient, the method comprising: configuring the device to apply the action to the patient by at least one processor using the electronic prescription; verifying the action for the patient using a replicated record of the action from the distributed ledger by at least one processor using the electronic prescription; and propagating a record of the action to the distributed ledger by the at least one processor using the electronic prescription.

17. The method according to claim 16, wherein when the electronic prescription is processed by a controller, the controller is caused to verify a dosage in the electronic prescription for the patient.

18. The method according to claim 16, wherein the device is a first device, and a correction of the electronic prescription by at least one of the first device or the second device generates an additional record associated with the electronic prescription in the distributed ledger.

19. The method according to claim 18, wherein verifying further comprises verifying the action by the second device using a replicated record of the action from the distributed ledger.

Images