Invention for Secure Token Identification and Medical Rule-Based Authorization System
Invented by Jack Stockert, Charles Aunger, Neile Grayson, Roel Nuyts, Doug Given, Health2047 Inc
In today’s digital age, healthcare organizations are facing numerous challenges when it comes to protecting patient data. With the rise in cyber threats and data breaches, there is a growing demand for advanced security measures to safeguard sensitive medical records. This is where Secure Token Identification and Medical Rule-Based Authorization System comes into play.
Secure Token Identification is a method of authentication that uses a physical token, such as a smart card or a USB device, to verify the identity of the user. This adds an extra layer of security as it requires the physical presence of the token in addition to a password or PIN. By implementing this system, healthcare organizations can ensure that only authorized personnel have access to patient records, reducing the risk of data breaches and unauthorized access.
Additionally, the Medical Rule-Based Authorization System complements the Secure Token Identification by providing a rule-based access control mechanism. This system allows healthcare organizations to define specific rules and policies regarding access to patient data. For example, doctors may have access to a patient’s medical history, while nurses may only have access to the patient’s current medications. By implementing these rules, healthcare organizations can ensure that only the relevant personnel can access specific information, further enhancing data security.
The market for Secure Token Identification and Medical Rule-Based Authorization System is expected to witness substantial growth in the coming years. The increasing adoption of electronic health records (EHRs) and the need for interoperability among healthcare systems are driving the demand for secure access control solutions. Moreover, the growing awareness regarding data privacy and the need for compliance with regulations such as the Health Insurance Portability and Accountability Act (HIPAA) are also contributing to the market growth.
Furthermore, the COVID-19 pandemic has accelerated the digital transformation in the healthcare sector, leading to an increased reliance on telehealth and remote patient monitoring. As more patient data is being transmitted and stored electronically, the need for robust security measures has become paramount. Secure Token Identification and Medical Rule-Based Authorization System offer healthcare organizations the peace of mind that patient data is protected, even in remote settings.
In terms of market players, several companies are actively involved in providing Secure Token Identification and Medical Rule-Based Authorization System solutions. These companies offer a range of products and services, including hardware tokens, software solutions, and consulting services to help healthcare organizations implement and manage these systems effectively.
In conclusion, the market for Secure Token Identification and Medical Rule-Based Authorization System is witnessing significant growth due to the increasing need for secure access control in healthcare organizations. This technology offers a robust solution to protect patient data privacy and prevent unauthorized access to sensitive medical information. With the rising adoption of EHRs and the growing emphasis on data security, the demand for these systems is expected to continue growing in the coming years.
The Health2047 Inc invention works as follows
Systems for rapid data importation including object tracking in time. One method involves receiving a request from a medical practitioner to authorize a prescribing for a patient. The request is received by a network. Information associated with the patient is used to determine whether or not the request should be approved. The prescription is linked to transaction information, which specifies that the patient has been authorized to receive the associated pharmaceutical. This transaction information is then included in the patient’s transaction record. The prescription generates authorization information, which is then provided to the user device of the patients. This authorization information allows an external system to confirm that the prescription has been authorized. The user device of a patient receives speech information related to the prescription. Upon confirmation of presentation, the transaction record for the patient will be updated.
Background for Secure Token Identification and Medical Rule-Based Authorization System
Patient records are essential in determining the current state of a patient’s health and future risk indicators. The medical information and health records are created using proprietary complex systems that are stored at different locations, making them difficult to access. The existing systems often allow inconsistent access to medical data. A hospital, for example, may have a number of proprietary computer systems which each record and maintain medical information about patients in a unique proprietary format. Medical professionals can only access medical information on certain computer systems located in specific hospital wards. It is common for staff to request hard copies of the medical information, which are then pulled from different storage systems one by one. This can cause significant waiting times.
A medical professional’s access to all the medical data associated with a particular patient may be limited, complicating the delivery of healthcare. A patient’s medical information may be stored in a multitude of hospitals. The medical professional in this case may not be aware of or have no access to the medical information stored at multiple hospitals. Another example is a patient who visits a number of emergency rooms to receive healthcare. Information from this series of visits might not be available to all medical practitioners. This inaccessibility can cause problems for medical professionals when it comes to certain classes of pharmaceuticals such as pain medications. A medical professional, for example, may prescribe a particular pharmaceutical class to a client without knowing how many prescriptions the patient has had.
A patient with a valid prescription may face obstacles in obtaining the pharmaceutical. While at a pharmacist, the patient might be asked to provide proof of his/her identification. The pharmacy may also require that proof be provided to prove the validity of the authorization. The pharmacy, for example, may ask that the prescription is confirmed with a medical professional. These steps to prove authorization may prevent unauthorized access to pharmaceuticals but may also make it difficult for a patient who is authorized to obtain the pharmaceutical. The existing systems and schemes do not have the necessary technical solutions for automatic identification of patients at the pharmacy and determination of their valid authorization to purchase pharmaceuticals.
Specific embodiments of the subject described in this specification may be implemented to achieve one or more of these advantages. The system described can be used to protect sensitive medical data of patients while tightly integrating it with the systems of medical professionals, pharmaceutical firms, etc., in order to perform actions. The system’s actions can be enabled based on the strict adherence of authorization information. One example of an action is authorizing a prescription by a medical professional for a specific patient. A second example can be to send authorization information (e.g. mobile device) to the user device of the patient. In this manner, the patient can enter the pharmacy and, using the authorization information stored on his/her device, quickly obtain the associated pharmaceutical. The authorization information confirms that the prescription is valid, while the user device confirms the identity of the patient (e.g. via biometric identification). Authorization information can include tokens or encrypted information.
The system described in this document can ensure that the totality of medical information about a patient is automatically analyzed before a prescription is authorized. The system is able to access medical data from disparate sources and analyze it automatically in order to make sure that the prescription does not have contraindications. The system can also ensure that a prescribed class of pharmaceuticals, such as painkillers, can be given to the patient. The system, for example, can determine if the patient visited other medical professionals or hospitals to obtain pharmaceuticals of a particular class.
The system can enforce strict conditions of trust regarding the visibility of patient medical data. The system allows patients to “trust” the system. Medical professionals can then access specific portions of (or all) the patient’s records and medical history. A medical professional can review the detailed medical records of a patient with the trust. The system can also restrict access to certain portions of a patient’s medical records. While the system may analyze medical data prior to authorizing prescriptions, it can also limit the extent to which medical professionals can view that information. The system can tell a medical professional if a drug is contraindicated, but limit their access to detailed information about the patient.
A pharmaceutical company might require a specific speech to be read out loud or shown to a patient. For example, warnings about narcotic or cancer drugs, etc., may be required to be shown to patients. The system will automatically present the speech to a specific patient. This is in contrast to current methods where a pharmaceutical company would have to call a patient and ensure that the speech was delivered. The system can even ensure that a patient’s device was used to present the speech, and that they confirmed it. The system allows for an end-toend scheme to ensure that speech such as questions, information and other content can be confidently presented to patients.
As will be explained, the system is able to maintain communication with pharmaceutical systems that can send updated speech rules for their pharmaceuticals. The system, for example, can be informed by a doctor that a certain pharmaceutical is prescribed to a patient. The system could then get rules for ‘Pharmaceutical B? An associated pharmaceutical company can provide rules. Examples of rules include requiring the patient to read certain information, view a video or answer questions. The system will authorize the prescription if the rules are met.
Likewise, the system can de-authorize prescriptions provided to an individual patient’s device if they violate one or more rules. For example, a patient could be required to communicate regularly with their medical professional or to perform certain actions, such as recording weight and blood glucose levels. The system can de-authorize prescriptions so that the patient cannot fill them at a pharmacy. The system can deauthorize a token of authentication stored on a patient’s device or update information to reflect the deauthorization.
The systems and methods are able to improve the performance of the computer in this manner and provide technical benefits. The system, for example, can adhere strictly to authorization rights so that users (e.g. patients) can quickly perform actions. The techniques described in this document would have required pharmaceutical companies to develop complex systems and methods to ensure adherence of rules related with their pharmaceuticals. A pharmaceutical company, for example, may need to contact patients to confirm that they received certain information. The pharmaceutical company might also need to approve the prescription of certain pharmaceuticals and make sure that doctors, pharmacists and others adhere to these rules. The system used here solves these technical shortcomings by utilizing authorization information.
Also, a user can access all prescriptions authorized and other medical data. By interacting with the device and using the system, pharmacies are able to reduce the friction associated with the issuing of pharmaceuticals. It is possible to implement automatic processes that (1) validate the patient’s identity and (2) verify the patient’s authorization to receive a pharmaceutical. The system will describe how it can issue debits and credits to patients in relation to prescriptions. The pharmacy will receive a rapid indication that the patient has been authorized to purchase the associated pharmaceutical. The system can also de-authorize prescriptions, such as via debit, so that the issuance of a prescription is blocked in real time.
In various embodiments, the system can efficiently and compactly present calculated data to the user. In some embodiments, user interfaces are more efficient than previous interfaces where data was not dynamically updated, and it was presented compactly and efficiently to the user.
Further as described in this document, the system can be configured or designed to generate the user interface data that is used for rendering the interactive user interfaces described. The system and/or other computer systems, devices, or software programs (for instance, a web browser program) may use the user interface data to render interactive user interfaces. Interactive user interfaces can be displayed, for instance, on electronic displays, including touch-enabled ones.
The appended claims may be used to summarize the disclosure in addition.
In various embodiments systems and/or computers are disclosed which comprise a computer-readable storage medium with program instructions embedded therein, and one/more processors configured for the execution of the program instructions, causing the one/more processors to perform one/more aspects of embodiments described above and/or below (including one/more aspects of appended claims).
In various embodiments, computer implemented methods are disclosed where, by one/more processors executing instructions, one/more aspects of the above and/or below described embodiments are implemented and/or executed (including one/more aspects of appended claims).
In different embodiments, computer programs comprising a computer-readable storage medium, are disclosed. The computer-readable storage medium contains program instructions, which can be executed by one or multiple processors. These program instructions cause the processors to perform one or several aspects of embodiments described above and/or below (including some aspects of appended claims).
This specification describes a medical risk authorization system (e.g. the system 100 described below), which can interface with patients, medical professionals and payers, such as insurance entities. The system will be described as a way to authorize prescriptions that medical professionals give patients. The system will analyze the medical data of the patient to determine whether a prescription is authorized. For instance, a doctor can specify that a certain pharmaceutical should be prescribed to a specific patient. The system allows pharmaceutical entities, such as pharmaceutical companies and manufacturers, to specify rules for controlled speech in relation to specific pharmaceuticals. The system, for example, can get rules related to a specific pharmaceutical upon receiving a request from a patient to authorize the pharmaceutical. The system can, as described below, request updated rules from a pharmaceutical entity and enforce them before the pharmaceutical is authorized. The patient could be asked to watch a video or answer questions. The system may then update logs that are associated with the patient. For example, it could update a blockchain-based record.
The system described here can be a medical network that can credit or debit certain medical actions. The system, for example, can update information when a doctor indicates that a patient will receive a prescription. The system can then authorize patients to receive pharmaceuticals in response to the approval of medical professionals for prescriptions associated with those products. As described above, it is possible for the system to analyze the medical history of a patient before authorizing the purchase. The system can, as will be explained in greater detail below maintain optional information about each patient that indicates a transaction record. A transaction record is defined in this specification as any information that indicates authorizations or deauthorizations for prescriptions. The system can check the transaction record in order to make sure that the patient does not take any pharmaceuticals which are contraindicated to a possible prescription. A transaction record may specify restrictions for each prescription. Examples of constraints include the number of pills a patient is allowed to receive of a particular pharmaceutical, dosage, duration of prescription and so on.
Upon authorizing a prescription and as described above the system can update an associated transaction record with a patient. The system can maintain a record for authorizations in this manner. The system can transmit this authorization to the prescribing physician and/or patient so that they can use it to fill the prescription. The system can create an authorization token that is stored on a patient’s device. This authorization token confirms the validity of authorization for a specific pharmaceutical. The system can also electronically sign data that is stored on the device of the patient. The system, for example, can use a public-key/private-key based signature scheme so that other systems (e.g. a pharmacy system), can verify that the information received came from the system.
The authorization information may be used by a pharmacist to confirm the prescription of a patient. The patient’s device (e.g. an electronic “app”? Downloaded from an app store, the application can be used to show authorized prescriptions to patients. This application can receive authorization information from the system. The application can also store authorization information. The application can be required to require biometric authentication or password authentication in order to ensure that it is only accessible by specific patients.
Click here to view the patent on Google Patents.
