Not applicable.
In recent years, healthcare service providers have been making the transition from manual paper-based medical records and scheduling to an electronic format. Commercially available computer software, such as PowerChart®, PowerChart Office®, and other Cerner Millennium® solutions marketed by the Cerner Corporation of Kansas City, Mo. have advanced the state of the art well beyond the conventional manual approach. A potential problem physicians face when using this new technology is the large volume of information available to the physician for review compared to the limited amount of time the physician has to locate and analyze relevant patient information and make treatment decisions during patient visits. An electronic medical record can contain very large quantities of data pertaining to the entire medical history of the patient. Usually, the entire medical history is not needed by a physician who is about to meet with a patient. Providing too much information to the physician makes it difficult and time-consuming for the physician to sift through the record and locate the treatment data that is relevant to the patient visit.
This problem is compounded when, as is often the case, multiple physicians see a particular patient and a particular physician must determine what changes have occurred in the patient's treatment history or what new information is available since the last time that particular physician saw the patient. In an ambulatory setting, a physician needs to be able to quickly determine what has happened since the last time that physician treated the patient without being inundated by all of the information contained in the patient's electronic medical record. Providing the physician with relevant high-level information summarizing new treatment events that have occurred since the last time this physician saw the patient would allow the physician to quickly prepare for a patient visit.
A way is needed for a physician to quickly, easily, and accurately determine what patient information is new since the last time that particular physician saw the patient, without having to decipher a multitude of paper medical charts or search volumes of electronically stored data. Additionally, a physician would benefit from being able to review prior treatment decisions and diagnoses of other physicians who previously treated the patient by being able to easily view the patient's treatment information that is new since the last time that physician saw the patient.
Embodiments of the present invention relate to methods for displaying patient treatment data that is new to a computerized healthcare system or has been updated relative to a point in time unique to a particular user. The point in time may be the time that the particular user last saw the patient for treatment purposes or last accessed the patient's data. The treatment data is displayed in sections as clinical events with associated relevant attributes.
Embodiments include filtering a patient's data to retrieve treatment data entered subsequent to a time and date stamp unique to the user. Another embodiment provides selectable regions operative to access additional information associated with selected clinical events. The additional information can be displayed as a clinical event summary that displays results relevant to the selected clinical events as well as prior results associated with prior related clinical events.
In one possible embodiment, the user interface of an electronic medical records system contains a “since last time” user interface tab that concisely displays logical sections of relevant patient treatment data generated since the prior time a particular physician saw a particular patient or accessed the patient's data. The “since last time” tab contains selectable regions operative to retrieve additional information associated with the displayed treatment data. The tab also contains page selection regions for navigating the displayed treatment data.
In another embodiment, the user interface contains a time and date stamp display area for visually providing the point in time referenced to filter the displayed treatment data. The user interface also contains a time and date stamp selection region operative to manually time and date stamp the displayed treatment data so the displayed data will not be shown to the user the next time the user accesses the “since last time” user interface tab for the particular patient.
Computer-readable media having computer executable instructions for performing embodiments of the present invention are also provided.
The present invention is described in detail below with reference to the attached drawing figures, wherein:
The subject matter of the present invention is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms “step” and/or “block” may be used herein to connote different components of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.
Embodiments of the present invention provide computerized methods, computer readable media, and user interfaces for displaying a particular patient's treatment data that is new to a computerized healthcare system since the last time a particular user saw the patient. Embodiments of the present invention allow a physician or other healthcare professional to quickly identify changes that have occurred in a patient's medical history since the last time that particular physician or other healthcare professional saw the patient for treatment purposes. An exemplary operating environment is described below.
Referring to the drawings in general, and initially to
The present invention may be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the present invention include, by way of example only, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above-mentioned systems or devices, and the like.
The present invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The present invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media including, by way of example only, memory storage devices.
With continued reference to
The control server 22 typically includes therein, or has access to, a variety of computer readable media, for instance, database cluster 24. Computer readable media can be any available media that may be accessed by control server 22, and includes volatile and nonvolatile media, as well as removable and nonremovable media. By way of example, and not limitation, computer readable media may include computer storage media and communication media. Computer storage media may include, without limitation, volatile and nonvolatile media, as well as removable and nonremovable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. In this regard, computer storage media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage device, or any other medium which can be used to store the desired information and which may be accessed by control server 22. Communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media. As used herein, the term “modulated data signal” refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above also may be included within the scope of computer readable media.
The computer storage media discussed above and illustrated in
The control server 22 may operate in a computer network 26 using logical connections to one or more remote computers 28. Remote computers 28 may be located at a variety of locations in a medical environment, for example, but not limited to, clinical laboratories, hospitals and other inpatient settings, ambulatory settings, medical billing and financial offices, hospital administration settings, home health care environments, and clinicians' offices. Clinicians may include, but are not limited to, a treating physician or physicians, specialists such as surgeons, radiologists and cardiologists, emergency medical technicians, physicians' assistants, nurse practitioners, nurses, nurses' aides, pharmacists, dieticians, microbiologists, and the like. Remote computers 28 may also be physically located in non-traditional medical care environments so that the entire health care community may be capable of integration on the network. Remote computers 28 may be personal computers, servers, routers, network PCs, peer devices, other common network nodes, or the like, and may include some or all of the elements described above in relation to the control server 22.
Exemplary computer networks 26 may include, without limitation, local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When utilized in a WAN networking environment, the control server 22 may include a modem or other means for establishing communications over the WAN, such as the Internet. In a networked environment, program modules or portions thereof may be stored in the control server 22, in the database cluster 24, or on any of the remote computers 28. For example, and not by way of limitation, various application programs may reside on the memory associated with any one or all of the remote computers 28. It will be appreciated by those of ordinary skill in the art that the network connections shown are exemplary and other means of establishing a communications link between the computers (e.g., control server 22 and remote computers 28) may be utilized.
In operation, a user may enter commands and information into the control server 22 or convey the commands and information to the control server 22 via one or more of the remote computers 28 through input devices, such as a keyboard, a pointing device (commonly referred to as a mouse), a trackball, or a touch pad. Other input devices may include, without limitation, microphones, satellite dishes, scanners, or the like. The control server 22 and/or remote computers 28 may include other peripheral output devices, such as speakers and a printer.
Although many other internal components of the control server 22 and the remote computers 28 are not shown, those of ordinary skill in the art will appreciate that such components and their interconnection are well known. Accordingly, additional details concerning the internal construction of the control server 22 and the remote computers 28 are not further disclosed herein.
Although methods and systems of embodiments of the present invention are described as being implemented in a WINDOWS operating system, operating in conjunction with an Internet-based system, one of ordinary skill in the art will recognize that the described methods and systems can be implemented in any system supporting the receipt and processing of healthcare orders. As contemplated by the language above, the methods and systems of embodiments of the present invention may also be implemented on a stand-alone desktop, personal computer, or any other computing device used in a healthcare environment or any of a number of other locations.
As mentioned above, embodiments of the present invention provide computerized methods, computer readable media, and user interfaces for displaying patient treatment data that is new to a computerized healthcare system or has been updated since the last time that a particular user accessed the patient treatment data or saw the patient for treatment purposes. For simplicity, the particular user will often be referred to as the physician, but the particular user can be any healthcare professional and is not limited to a physician. Embodiments of the present invention allow a physician to quickly access the portions of a patient's treatment data that are new to the system or have been updated since the last time that particular physician saw the patient.
With reference to
At a step 210, a request is received to view a patient's treatment data entered since the last time that the particular user saw the patient for treatment purposes or last accessed the patient's data. For example, the request may be received by the user selecting a “since last time” user interface tab. The user interface may be that of any electronic medical record system. An exemplary user interface containing a since last time tab is shown in
At a step 215, a time and date stamp is accessed for the particular user. The time and date stamp serves as a temporal reference point that designates the last time that the particular user saw the patient for treatment purposes or accessed the patient data. The current time and date stamp may be stored locally on a client, such as a remote computer 28 or remotely on a server, such as a control server 22. The time and date stamp is used to designate the portion of the patient data or electronic medical record that has already been previously displayed to the particular user. The portion of the patient data having an associated time and date stamp subsequent to the particular user's time and date stamp is deemed to be “new” information that must be displayed to satisfy the user's request to view the “since last time” treatment data.
For example, if Dr. John Jones last saw a patient, Pamela Kohler, on Jun. 1, 2005 at 2:00 p.m., then a time and date stamp of 2:00 p.m. on Jun. 1, 2005 had been assigned to Ms. Kohler's record for Dr. Jones. In this case, any patient data entered or updated for Ms. Kohler subsequent to 2:00 p.m. on Jun. 1, 2005 is deemed new to Dr. Jones even though it may not be new relative to other physicians who may have treated Ms. Kohler or accessed her patient data since 2:00 p.m. on Jun. 1, 2005.
At a step 220, the clinical patient's electronic medical record is retrieved and the patient's data is accessed. This could involve accessing locally stored data or accessing remotely stored data to obtain patient data stored for the patient in the system. The patient data are filtered to obtain the desired treatment data, because the portion of the patient data with an associated creation time or update time subsequent to the particular user's time and date stamp are the desired treatment data.
At a step 225, one or more filters are applied to the patient data to extract the treatment data, which is the information that is subsequent to the current time and date stamp for the particular user. In the alternative, a bookmark or series of bookmarks could be used as the temporal reference point to designate the new or updated treatment data of interest to the particular user. The temporal reference point is used to filter the patient data. For example, on Oct. 31, 2005, Dr. Jones is preparing for a visit with a patient, Ms. Kohler, and requests to view the portion of Ms. Kohler's patient data that is new or has been updated since the last time he saw Ms. Kohler. If Dr. Jones last saw her on Jun. 1, 2005, a time and date stamp of Jun. 1, 2005 exists for Dr. Jones, the particular user. To satisfy Dr. Jones' request, Ms. Kohler's patient data are filtered to retrieve the treatment data of interest, the data entered between Jun. 1, 2005 and Oct. 31, 2005. This is done by retrieving the data with a creation (or update) time and date subsequent to the Jun. 1, 2005 time and date stamp.
At a step 230, the filtered patient data (i.e., the treatment data) are displayed. The treatment data can be categorized and displayed by configurable user-defined instructions. In this embodiment, a particular categorization scheme is applied to the patient data and will be described in further detail below with reference to
At a step 235, a new time and date stamp is assigned to the displayed patient treatment data and stored. The new time and date stamp designates that this portion of the patient's electronic medical record has been viewed during this visit and should not be displayed in the future under the “since last time” tab the next time that the particular user requests to view the since last time treatment data. The assignment of the new time and date stamp can be automatic or can be performed manually upon receiving a request to assign a new time and date stamp, such as by the user selecting a time and date stamp selection region. The new time and date stamp can be stored locally or remotely.
For example, after viewing Ms. Kohler's treatment data, which was new or updated since her last visit with Dr. Jones, and meeting with Ms. Kohler on Oct. 31, 2005, Dr. Jones may assign a new time and date stamp of Oct. 31, 2005, unique to him, to her record. This may be done by receiving a selection via a time and date stamp selection region or it may occur automatically upon Dr. Jones viewing the since last time treatment data. In this example, the next time Dr. Jones views Ms. Kohler's record, patient data subsequent to Oct. 31, 2005 will appear in the since last time user interface tab of her record. In this embodiment, prior time and date stamps corresponding to previous visits can be stored in an archive to allow the particular physician user, auditors, or other individuals to view what information was displayed in the since last time tab for that particular visit.
After completion of the exemplary method 200, the user can quickly determine any changes that have occurred in the patient's treatment history since the last time that he or she saw this patient or accessed the patient's data. The method 200 eliminates noise from the large quantity of data that is stored in the patient's electronic medical record. This noise, or extraneous data, is not relevant to a physician about to meet with a patient. The physician can, of course, still review the patient's entire electronic medical record, if necessary. The method 200 displays a concise view summarizing the new or updated treatment events occurring in the patient's history since the last time this physician saw the patient. Additionally, the physician may obtain more detailed information about these new or updated treatment events by interacting with the “since last time” user interface tab, as discussed below.
With reference to
At a step 310, one or more clinical event selections is received. A clinical event may be any patient treatment event, such as, for example, a patient visit encounter, a laboratory test or panel of tests, a radiology event, medications ordered or taken, ordered or performed procedures, administrative events, documents relevant to the patient's treatment, brief notes, comments, or any other item pertaining to treatment or care of the patient. A clinical event selection may be received by a user selecting an associated selectable region corresponding to the clinical event. The clinical event selection can take the form of, for example, placing a check in a box or highlighting the clinical event. In this embodiment, multiple clinical event selections may be made within a section. For example, several laboratory tests may have been conducted since the physician last saw the patient and the physician may want to access results for all of these tests. The physician might select a clinical event corresponding to a hemoglobin A1C test and a clinical event corresponding to a lipid panel test that were performed since the last time the physician saw the patient.
At a step 315, a request is received to generate a clinical event summary, such as a flowsheet or other results summary providing additional information regarding the clinical event selections. For example, the physician may want to view a summary of the results from the selected hemoglobin A1C and lipid panel tests referred to in the above example. In addition, the physician would probably also be interested in laboratory results from any prior hemoglobin A1C and lipid panel tests, as well as any other prior laboratory test results from tests typically ordered for the same reasons that hemoglobin A1C and lipid panel tests are usually ordered. For example, if a user requests to view a clinical event summary of results of a lipid panel test, which includes cholesterol and triglyceride levels, prior results from other similar tests that also contain results for cholesterol and triglyceride levels may also be relevant to the physician's request. In an embodiment, the clinical event summary can also display such prior results from prior clinical events having a related attribute (e.g., cholesterol and triglyceride levels) associating the prior clinical events with the selected clinical events.
At a step 320, the patient data corresponding to results for the selected clinical events are accessed. And, at a step 325, the patient data corresponding to prior results for the prior clinical events having a related attribute associating the prior clinical events with the selected clinical events are also accessed. For example, the results for the selected hemoglobin A1C and lipid panel tests are accessed as well as prior results for prior hemoglobin A1C, lipid panel, and related tests, such as those discussed in the above example.
At a step 330, results from the selected clinical events and prior results from the prior clinical events are displayed in a flow sheet or other summary format. The results associated with the selected laboratory test clinical events are displayed along with the historical results associated with the prior related laboratory test clinical events. In this embodiment, the results for the selected laboratory tests are displayed along with the results from five prior laboratory tests. This will be discussed in further detail below with reference to
After completion of an exemplary method 300, additional detailed information associated with clinical events located in a “since last time” user interface tab has been displayed satisfying the physician's request for lower level information pertaining to the patient.
In
In one embodiment, encounter clinical events 406A-406B represent patient visit encounters. Attributes 408A-408G containing information relevant to each clinical event are displayed for each clinical event. Attributes may vary depending on the section. For example, a patient visit clinical event 406A within encounter section 404A may have a date and time attribute 408A, a discharge date and time attribute 408B, and an encounter type attribute 408C, as well as other attributes. These attributes contain information relevant to the clinical event. For example, some of these attributes describe the date and time of the patient visit, the date and time the patient was discharged, and the type of patient visit, such as an outpatient encounter. The attributes displayed for a particular section may be based on a configurable pre-defined database. In this embodiment, a particular categorization scheme has been employed.
Within a labs section 404B, laboratory test clinical events 406C-406F corresponding to tests performed since the last time the physician saw the patient are displayed. In this embodiment, the attributes 410A-410G associated with laboratory test clinical events 406C-406F provide details for the particular laboratory test clinical events. For example, laboratory test clinical event 406C corresponds to a hemoglobin A1C test performed on Oct. 4, 2005 at 10:00 at the baseline lab facility, for example.
In one embodiment, each section has a selectable region 420 for receiving a request to display additional information about the clinical events within that section. Each clinical event within a section has an associated selectable region. For example, labs section 404B has an “open flowsheet” selection region 420 that is operative to generate and display a flow sheet containing information associated with any lab clinical events 406C-406F that are selected by the user. This will be discussed in further detail below.
In an embodiment, “since last time” user interface tab 402 also contains a time and date stamp display area 412 indicating the date and time stamp assigned to the particular user. Display area 412 further indicates the stamp that was used during filtering of the patient data, which yielded the treatment data displayed in tab 402. The time and date stamp was discussed above with reference to
In one embodiment, each section contains page selection regions 416 and 418. In this embodiment, each section contains a page up selection region 416 and a page down selection region 418 operative to reconfigure interface 400 to display other additional clinical events within each section. For example, a user may want to view a patient visit clinical event occurring before the patient visit clinical event 406B and could do so by selecting page down selection region 418. The user interface tab 402 can be configured to display more or fewer clinical events under each section. For example, labs section 404B displays four lab clinical events 406C-F; this section can be configured to display more or less than four clinical events. The page up and page down selection regions allow the user to view additional clinical events, and, at the same time, the page up and page down selection regions facilitate a concise representation of data. A concise representation allows the physician to be quickly and efficiently updated about a patient's case prior to a patient visit without being overloaded with information.
In
As shown in
As shown in
Referring to
Referring to
Upon receiving a request to create a report for a document clinical event selection, the system displays a user interface 1000, as shown in
As shown in
As shown in
The present invention has been described in relation to particular embodiments, which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those of ordinary skill in the art to which the present invention pertains without departing from its scope.
From the foregoing, it will be seen that this invention is one well adapted to attain all the ends and objects set forth above, together with other advantages which are obvious and inherent to the system and method. It will be understood that certain features and sub-combinations are of utility and may be employed without reference to other features and sub-combinations. This is contemplated by and within the scope of the claims.
This application claims the benefit of U.S. Provisional Application Ser. No. 60/717,294, filed Sep. 15, 2005 and entitled “System and Method for Accessing Patient Treatment Information Generated Since a Previous Visit and Notification of Patient Treatment Information Updates,” which is hereby incorporated herein by reference. This application is related by subject matter to the invention disclosed in the commonly assigned application U.S. Application No. (not yet assigned) (Attorney Docket Number CRNI.125805), filed on even date herewith, entitled “DISPLAYING PATIENT TREATMENT INFORMATION SINCE A PREVIOUS VISIT.”
Number | Date | Country | |
---|---|---|---|
60717294 | Sep 2005 | US |