WO2016122664A1 - Method and system for prescribing and determining risk associated with medications - Google Patents

Method and system for prescribing and determining risk associated with medications Download PDF

Info

Publication number
WO2016122664A1
WO2016122664A1 PCT/US2015/013973 US2015013973W WO2016122664A1 WO 2016122664 A1 WO2016122664 A1 WO 2016122664A1 US 2015013973 W US2015013973 W US 2015013973W WO 2016122664 A1 WO2016122664 A1 WO 2016122664A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
alert
patient
medication
point
Prior art date
Application number
PCT/US2015/013973
Other languages
French (fr)
Inventor
Justin Domesek
Original Assignee
Justin Domesek
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Justin Domesek filed Critical Justin Domesek
Priority to PCT/US2015/013973 priority Critical patent/WO2016122664A1/en
Publication of WO2016122664A1 publication Critical patent/WO2016122664A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00ICT specially adapted for the handling or processing of medical references
    • G16H70/40ICT specially adapted for the handling or processing of medical references relating to drugs, e.g. their side effects or intended usage
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Definitions

  • narcotics such as Hydrocodone from a primary doctor, more narcotics such as Percocet from a Pain Management specialist, and sleeping pills like Ambien from a Sleep specialist, while they are getting sedatives such as Valium from their Psychiatrist.
  • PDMPs Programs to view a patient's controlled substance medication history.
  • PDMPs are electronic databases intended to track all prescriptions of controlled substances dispensed in the state.
  • PDMPs pull prescription information from the pharmacy databases and make it available to individuals who are authorized under state law to view the information for purposes of their profession (i.e. physicians and pharmacists).
  • Each PDMP is housed by a specified s nationwide regulatory, administrative or law enforcement agency. However each program is managed by different governing bodies which create inconsistency. Another PDMP discrepancy is in the manner and frequency that the data is collected among states. Some states report information daily, some report weekly and others report it monthly. The inconsistency in state laws and the lack of accurate and accessible information has resulted in poor compliance of these state-led monitoring programs.
  • PDMPs pull prescription information from the pharmacy databases (the ones that allow them to; CVS does not report all their data) and distribute it to individuals who are authorized under state law to receive the information for purposes of their profession (i.e. physicians and pharmacists).
  • CVS cardiovascular disease
  • PDMPs are investigative tools that fail to prevent prescription drug abuse from taking place, and do a poor job of providing accurate medication history for medication reconciliation purposes.
  • state-run programs have proven unable to identify problem patients and problem practitioners in the early stages of abuse. Even when diversion is suspected and prescriptions are denied, abusers are recycled back into the system without any warning for other physicians of their risk.
  • Embodiments described herein may be used to deliver real-time medication history, detailed drug and provider summaries, and prescription risk assessments in seconds to enhance clinical excellence and financial performance.
  • embodiments may deliver a point-of-care application for health systems and pharmacies to reduce medication errors and prevent prescription fraud, while improving each patient encounter.
  • Embodiments described herein offer the most comprehensive, real-time prescription and provider data sets available today. Embodiments may be used to establish communication with data sources such as aggregators of medication history and medical provider data in the United States to deliver the most accurate and updated information.
  • the exemplary unique point-of-care tool delivers real-time data and clinical alerts to reduce medication errors, prevent prescription fraud, improve patient outcomes, and reduce costs.
  • the application may receive current mailing address, phone, and fax information for retail, independent, government, compound/specialty pharmacies, urgent/emergency care facilities, and dispensing physician practices. DEA, NPI, and State medical licenses may also be received that are automatically accessed, verified and updated from primary and authoritative sources.
  • the real-time contact information for all medical providers and pharmacies promote effective communication and enhances care coordination.
  • Exemplary embodiments provide a cloud-based application that seamlessly integrates within any Electronic Health Record (EHR) and/or Hospital Information System.
  • EHR Electronic Health Record
  • a licensed prescriber or pharmacist may query the system for their patient; this sends a secure request to external data sources and/or databases, which securely return the patient report to the system, where it is synthesized and populated with critical prescription alerts.
  • Each patient report is sourced only by the request of the treating medical provider and no Personal Health Information (PHI) is stored within the ScriptGuard system.
  • PHI Personal Health Information
  • Real-time medication history and drug information may prevent medication errors in the emergency department, and throughout all points of care within a health care system.
  • doctors and nurses can effectively manage a patient's medications, reduce the likelihood of adverse drug events, protect their professional liability, and improve each patient encounter.
  • Embodiments described herein may be used to synthesize the medication history in seconds before displaying a prescription risk assessment with alerts. These realtime medication alerts may be used to prevent or reduce prescription fraud and reduce the number of Adverse Drug Events.
  • the exemplary unique tool described herein may offer real-time prescription data across state lines and is compatible with all current electronic prescribing systems. All prescription information may be automated and tracked at the point of care to ensure accuracy and accountability of the data.
  • FIG. 1 is an exemplary system flow diagram according to embodiments described herein.
  • FIGS. 2A and 2D define exemplary alerts based on data synthesis according to embodiments described herein.
  • FIGS. 3A-3C are excerpts of exemplary user display sections of an exemplary informational display.
  • FIGS. 4A-4B are exemplary user interfaces for displaying the aggregated and analyzed data to a user.
  • FIG. 5A illustrates an exemplary use case patient activity report functionality
  • FIG. 5B illustrates an exemplary process flow diagram of patient activity report functionality.
  • FIGS. 6A and 6B illustrate exemplary methods using an exemplary standalone and integrated application, respectively, as described herein.
  • FIG. 1 is an exemplary system flow diagram.
  • the system includes one or more source data feeds, such that the system has access to one or more databases of patient information, health information, medication histories, demographic information, geographic information, pharmacy information, physician information, drug information, and any combination thereof.
  • the system then processes that information to provide a information delivery portal.
  • the information delivery may present the aggregated information in a convenient and efficient manner.
  • the information delivery may also provide one or more alerts, warnings, or notices based on the processing of the compiled information.
  • the system may deliver a HIPAA-compliant real-time medication history, provider validation, and prescription risk assessment in a matter of seconds.
  • the system may have access to one or more databases to provide comprehensive information to a user.
  • Collective information may be related to a patient, medications, physicians, pharmacies, or others of interest or relevance to the particular audience.
  • Patient information may include name, age, birth date, ethnicity, contact information, residence city, residence state, address, medical records, allergies, diagnoses, prescriptions, etc.
  • Pharmacy and physician information may include name, contact information, license information, license status, prescribing histories, etc.
  • the system may include or aggregate prescription information of patients.
  • the prescription history is preferably based on prescriptions actually filled by a patient at the time or close to the time the patient fills the prescription.
  • one or more prescription data repositories 12 may be accessed and/or aggregated.
  • the prescription information may include the name of the drug, the unit dosage, quantity, the drug class, or any combination thereof.
  • information or databases tracking written prescriptions, whether filled or unfilled, may also be used.
  • the filled prescription information may be used by the system to detect conflicts in kind, quantity, or duration for one or more medications.
  • the system may be integrated with or interface with the patient's electronic health record 18.
  • the health record can provide a physician a history of the patient, including illnesses and corresponding diagnoses.
  • the health record can provide a timeline of patient illnesses, such as those requiring that a prescription be administered.
  • Patient demographics, such as patient age, gender, ethnicity, and allergies may also be obtained from the patient health record, such that the system may monitor for or provide alerts with respect to possible conditions that may make a prescription combination adverse to a given patient.
  • the system may also include information on physicians 14 and pharmacies 20, including their contact information. Therefore, when one entity is reviewing a patient history or medication association, and questions arise, the user can easily review and contact the responsible or knowledgeable person.
  • Information on the physician and pharmacies may include license information, license status (active/lapsed/revoked), prescribing history or warnings, etc. such that the system may display or provide warnings or alerts to another participant in the medication prescribing chain about the other participants in the chain.
  • Information of the physician and pharmacies may include name, address, contact phone, fax, or other contact and/or location information.
  • Information of the physician may include the preserver's DEA license status, such as if it has been revoked or suspended.
  • the system may also provide drug information, such as drug labeling information.
  • drug information may include the description of the drug, a picture of the drug, the drug's adverse interactions with other drugs, potential adverse symptoms associated with the drug, drug uses, drug classification, etc.
  • This information may be used by physicians and pharmacies to properly prescribe the drug, confirm the appropriate drug is being administered at a reasonable amount or interval.
  • This information may provide both the physician and pharmacy up to date information about a drug, its appearance, its effects, it uses, or other information relevant to a pharmacy or physician in prescribing a drug.
  • the system may also use this information to assess an appropriate dosage amount, duration, and frequency, or determine a conflict with other drugs or over-prescriptions of drugs within the same class.
  • Geographic information 22 may also be provided, such that the system may compare locations of the patient, physician, and pharmacy. The system may then analyze the prescription habit of a patient from the geographic perspective, such that the system may provide warnings if a patient travels an usual amount between pharmacies or physicians to receive or fill a prescription.
  • each doctor-patient encounter may also be stored and accessed when a prescription is filled.
  • the prescription activity of each provider and patient in a given insurer's network may be accessed through the system database.
  • the exemplary information may be obtained from one or more databases or sources, either internal or external to the system.
  • ESI Healthcare Business Solutions may be used to obtain prescription details for a patient that is provided directly from the pharmacies and includes information regarding filled prescriptions.
  • Other exemplary databases or sources may include Emdeon,
  • RelayHealth, QS/1 which may be used individually or in conjunction to provide accurate, complete, and real time information.
  • Comprehensive provider credentials 14 may be obtained, for example, from the National Council for Prescriptions Drug Programs (NCPDP).
  • NCPDP National Council for Prescriptions Drug Programs
  • Detailed drug labeling information 16 may be obtained from, for example, First Data Bank. Geographic information may be obtained by a location database, such as google maps integrated software application. Other databases or sources may, for example, include Truven's Micromedex Medication Management, NCPDP's HCIDea and/or DataQ, Allscripts TouchWorks EMR.
  • Exemplary embodiments of the system may then synthesize the aggregated data and provide a concise summary of a patient's medication history and one or more risk factors, warnings, or alerts associated with prescribing or filling medications for that patient.
  • alerts are generated from the medication details, as well as one or more other separate data sources based on configured and/or configurable alert algorithms.
  • Alerts may be prioritized or ranked, such that major indicators, minor, or any level of intermediate indicators are brought to the attention of a user in one or more formats.
  • alerts may be consolidated and listed or displayed to a user in one section of the user interface.
  • One or more pieces of aggregated data may also be highlighted or otherwise emphasis in the user interface view, such that it is brought to the attention of the user during normal perusal of the displayed information.
  • the system may also provide one or more levels of information to the user through the user interface, such that the user can "drill down" to obtain higher or more detailed levels of information upon for one or more indicators.
  • Exemplary alerts 24 are illustrated in FIG. 1 provided to a user through one or more alternative applications 26a, 26b.
  • the alerts may provide notice to a user of potential prescription abuse, such as obtaining or filling prescriptions in multiple states, or over long distances, while other alerts may be provided to avoid possible oversight in patient prescriptions, such as multiple drugs prescribed in the same class.
  • FIGS. 2A and B illustrate an exemplary logic chart for exemplary alerts and associated default rules or settings for each alert. Each parameter may be static or configurable by a user to obtain a tailored alerts list based on the aggregated information.
  • the alert is classified or given a priority and an output message or text.
  • the alert priority may indicate where, when, and/or how it is displayed to a user.
  • major alerts may include an output message that is either opened in a separate window and requires acknowledgement to proceed, or may be consolidated in a major alert section of the user interface, or otherwise highlighted to a heightened level corresponding to its relative importance. Lesser alerts may not include text, or may simply be highlighted or otherwise brought to stand out, but not specifically called out or explained to a user. The user may be given an opportunity to find out more information if desired, as described herein.
  • Exemplary input parameters, the source of the parameter, the computation of the parameter, and the condition to trigger an alert based on the computation is provided in FIG. 2B.
  • Exemplary alerts, their condition, duration, nature, and associated result or message are illustrated in FIG. 2A.
  • the alert corresponds to having more than a desired number of prescribers for all medications within a time period.
  • the basis for trigger the alert is then comparing the number of prescribing physicians to the threshold, i.e. 5, within a given period, i.e. 90 days, row 1, corresponding to the alert for the number of prescribers, the input parameter or the aggregated data used to trigger the alert is based on the number of different prescribers.
  • the system aggregates the data for a given patient, the system will look to the databases or sources from the input source column and determine a new parameters for the field. This new parameter, or field, is then compared to the condition to determine if an alert is generated.
  • FIG. 2A is used to determine its nature and/or the result, including the associated display text. For example, in the case of multiple prescribers, the system looks to the ESI & NCPDP data sources and counts the number of prescribers, that prescriber count field is then compared to the condition of >5 to determine if an alert should be given. If the prescribers count field is greater than 5, then a major alert is given and the associated message is ">5 prescribers.”
  • the system may use information about the prescriber and/or pharmacy to provide an alert to a user that the prescription was either written or filled by an entity with a license in question. For example, if a preserver's license is revoked, suspended, or lapsed, an alert or indicator may appear to a user such that a user can more actively scrutinize the activities medications associated with that entity. For example, the user may be provided a notice on a list of provider names and addresses, such as that illustrated in FIG. 3A.
  • the associated medications that were provided from that prescriber may also be highlighted or otherwise indicated, such as by changing font, color, highlighting, underlining, bold, providing a symbol, or other indicator alerting a user to a suspicious prescriber and/or the suspicious medications from that prescriber.
  • the system may provide an alert when the patient information conflicts with one or more attributes of a prescribed medication.
  • the Beers drug list provides a list of drugs that are inappropriate for older users. This list, other similar list, or drug labeling information may be used in conjunction with the patient information to provide an alert to a user when the parameters or characteristics for concern overlap with the patient's characteristics or parameters. For example, the system may provide an alert when the age of the patient is over 65 and a drug is filled from the Beers drug list indicating drugs inappropriate for patients over 65.
  • a beers list alert may be provided. Based on
  • the system can check for a match for fill drugs with the Beers list of drugs. If any match is found, the system should trigger this alert.
  • the alert of this type may be minor.
  • the condition is for an age over 65, which may not be editable so that it corresponds to the condition of the associated list, for example, in this case the Beers list.
  • the parameter that is compared is the drug name against the list of drug names associated with the limitation for patients that are over 65.
  • the system may compare typical or recommended dosage limits, such as provided in drug labeling information and/or other drug information. Medication dosages may then be compared on a per drug basis and/or on a flat ceiling basis. Accordingly, an alert may be provided when an excess dosage amount is perceived based on a general understanding of excessive across a drug type, across all drugs, or for a particular medication.
  • the fill quantity may also provide a basis for warning.
  • the alert may be provided when the fill quantity exceeds a predetermined ceiling, such as, for example 100 or 200 pills, or when a given prescription exceeds a certain quantity based on the class of drug, the type or drug, or for a specific medication.
  • controlled substances may trigger an alert at a lower fill quantity threshold than a non-controlled substance fill.
  • the system may provide an alert for a patient receiving more than 200 pills of a controlled medication.
  • the alert type may be minor.
  • the system may receive information from the ESI database for the medication and quantity. If medication is compared to the controlled medications list and the no of pills or quantity is compared to 200. If the patient is receiving 200 or more pills, then an appropriate display message may be shown.
  • the system may aggregate all of the pill counts of controlled substances or may compare each pill count per medication to the desired limit.
  • An identification of a specific drug may also trigger an alert.
  • drugs that are likely to interact with a majority of other drugs, or are likely to cause patients difficulty by themselves may be highlighted or brought to the attention of the user.
  • any prescription filled for an immunosuppressive may be a basis for an alert.
  • An identification of two or more (or any other desired threshold) drugs of the same class may be used to trigger an alert. For example, if two anticoagulants are prescribed an alert may be triggered such that their combined effect can be reviewed and the prescription verified and confirmed.
  • an alert may be provided for multiple anticoagulants, such as for example two or more. Therefore, based on ESI inputs, the fill drugs are checked for the drug class with, for example, the Truven database. If 2 or more drugs fall under same anti-coagulant class, then this Alert will be triggered.
  • the threshold parameter or condition may be configurable. The type of alert may be major. The drug class is therefore compared to a specific type, i.e. anticoagulants and summed for each true association and then compared or determined to be greater than 1.
  • an alert may be provided for any certain threshold of drugs in the same class. For example, an alert may be provided if three or more drugs in the same class is prescribed to the same patient. Based on ESI inputs, the system will check the medication class for all the drugs with Truven database. If 3 or more drugs fall under same drug class then this alert will be triggered.
  • the threshold amount may be configurable. The system may provide an alert identifying the class of drugs, the prescribed drugs in the class, and/or the total medications prescribed in any given class.
  • the quantity of drugs, the quantity of physicians prescribing medications, and/or the quantity of pharmacies filling medication prescriptions may also trigger an alert.
  • an alert may trigger if the total combination of drugs overlap such that it is likely the patient is taking more than a determined threshold (for example 7) at any given time.
  • the system provides an alert if more than seven drugs are taken concurrently.
  • the system may similarly compare the number of prescribers, such as pharmacies and/or physicians for any combination of drugs.
  • the alert may be triggered based on the class of drugs, the specific drug, or across all drugs. For example, if five or more prescribers are used to receive or fill any combination of medications, and/or two or more prescribers are used to fill a controlled substance medication, then an alert may be provided.
  • an alert may be provided when a patient is taking more than a threshold number of drugs, such as, for example 7. Based on ESI inputs, the system can count the number of different drugs filled by the patient. If the number exceeds above 7 (configurable parameter) then this Alert will be triggered. This alert may be a minor alert that provides a user with the class of drugs, the quantity of drugs in a class, and/or the name of drugs prescribed.
  • a threshold number of drugs such as, for example 7.
  • an alert may be provided when a patient uses multiple prescribers for medication, such as, for example five different prescribers. Based on ESI inputs, the system can count the number of different prescribers for the last 100 days (configurable parameter) and trigger the alert if the preserver's count is more than 5
  • the actual count of prescribers would be picked up and presented when the alert message is displayed.
  • the alert may be a major alert.
  • the input source may be ESI and NCPDP.
  • the system may provide a list of the providers and/or the corresponding medications for the multiple prescribers.
  • an alert may be provided for a patient filling controlled substances with multiple prescribers. Similar to the above, here the system checks the number of Prescribers for Scheduled drugs and triggers the alert if the count is more than 1 (configurable parameter). Truven database is referred to to check if the prescribed drug is classified under scheduled drugs. Therefore, the system may use various input sources including ESI, NCPDP, and Truven to determine the count, the physician, and the characterization of the medication as controlled. The alert type may be major, and may provide a user with the identity of the prescribers and/or the associated controlled substances.
  • an alert may be provided for a patient filling controlled substance medications with multiple pharmacies. Similar to the above, dispensing pharmacy count for scheduled drug is checked and an alert is triggered if the count is more than 2 (configurable parameter).
  • the alert type may be major and may use the ESI, NCPDP, and Truven databases to provide the identity of the pharmacies, and/or associated medications filled by the pharmacies.
  • An exemplary alert that is provided as a pop-up window that must be closed out before proceeding is illustrated in FIG. 3C for this exemplary alert. The alert provides the medication details, the filling details, and the pharmacy details so that a user can contact or reconcile the information as necessary.
  • the system may also compare the geographic locations of the patient, the physician, and the pharmacist. For example, if the pharmacist or physician is more than a predetermine geographic distance away from the patient and/or each other or if the pharmacist and/or physician are in different states from the patient and/or each other, then an alert may be provided. For example, if there is more than 20 miles between the pharmacist, the physician, and/or the patient, and/or any are within different states, an alert may be provided.
  • the system may provide an alert if the patient travels a distance to a prescriber. Based on ESI inputs on Patient address and NCPDP database inputs on Prescriber's address & Zip code, the system can query Google Maps for fetching the distance between patient address and prescriber's address. If the distance presented is more than 20 miles (configurable parameter) this alert will be triggered. There can be more than 1 trigger for this rule, but the results may show up as single or multiple alerts. The alert may be minor, and may use the databases NCPDP and google maps to compare the distance to a configurable parameter. A similar alert and/or analysis may be performed for the pharmacy distance.
  • the system may provide an alert if a prescription is filled or prescribed in multiple states. Similar to the above, if the patient address and the pharmacy address and/or physician address is across different states this alert will be triggered.
  • the information retrieved may be the zip code, which is assigned a state and compared, or the state can be pulled directly and compared.
  • the system may simply track medications that are prescribed in a certain time frame, for example, 30, 60, 90, or 180 days.
  • the system may also compare drug specific information such as quantity, administration times, and/or terminal duration limits to access whether the prescriptions overlap in time. For example, the system may determine that a medication filled for 31 tablets with an administration rate of once per day will be administered to the patient for 31 or about 31 days. The system will then compare that medication to other medications, and/or other sourced or stored information for that 31 day window.
  • the system may include an error window such that an alert is given or a lower level warning is provided when an indication occurs within the duration of a medication, or close to the duration of the medication, for example within 5 days of the expected termination of a medication.
  • FIGS. 3A-3C illustrate exemplary portions of the user interface that may provide medication details, FIG. 3B, prescriber information, FIG. 3A, and alerts, FIG. 3C, as described herein.
  • FIG. 4A and 4B illustrate exemplary alternative embodiments of exemplary user interfaces in which various information is provided to a user.
  • the user interface may be a graphical user interface for displaying the activity report with alerts for a patient.
  • alerts 44 classified by priority, e.g. major 44a and minor 44b
  • medications 46 e.g. major 44a and minor 44b
  • the medication information is filtered and displayed. For example, a desired duration, such as 90 days, may be automatically displayed.
  • the display may permit the user to configure the parameters, and change the filters. For example, the user may select to view only controlled medications, or may change the medication history time period.
  • the medication information is displayed.
  • An exemplary medication display is shown in FIG. 3B.
  • the display may include the name of the drug, the amount, the classification, is control status, the number of pills, or any combination thereof.
  • the medication details may also provide a user with additional information about the medication. In an exemplary embodiment, as seen in FIG.
  • the drug label information is displayed on a pop-out screen, in a new window, or as a drop down description of the medication name.
  • the additional drug information may include the information not displayed on the primary medication details portal.
  • the various names of the drug may be identified, its class, its therapeutic use, indications, and contraindications, or any combination thereof.
  • Alerts may be displayed in one or more ways. For example, as shown, alerts may be provided in a segregated section and ranked by priority, such as major and minor alerts.
  • the alert may provide a general alert statement, but may permit the user to obtain additional information that triggered the alert. For example, if the user selects more information on the third exemplary major alert of FIG. 4A, a pop up alert, such as that illustrated in FIG. 3C is provided.
  • the information may be provided in a drop down, expanded view, separate window, pop-out or call out section, etc.
  • the additional information may be provided if a user hovers over the alert and/or if the user clicks for additional information.
  • the additional information may include a summary of all of the information that generated the alert.
  • the pharmacies and the associated medications are provided. If the alert corresponded to the distance limitation, then the associated distance between the offending pharmacy and/or physician and the patient may be displayed.
  • the contact information of the pharmacy and/or physician of the medication may be included such that the user can notify the relevant entities and either provide a warning and/or retrieve additional information to confirm the authenticity, legitimacy, and/or appropriateness of the prescription.
  • the interface may also permit a user to print and/or copy the alerts and/or medication information.
  • the user may highlight a subsection, and/or select an entire one or more sections or portals within the user interface to display.
  • the system may configure the copied information, such that it can be pasted into another application.
  • the copied information may be saved in a table format, list, text, or other configuration, such that it can be copied into another application.
  • the system may also be configured to interface with the patient's medical records, such that information displayed through the user interface may be imported into the patient record and stored or retrieved through the patient's electronic medical records.
  • All or portions of the user interface may also be printed such that a hard copy can be provided, such as given to the patient and/or put in a hard copy patient file.
  • the system may permit a user to copy and/or print all of the alerts, the major alerts, the minor alerts, the medication information, the physician information, the pharmacy information, and any combination thereof.
  • the system may also permit a user to generate one or more reports from the data imported and/or operational reports about the use of the system.
  • Operational reports may include information such as the number of queries sent, the number of returned queries, the number of alerts triggered, the number of queries dropped, the number of users, the number of authenticated users, the number of unauthenticated users, date ranges used for specific data providers, clients, date ranges, number of queries with results, number of clicks on medication details, queries, response time, number of views on all medications, number of views on controlled medications, error logs, and other user generated statistics.
  • FIG. 5A illustrates an exemplary use case patient activity report functionality
  • FIG. 5B illustrates an exemplary process flow diagram of patient activity report functionality.
  • This use case describes how the Patient Medication History details will be fetched from ESI database and displayed on "All Medication Activity Report" and
  • a facility user can log into the application, enter patient demographic details in the search page and click to initiate the search.
  • the system may then automatically log into the ESI database with facility specific ESI access credentials and pass the search criteria to the ESI database.
  • ESI built in engine queries the Patient Rx matching history for the last 365 days and fetches the data and passes it in NCPDP format to the "All Medication Activity Report" page of the system to display Patient Rx history. By default 100 days data may be displayed on the page.
  • the temporary file generated in the local system may store the 365 days Rx history.
  • the search function within this page may retrieve complete 365 day details of the searched Medication or Prescriber or Pharmacy.
  • the system may sort (by Drug name, prescriber, etc.) will only go against the 100 days.
  • the day limit criteria may be configurable and defined in a user configuration page.
  • the page viewed by the exemplary unit may have different sections.
  • the exemplary user interface may include patient details, alert section, search section, or displayed medical history.
  • the patient details may be displayed on the top left corner of the banner with details as available (from EMR in integrated mode), including patient name, date of birth, address details, state, city, zip, contact (Phone No. / Email ID).
  • Facility specific Alert rules may be configured in by a facility administrator.
  • the data is validated based on the alert rule to defined and generate the respective alerts in Major and Minor categories for the last 100 days.
  • the Major and Minor alerts may be displayed in separate columns under an Alert Section.
  • the Major alerts may be highlighted with Red alert icon.
  • Minor alerts may be highlighted in with a yellow alert icon.
  • alerts messages may be presented in highlighted /bold /shaded letters to get the right attention from the user when displayed.
  • Exemplary alerts will be having "More Info" hyperlinks to drill down and view alert details in a popup page. The details may get changed based on type of alerts selected.
  • the system may be unable to find any alert specific to a patient.
  • a given alert may be provided such as a green ribbon bar or other positive indicator.
  • a user can perform a search action to search patient Rx details.
  • a user may search any of the following details in the search filed: Medication Details, Prescriber Details; Fill Date; or Pharmacy Details.
  • the Search function may retrieve complete 365 days details of the searched Medication or Prescriber or Pharmacy or fill date information. If a user clicks on the "365 Days Medication” button, the system may populated the patient medication history for the last 365 days while retaining the alerts for 100 days. If a user clicks on the "Controlled Medications only” button the display may show the Controlled Medication Activity Report. All other functions are similar to All Medication Activity Report functions.
  • the Page caption may be changed to "Controlled Medication Activity Report".
  • a user can click on "All Medication Activity Report” button in the search section to be redirect to "All Medication Activity Report” page.
  • the user may then click on "Patient Search” button to close the page and the system may be redirected to the "Patient Search” page.
  • the system may include an EMR Integrated mode, in place of "Patient Search” button there may be an “Exit” button to return control to the calling application.
  • patient medication details may be displayed for the last 100 days.
  • four columns may display information, such as Medication Details (displayed as Drug Name and Unit Doses hyperlink), Fill Date, Prescriber Name (on a mouse move over the name or on click of a hyperlink, the Prescriber address details may show up including State, City, Zip, Phone No.; Pharmacy Name (on mouse move over of name or on click of the hyperlink, the Pharmacy address details should show up including State, City, Zip, Phone No.
  • each column may include an icon (such as an up and/or down arrow) for alphabetical or chronological sorting of the information.
  • the column header of the controlling sort may be highlighted with a different color or given some other indicator.
  • the ESI data source will send back the NPI number of the Prescriber and Pharmacy. This NPI number may be passed into the NCPDP database to extract the Prescriber and Pharmacy address along and other details and displayed in respective columns. In the exemplary case, the NPI number is not available in the ESI database but details of the Prescriber or Pharmacy is available, then such data may be displayed.
  • the hyperlink may extract the Prescriber' s details from the NCPDP database and display the "Prescriber's Profile" popup page in a non-editable mode.
  • the Pharmacy Outlet details including physical and mailing addresses, phone and fax number, pharmacy services, license number, ownership etc. may come from DataQ.
  • a user may click on the Drug Name hyperlink (Under
  • the Medicine Details pop-up screen may have the following field details, including for example, generic name, trade names, therapeutic class, adult dose, pediatric dose, dosing adjustments, FDA-label indications, non-FDA label indications, contraindications, precautions, common effects, serious effects, drug interactions, black box warning.
  • a user may click on the logout button that may log off the system and the user may re-login to access application.
  • facility Users may pass patient query information to the ESI data source for retrieving Rx matching history (Medication Activity Report).
  • the process for Google Map API calls are as follows: users may send their query to ESI data source. The ESI data source then sends back results along with NPI number of Prescriber and Pharmacy information. This NPI number is passed into the NCPDP database to extract the Prescriber and Pharmacy address along with other details. Based on the extracted Prescriber, Pharmacy and Patient address, Google Maps API may be called with the Address parameter details and may provide inputs of the distance between Patient address to Prescriber address and Patient address to Pharmacy address. If this distance is beyond 20 miles then an Alert may be triggered within the application.
  • session time out or error messages due to invalid data may occur and this count need to be captured in separate tables of the application database and the above report may be displayed based on filters like - facility (All/ specific), in a data range etc.
  • Embodiments of the application described herein may be a cloud-based tool that may not require any hardware or software and can be integrated within any Electronic Health Record or pharmacy software system.
  • the data is highly secure, encrypted, and available to all physicians and pharmacists with a valid system account.
  • an administrator of the system may access the details of the alerts rules.
  • the rules may be populated with a default set of rules.
  • An administrator may enter the alert period (Days) value which each alert rule will check the patient Rx history details are compare against and generate an alert.
  • the default value is 100 days, which an be modified by an administrator user.
  • Alerts may include fields such as alert description (which is a brief description of the alert), nature of the alert (which is the dropdown value of priority such as major or minor), active (which displays the alert state), alert effective date (which displays the alert effective date), display message (which displays includes the text displayed in the medication page once the alerts are triggers), and additional fields for other specific alerts information.
  • GUI graphical user interface
  • the user interface may request information such as user name, password, other personal identifier,
  • Exemplary embodiments of the exemplary application may be run in different modes.
  • the application may be run in a stand along mode, a web service mode, or a tightly integrated mode.
  • the stand-alone mode may be configured such that data is copied source or external databases and pasted into the user's Electronic Health Record or Pharmacy Management System.
  • the web services mode may include an application that runs as a web service that interfaces between multiple data sources and present a user interface to the user to display the aggregated information and provide the alerts of the analyzed data.
  • the system may be run in a tightly integrated mode where the application is tightly integrated with the Electronic Health Record or Pharmacy Management System using HL7 CCOW where possible, and custom interfaces where CCOW integration is not available.
  • the user enters the patient's identifying information into the search screen; a service call is sent to external data source's server to request and retrieve the patient's medication history; the user may choose to copy the medication history, with or without any alerts, into the Electronic Health Record or Pharmacy Management System.
  • the access to the patient's information is logged, as described herein.
  • FIG. 6 illustrates an exemplary method using the stand alone application.
  • client application calls the application with the patient's identifying information.
  • the medication history is retrieved and alerts are computed.
  • the application screen with the history either: 1) always comes up for viewing; or 2) appears as a button within Electronic Health Record or Pharmacy Management System, which can be called by the user by pressing a button (the application button could be a different color depending on whether alerts are present and have reached a certain threshold).
  • the client application passes the prescriber identifying information and the patient identifying information to the application.
  • the patient's medication history is then presented by the application.
  • the user can select a "Copy" button within the application, in which case, upon return to their Electronic Health Record or Pharmacy Management System, the medication history +/- alerts will appear within the Electronic Health Record or Pharmacy Management System.
  • Exemplary embodiments may follow the NIST 800-66 Security Framework for over-all security.
  • the database may reside on an encrypted disk. It may contain an audit log for which prescriber accessed which patient's medication history; the fields in the log may include prescriber identifying information as well as the patient's identifying information consisting of name, birthdate, gender and zip code.
  • the actual medication history for a patient may be displayed or viewed through application, but the application preferably does not stored any patient medical data within the system.
  • Data in transit may be encrypted using 128-bit encryption.
  • the service call between the application and the external data sources may be encrypted.
  • the web server to user browser stream may also be encrypted.
  • the application is accessed using a web service by the Electronic Health Record or Pharmacy Management System client, that communication may be encrypted.
  • the application may use two-factor authentication to verify users of the system.
  • the application and database may be run on a secured server farm with load balancing to handle enterprise level throughput. Rapid-page serving may be had by using optimized code to reduce costly database calls and simplified data presentation with small footprint webpages.
  • the webserver is Apache running on Linux, a proven system for high traffic sites such as Facebook. The data-driven pages may be written in PHP programming language.
  • Prescribers and Pharmacists access the application by entering their unique login and password information.
  • the user may enter the patient's name, date of birth, gender, and zip code to view the Patient Activity Report (PAR).
  • the PAR report includes detailed information about all medications that patient has received; it reports the date the prescription was written, the medication name, form (pill, patch, etc.), quantity, strength, who prescribed the medication, and where it was filled.
  • the physician and/or pharmacist can decide how to proceed with the patient encounter. In all of these modes, the medication history alerts can be transferred into the Electronic Health Record or Pharmacy Management System, based on the user's discretion.
  • Two-factor authentication may be used for verifying the user's credentials for accessing the system, a fashion typical for Two Factor Authentication.
  • the application administrator sets up a new user, they can, in addition to the various elements in the user profile, enter the user's cell phone number (if available), and/or email address.
  • a password preferably a minimum of 8 digits, consisting of at least 1 uppercase, 1 lower case, 1 number, and 1 special character/symbol; this will be determined by the security policy at the user site).
  • the user is then offered the choice of how to be contacted (cell phone, preferably; or by email); a six- digit code may then be generated, which will be sent to the user's cell phone or email. If sent to a cell phone, the user may need to enter the code into the system. If sent to an email address, the user may need to click through on a link from an email message. Users' passwords may be forced to be changed, at a frequency determined by the client
  • single sign-on may also be used, in which case the user may not need to separately log into the application; they can access the application if already logged into their Electronic Health Record or Pharmacy Management System.
  • the user may still have a profile within the system set up by the application administrator.
  • Embodiments described herein may include different user levels such as administrators and users.
  • the administrators may add or edit users, set display preferences, change alert parameters, etc.
  • General users may retrieve information from the system.
  • [0098] The healthcare industry has failed to develop and execute strategies that minimize prescription drug abuse without compromising access to pain medications. The high potential for addiction, the opportunity to resell controlled medications on the black market for huge profits, and the lack of prescription security measures have caused this problem to reach catastrophic proportions. With more than $200 billion lost on prescription drug abuse each year, and with the skyrocketing costs of healthcare, it is imperative that healthcare organizations (insurers, private practice groups, independent practice associations, etc.) utilize tools to maximize their resources and cut costs.
  • Embodiments used herein may be used to help healthcare systems more effectively utilize their resources and increase productivity and net profits. By mitigating the risk of prescription transactions and streamlining claims reviews, valuable resources can be allocated to satisfy other areas of need.
  • Embodiments described herein offer the healthcare industry a reduction in spending through expediting and improving the prescription validation process and reducing the need for claims review. Increased savings will allow insurers to offer lower premiums and in turn recruit more members. Commercial organizations will pay less to subsidize healthcare premiums for their employees; Emergency Rooms and Urgent Care clinics will be less crowded with patients seeking narcotics and suffering from abuse; doctors will have more control of patient treatments and in turn patient results; new system controls will deter fraudulent behavior and ensure the safety of patients. The ability to more easily identify the "problem patients” and "problem practitioners," and the foresight to take punitive action will better protect bottom lines and patient lives.
  • the advantage of the system and embodiments described herein may provide a web-based application that delivers real-time and verified prescription information, with built-in analytics, from thousands of authoritative sources.
  • DEA, NPI, and State medical licenses are electronically and automatically accessed, verified and updated from over 2, 100 primary and authoritative sources.
  • Medication history is aggregated from Surescripts, Emdeon, RelayHealth, QS1, a network of independent pharmacies, and from system customers (health systems, pharmacies, nursing homes, medical offices).
  • Embodiments described herein may provide a medication history/med reconciliation tool that includes current mailing address, phone, and fax information for retail, independent, government, compound/specialty pharmacies, urgent/emergency care facilities, and dispensing physician practices, as well as the current contact information from licensed prescribers (name, address, phone, fax, license information).
  • the clinical rules- based alert system may allow physicians and pharmacists to pay closer attention to prescription risks, medication adherence concerns, and fraudulent activity.
  • Embodiments describes herein synthesizes the data and presents it in an easy-to-use, actionable format, unlike any other solution on the market. All current solutions in the marketplace display raw data and have no built-in analytics as part of their prescription assessment.
  • Exemplary embodiments described herein may provide safe, secure, and HIPAA-compliant solution to patient medication handling. It can be elegant, intuitive, easy to use, and offers no delays of information, unlike the cumbersome nature of PDMPs.
  • Exemplary embodiments do not store any patient health information, and therefore reduces the possibility of HIPAA data breaches.
  • Exemplary embodiments may provide insurers with a database management tool to validate prescription drug encounters and mitigate risk of foreseeable events related to abuse.
  • the ability to interact with Electronic medical record systems across the country and deliver real-time information allows physicians, pharmacies, health systems, and insurers to take a more active role in the fight against prescription drug abuse.
  • the application may track electronic and paper prescriptions, as well as phoned-in and faxed-in prescriptions, and produces real-time Patient Activity Reports (PAR).
  • PAR Patient Activity Reports
  • embodiments of the invention may be described and illustrated herein in terms of various features including the accumulation and assessment of patient information, prescriber information, drug information, drug indication information, prescription history, pharmacy information, risk patterns, etc. it should be understood that embodiments of this invention can be used in any combination, recombination, or subcombination, such that the information or modules may be duplicated, deleted, integrated, or separated. Exemplary embodiments, are also described herein for patient prescription use, but apply in other context of controlled substances.

Abstract

Embodiments described herein may be used to deliver real-time medication history, detailed drug and provider summaries, and prescription risk assessments in seconds to enhance clinical excellence and financial performance. For example, embodiments may deliver a point-of-care application for health systems and pharmacies to reduce medication errors and prevent prescription fraud, while improving each patient encounter.

Description

Method and System for Prescribing and Determining Risk Associated with Medications
PRIORITY
[0001] This application claims priority to U.S. Application No. 61/933,727, filed
January 30, 2014, which is incorporated by reference in its entirety into this application.
BACKGROUND
[0002] With 30% of adults taking 5 or more prescription medications, and the average
Medicare patient taking 14 to 18 prescriptions, the risk for drug-drug interactions is enormous. Each year there are over 1,800,000 hospitalizations for Adverse Drug Events (ADE's) and more than 770,000 of these result in serious injury or death. The Agency for Healthcare Research & Quality reports that more than 40% of these ADE's are caused by improper medication reconciliation, which translates into over 308,000 serious injuries or deaths that could have been prevented each year, simply through proper medication reconciliation.
[0003] In addition, there is a catastrophic prescription drug abuse epidemic in the
United States and it is taking a massive financial toll on the healthcare industry. Hospitals, treatment centers, and medical clinics have been overwhelmed with the dramatic increase in patient care related to prescription drug abuse. The staggering cost for Urgent Care and Emergency Room visits, overdose treatments, and outpatient office visits related to prescription drug dependence and abuse threatens the solvency of healthcare systems.
[0004] In the past two years, over 75,000 men, women and children have died from narcotic related overdose in the United States. The fact that the United States consumes 98% of all the hydrocodone in the world, the ease with which patients can secure prescriptions from licensed medical providers, and the dramatic unpredictability these medications have on patients that have never taken controlled prescriptions in the past, has fueled the current narcotic epidemic in the U.S. [0005] In addition to the many types of overdose occurrences, whether from negligent or unintentional improperly prescribed medication combinations, or abuse or overdose of valid or invalid prescriptions, insurers are burdened with the cost of the medications themselves.
[0006] Licensed medical providers are caught in the middle of a treatment dilemma.
They have a medico-legal responsibility to treat a patient, however they also risk their license to practice and the lives of their patients should they prescribe irresponsibly or ignorantly. To make matters worse, patients are poor historians and consistently omit important medication and treatment details which greatly affect a doctor's decision making abilities. The challenge for licensed medical providers is further complicated by the fact that a large percentage of patients are receiving prescriptions in the same class (of medications) from at least two providers. For example, a patient may receive narcotics such as Hydrocodone from a primary doctor, more narcotics such as Percocet from a Pain Management specialist, and sleeping pills like Ambien from a Sleep specialist, while they are getting sedatives such as Valium from their Psychiatrist. The combination of these medications can, and often does, lead to respiratory failure and death. The treating doctors for this type of patient are completely unaware that the patient was getting narcotic and controlled medications from other providers. These 4 doctors are unknowingly increasing their own professional license liability, increasing their likelihood of serving jail time, and increasing their chances of being sued for malpractice by patients' families.
[0007] Pharmacists are in an equally precarious position as they attempt to validate every patient, prescription, and provider that is presented to them. There is a lack of resources to access real-time information about the medical provider subscribing the prescription, the prescription habits of the patient, and information about the individual medications in a meaningful and efficient manner. Another substantial challenge for the pharmacist is validating the authenticity of the medical provider requesting a prescription. This prescriber validation is beneficial to pharmacists as they share an equivalent burden of risk every time they fill a narcotic or controlled prescription for a patient. Many states allow physicians to practice medicine without board certification which poses an increased risk to pharmacies and pharmacists filling their prescriptions. Additionally, it is common for physicians to involuntarily allow their DEA Licenses and State Licenses to lapse (usually a responsibility of physician's staff member to keep updated). Pharmacies are fined $25,000 for each prescription they fill by a medical provider that has an invalid, suspended or lapsed license. In 2012 there was over $1.5 Billion paid in fines for prescription filled with invalid DEA numbers.
[0008] Pharmacists and doctors typically consult Prescription Drug Monitoring
Programs (PDMPs) to view a patient's controlled substance medication history. PDMPs are electronic databases intended to track all prescriptions of controlled substances dispensed in the state. PDMPs pull prescription information from the pharmacy databases and make it available to individuals who are authorized under state law to view the information for purposes of their profession (i.e. physicians and pharmacists). Each PDMP is housed by a specified statewide regulatory, administrative or law enforcement agency. However each program is managed by different governing bodies which create inconsistency. Another PDMP discrepancy is in the manner and frequency that the data is collected among states. Some states report information daily, some report weekly and others report it monthly. The inconsistency in state laws and the lack of accurate and accessible information has resulted in poor compliance of these state-led monitoring programs.
[0009] When surveyed by the Office of the National Coordinator for Health
Information Technology, healthcare providers reported that their major aversion to PDMPs was that they required an interruption in their daily workflow (having to check a separate database that took several minutes to process the complete request).
[0010] Therefore, these PDMP programs have proven to be inefficient and ineffective. PDMPs pull prescription information from the pharmacy databases (the ones that allow them to; CVS does not report all their data) and distribute it to individuals who are authorized under state law to receive the information for purposes of their profession (i.e. physicians and pharmacists). Moreover, PDMPs are investigative tools that fail to prevent prescription drug abuse from taking place, and do a poor job of providing accurate medication history for medication reconciliation purposes. These state-run programs have proven unable to identify problem patients and problem practitioners in the early stages of abuse. Even when diversion is suspected and prescriptions are denied, abusers are recycled back into the system without any warning for other physicians of their risk.
[0011] Accordingly, real-time prescription information is not currently shared among healthcare providers, health systems, or pharmacies. The lack of accurate and accessible prescription information has driven medication errors, adverse drug events, and prescription fraud to all-time highs. The inability to accurately reconcile a patient's medications results in billions of dollars wasted on unnecessary medications, avoidable office/emergency room visits, and excessive hospitalizations. These adverse events expose patients to serious injuries and deaths. They significantly threaten the professional licenses of doctors and pharmacists, and expose them to massive fines and jail time.
SUMMARY
[0012] Embodiments described herein may be used to deliver real-time medication history, detailed drug and provider summaries, and prescription risk assessments in seconds to enhance clinical excellence and financial performance. For example, embodiments may deliver a point-of-care application for health systems and pharmacies to reduce medication errors and prevent prescription fraud, while improving each patient encounter.
[0013] Real-time prescription information is not currently shared among healthcare providers, health systems, or pharmacies. The lack of accurate and accessible prescription information has driven medication errors, adverse drug events, and prescription fraud to all- time highs. The inability to accurately reconcile a patient's medications results in billions of dollars wasted on unnecessary medications, avoidable office/emergency room visits, and excessive hospitalizations. These adverse events expose patients to serious injuries and deaths. They significantly threaten the professional licenses of doctors and pharmacists, and expose them to massive fines and jail time.
[0014] Embodiments described herein offer the most comprehensive, real-time prescription and provider data sets available today. Embodiments may be used to establish communication with data sources such as aggregators of medication history and medical provider data in the United States to deliver the most accurate and updated information. The exemplary unique point-of-care tool delivers real-time data and clinical alerts to reduce medication errors, prevent prescription fraud, improve patient outcomes, and reduce costs. The application may receive current mailing address, phone, and fax information for retail, independent, government, compound/specialty pharmacies, urgent/emergency care facilities, and dispensing physician practices. DEA, NPI, and State medical licenses may also be received that are automatically accessed, verified and updated from primary and authoritative sources. The real-time contact information for all medical providers and pharmacies promote effective communication and enhances care coordination.
[0015] Exemplary embodiments provide a cloud-based application that seamlessly integrates within any Electronic Health Record (EHR) and/or Hospital Information System. A licensed prescriber or pharmacist may query the system for their patient; this sends a secure request to external data sources and/or databases, which securely return the patient report to the system, where it is synthesized and populated with critical prescription alerts. Each patient report is sourced only by the request of the treating medical provider and no Personal Health Information (PHI) is stored within the ScriptGuard system.
[0016] Real-time medication history and drug information may prevent medication errors in the emergency department, and throughout all points of care within a health care system. By delivering the most accurate and comprehensive prescription information, doctors and nurses can effectively manage a patient's medications, reduce the likelihood of adverse drug events, protect their professional liability, and improve each patient encounter.
[0017] Embodiments described herein may be used to synthesize the medication history in seconds before displaying a prescription risk assessment with alerts. These realtime medication alerts may be used to prevent or reduce prescription fraud and reduce the number of Adverse Drug Events.
[0018] The exemplary unique tool described herein may offer real-time prescription data across state lines and is compatible with all current electronic prescribing systems. All prescription information may be automated and tracked at the point of care to ensure accuracy and accountability of the data.
DRAWINGS
[0019] FIG. 1 is an exemplary system flow diagram according to embodiments described herein.
[0020] FIGS. 2A and 2D define exemplary alerts based on data synthesis according to embodiments described herein.
[0021] FIGS. 3A-3C are excerpts of exemplary user display sections of an exemplary informational display. [0022] FIGS. 4A-4B are exemplary user interfaces for displaying the aggregated and analyzed data to a user.
[0023] FIG. 5A illustrates an exemplary use case patient activity report functionality, and FIG. 5B illustrates an exemplary process flow diagram of patient activity report functionality.
[0024] FIGS. 6A and 6B illustrate exemplary methods using an exemplary standalone and integrated application, respectively, as described herein.
DESCRIPTION
[0025] The following detailed description illustrates by way of example, not by way of limitation, the principles of the invention. This description will clearly enable one skilled in the art to make and use the invention, and describes several embodiments, adaptations, variations, alternatives and uses of the invention, including what is presently believed to be the best mode of carrying out the invention. It should be understood that the drawings are diagrammatic and schematic representations of exemplary embodiments of the invention, and are not limiting of the present invention nor are they necessarily drawn to scale.
[0026] Healthcare systems need a pro-active solution to protect their patients, providers, and their bottom line. Exemplary embodiments described herein may be used as a point-of-care solution designed to optimize physician and pharmacy work flow, while simultaneously assessing prescription behavior and comprehensively aggregating a patient's current medication list.
[0027] FIG. 1 is an exemplary system flow diagram. As shown, the system includes one or more source data feeds, such that the system has access to one or more databases of patient information, health information, medication histories, demographic information, geographic information, pharmacy information, physician information, drug information, and any combination thereof. The system then processes that information to provide a information delivery portal. The information delivery may present the aggregated information in a convenient and efficient manner. The information delivery may also provide one or more alerts, warnings, or notices based on the processing of the compiled information. In an exemplary embodiment, the system may deliver a HIPAA-compliant real-time medication history, provider validation, and prescription risk assessment in a matter of seconds.
[0028] In an exemplary embodiment, the system may have access to one or more databases to provide comprehensive information to a user. Collective information may be related to a patient, medications, physicians, pharmacies, or others of interest or relevance to the particular audience. Patient information may include name, age, birth date, ethnicity, contact information, residence city, residence state, address, medical records, allergies, diagnoses, prescriptions, etc. Pharmacy and physician information may include name, contact information, license information, license status, prescribing histories, etc.
[0029] For example, the system may include or aggregate prescription information of patients. The prescription history is preferably based on prescriptions actually filled by a patient at the time or close to the time the patient fills the prescription. For example, one or more prescription data repositories 12 may be accessed and/or aggregated. The prescription information may include the name of the drug, the unit dosage, quantity, the drug class, or any combination thereof. Alternatively, information or databases tracking written prescriptions, whether filled or unfilled, may also be used. The filled prescription information may be used by the system to detect conflicts in kind, quantity, or duration for one or more medications.
[0030] The system may be integrated with or interface with the patient's electronic health record 18. The health record can provide a physician a history of the patient, including illnesses and corresponding diagnoses. The health record can provide a timeline of patient illnesses, such as those requiring that a prescription be administered. Patient demographics, such as patient age, gender, ethnicity, and allergies may also be obtained from the patient health record, such that the system may monitor for or provide alerts with respect to possible conditions that may make a prescription combination adverse to a given patient.
[0031] The system may also include information on physicians 14 and pharmacies 20, including their contact information. Therefore, when one entity is reviewing a patient history or medication association, and questions arise, the user can easily review and contact the responsible or knowledgeable person. Information on the physician and pharmacies may include license information, license status (active/lapsed/revoked), prescribing history or warnings, etc. such that the system may display or provide warnings or alerts to another participant in the medication prescribing chain about the other participants in the chain. Information of the physician and pharmacies may include name, address, contact phone, fax, or other contact and/or location information. Information of the physician may include the preserver's DEA license status, such as if it has been revoked or suspended.
[0032] The system may also provide drug information, such as drug labeling information. This information may include the description of the drug, a picture of the drug, the drug's adverse interactions with other drugs, potential adverse symptoms associated with the drug, drug uses, drug classification, etc. This information may be used by physicians and pharmacies to properly prescribe the drug, confirm the appropriate drug is being administered at a reasonable amount or interval. This information may provide both the physician and pharmacy up to date information about a drug, its appearance, its effects, it uses, or other information relevant to a pharmacy or physician in prescribing a drug. The system may also use this information to assess an appropriate dosage amount, duration, and frequency, or determine a conflict with other drugs or over-prescriptions of drugs within the same class.
[0033] Geographic information 22 may also be provided, such that the system may compare locations of the patient, physician, and pharmacy. The system may then analyze the prescription habit of a patient from the geographic perspective, such that the system may provide warnings if a patient travels an usual amount between pharmacies or physicians to receive or fill a prescription.
[0034] Details of each doctor-patient encounter may also be stored and accessed when a prescription is filled. The prescription activity of each provider and patient in a given insurer's network, for example, may be accessed through the system database.
[0035] In an exemplary embodiment, the exemplary information may be obtained from one or more databases or sources, either internal or external to the system. For example, ESI Healthcare Business Solutions may be used to obtain prescription details for a patient that is provided directly from the pharmacies and includes information regarding filled prescriptions. Other exemplary databases or sources may include Emdeon,
RelayHealth, QS/1, which may be used individually or in conjunction to provide accurate, complete, and real time information. Comprehensive provider credentials 14 may be obtained, for example, from the National Council for Prescriptions Drug Programs (NCPDP). Detailed drug labeling information 16 may be obtained from, for example, First Data Bank. Geographic information may be obtained by a location database, such as google maps integrated software application. Other databases or sources may, for example, include Truven's Micromedex Medication Management, NCPDP's HCIDea and/or DataQ, Allscripts TouchWorks EMR.
[0036] These database relationships allow exemplary embodiments of the system access to the most current information on patients, medications, providers, administers, and their licenses. Therefore, mailing address, phone, and fax information for retail, independent, government, compound/specialty pharmacies, urgent/emergency care facilities, and dispensing physician practices may be provided. DEA, NPI, and State medical licenses may be electronically and automatically accessed, verified and updated from various primary and authoritative sources. Complete and up-to-date FDA-approved labeling, time-sensitive alerts, and medication warnings may also be available.
[0037] Exemplary embodiments of the system may then synthesize the aggregated data and provide a concise summary of a patient's medication history and one or more risk factors, warnings, or alerts associated with prescribing or filling medications for that patient.
[0038] In an exemplary embodiment, alerts are generated from the medication details, as well as one or more other separate data sources based on configured and/or configurable alert algorithms. Alerts may be prioritized or ranked, such that major indicators, minor, or any level of intermediate indicators are brought to the attention of a user in one or more formats. For example, alerts may be consolidated and listed or displayed to a user in one section of the user interface. One or more pieces of aggregated data may also be highlighted or otherwise emphasis in the user interface view, such that it is brought to the attention of the user during normal perusal of the displayed information. The system may also provide one or more levels of information to the user through the user interface, such that the user can "drill down" to obtain higher or more detailed levels of information upon for one or more indicators.
[0039] Exemplary alerts 24 are illustrated in FIG. 1 provided to a user through one or more alternative applications 26a, 26b. The alerts may provide notice to a user of potential prescription abuse, such as obtaining or filling prescriptions in multiple states, or over long distances, while other alerts may be provided to avoid possible oversight in patient prescriptions, such as multiple drugs prescribed in the same class. [0040] FIGS. 2A and B illustrate an exemplary logic chart for exemplary alerts and associated default rules or settings for each alert. Each parameter may be static or configurable by a user to obtain a tailored alerts list based on the aggregated information. The alert is classified or given a priority and an output message or text. The alert priority may indicate where, when, and/or how it is displayed to a user. For example, major alerts may include an output message that is either opened in a separate window and requires acknowledgement to proceed, or may be consolidated in a major alert section of the user interface, or otherwise highlighted to a heightened level corresponding to its relative importance. Lesser alerts may not include text, or may simply be highlighted or otherwise brought to stand out, but not specifically called out or explained to a user. The user may be given an opportunity to find out more information if desired, as described herein. Exemplary input parameters, the source of the parameter, the computation of the parameter, and the condition to trigger an alert based on the computation is provided in FIG. 2B. Exemplary alerts, their condition, duration, nature, and associated result or message are illustrated in FIG. 2A.
[0041] For example, as seen in FIGS. 2A and 2B, at row 1, the alert corresponds to having more than a desired number of prescribers for all medications within a time period. The basis for trigger the alert is then comparing the number of prescribing physicians to the threshold, i.e. 5, within a given period, i.e. 90 days, row 1, corresponding to the alert for the number of prescribers, the input parameter or the aggregated data used to trigger the alert is based on the number of different prescribers. When the system aggregates the data for a given patient, the system will look to the databases or sources from the input source column and determine a new parameters for the field. This new parameter, or field, is then compared to the condition to determine if an alert is generated. If an alert is generated, then FIG. 2A is used to determine its nature and/or the result, including the associated display text. For example, in the case of multiple prescribers, the system looks to the ESI & NCPDP data sources and counts the number of prescribers, that prescriber count field is then compared to the condition of >5 to determine if an alert should be given. If the prescribers count field is greater than 5, then a major alert is given and the associated message is ">5 prescribers."
[0042] In an exemplary embodiment, the system may use information about the prescriber and/or pharmacy to provide an alert to a user that the prescription was either written or filled by an entity with a license in question. For example, if a preserver's license is revoked, suspended, or lapsed, an alert or indicator may appear to a user such that a user can more actively scrutinize the activities medications associated with that entity. For example, the user may be provided a notice on a list of provider names and addresses, such as that illustrated in FIG. 3A. The associated medications that were provided from that prescriber may also be highlighted or otherwise indicated, such as by changing font, color, highlighting, underlining, bold, providing a symbol, or other indicator alerting a user to a suspicious prescriber and/or the suspicious medications from that prescriber.
[0043] The system may provide an alert when the patient information conflicts with one or more attributes of a prescribed medication. The Beers drug list provides a list of drugs that are inappropriate for older users. This list, other similar list, or drug labeling information may be used in conjunction with the patient information to provide an alert to a user when the parameters or characteristics for concern overlap with the patient's characteristics or parameters. For example, the system may provide an alert when the age of the patient is over 65 and a drug is filled from the Beers drug list indicating drugs inappropriate for patients over 65.
[0044] In an exemplary embodiment, a beers list alert may be provided. Based on
ESI inputs and the Patient's age above 65 years (or some static or configurable parameter), as received from patient information, medical records, etc., the system can check for a match for fill drugs with the Beers list of drugs. If any match is found, the system should trigger this alert. The alert of this type may be minor. In an exemplary embodiment, the condition is for an age over 65, which may not be editable so that it corresponds to the condition of the associated list, for example, in this case the Beers list. The parameter that is compared is the drug name against the list of drug names associated with the limitation for patients that are over 65.
[0045] The system may compare typical or recommended dosage limits, such as provided in drug labeling information and/or other drug information. Medication dosages may then be compared on a per drug basis and/or on a flat ceiling basis. Accordingly, an alert may be provided when an excess dosage amount is perceived based on a general understanding of excessive across a drug type, across all drugs, or for a particular medication.
[0046] Similar to dosage, the fill quantity may also provide a basis for warning. The alert may be provided when the fill quantity exceeds a predetermined ceiling, such as, for example 100 or 200 pills, or when a given prescription exceeds a certain quantity based on the class of drug, the type or drug, or for a specific medication. For example, controlled substances may trigger an alert at a lower fill quantity threshold than a non-controlled substance fill.
[0047] In an exemplary embodiment, the system may provide an alert for a patient receiving more than 200 pills of a controlled medication. The alert type may be minor. The system may receive information from the ESI database for the medication and quantity. If medication is compared to the controlled medications list and the no of pills or quantity is compared to 200. If the patient is receiving 200 or more pills, then an appropriate display message may be shown. The system may aggregate all of the pill counts of controlled substances or may compare each pill count per medication to the desired limit.
[0048] An identification of a specific drug may also trigger an alert. For example, drugs that are likely to interact with a majority of other drugs, or are likely to cause patients difficulty by themselves may be highlighted or brought to the attention of the user. In an exemplary embodiment, any prescription filled for an immunosuppressive may be a basis for an alert.
[0049] An identification of two or more (or any other desired threshold) drugs of the same class may be used to trigger an alert. For example, if two anticoagulants are prescribed an alert may be triggered such that their combined effect can be reviewed and the prescription verified and confirmed.
[0050] In an exemplary embodiment, an alert may be provided for multiple anticoagulants, such as for example two or more. Therefore, based on ESI inputs, the fill drugs are checked for the drug class with, for example, the Truven database. If 2 or more drugs fall under same anti-coagulant class, then this Alert will be triggered. The threshold parameter or condition may be configurable. The type of alert may be major. The drug class is therefore compared to a specific type, i.e. anticoagulants and summed for each true association and then compared or determined to be greater than 1.
[0051] In an exemplary embodiment, an alert may be provided for any certain threshold of drugs in the same class. For example, an alert may be provided if three or more drugs in the same class is prescribed to the same patient. Based on ESI inputs, the system will check the medication class for all the drugs with Truven database. If 3 or more drugs fall under same drug class then this alert will be triggered. The threshold amount may be configurable. The system may provide an alert identifying the class of drugs, the prescribed drugs in the class, and/or the total medications prescribed in any given class.
[0052] The quantity of drugs, the quantity of physicians prescribing medications, and/or the quantity of pharmacies filling medication prescriptions may also trigger an alert. For example, an alert may trigger if the total combination of drugs overlap such that it is likely the patient is taking more than a determined threshold (for example 7) at any given time. In an exemplary embodiment, the system provides an alert if more than seven drugs are taken concurrently. The system may similarly compare the number of prescribers, such as pharmacies and/or physicians for any combination of drugs. The alert may be triggered based on the class of drugs, the specific drug, or across all drugs. For example, if five or more prescribers are used to receive or fill any combination of medications, and/or two or more prescribers are used to fill a controlled substance medication, then an alert may be provided.
[0053] In an exemplary embodiment, an alert may be provided when a patient is taking more than a threshold number of drugs, such as, for example 7. Based on ESI inputs, the system can count the number of different drugs filled by the patient. If the number exceeds above 7 (configurable parameter) then this Alert will be triggered. This alert may be a minor alert that provides a user with the class of drugs, the quantity of drugs in a class, and/or the name of drugs prescribed.
[0054] In an exemplary embodiment, an alert may be provided when a patient uses multiple prescribers for medication, such as, for example five different prescribers. Based on ESI inputs, the system can count the number of different prescribers for the last 100 days (configurable parameter) and trigger the alert if the preserver's count is more than 5
(configurable parameter). The actual count of prescribers would be picked up and presented when the alert message is displayed. The alert may be a major alert. The input source may be ESI and NCPDP. The system may provide a list of the providers and/or the corresponding medications for the multiple prescribers.
[0055] In an exemplary embodiment, an alert may be provided for a patient filling controlled substances with multiple prescribers. Similar to the above, here the system checks the number of Prescribers for Scheduled drugs and triggers the alert if the count is more than 1 (configurable parameter). Truven database is referred to to check if the prescribed drug is classified under scheduled drugs. Therefore, the system may use various input sources including ESI, NCPDP, and Truven to determine the count, the physician, and the characterization of the medication as controlled. The alert type may be major, and may provide a user with the identity of the prescribers and/or the associated controlled substances.
[0056] In an exemplary embodiment, an alert may be provided for a patient filling controlled substance medications with multiple pharmacies. Similar to the above, dispensing pharmacy count for scheduled drug is checked and an alert is triggered if the count is more than 2 (configurable parameter). The alert type may be major and may use the ESI, NCPDP, and Truven databases to provide the identity of the pharmacies, and/or associated medications filled by the pharmacies. An exemplary alert that is provided as a pop-up window that must be closed out before proceeding is illustrated in FIG. 3C for this exemplary alert. The alert provides the medication details, the filling details, and the pharmacy details so that a user can contact or reconcile the information as necessary.
[0057] The system may also compare the geographic locations of the patient, the physician, and the pharmacist. For example, if the pharmacist or physician is more than a predetermine geographic distance away from the patient and/or each other or if the pharmacist and/or physician are in different states from the patient and/or each other, then an alert may be provided. For example, if there is more than 20 miles between the pharmacist, the physician, and/or the patient, and/or any are within different states, an alert may be provided.
[0058] In an exemplary embodiment, the system may provide an alert if the patient travels a distance to a prescriber. Based on ESI inputs on Patient address and NCPDP database inputs on Prescriber's address & Zip code, the system can query Google Maps for fetching the distance between patient address and prescriber's address. If the distance presented is more than 20 miles (configurable parameter) this alert will be triggered. There can be more than 1 trigger for this rule, but the results may show up as single or multiple alerts. The alert may be minor, and may use the databases NCPDP and google maps to compare the distance to a configurable parameter. A similar alert and/or analysis may be performed for the pharmacy distance. [0059] In an exemplary embodiment, the system may provide an alert if a prescription is filled or prescribed in multiple states. Similar to the above, if the patient address and the pharmacy address and/or physician address is across different states this alert will be triggered. The information retrieved may be the zip code, which is assigned a state and compared, or the state can be pulled directly and compared.
[0060] The system may simply track medications that are prescribed in a certain time frame, for example, 30, 60, 90, or 180 days. The system may also compare drug specific information such as quantity, administration times, and/or terminal duration limits to access whether the prescriptions overlap in time. For example, the system may determine that a medication filled for 31 tablets with an administration rate of once per day will be administered to the patient for 31 or about 31 days. The system will then compare that medication to other medications, and/or other sourced or stored information for that 31 day window. The system may include an error window such that an alert is given or a lower level warning is provided when an indication occurs within the duration of a medication, or close to the duration of the medication, for example within 5 days of the expected termination of a medication.
[0061] Exemplary embodiments described herein may provide a user an easy and efficient aggregation of the information from the various data sources or databases and present the information in a convenient and efficient user interface. FIGS. 3A-3C illustrate exemplary portions of the user interface that may provide medication details, FIG. 3B, prescriber information, FIG. 3A, and alerts, FIG. 3C, as described herein. FIG. 4A and 4B illustrate exemplary alternative embodiments of exemplary user interfaces in which various information is provided to a user. In an exemplary embodiment, the user interface may be a graphical user interface for displaying the activity report with alerts for a patient. For example, a user may be provided the patient's information 42, alerts 44 (classified by priority, e.g. major 44a and minor 44b), medications 46, physician information 48, and pharmacy information 50.
[0062] In an exemplary embodiment, the medication information is filtered and displayed. For example, a desired duration, such as 90 days, may be automatically displayed. The display may permit the user to configure the parameters, and change the filters. For example, the user may select to view only controlled medications, or may change the medication history time period. [0063] In an exemplary embodiment, the medication information is displayed. An exemplary medication display is shown in FIG. 3B. The display may include the name of the drug, the amount, the classification, is control status, the number of pills, or any combination thereof. The medication details may also provide a user with additional information about the medication. In an exemplary embodiment, as seen in FIG. 3B, if a user hovers or clicks on a drug name, the drug label information is displayed on a pop-out screen, in a new window, or as a drop down description of the medication name. The additional drug information may include the information not displayed on the primary medication details portal. For example, the various names of the drug may be identified, its class, its therapeutic use, indications, and contraindications, or any combination thereof.
[0064] Alerts may be displayed in one or more ways. For example, as shown, alerts may be provided in a segregated section and ranked by priority, such as major and minor alerts. The alert may provide a general alert statement, but may permit the user to obtain additional information that triggered the alert. For example, if the user selects more information on the third exemplary major alert of FIG. 4A, a pop up alert, such as that illustrated in FIG. 3C is provided. The information may be provided in a drop down, expanded view, separate window, pop-out or call out section, etc. The additional information may be provided if a user hovers over the alert and/or if the user clicks for additional information. The additional information may include a summary of all of the information that generated the alert. Therefore, for the illustrated alert, all of the pharmacies and the associated medications are provided. If the alert corresponded to the distance limitation, then the associated distance between the offending pharmacy and/or physician and the patient may be displayed. The contact information of the pharmacy and/or physician of the medication may be included such that the user can notify the relevant entities and either provide a warning and/or retrieve additional information to confirm the authenticity, legitimacy, and/or appropriateness of the prescription.
[0065] The interface may also permit a user to print and/or copy the alerts and/or medication information. For example, the user may highlight a subsection, and/or select an entire one or more sections or portals within the user interface to display. The system may configure the copied information, such that it can be pasted into another application. For example, the copied information may be saved in a table format, list, text, or other configuration, such that it can be copied into another application. [0066] The system may also be configured to interface with the patient's medical records, such that information displayed through the user interface may be imported into the patient record and stored or retrieved through the patient's electronic medical records.
[0067] All or portions of the user interface may also be printed such that a hard copy can be provided, such as given to the patient and/or put in a hard copy patient file.
[0068] In an exemplary embodiment, the system may permit a user to copy and/or print all of the alerts, the major alerts, the minor alerts, the medication information, the physician information, the pharmacy information, and any combination thereof.
[0069] The system may also permit a user to generate one or more reports from the data imported and/or operational reports about the use of the system. Operational reports may include information such as the number of queries sent, the number of returned queries, the number of alerts triggered, the number of queries dropped, the number of users, the number of authenticated users, the number of unauthenticated users, date ranges used for specific data providers, clients, date ranges, number of queries with results, number of clicks on medication details, queries, response time, number of views on all medications, number of views on controlled medications, error logs, and other user generated statistics.
[0070] FIG. 5A illustrates an exemplary use case patient activity report functionality, and FIG. 5B illustrates an exemplary process flow diagram of patient activity report functionality. This use case describes how the Patient Medication History details will be fetched from ESI database and displayed on "All Medication Activity Report" and
"Controlled Medication Activity Report" pages.
[0071] In an exemplary embodiment, a facility user can log into the application, enter patient demographic details in the search page and click to initiate the search. The system may then automatically log into the ESI database with facility specific ESI access credentials and pass the search criteria to the ESI database. ESI built in engine queries the Patient Rx matching history for the last 365 days and fetches the data and passes it in NCPDP format to the "All Medication Activity Report" page of the system to display Patient Rx history. By default 100 days data may be displayed on the page. The temporary file generated in the local system may store the 365 days Rx history. The search function within this page may retrieve complete 365 day details of the searched Medication or Prescriber or Pharmacy. The system may sort (by Drug name, prescriber, etc.) will only go against the 100 days. The day limit criteria may be configurable and defined in a user configuration page. The page viewed by the exemplary unit may have different sections. In an exemplary embodiment the exemplary user interface may include patient details, alert section, search section, or displayed medical history.
[0072] In an exemplary embodiment, the patient details may be displayed on the top left corner of the banner with details as available (from EMR in integrated mode), including patient name, date of birth, address details, state, city, zip, contact (Phone No. / Email ID).
[0073] Facility specific Alert rules may be configured in by a facility administrator.
Once the Rx history specific to a patient is generated from ESI for the last 365 days, the data is validated based on the alert rule to defined and generate the respective alerts in Major and Minor categories for the last 100 days. The Major and Minor alerts may be displayed in separate columns under an Alert Section. The Major alerts may be highlighted with Red alert icon. Minor alerts may be highlighted in with a yellow alert icon. In an exemplary embodiment, alerts messages may be presented in highlighted /bold /shaded letters to get the right attention from the user when displayed. Exemplary alerts will be having "More Info" hyperlinks to drill down and view alert details in a popup page. The details may get changed based on type of alerts selected.
[0074] In an exemplary case, the system may be unable to find any alert specific to a patient. In this case, a given alert may be provided such as a green ribbon bar or other positive indicator.
[0075] In an exemplary embodiment, a user can perform a search action to search patient Rx details. In an exemplary embodiment, a user may search any of the following details in the search filed: Medication Details, Prescriber Details; Fill Date; or Pharmacy Details. The Search function may retrieve complete 365 days details of the searched Medication or Prescriber or Pharmacy or fill date information. If a user clicks on the "365 Days Medication" button, the system may populated the patient medication history for the last 365 days while retaining the alerts for 100 days. If a user clicks on the "Controlled Medications only" button the display may show the Controlled Medication Activity Report. All other functions are similar to All Medication Activity Report functions. The Page caption may be changed to "Controlled Medication Activity Report". A user can click on "All Medication Activity Report" button in the search section to be redirect to "All Medication Activity Report" page. The user may then click on "Patient Search" button to close the page and the system may be redirected to the "Patient Search" page. In an exemplary
embodiment, the system may include an EMR Integrated mode, in place of "Patient Search" button there may be an "Exit" button to return control to the calling application.
[0076] In an exemplary embodiment, patient medication details may be displayed for the last 100 days. In an exemplary embodiment, four columns may display information, such as Medication Details (displayed as Drug Name and Unit Doses hyperlink), Fill Date, Prescriber Name (on a mouse move over the name or on click of a hyperlink, the Prescriber address details may show up including State, City, Zip, Phone No.; Pharmacy Name (on mouse move over of name or on click of the hyperlink, the Pharmacy address details should show up including State, City, Zip, Phone No.
[0077] In an exemplary embodiment, each column may include an icon (such as an up and/or down arrow) for alphabetical or chronological sorting of the information. The column header of the controlling sort may be highlighted with a different color or given some other indicator. During a search, the ESI data source will send back the NPI number of the Prescriber and Pharmacy. This NPI number may be passed into the NCPDP database to extract the Prescriber and Pharmacy address along and other details and displayed in respective columns. In the exemplary case, the NPI number is not available in the ESI database but details of the Prescriber or Pharmacy is available, then such data may be displayed. When a user clicks on a Prescriber's Name, the hyperlink may extract the Prescriber' s details from the NCPDP database and display the "Prescriber's Profile" popup page in a non-editable mode.
[0078] In an exemplary embodiment, the Pharmacy Outlet details, including physical and mailing addresses, phone and fax number, pharmacy services, license number, ownership etc. may come from DataQ. A user may click on the Drug Name hyperlink (Under
Medication Details Column) to open a popup page to display the information from the Truven Drug Database. The Medicine Details pop-up screen may have the following field details, including for example, generic name, trade names, therapeutic class, adult dose, pediatric dose, dosing adjustments, FDA-label indications, non-FDA label indications, contraindications, precautions, common effects, serious effects, drug interactions, black box warning. [0079] In an exemplary embodiment, a user may click on the logout button that may log off the system and the user may re-login to access application.
[0080] Facility Users may pass patient query information to the ESI data source for retrieving Rx matching history (Medication Activity Report). The process for Google Map API calls are as follows: users may send their query to ESI data source. The ESI data source then sends back results along with NPI number of Prescriber and Pharmacy information. This NPI number is passed into the NCPDP database to extract the Prescriber and Pharmacy address along with other details. Based on the extracted Prescriber, Pharmacy and Patient address, Google Maps API may be called with the Address parameter details and may provide inputs of the distance between Patient address to Prescriber address and Patient address to Pharmacy address. If this distance is beyond 20 miles then an Alert may be triggered within the application. Sometimes, session time out or error messages due to invalid data (like - wrong Zip code, State code etc.) may occur and this count need to be captured in separate tables of the application database and the above report may be displayed based on filters like - facility (All/ specific), in a data range etc.
[0081] Embodiments of the application described herein may be a cloud-based tool that may not require any hardware or software and can be integrated within any Electronic Health Record or pharmacy software system. The data is highly secure, encrypted, and available to all physicians and pharmacists with a valid system account.
[0082] In an exemplary embodiment, an administrator of the system may access the details of the alerts rules. The rules may be populated with a default set of rules. An administrator may enter the alert period (Days) value which each alert rule will check the patient Rx history details are compare against and generate an alert. In an exemplary embodiment, the default value is 100 days, which an be modified by an administrator user. Alerts may include fields such as alert description (which is a brief description of the alert), nature of the alert (which is the dropdown value of priority such as major or minor), active (which displays the alert state), alert effective date (which displays the alert effective date), display message (which displays includes the text displayed in the medication page once the alerts are triggers), and additional fields for other specific alerts information. [0083] When a user enters the system, the user may be presented with a graphical user interface (GUI) screen. The user interface may request information such as user name, password, other personal identifier,
[0084] Exemplary embodiments of the exemplary application may be run in different modes. For example, the application may be run in a stand along mode, a web service mode, or a tightly integrated mode. In an exemplary embodiment, the stand-alone mode may be configured such that data is copied source or external databases and pasted into the user's Electronic Health Record or Pharmacy Management System. In an exemplary embodiment, the web services mode may include an application that runs as a web service that interfaces between multiple data sources and present a user interface to the user to display the aggregated information and provide the alerts of the analyzed data. In an exemplary embodiment, the system may be run in a tightly integrated mode where the application is tightly integrated with the Electronic Health Record or Pharmacy Management System using HL7 CCOW where possible, and custom interfaces where CCOW integration is not available.
[0085] In stand-alone mode, the user enters the patient's identifying information into the search screen; a service call is sent to external data source's server to request and retrieve the patient's medication history; the user may choose to copy the medication history, with or without any alerts, into the Electronic Health Record or Pharmacy Management System. The access to the patient's information is logged, as described herein. FIG. 6 illustrates an exemplary method using the stand alone application.
[0086] In the web services mode, the Electronic Health Record or Pharmacy
Management System (client application) calls the application with the patient's identifying information. The medication history is retrieved and alerts are computed. Depending on the client organization's preference, the application screen with the history either: 1) always comes up for viewing; or 2) appears as a button within Electronic Health Record or Pharmacy Management System, which can be called by the user by pressing a button (the application button could be a different color depending on whether alerts are present and have reached a certain threshold).
[0087] In the tightly integrated mode, the client application passes the prescriber identifying information and the patient identifying information to the application. There may be an application button on the user's screen which the user may decide to select; this could be a different color if alerts reach a sufficient threshold. The patient's medication history is then presented by the application. The user can select a "Copy" button within the application, in which case, upon return to their Electronic Health Record or Pharmacy Management System, the medication history +/- alerts will appear within the Electronic Health Record or Pharmacy Management System.
[0088] Whenever a user views the medication history, the access to the patient's history is logged, as described herein.
[0089] Exemplary embodiments may follow the NIST 800-66 Security Framework for over-all security. For data at rest, the database may reside on an encrypted disk. It may contain an audit log for which prescriber accessed which patient's medication history; the fields in the log may include prescriber identifying information as well as the patient's identifying information consisting of name, birthdate, gender and zip code. The actual medication history for a patient may be displayed or viewed through application, but the application preferably does not stored any patient medical data within the system.
[0090] Data in transit may be encrypted using 128-bit encryption. The service call between the application and the external data sources may be encrypted. The web server to user browser stream may also be encrypted. When the application is accessed using a web service by the Electronic Health Record or Pharmacy Management System client, that communication may be encrypted.
[0091] In an exemplary embodiment, the application may use two-factor authentication to verify users of the system.
[0092] In an exemplary embodiment, the application and database may be run on a secured server farm with load balancing to handle enterprise level throughput. Rapid-page serving may be had by using optimized code to reduce costly database calls and simplified data presentation with small footprint webpages. In an exemplary embodiment, the webserver is Apache running on Linux, a proven system for high traffic sites such as Facebook. The data-driven pages may be written in PHP programming language.
[0093] Prescribers and Pharmacists access the application by entering their unique login and password information. Once in the system, the user may enter the patient's name, date of birth, gender, and zip code to view the Patient Activity Report (PAR). The PAR report includes detailed information about all medications that patient has received; it reports the date the prescription was written, the medication name, form (pill, patch, etc.), quantity, strength, who prescribed the medication, and where it was filled. After reviewing this information, the physician and/or pharmacist can decide how to proceed with the patient encounter. In all of these modes, the medication history alerts can be transferred into the Electronic Health Record or Pharmacy Management System, based on the user's discretion.
[0094] Two-factor authentication may be used for verifying the user's credentials for accessing the system, a fashion typical for Two Factor Authentication. When the application administrator sets up a new user, they can, in addition to the various elements in the user profile, enter the user's cell phone number (if available), and/or email address. As part of the user's initial sign-on to the system, they will have to choose a password (preferably a minimum of 8 digits, consisting of at least 1 uppercase, 1 lower case, 1 number, and 1 special character/symbol; this will be determined by the security policy at the user site). The user is then offered the choice of how to be contacted (cell phone, preferably; or by email); a six- digit code may then be generated, which will be sent to the user's cell phone or email. If sent to a cell phone, the user may need to enter the code into the system. If sent to an email address, the user may need to click through on a link from an email message. Users' passwords may be forced to be changed, at a frequency determined by the client
organization's policy. Whenever a password is changed, the user may need to go through the Two Factor Authentication process again.
[0095] In stand-alone mode, the user signs into the user with their username and password.
[0096] In an exemplary embodiment, single sign-on may also be used, in which case the user may not need to separately log into the application; they can access the application if already logged into their Electronic Health Record or Pharmacy Management System.
However, the user may still have a profile within the system set up by the application administrator.
[0097] Embodiments described herein may include different user levels such as administrators and users. The administrators may add or edit users, set display preferences, change alert parameters, etc. General users may retrieve information from the system. [0098] The healthcare industry has failed to develop and execute strategies that minimize prescription drug abuse without compromising access to pain medications. The high potential for addiction, the opportunity to resell controlled medications on the black market for huge profits, and the lack of prescription security measures have caused this problem to reach catastrophic proportions. With more than $200 billion lost on prescription drug abuse each year, and with the skyrocketing costs of healthcare, it is imperative that healthcare organizations (insurers, private practice groups, independent practice associations, etc.) utilize tools to maximize their resources and cut costs.
[0099] Currently there is no solution that offers real-time prescription drug monitoring and prescription drug validation. The only tool available to providers are state- run prescription drug monitoring programs (PDMPs), however, PDMPs are underfunded, underutilized, lack accurate information, and offer no consistency or transparency between other state-run programs. The CURES Program for the State of California has lacked appropriate funding for the past two years. The resource problems in California are mirrored across the country, and are allowing patients to visit multiple doctors and hospitals across multiple states without providers having any knowledge of their drug seeking activities.
[00100] State-run monitoring programs were intended to help curtail doctor shopping, but the lack of timely and accurate information has deterred physicians from using these systems on a daily basis. In the state of California, there are over 187,000 medical providers; the CURES Program is accessed by less than 5% of all medical providers in the State of California. Exemplary embodiments described herein however, real-time, accurate data, and will track each doctor-patient interaction of all registered users. The information is immediate and available to all registered physicians as soon as they log into the system. This information allows them to make more informed decisions and protect their professional integrity, their patients, and their medical license.
[00101] Since insurers do not have access to Prescription Drug monitoring Programs or real-time prescription data, they are forced to fight prescription drug abuse retroactively through claims matching and auditing. These strategies have significant challenges because many of the claims databases do not interface with one another. There are many different pharmacy benefit management companies who control this data and it is available in different formats that are difficult to analyze (there are 70 different pharmacy benefit management companies in the United States). With more than 12 billion claims to review and adjudicate each year, insurers are simply overwhelmed and need a solution to maximize their resources and reduce the number of fraudulent claims submitted.
[00102] Embodiments used herein may be used to help healthcare systems more effectively utilize their resources and increase productivity and net profits. By mitigating the risk of prescription transactions and streamlining claims reviews, valuable resources can be allocated to satisfy other areas of need.
[00103] Embodiments described herein offer the healthcare industry a reduction in spending through expediting and improving the prescription validation process and reducing the need for claims review. Increased savings will allow insurers to offer lower premiums and in turn recruit more members. Commercial organizations will pay less to subsidize healthcare premiums for their employees; Emergency Rooms and Urgent Care clinics will be less crowded with patients seeking narcotics and suffering from abuse; doctors will have more control of patient treatments and in turn patient results; new system controls will deter fraudulent behavior and ensure the safety of patients. The ability to more easily identify the "problem patients" and "problem practitioners," and the foresight to take punitive action will better protect bottom lines and patient lives.
[00104] The advantage of the system and embodiments described herein may provide a web-based application that delivers real-time and verified prescription information, with built-in analytics, from thousands of authoritative sources. DEA, NPI, and State medical licenses are electronically and automatically accessed, verified and updated from over 2, 100 primary and authoritative sources. Medication history is aggregated from Surescripts, Emdeon, RelayHealth, QS1, a network of independent pharmacies, and from system customers (health systems, pharmacies, nursing homes, medical offices).
[00105] Embodiments described herein may provide a medication history/med reconciliation tool that includes current mailing address, phone, and fax information for retail, independent, government, compound/specialty pharmacies, urgent/emergency care facilities, and dispensing physician practices, as well as the current contact information from licensed prescribers (name, address, phone, fax, license information). The clinical rules- based alert system may allow physicians and pharmacists to pay closer attention to prescription risks, medication adherence concerns, and fraudulent activity. Embodiments describes herein synthesizes the data and presents it in an easy-to-use, actionable format, unlike any other solution on the market. All current solutions in the marketplace display raw data and have no built-in analytics as part of their prescription assessment.
[00106] Exemplary embodiments described herein may provide safe, secure, and HIPAA-compliant solution to patient medication handling. It can be elegant, intuitive, easy to use, and offers no delays of information, unlike the cumbersome nature of PDMPs.
Exemplary embodiments do not store any patient health information, and therefore reduces the possibility of HIPAA data breaches.
[00107] Exemplary embodiments may provide insurers with a database management tool to validate prescription drug encounters and mitigate risk of foreseeable events related to abuse. The ability to interact with Electronic medical record systems across the country and deliver real-time information allows physicians, pharmacies, health systems, and insurers to take a more active role in the fight against prescription drug abuse. The application may track electronic and paper prescriptions, as well as phoned-in and faxed-in prescriptions, and produces real-time Patient Activity Reports (PAR).
[00108] Although embodiments of the invention may be described and illustrated herein in terms of various features including the accumulation and assessment of patient information, prescriber information, drug information, drug indication information, prescription history, pharmacy information, risk patterns, etc. it should be understood that embodiments of this invention can be used in any combination, recombination, or subcombination, such that the information or modules may be duplicated, deleted, integrated, or separated. Exemplary embodiments, are also described herein for patient prescription use, but apply in other context of controlled substances.
[00109] While some specific embodiments of the invention have been shown the invention is not to be limited to these embodiments. For example, most functions performed by electronic hardware components may be duplicated by software emulation. Thus, a software program written to accomplish those same functions may emulate the functionality of the hardware components in input-output circuitry. The invention is to be understood as not limited by the specific embodiments described herein, but only by scope of the appended claims.
[00110] Although embodiments of this invention have been fully described with reference to the accompanying drawings, it is to be noted that various changes and modifications will become apparent to those skilled in the art. Such changes and modifications are to be understood as being included within the scope of embodiments of this invention as defined by the appended claims. For example, the functions and methods described include one or more analytical tools and presentations of information to a user. Any combination of functions, features, and/or displays is considered within the scope of the present disclosure. Accordingly, any function, features, or display may be duplicated, removed, integrated, separated, etc. and still remain within the scope of the present disclosure.

Claims

CLAIMS The invention claimed is:
1. A point of care application for users requiring access to patient medication information, comprising: an aggregation engine for retrieving information from more than one unrelated source to create aggregated information; an alert engine to analyze the aggregated information and identify an alert based on the aggregated information; and a user interface for displaying the aggregated information and the alert.
2. The point of care application of claim 1, wherein the aggregation engine is configured to receive information from a first source to obtain physician information, a source to obtain pharmacy information, a third source to receive geographic information, a fourth source to receive prescription information specific to a patient, and a fifth source to receive medication information.
3. The point of care application of claim 2, wherein the first, second, third, fourth, and fifth sources are from at least two unrelated databases.
4. The point of care application of claim 3, wherein the alert engine analyzes the aggregated information to provide an alert when the number of physicians or pharmacies over a predetermined amount of time exceeds a threshold number.
5. The point of care application of claim 3, wherein the alert engine analyzes the aggregated information to provide an alert when the distance between a patient residence and a physician office or the patient residence and a pharmacy location is greater than a threshold number.
6. The point of care application of claim 3, wherein the alert engine analyzes the aggregated information to provide an alert when a state of patient residence is different than a state of pharmacy location.
7. The point of care application of claim 3, wherein the alert engine analyzes the aggregated information to provide an alert when a total number of medications in a given time exceeds a minimum number.
8. The point of care application of claim 3, wherein the alert is based on patient activities for a previous 90 days.
9. The point of care application of claim 3, wherein the user interface comprises a first area for displaying medication information including a medication name, a medication quantity, and a medication strength.
10. The point of care application of claim 9, wherein the user interface comprises a second area for displaying pharmacy contact information and physician contact information for a given medication name.
1 1. The point of care application of claim 10, wherein the user interface comprises an alert area for displaying alerts in a prioritized manner.
12. The point of care application of claim 11, wherein one or more pieces of displayed information may be activated to provide additional information about the displayed information.
13. The point of care application of claim 12, wherein the displayed information is medication name and the additional information comprises labeling information.
14. The point of care application of claim 10, wherein the point of care application is a cloud based application.
15. The point of care application of claim 3, further comprising a database configured to store usage details of user interactions with the point of care application.
PCT/US2015/013973 2015-01-30 2015-01-30 Method and system for prescribing and determining risk associated with medications WO2016122664A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2015/013973 WO2016122664A1 (en) 2015-01-30 2015-01-30 Method and system for prescribing and determining risk associated with medications

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2015/013973 WO2016122664A1 (en) 2015-01-30 2015-01-30 Method and system for prescribing and determining risk associated with medications

Publications (1)

Publication Number Publication Date
WO2016122664A1 true WO2016122664A1 (en) 2016-08-04

Family

ID=56544080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/013973 WO2016122664A1 (en) 2015-01-30 2015-01-30 Method and system for prescribing and determining risk associated with medications

Country Status (1)

Country Link
WO (1) WO2016122664A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018163181A1 (en) * 2017-03-08 2018-09-13 Medaware Ltd. System and method for drug interaction prediction
CN109523394A (en) * 2018-10-23 2019-03-26 平安科技(深圳)有限公司 A kind of risk checking method based on data processing, device and storage medium
CN109545312A (en) * 2018-10-23 2019-03-29 平安医疗健康管理股份有限公司 A kind of pharmacy's advice of settlement risk checking method and device
US20230230666A1 (en) * 2016-06-28 2023-07-20 Melrose Pain Solutions LLC Melrose Pain Solutions Method and Algorithm: Managing Pain in Opioid Dependent Patients

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090076559A1 (en) * 2007-09-14 2009-03-19 Corventis, Inc. Adherent Device for Cardiac Rhythm Management
US20090273467A1 (en) * 2006-09-18 2009-11-05 Koninklijke Philips Electronics N. V. Ip based monitoring and alarming
US20100299158A1 (en) * 2008-02-12 2010-11-25 Steven Siegel System and method for monitoring medication prescriptions using biometric identification and verification
US20110173020A1 (en) * 2009-12-14 2011-07-14 Clear View Technology, Inc Safeguard System in the Prescription and Dispensing of Drugs
US20120173319A1 (en) * 2010-12-31 2012-07-05 Daniel Ferrara System and method for increasing medication adherence rates

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090273467A1 (en) * 2006-09-18 2009-11-05 Koninklijke Philips Electronics N. V. Ip based monitoring and alarming
US20090076559A1 (en) * 2007-09-14 2009-03-19 Corventis, Inc. Adherent Device for Cardiac Rhythm Management
US20100299158A1 (en) * 2008-02-12 2010-11-25 Steven Siegel System and method for monitoring medication prescriptions using biometric identification and verification
US20110173020A1 (en) * 2009-12-14 2011-07-14 Clear View Technology, Inc Safeguard System in the Prescription and Dispensing of Drugs
US20120173319A1 (en) * 2010-12-31 2012-07-05 Daniel Ferrara System and method for increasing medication adherence rates

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230230666A1 (en) * 2016-06-28 2023-07-20 Melrose Pain Solutions LLC Melrose Pain Solutions Method and Algorithm: Managing Pain in Opioid Dependent Patients
WO2018163181A1 (en) * 2017-03-08 2018-09-13 Medaware Ltd. System and method for drug interaction prediction
CN109523394A (en) * 2018-10-23 2019-03-26 平安科技(深圳)有限公司 A kind of risk checking method based on data processing, device and storage medium
CN109545312A (en) * 2018-10-23 2019-03-29 平安医疗健康管理股份有限公司 A kind of pharmacy's advice of settlement risk checking method and device
CN109523394B (en) * 2018-10-23 2023-06-23 平安科技(深圳)有限公司 Risk detection method, device and storage medium based on data processing
CN109545312B (en) * 2018-10-23 2023-08-08 平安医疗健康管理股份有限公司 Drug store statement risk detection method and device

Similar Documents

Publication Publication Date Title
US20200294642A1 (en) Methods and systems for a pharmacological tracking and reporting platform
US20210202100A1 (en) Identification of medical coding inconsistencies
US8768724B2 (en) System and method for detecting drug fraud and abuse
US20180005331A1 (en) Database sharing system
US10796782B2 (en) System, method and apparatus to enhance privacy and enable broad sharing of bioinformatic data
Porterfield et al. Electronic prescribing: improving the efficiency and accuracy of prescribing in the ambulatory care setting
US8296164B2 (en) Pharmacy benefits management method and apparatus
US11030581B2 (en) Medical claims lead summary report generation
US20060271405A1 (en) Pharmaceutical care of patients and documentation system therefor
US20140278479A1 (en) Fraud detection in healthcare
US8725532B1 (en) Systems and methods for monitoring controlled substance distribution
US20060184524A1 (en) Method and system for automated data analysis, performance estimation and data model creation
US20160034578A1 (en) Querying medical claims data
US20090012816A1 (en) Systems and methods for clinical analysis integration services
US20200051679A1 (en) Methods and systems for a pharmacological tracking and reporting platform
US20180330060A1 (en) Systems and methods for transforming patient data by a healthcare information platform
Fleming et al. Prescribers and pharmacists requests for prescription monitoring program (PMP) data: does PMP structure matter?
WO2016122664A1 (en) Method and system for prescribing and determining risk associated with medications
Martin et al. Post-incarceration outcomes of a comprehensive statewide correctional MOUD program: a retrospective cohort study
US20140149139A1 (en) Method and system for providing access to health care information
US20140012600A1 (en) Method of preventing prescripton abuse
CN104008265A (en) Linking health care applications for information management
Hincapie et al. A quantitative and qualitative analysis of electronic prescribing incidents reported by community pharmacists
Wang et al. Cross‐sectional investigation of drug‐related problems among adults in a medical center outpatient clinic: application of virtual medicine records in the cloud
US11599962B2 (en) Methods and apparatus for processing medical data from a plurality of users

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15880554

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15880554

Country of ref document: EP

Kind code of ref document: A1