US20210057065A1 - Systems and methods for supplementing an electronic medical record - Google Patents

Abstract

Systems and methods are provided to supplement an electronic record with additional information related to the electronic record. The additional information is provided to the user of the electronic record as a banner, ribbon or pop-up window that overlays or “floats” over the electronic record. The user can interact with the ribbon to obtain the additional information or ignore the ribbon and the ribbon can be hidden automatically. The ribbon can be launched in response to the user accessing a specific screen or page of the electronic record. The ribbon can provide the user with the additional information that is related to the current screen or page of the electronic record. The additional information can include information obtained from other sources that is not part of the electronic record and calculations and metrics that are not part of the electronic record.

Description

CROSS-REFERENCE TO RELATED APPLICATION
• This application is a continuation of U.S. patent application Ser. No. 14/575,706, entitled “Systems and Methods for Supplementing an Electronic Medical Record,” filed on Dec. 18, 2014, which application is hereby expressly incorporated herein by reference in its entirety.
BACKGROUND
• The present application generally relates to systems and methods for providing an information overlay to an electronic medical record. More specifically, the present application relates to systems and methods for providing a healthcare provider with financial and patient safety metrics to supplement the patient's clinical electronic medical record.
• Each time a person, i.e., a patient, is examined or receives treatment from a healthcare provider, information regarding the patient's examination or treatment is entered and stored in a medical record for the patient. The medical record of the patient can be electronically stored by the healthcare provider as an electronic medical record (EMR) or an electronic health record (EHR). The EMR or EHR of a patient can include administrative clinical data associated with the patient such as medications, allergies, vital signs, medical history, provider/progress notes, problems, immunizations, laboratory data and/or test results and radiology reports and/or images.
• When a patient is receiving treatment from a healthcare provider, the healthcare provider can make decisions regarding the patient's treatment based on the EMR of the patient. The decisions made by the healthcare provider can have a direct impact on the costs associated with the patient's treatment. However, information regarding costs is not routinely provided within the patient's EMR. In addition, the patient's EMR does not provide the healthcare provider with any information on possible health risks to the patient associated with the cumulative effect of the medications, radiographic tests, and/or laboratory tests and procedures to which the patient has been subjected.
• Therefore, what is needed are systems and methods to provide a healthcare provider viewing a patient's EMR with information on utilization, expenditure and consequential risks associated with the patient's treatment by the healthcare provider.
SUMMARY
• The present application generally pertains to systems and methods for supplementing an electronic record with additional information related to the electronic record. The additional information can be obtained from sources that are not directly associated with the electronic record and can supplement the information contained in the electronic record. The additional information is provided to the user of the electronic record as a banner, ribbon or pop-up window that overlays or “floats” over the electronic record. The user can interact with the ribbon to obtain the additional information or ignore the ribbon, which can result in the ribbon automatically becoming hidden after the passage of a preselected time period with no user interaction. The additional information in the ribbon can be related to the current screen, page or state of the electronic record. The present application can determine the specific screen or page of the electronic record without directly accessing the electronic record by using an accessibility framework to determine the displayed elements of the electronic record.
• One advantage of the present application is that it provides a ribbon or banner of actionable intelligence that is displayed concurrently with the electronic record.
• Another advantage of the present application is that the provided ribbon or banner is specific to the subject of the electronic record.
• A further advantage of the present application is that the ribbon or banner can provide additional patient specific information to a patient's electronic medical record and can influence healthcare providers prospectively in the care of a patient.
• Other features and advantages of the present application will be apparent from the following more detailed description of the identified embodiments, taken in conjunction with the accompanying drawings which show, by way of example, the principles of the application.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a block diagram showing an embodiment of a computer system in a medical environment.
• FIG. 2 shows a page of an embodiment of an electronic medical record.
• FIG. 3 shows an embodiment of a ribbon window overlaying a page of an electronic medical record.
• FIG. 4 is a block diagram showing an embodiment of a user device.
• FIG. 5 shows an embodiment of the ribbon window displaying additional information for a medication frame.
• FIG. 6 shows an embodiment of a process for calculating a patient's risk of aClostridium difficileinfection.
• FIG. 7 shows an embodiment of a process for calculating the number of medications using an enzymatic pathway.
• FIG. 8 shows an embodiment of the ribbon window displaying additional information for a laboratory frame.
• FIG. 9 shows an embodiment of a process for calculating an amount of blood drawn from a patient.
• FIG. 10 shows an embodiment of the ribbon window displaying additional information for a radiation frame.
• FIG. 11 shows an embodiment of a process for calculating a patient's estimated radiation.
• Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like parts.
DETAILED DESCRIPTION
• FIG. 1 shows an embodiment of acomputer system10 for a medical or healthcare environment. Thesystem10 includes anEMR server12 for hosting or executing EMR (electronic medical record) software and/or applications, which can be implemented in software, hardware, firmware or any combination thereof. The EMR application, when implemented in software, can be stored and transported on any non-transitory computer-readable medium for use by or in connection with an instruction execution apparatus, e.g., a microprocessor, that can fetch and execute instructions. The EMR software can be used to input, save and output or display information associated with a patient's EMR or EHR. TheEMR server12 can be accessed over anetwork18 by one ormore user devices15 used by healthcare providers and/or departments of a medical or healthcare facility. In one embodiment, theuser devices15 can be “dummy” clients that emulate or virtualize the EMR software that is executed by theEMR server12. However, in other embodiments, theuser devices15 can execute some or all of the EMR software and/or application independent of theEMR server12.
• Theuser devices15 can be used by doctors, nurses, an admissions department, a radiology department, a laboratory and/or any other healthcare provider or department associated with the medical or healthcare facility. Eachuser device15 is communicatively coupled to thenetwork18 to exchange (i.e., send and receive) instructions, data and/or information related to a patient's EMR with theEMR server12. Eachuser device15 can be, but is not limited to, a desktop, laptop or tablet computer, a hand-held device, such as a cellular telephone (e.g., smartphone), or attachable, wearable, implantable or non-invasive computers or devices. Eachuser device15 can have one or more input devices to permit a user to enter instructions, data and/or information into theuser device15 and one or more output devices to permit the user to display instructions, data and/or information on theuser device15. In one embodiment, thenetwork18 can be the Internet, an Intranet, a local area network (LAN), a wide area network (WAN), or any other type of communication network using one or more communication protocols, e.g., transmission control protocol/Internet protocol (TCP/IP), to communicate over thenetwork18.
• TheEMR server12 can store patient data for each patient in apatient database22. The patient data for a patient can be extracted from the patient database by the EMR software and included in the patient's EMR that can be accessed by any of theuser devices15. The patient data may include one or more of the following: test results; doctor orders; documents; diagnosis; patient information; medications; allergies; patient chart; patient history; forms; immunizations; and billing information. The EMR software can display the patient's EMR on theuser device15. The patient's EMR displayed on theuser device15 may use one or more pages, screens or views to provide some or all of the patient's data to the healthcare provider.
• FIG. 2 shows an embodiment of a page of an EMR for a patient. TheEMR page25 can include some or all of the patient's data stored in thepatient database22 and can be displayed by theuser device15. TheEMR page25 may have numerous objects orselectable icons28 for selecting or obtaining more specific patient data from thepatient database22 stored by theEMR server12. Depending on the object oricon28 selected by the user, theEMR page25 may be changed or modified to correspond to the patient data associated with the user's request.
• In addition to viewing information in a patient's EMR, a healthcare provider can also input information into the displayedEMR page25 to add to or update the patient's data stored in thepatient database22. In addition, someuser devices15 may communicate with theEMR server12 to add information to a patient's data in thepatient database22 without using or going through the patient's EMR. When theEMR server12 receives information from auser device15 to update a patient's data in thepatient database22, whether the information is sent through anEMR page25 of the patient's EMR or the information is sent through a separate message, theEMR server12 can send a notification toother user devices15 and/or other systems that may need to be informed of the event that generated the message to theEMR server12. For example, information sent to theEMR server12 from the radiology department concerning the completion of an x-ray may result in theEMR server12 sending or forwarding a message to the medical facility's billing department to obtain payment for the completed x-ray. The EMRserver12 can include amessage router50 or interface engine to exchange, i.e., receive and distribute, messages and/or information among theuser devices15 or other systems of the medical facility.
• To facilitate the transfer or sharing of information and messages among the members or components of thesystem10 usingcomputer network18, an information sharing language or standard can be used by themessage router50, theuser devices15 and the other systems of the medical facility to define the content and structures of the information and/or messages to be communicated over thecomputer network18. In one embodiment, the information sharing standard can be Health Level 7 (HL7), but the information sharing standard or language can be any suitable standard or language to facilitate communication of clinical and administrative data among components in a medical facility.
• FIG. 3 shows a ribbon window providing additional patient information in conjunction with a page of a patient's EMR. A banner, ribbon or pop-upwindow100 can overlay or “float” over a portion of anEMR page25. Theribbon window100 can be generated by executing ribbon application or software52 (seeFIG. 4). Theribbon application52 can be installed and/or stored on eachuser device15. Theribbon application52 can be initiated or launched when the healthcare provider logs into or activates theuser device15. When a “ribbon trigger event” (e.g., navigation to an appropriate screen or page in the EMR) occurs, theribbon application52 can determine the current patient and launch theribbon window100. Theribbon application52 on theuser device15 can communicate with theribbon server55 to get or obtain the appropriate patient information and data to populate or include in theribbon window100. Theribbon window100 can be launched or appear over theEMR page25 in response to specific information, data or fields being displayed in theEMR page25, i.e., the “ribbon trigger event.” To determine the specific information, data or fields being displayed in theEMR page25, theribbon application52 can use or work with an accessibility framework to analyze and/or evaluate theEMR page25 and provide theribbon application52 with the appropriate details and information pertaining to theEMR page25. After receiving the information on theEMR page25, theribbon application52 can evaluate the EMR page information to determine if a “ribbon trigger event” occurred and theribbon window100 should be launched with theEMR page25. For example, theribbon application52 can launch theribbon window100 if theribbon application52 determines that specific patient information is being displayed in theEMR page25. Theribbon application52 can also select and configure the information to be provided in theribbon window100 based on the EMR page information. In alternate embodiments, theribbon window100 can be launched each time a user accesses anEMR page25 or selects anobject28 on anEMR page25 and/or the information provided or displayed in theribbon window100 can be predetermined regardless of the information provided in theEMR page25.
• The accessibility framework can enable applications, e.g., theribbon application52, to provide and consume programmatic information about user interfaces (UIs), e.g., EMR pages25, and provide programmatic access to all or most UI elements, e.g., objects28, on the desktop, e.g., auser device15. The accessibility framework can expose every portion of the UI to theribbon application52 as an automation element. The ribbon software orapplication52 can use the accessibility framework to “read” what the healthcare provider is seeing on the screen of theEMR page25 when he/she is using the EMR software executed by theEMR server12. Everything on the screen of theEMR page25 can be a readable “automation element” using the accessibility framework. The automation element can provide or expose common properties of the UI element the automation element represents. One type of property can be the textual content. The textual content can be a text stream that represents the contents of a text container along with format and style attributes. Another type of property can be the control type which defines basic appearance and functionality. The automation elements can also provide or expose control patterns that provide properties, e.g., an expand and collapse ability or a selection mechanism, specific to one or more control types. The accessibility framework can also provide information to theribbon software52 through events. Theribbon software52 can receive event notifications from the accessibility network concerning specific events that occur in theEMR page25. The event notifications can provide information on the automation element that triggered the event and other properties and control pattern information associated with the event. In one embodiment, the accessibility framework can be Microsoft UI Automation, but could be other types of accessibility frameworks in other embodiments.
• Theribbon application52 inspects the automation elements to determine, among other things, the healthcare provider or doctor viewing the EMR, the patient associated with the EMR, and the current screen of theEMR page25 being viewed by the healthcare provider. In one embodiment, theribbon application52 can determine the healthcare provider or doctor viewing the EMR, the patient associated with the EMR, and the current screen of theEMR page25 by reading the textual content properties of the automation elements. In another embodiment, theribbon application52 can determine the current screen of theEMR page25 by analyzing the control type and other properties of the automation elements to determine the configuration and arrangement of the elements displayed on the screen. By reviewing the automation elements from the accessibility framework, theribbon application52 can launch theribbon window100 on the appropriate EMR pages25, for the right patient and track how that particular healthcare provider uses theribbon window100.
• Once launched, theribbon window100 can remain displayed over theEMR page25 for a preselected time period. If the user does not interact with theribbon window100, such as by scrolling over a portion of theribbon window100, within the preselected time period, theribbon window100 can automatically close or be hidden leaving theentire EMR page25 displayed for the user. In one embodiment, the preselected time period can be in the range of 3 seconds to 20 seconds. If theribbon window100 is closed or hidden, theribbon window100 can be reopened by selecting an icon or link that is made available or presented to the user. However, if the user does interact with theribbon window100, theribbon window100 can remain open until closed by the user. In another embodiment, once the user interacts with theribbon window100, theribbon window100 can stay open until a preselected time period of user inactivity with theribbon window100 has elapsed. The preselected time period of user inactivity can be the same time period as the preselected time period for interaction or a different time period.
• Theribbon window100 can display additional information related to a patient's
• EMR in one or more frames, sections or fields. In one embodiment shown inFIG. 3, theribbon window100 can include apatient frame120, anobservation frame140, amedication frame160, alaboratory frame180, aradiation frame200 and atransfusions frame220. Thepatient frame120 can provide the user with the name, age and sex of the patient. The healthcare provider or user can then use the information in thepatient frame120 to verify that the patient and patient information in theribbon window100 corresponds to the patient and patient information in theEMR page25. Theobservation frame140 can provide the user with information on the time remaining in an observation period for the patient and information on the patient's length of stay (LOS) in the medical facility. Themedication frame160 can provide the user with information on the number of daily medications for the patient, the cost of the daily medications for the patient, the patient's relative risk of aClostridium difficile(C. diff) infection, the patient's risk of falling and the enzymatic pathways related to medication metabolism. Thelaboratory frame180 can provide the user with information on the estimated blood loss (EBL) of the patient from laboratory procedures, the patient's medical facility or hospital acquired anemia (HAA) risk, the number of laboratory procedures for the patient and the cost of the laboratory procedures for the patient. Theradiation frame200 can provide the user with an estimate of the amount of radiation the patient has received since being admitted to the medical facility, an estimate on the amount of radiation the patient has received this year and the associated cost of the radiation procedures since the patient was admitted to the medical facility. Thetransfusions frame220 can provide the user with information on how many units of packed red blood cells (pRBCs) the patient has received, how many units of fresh frozen plasma (FFP) the patient has received, how many units of platelets the patient has received and the associated cost of the transfusions. In one embodiment, the frames presented to the user and/or the contents of the frames within theribbon window100 can be dependent on user interaction with theribbon window100. In another embodiment, the frames or sections included in theribbon window100 can be dependent on the patient information being displayed in theEMR page25 and/or on the availability of additional patient data for a particular frame or section.
• When theribbon window100 is launched, theribbon application52 can populate the sections or frames of theribbon window100 with clinical data and metrics, financial data and/or other appropriate additional patient information obtained from the ribbon sever55. Theribbon server55 can be connected over anetwork42 tooutside information sources44, e.g., published research studies, Medicare and Medicaid databases, wholesale acquisition cost (WAC) and average wholesale price (AWP) databases and medical reference databases and manuals, to obtain or generate some of the information included in theribbon window100. In one embodiment, thenetwork42 can be the Internet, an Intranet, a local area network (LAN), a wide area network (WAN), or any other type of communication network using one or more communication protocols, e.g., transmission control protocol/Internet protocol (TCP/IP), to communicate over thenetwork42. Further, whilenetwork18 andnetwork42 are shown as separate networks inFIG. 1,network18 andnetwork42 can be combined or can be the same network in another embodiment.
• Theribbon server55 can also be connected to information sources that are internal to or within the medical or healthcare facility to obtain or generate some of the information included in theribbon window100. For example, theribbon server55 can access a healthcare facility's financial systems ordatabases45, e.g., a drug acquisition cost database, a pharmacy database, a radiology database, a supply chain database and/or a cost accounting system, overnetwork18 to obtain or generate some of the information included in theribbon window100. In one embodiment, the healthcare facility's financial systems ordatabases45 can be stored or included inEMR server12.
• FIG. 4 shows an embodiment of theuser device15. Theuser device15 includes theribbon application52, which can be implemented in software, hardware, firmware or any combination thereof. In theuser device15 shown inFIG. 4, theribbon application52 can be implemented in software and stored inmemory66. Theribbon application52, when implemented in software, can be stored and transported on any non-transitory computer-readable medium for use by or in connection with an instruction execution apparatus, e.g., a microprocessor, that can fetch and execute instructions. In the context of this application, a “computer-readable medium” can be any device, system or technique that can contain or store a computer program for use by or in connection with an instruction execution apparatus.
• Theuser device15 shown byFIG. 4 includes at least oneconventional processing element71, such as a digital signal processor (DSP) or a central processing unit (CPU), that communicates to and drives the other elements within theuser device15 via alocal interface74, which can include at least one bus. Furthermore, aninput interface77, for example, a keyboard or a mouse, can be used to input data from a user of theuser device15, and anoutput interface83, for example, a printer, monitor, liquid crystal display (LCD), or other display apparatus, can be used to output data to the user of theuser device15. Anetwork interface85, such as at least one modem, may be used to exchange data with thenetwork18.
• Theribbon application52 can use information stored in acentral ribbon database68 when preparing and assembling the information for theribbon window100. Theribbon application52 can request the information for theribbon window100 from theribbon server55 which can then access the ribbon database68 (seeFIG. 1) over thenetwork42 to obtain the appropriate information for theribbon window100. In another embodiment, theribbon database68 can be stored in memory of theribbon server55.
• Theribbon database68 can be implemented in software, hardware, firmware or any combination thereof on either theribbon server55 or on a separate computer or hardware device as shown inFIG. 1. In one embodiment, theribbon database68 can be implemented in software and stored in a memory device. Theribbon database68, when implemented in software, can be stored and transported on any non-transitory computer-readable medium for use by or in connection with an instruction execution apparatus, e.g., a microprocessor, that can fetch and execute instructions. In the context of this application, a “computer-readable medium” can be any device, system or technique that can contain or store a computer program for use by or in connection with an instruction execution apparatus.
• Theribbon server55 and the ribbon database computer can each include at least one conventional processing element, such as a digital signal processor (DSP) or a central processing unit (CPU), that communicates to and drives the other elements within theribbon server55 or the ribbon database computer via a local interface, which can include at least one bus. Furthermore, an input interface, for example, a keyboard or a mouse, can be used to input data from a user of theribbon server55 or the ribbon database computer and an output interface, for example, a printer, monitor, liquid crystal display (LCD), or other display apparatus, can be used to output data to the user of theribbon server55 or the ribbon database computer. A network interface(s), such as at least one modem, may be used by theribbon server55 or the ribbon database computer to exchange data with thenetwork18 and/ornetwork42.
• Theribbon database68 can include patient data and information stored in a patient database63 (seeFIG. 1) and information stored in a medical information database90 (seeFIG. 1). The information inmedical information database90 can include information relating to published research studies, Medicare and Medicaid databases, wholesale acquisition cost (WAC) databases and medical reference databases and manuals that was obtained from information sources44 (seeFIG. 1) not associated withcomputer network18. The information inmedical information database90 can also include information obtained from the healthcare facility's financial systems ordatabases45. Thepatient database63 can include, for each patient, patient data that was obtained from thenetwork18 and/orEMR server12 and/or patient data that was obtained from other sources not connected to network18. In one embodiment, the patient data from other sources can be obtained overnetwork42. Theribbon database68 can also include computations, categorizations, and/or derivations of data from either or both of thepatient database63 and themedical information database90.
• Information for thepatient database63 can be obtained from messages received over thenetwork18 by theribbon server55. Theribbon server55 can be copied or included in communications or messages between theuser devices15 and theEMR server12 over thenetwork18. A message listener in theribbon server55 can be used to monitor the communications over thenetwork18 to obtain information for thepatient database63. When a message or communication is received by the message listener and theribbon server55, the message can be parsed by theribbon server55 into one or more individual segments. The segments can then be reviewed to determine if the segments have information related or relevant to information to be provided in theribbon window100. The relevant information from the segments of the parsed message can be saved in the patient database63 (based the patient who was the subject of the message) and the information and/or segments that are not used or required for theribbon window100 can be discarded or ignored. Since thepatient database63 does not store all of the information obtained from a parsed message, the patient data inpatient database63 can be different from the patient data inpatient database22. In addition, thepatient database63 can include additional patient data from other sources that are separate from or not connected to thenetwork18.
• As previously discussed, theribbon application52 can receive information from theaccessibility framework92 to determine when to launch theribbon window100 with theEMR page25. Theaccessibility framework92 can include an application programming interface (API) that can communicate directly with the API on theuser device15.
• Theribbon window100 can provide the healthcare provider with a broader patient “context” than can be found in the patient's EMR by enabling the healthcare provider to access additional information that is related to or relevant to the patient. For example, theobservation frame120 can provide the healthcare provider with information on how long the patient has been under observation or, alternatively, how much time is remaining in insurance defined observation periods. Information on the amount of time the patient has been under observation is important to the healthcare provider because if the patient is under observation for greater than a specified observation period, e.g., 48 hours, the patient's health insurance may not reimburse the healthcare provider and/or the medical facility for any costs incurred after the expiration of the observation period. The non-reimbursed costs may then have to be absorbed by the healthcare provider and/or medical facility.
• Other frames of theribbon window100 can provide additional information and/or detail when the healthcare provider selects or interacts with the frames. Theribbon window100 can transform into an expanded frame window to provide additional information for a particular frame. In one embodiment, themedication frame160, thelaboratory frame180 and theradiation frame200 can all provide additional information and details when selected by the healthcare provider.
• FIG. 5 shows an embodiment of the ribbon window displaying additional information for a medication frame. Themedication frame160 can include one or more additional frames or sections to provide additional or supplemental information on the medications being provided to the patient. The displaying of the additional frames and/or additional information in themedication frame160 can be dependent on the information available in theribbon database68. In other words, theribbon application52 may not display particular information or a particular frame in themedication frame160 if there is no corresponding information from theribbon database68.
• A number ofmedications frame162 can provide the healthcare provider with a graph showing the number of medications administered to the patient over the patient's length of stay (LOS) at the medical facility. Amedication cost frame164 can provide the healthcare provider with a total cost of medications administered to the patient and the cost of the medications administered orally and intravenously. Theribbon database68 can calculate the medication costs by reviewing the list of medications for the patient from thepatient database63, correlating the corresponding cost information from themedical information database90 to the identified medications and adding the individual costs. In one embodiment, the medication cost information in themedical information database90 can be obtained from a wholesale acquisition cost database (information source44) over thenetwork42. In another embodiment, the medication cost information in themedical information database90 can include cost information obtained from the healthcare facility's financial systems ordatabases45 such as a pharmacy database and/or a supply chain database. Aprescription cost frame166 can provide the healthcare provider with the cost of the individual prescriptions for the patient. The cost of the individual prescriptions is determined similar to the cost of the medications. Analternative medication frame168 can provide the healthcare provider with recommendations on alternative medications that have a lower cost and show the healthcare provider the difference in cost. Theribbon database68 can review the patient's medications and information frommedical information database90 to determine if there is a similar lower cost medication available to treat the patient's condition instead of the current medication and then provide the lower cost medication information to theribbon application52 for display in theribbon window100. For example, an oral medication may be a lower cost substitute for the intravenous form of the medication if the patient can accept an oral medication.
• A CDIrelative risk frame170 can provide the healthcare provider with information on the patient's real-time risk for potentially acquiring aClostridium difficileinfection (CDI) based on the medications received by the patient. TheCDI risk frame170 can also provide a CDI risk incorporating the antibiotics (ABXs) taken by the patient and the proton pump inhibitors (PPIs) or acid blockers taken by the patient. If the healthcare provider requires more information, a medication-specificCDI risk frame172 can be accessed from theCDI risk frame170 by interacting with theCDI risk frame170. A medication-specificCDI risk frame172 can be used to provide the CDI risk for each of the medications taken by the patient.
• FIG. 6 shows an embodiment of a process for calculating a patient's relative risk of a CDI. The process begins with theribbon database68 identifying the patient's medications that are classified as an ABX or as a PPI (step602). Some examples of ABXs can include piperacillin, levofloxacin and clarithromycin. Some examples of PPIs can include pantoprazole and esomeprazole. To identify the patient's ABX and PPI medications, theribbon database68 accesses and reviews the patient data from thepatient database63 and medication information from themedical information database90 to determine which medications are classified as an ABX or a PPI. Thepatient database63 can include information on the patient's medications obtained from messages from theEMR server12.
• Once theribbon database68 has identified the ABX and PPI medications, theribbon database68 then determines the ordered dosage of each of the scheduled medications (step604). Theribbon database68 can obtain the dosage of the medication directly from the patient data if the patient was provided a dose of only that medication. However, if the dosage of a medication to a patient includes multiple medications, such as from a combination medication formed from multiple medications, theribbon database68 can analyze the dosage of the combination medication to determine the dosage of the individual medications. Theribbon database68 can determine the dosage of each of the individual medications in the combination medication, or theribbon database68 can determine the dosage of only the ABX or PPI medications in the combination medications. Theribbon database68 can first determine the dosage of the medications as a weight or volume, e.g., mg or ml, and then convert the weight or volume dosage to a unit dosage that reflects the dosage amount relative to a manufacturer recommended dose (defined daily dose (DDD)). For example, a half dose of a medication may be 0.5 units, a recommended dose of the medication may be 1.0 units and a double dose of the medication may be 2.0 units. In one embodiment, theribbon database68 can adjust the risk of CDI from a medication based on the defined daily dose of the medication administered to the patient. Theribbon database68 can then use information from themedical information database90 to determine the adjusted currentClostridium difficilerelative risk at a given point in time.
• Once theribbon database68 has calculated the dosage of each ABX or PPI medication, theribbon database68 then calculates or determines the CDI risk to the patient for each of the ABX or PPI medications (step606). Theribbon database68 can calculate the patient's adjusted CDI relative risk for each ABX or PPI medication by taking the medication type and the dosage of the medication and generating a risk value for the patient using formulas and/or medical research (possibly stored in and obtained from medical information database90) that correlate CDI risk to the dosage amount for that medication. The relative risk of CDI can be the multiple of the individual dose-adjusted risks for each antibiotic the patient is currently receiving and a multiple of the risk associated with a proton pump inhibitor, if the patient is currently receiving that class of medication. The adjusted CDI relative risk adjusts in real-time as the medication profile changes. A CDI risk profile can be provided for a given medication profile rather than for a patient profile as the patient profile does not attempt to adjust for demographic or prior factors that affect CDI. The medication profile can be a more important metric in its value in promoting judicious antibiotic and PPI stewardship. In one embodiment, theribbon database68 can calculate the adjusted CDI risk for each medication under the assumption that a recommended dose (or ordered dose) of medication was provided for the patient. After calculating the initial CDI risk for each medication, theribbon database68 can adjust, i.e., increase or decrease, the patient's CDI risk based on whether the patient actually received less than or greater than the recommended dose. For example, a patient receiving double the recommended dose of a medication may result in a doubling of the patient's adjusted CDI risk for that medication.
• Theribbon database68 can then take the individual CDI risks from each of the medications and determine the patient's total CDI risk (step608). The patient's total CDI risk can be obtained by multiplying the composite adjusted PPI CDI risk and the composite adjusted ABX CDI risk. The composite ABX CDI risk can be determined by multiplying the individual adjusted ABX CDI risks. Theribbon database68 can then provide the patient's total CDI risk to theribbon application52 for display in the ribbon window100 (step610).
• Apathways frame174 can provide the healthcare provider with information on the number of medications being metabolized in particular enzymatic or metabolic pathways. If the healthcare provider requires more information, anindividual pathway frame176 can be accessed from thepathways frame174 by interacting with thepathways frame174. Theindividual pathway frame176 can be used to provide a list of the medications using the particular pathway and some or all of the medication's properties (inducer, substrate or inhibitor) with respect to that pathway.
• FIG. 7 shows an embodiment of a process for calculating the number of medications using an enzymatic pathway. The process begins with theribbon database68 identifying the patient's medications (step702). To identify the patient's medications, theribbon database68 accesses and reviews the patient data from thepatient database63. Thepatient database63 can include information on the patient's medications obtained from messages from theEMR server12. Next, theribbon database68 determines the enzymatic pathway for each of the medications (step704) by reference to themedical information database90. Some examples of enzymatic pathways can include the cytochrome P450 (CYP) superfamily of enzymes and more specifically the CYP1A2, CYP2C9, CYP2C19, CYP2D6, CYP3A4, and CYP3A5 enzymes. Once the enzymatic pathway for the medications is determined, if applicable, theribbon database68 then determines the medication's properties with relation to the enzymatic pathway, i.e., is the medication is an inhibitor, which decreases or blocks metabolic activity, an inducer, which increases metabolic activity, or a substrate, which has consumptive activity on the available enzyme. Theribbon database68 can use information from themedical information database90 to determine the medication's enzymatic pathway and properties with respect to the enzymatic pathway. After determining the enzymatic pathway for each of the applicable medications, theribbon database68 can then add the number of medications using each enzymatic path to get a total number of medications using each enzymatic pathway (step706). Theribbon database68 can then provide the number of medications using each enzymatic pathway to theribbon application52 for display in the ribbon window100 (step708). Theribbon application52 can also display the medications using an enzymatic pathway (as determined and provided to theribbon application52 by the ribbon database68) and the medications' properties with respect to that pathway (as determined and provided to theribbon application52 by the ribbon database68) inindividual pathway frame176.
• The pathway information can be useful to the healthcare provider to predict or prevent adverse drug reactions in the medical facility setting. An enzymatic pathway has a limited capacity to metabolize medications and if that capacity is altered by an inhibitor or an inducer medication or overloaded by too many medications using the enzymatic pathway, the patient may have an adverse drug reaction and/or the effectiveness of an administered medication may decline and impact the treatment of the patient as manifested by potential side effects of the medications. The healthcare provider can use the information regarding the pathway usage from thepathways frame174 andindividual pathway frame176 to determine if a particular medication may be impacting the effectiveness of the patient's treatment or may be in conflict with another medication. In one embodiment, theribbon database68 can also use information on the patient's pharmacogenomic profile (PGx) from thepatient database63, e.g., the patient is a slow metabolizer along particular genetic pathways, to generate information displayed byribbon application52 to assist the healthcare provider in determining whether the patient is on the proper medication regimen.
• FIG. 8 shows an embodiment of the ribbon window displaying additional information for a laboratory frame. Thelaboratory frame180 can include one or more additional frames or sections to provide additional or supplemental information on the laboratory procedures or tests being performed on the patient. The displaying of the additional frames and/or additional information in thelaboratory frame180 can be dependent on the information available in theribbon database68. In other words, theribbon application52 may not display particular information or a particular frame in thelaboratory frame180 if there is no corresponding information from theribbon database68.
• A number oflaboratories frame182 can provide the healthcare provider with a graph showing the number of laboratory procedures performed on the patient during the patient's LOS at the medical facility. A number ofduplicate procedures frame184 can provide the healthcare provider with information on the number of times the same laboratory procedure(s) have been performed on a patient. If the healthcare provider requires more information, a labtest library frame186 can be accessed from theduplicate procedures frame184 by interacting with theduplicate procedures frame184. The labtest library frame186 can provide a list of all laboratory procedures performed on the patient and the dates the laboratory procedures were performed. In one embodiment as shown inFIG. 8, the dates of the most recent three laboratory procedures can be provided.
• Alaboratory cost frame188 can provide the healthcare provider with a total cost of laboratory procedures performed on the patient, the cost of laboratory procedures performed on the patient for the current day and the cost associated with the performance of duplicate laboratory procedures on the patient. Theribbon database68 can calculate the laboratory costs by reviewing the list of laboratory procedures for the patient from thepatient database63, correlating the corresponding cost information from themedical information database90 to the identified laboratory procedures and adding the individual costs. In one embodiment, the laboratory cost information inmedical information database90 can be obtained from a Medicare allowable charges database (information source44) over thenetwork42. In another embodiment, the laboratory cost information in themedical information database90 can include cost information obtained from the healthcare facility's financial systems ordatabases45. A laboratoryprocedure cost frame190 can provide the healthcare provider with the total cost of the individual laboratory procedures performed on the patient. The total cost of the individual laboratory procedures is determined similar to the cost of all of the laboratory procedures. If the healthcare provider requires more information, the labtest library frame186 can also be accessed from the laboratoryprocedure cost frame190 by interacting with the laboratoryprocedure cost frame190. As previously described, the labtest library frame186 can provide a list of all available laboratory procedures performed on the patient and the dates the laboratory procedures were performed.
• Ananemia risk frame192 can provide the healthcare provider with information on the patient's risk of medical facility acquired anemia due to laboratory procedures or blood draws and an estimated blood loss (EBL) from phlebotomy procedures. The patient's risk of medical facility acquired anemia is calculated by theribbon database68 using the estimate of the amount of blood drawn from the patient. If the healthcare provider requires more information, an amount of blood drawnframe194 can be accessed from theanemia risk frame192 by interacting with theanemia risk frame192. The amount of blood drawnframe194 can provide a graph of the total EBL or estimated blood drawn from the patient during the patient's LOS at the medical facility.
• FIG. 9 shows an embodiment of a process for calculating an EBL or amount or volume of blood drawn from a patient. The process begins with theribbon database68 identifying the laboratory procedures performed on the patient (step902). Some examples of laboratory procedures can include a CBC (complete blood count) test, a CMP (comprehensive metabolic panel) test, a Hep (hepatitis) panel, a cardiac or heart enzyme study, a B12 test, a folate or folic acid test, and a blood culture test. To identify the patient's ordered and executed laboratory procedures, theribbon database68 accesses and reviews the patient data from thepatient database63. Thepatient database63 can include laboratory procedure information obtained from messages from theEMR server12.
• Once theribbon database68 has the identified laboratory procedures, theribbon database68 then determines an estimated blood draw amount for each identified procedure (step904). Theribbon database68 can obtain an estimated blood draw amount for each procedure from themedical information database90. The estimated blood draw amount or volume for each procedure stored in themedical information database90 can be based on medical research and can be determined as an average blood draw amount or volume for the laboratory procedure order or request. In one embodiment, theribbon database68 can calculate the average blood draw amount for a laboratory procedure based on information regarding the particular sample tube used for the procedure, if available, and/or information on the medical facility performing the procedure, if available. Theribbon database68 can then add the estimated blood draw amount for each identified laboratory procedure to obtain a total estimated blood draw amount or volume (step906).
• However, a medical facility may perform multiple laboratory procedures on one blood sample drawn from the patient. To account for this possibility and provide a more accurate estimate of the blood draw amount for the patient, theribbon database68 can adjust the total estimated blood draw amount or volume (step908). When determining whether to adjust the total estimated amount of blood draw, theribbon database68 first looks at the laboratory procedures performed on the patient and identifies procedures that cannot be adjusted because the laboratory test requires a fresh blood sample, e.g., a CBC test or a heart enzyme test, rather than being acquired from a previous blood draw. Once theribbon database68 identifies the procedures that cannot be adjusted (or assumed to be a zero volume laboratory), theribbon database68 reviews the executed laboratory procedures to determine if some laboratory procedures could have used a single blood sample. If more than one of the laboratory procedures has results provided within a predetermined time period, e.g., 24 hours, and the laboratory procedure is assigned a tube type (i.e., color) that has already been drawn and utilized by the phlebotomy department, theribbon database68 can assume that those multiple procedures were performed from a single blood sample. Theribbon database68 can group the procedures and lower the total estimated blood draw amount by the corresponding estimated blood draw amount for all of the procedures except for the procedure with the largest estimated blood draw amount. In one embodiment, theribbon database68 can estimate the total blood draw amount, for a cluster of laboratory procedures, as being the volume of one tube, if the non-excluded procedures over a 24 hour period can be drawn from the same tube. Theribbon database68 can then provide the adjusted estimated total blood draw amount to theribbon application52 for display in the ribbon window100 (step910).
• The adjusted estimated total blood draw amount from a patient can then be stored in thepatient database63 for use by theribbon database68 to determine the patient's real time medical facility acquired anemia risk as provided inframe192. Theribbon database68 can calculate the patient's medical facility acquired anemia risk by taking the adjusted estimated total blood draw amount of the patient from thepatient database63 and using the adjusted estimated total blood draw amount to generate a risk value for the patient using formulas and/or medical research (possibly stored in medical information database90) that correlate medical facility acquired anemia risk to the adjusted estimated total blood draw amount. In one embodiment, for every 50 mL of blood drawn, the patient's risk of medical facility acquired anemia can be an incremental 15%. In another embodiment, theribbon database68 can use the stored adjusted estimated total blood draw amount to calculate a new adjusted estimated total blood draw amount if the patient receives additional laboratory procedures.
• FIG. 10 shows an embodiment of the ribbon window displaying additional information for a radiation frame. Theradiation frame200 can include one or more additional frames or sections to provide additional or supplemental information on radiation treatments or procedures being provided to the patient. The displaying of the additional frames and/or additional information in theradiation frame200 can be dependent on the information available in theribbon database68. In other words, theribbon application52 may not display particular information or a particular frame in theradiation frame200 if there is no corresponding information from theribbon database68.
• Aradiology cost frame202 can provide the healthcare provider with a total cost of radiology procedures performed on the patient, the cost of radiology procedures performed on the patient while the patient has been admitted to the medical facility and the cost of radiology procedures performed on the patient for the current day. Theribbon database68 calculates the radiology procedure costs by reviewing the list of radiology procedures for the patient in thepatient database63, correlating the corresponding cost information from themedical information database90 to the identified radiology procedures and then adding the individual costs. In one embodiment, the radiology cost information inmedical information database90 can be obtained from a Medicare allowable charges database (information source44) over thenetwork42. In another embodiment, the radiology cost information in themedical information database90 can include information obtained from the healthcare facility's financial systems ordatabases45 such as a radiology database or system.
• A radiologyprocedure cost frame204 can provide the healthcare provider with the total cost of the individual radiology procedures performed on the patient. The total cost of the individual radiology procedures is determined similar to the cost of all of the radiology procedures. If the healthcare provider requires more information, the radiologytest library frame206 can be accessed from the radiologyprocedure cost frame204. The radiologytest library frame206 can provide a list of all radiology procedures performed on the patient and the dates the radiology procedures were performed. In one embodiment as shown inFIG. 10, the dates of the most recent three radiology procedures can be provided.
• An estimatedradiation frame208 can provide the healthcare provider with an estimated effective dose of radiation in milliSieverts (mSV), due to medical imaging, received by the patient for his/her life, an estimate of the effective dose of radiation received by the patient while the patient has been admitted to the medical facility and an estimate of the effective dose of radiation received by the patient for the calendar year, i.e., a year-to-date (YTD) total. If the healthcare provider requires more information, theradiation breakdown frame210 can be accessed from the estimatedradiation frame208 by interacting with the estimatedradiation frame208. Theradiation breakdown frame210 can provide a list of all radiology procedures performed on the patient and an estimate of the total effective dose of radiation received for the radiology procedures. Acancer risk frame212 can provide the healthcare provider with a graph and information on the patient's absolute risk of cancer based on the total effective dose of radiation received by the patient over his/her life.
• FIG. 11 shows an embodiment of a process for calculating a patient's estimated effective dose of radiation from medical imaging and other procedures. The process begins with theribbon database68 identifying the radiology procedures received by the patient (step1102). Some examples of radiology procedures can include x-rays, CT (computed tomography) scans and nuclear medicine scans. To identify the patient's ordered and executed radiology procedures, theribbon database68 accesses and reviews the patient data from thepatient database63. Thepatient database63 can include radiology procedure information obtained from messages from theEMR server12 and/or obtained from other medical facilities, systems and/or databases. If an estimated total effective dose of radiation is being provided for a time period less than the patient's life, e.g., a daily total or a LOS total, then theribbon database68 filters out the radiology procedures not in the desired time period. Once theribbon database68 has the identified radiology procedures, theribbon database68 then determines an estimated effective dose of radiation for each identified procedure (step1104). Theribbon database68 can obtain an estimated effective dose of radiation for each procedure from themedical information database90. The estimated effective dose of radiation for each procedure can be based on medical research and can be determined as an average effective dose of radiation for the procedure based on multiple imaging estimates being taken from multiple facilities and multiple devices. Theribbon database68 can then add the estimated effective dose of radiation for each identified radiology procedure to obtain a total estimated effective dose of radiation (step1106). Theribbon database68 can then provide the total estimated effective dose of radiation to theribbon application52 for display in the ribbon window100 (step1108).
• The estimated total effective dose of radiation received by a patient can then be stored in thepatient database63 for use by theribbon database68 to determine the patient's real time cancer risk as provided inframe212. Theribbon database68 can calculate the patient's cancer risk by taking the total estimated effective dose of radiation received by the patient from thepatient database63 and using the total estimated effective dose of radiation to generate a risk value for the patient using formulas and/or medical research (possibly stored in medical information database90) that correlate cancer risk to the total estimated effective dose of radiation. In one embodiment, the patient's risk of cancer can linearly increase by 1% for every100 mSV of radiation (effective dose). In another embodiment, theribbon database68 can use the stored estimated total effective dose of radiation to calculate a new estimated total effective dose of radiation if the patient has received additional radiology procedures.
• In one embodiment of the present application, theribbon database68 can pre-calculate, i.e., calculate before being requested by theribbon application52, one or more of the patient's risks or metrics, e.g., enzymatic pathway information, EBL or effective dose of radiation, based on information stored in thepatient database63 and themedical information database90. The pre-calculated risks or metrics for the patient can be stored in either theribbon database68 or thepatient database63 for immediate access and use by theribbon application52. In other embodiments, theribbon database68 can dynamically calculate the patient's risks and metrics when the information is required or requested by theribbon application52 for theribbon window100.
• Embodiments within the scope of the present application include program products with machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Machine-readable media can be any available non-transitory media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. When information is transferred or provided over a network or another communication connection (either hardwired, wireless, or a combination of hardwired or wireless) to a machine, the machine properly views the connection as a machine-readable medium. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machine to perform a certain function or group of functions.
• Although the figures herein may show a specific order of method steps, the order of the steps may differ from what is depicted. Also, two or more steps may be performed concurrently or with partial concurrence. Variations in step performance can depend on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the application. Software implementations could be accomplished with standard programming techniques, with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps.
• It should be understood that the identified embodiments are offered by way of example only. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present application. Accordingly, the present application is not limited to a particular embodiment, but extends to various modifications that nevertheless fall within the scope of the application. It should also be understood that the phraseology and terminology employed herein is for the purpose of description only and should not be regarded as limiting.

Claims (20)

What is claimed is:

1. A system to provide additional information to supplement an electronic medical record of a patient, the system comprising:

a first server computer comprising a first patient database, the first patient database including first patient information associated with a plurality of patients;

a second server computer comprising a second patient database, the second patient database including second patient information associated with the plurality of patients and medical information related to the first patient information, the second patient information being different from the first patient information;

at least one user device in communication with the first server computer, the at least one user device having an output interface to display a page of an electronic medical record provided to the at least one user device by an EMR application executed by the first server computer, the page of the electronic medical record being associated with a patient of the plurality of patients and including at least a portion of the first patient information associated with the patient from the first patient database; and

each user device comprising a processor and a ribbon application executable by the processor, the ribbon application, when executed by the processor, is configured to:

determine information about at least one displayed object from the displayed page of the electronic medical record;

identify the displayed page of the electronic medical record on the user device based on the determined information about the at least one displayed object;

identify the patient associated with the displayed page of the electronic medical record based on the determined information about the at least one displayed object;

obtain at least a portion of the second patient information associated with the identified patient from the second patient database in response to the identification of the displayed page of the electronic medical record and the identification of the patient associated with the displayed page of the electronic medical record; and

display a window in the output interface of the at least one user device, wherein the displayed window overlays a portion of the displayed page of the electronic medical record and includes the at least a portion of the second patient information associated with the patient from the second patient database.

2. The system ofclaim 1, wherein the ribbon application is configured to access a plurality of elements associated with the at least one displayed object, wherein the plurality of elements are generated from an additional application separate from the EMR application, each element of the plurality of elements including information about one or more properties of a corresponding displayed object.

3. The system ofclaim 2, wherein the additional application comprises an accessibility framework executed by the processor of the at least one user device and the accessibility framework is configured to identify the plurality of elements associated with the at least one displayed object.

4. The system ofclaim 2, wherein the ribbon application is configured to review text information in the plurality of elements, wherein the text information is obtained from the one or more properties of the at least one displayed object.

5. The system ofclaim 2, wherein the ribbon application is configured to detect an occurrence of a trigger event associated with the displayed page of the electronic medical record by analyzing the plurality of elements to identify the trigger event.

6. The system ofclaim 2, wherein the one or more properties include a textual content property and a control type property, wherein the textual content property represents a text stream of a text container in the corresponding displayed object and the control type property defines an appearance and functionality of the corresponding displayed object.

7. The system ofclaim 1, wherein the ribbon application is configured to hide the displayed window in response to a predetermined time period elapsing without a user interaction with the launched window.

8. The system ofclaim 1, wherein the second patient database is configured to calculate at least one metric for the patient using the second patient information associated with the patient and the medical information, the calculated at least one metric is stored in the second patient database.

9. The system ofclaim 8, wherein the calculated at least one metric includes one or more of an estimated blood loss for the patient, an estimated effective dose of radiation received by the patient, a risk for aClostridium difficileinfection, a risk of anemia from blood loss or a risk of cancer from received radiation.

10. The system ofclaim 8, wherein the at least a portion of the second patient information associated with the patient included in the displayed window includes the at least one metric.

11. The system ofclaim 1, wherein the displayed window includes one or more frames, the one or more frames displaying the at least a portion of the second patient information associated with the patient included in the displayed window.

12. The system ofclaim 11, wherein the one or more frames include one or more of a patient frame with information on the patient, an observation frame with information on a length of stay at a medical facility by the patient, a medication frame with information on medications received by the patient, a laboratory frame with information on laboratory procedures performed on the patient, a radiation frame with information on radiation received by the patient or a transfusions frame with information on transfusions received by the patient.

13. The system ofclaim 12, wherein the ribbon application is configured to transform the displayed window in response to a user interaction with one of the medication frame, the laboratory frame or the radiation frame, the transformed displayed window includes an additional portion of the second patient information associated with the patient from the second patient database, the additional portion of the second patient information is selected by the ribbon application in response to the identified patient and the frame interacted with by the user.

14. The system ofclaim 1, wherein the ribbon application is configured to detect an occurrence of a trigger event associated with the displayed page of the electronic medical record, and wherein the display of the window in the output interface occurs in response to the trigger event.

15. The system ofclaim 14, wherein the trigger event includes one or more of a predetermined page of the electronic medical record being displayed or a predetermined field being included in the displayed page of the electronic medical record.

16. A system to provide additional information to supplement an electronic medical record of a patient, the system comprising:

a first server computer comprising a first patient database, the first patient database including first patient information associated with a plurality of patients;

a second server computer comprising a second patient database, the second patient database including second patient information associated with the plurality of patients and medical information related to the first patient information, the second patient information being different from the first patient information;

at least one user device in communication with the first server computer, the at least one user device having an output interface to display a page of an electronic medical record provided to the at least one user device by an EMR application executed by the first server computer, the page of the electronic medical record being associated with a patient of the plurality of patients and including at least a portion of the first patient information associated with the patient from the first patient database; and

each user device comprising a processor and a ribbon application executable by the processor, the ribbon application, when executed by the processor, is configured to:

determine a healthcare provider viewing the displayed page of the electronic medical record;

determine information about at least one displayed object from the displayed page of the electronic medical record;

identify the displayed page of the electronic medical record on the user device and the patient associated with the displayed page of the electronic medical record based on the determined information about the at least one displayed object;

obtain at least a portion of the second patient information associated with the identified patient from the second patient database based on the healthcare provider, the identification of the displayed page of the electronic medical record, and the identification of the patient associated with the displayed page of the electronic medical record; and

provide a notification to the healthcare provider, wherein the notification includes the at least a portion of the second patient information associated with the patient from the second patient database.

17. The system ofclaim 16, wherein the at least a portion of the second patient information includes a recommendation for the healthcare provider.

18. The system ofclaim 17, wherein the recommendation for the healthcare provider includes a recommendation for a lower cost medication for the patient.

19. The system ofclaim 16, wherein the at least a portion of the second patient information includes cost information on one or more of medications or laboratory procedures.

20. The system ofclaim 16, wherein the at least a portion of the second patient information includes a risk level for the patent, wherein the risk level is calculated by the second database.

Images