User-centric methodology for navigating through and accessing databases of medical information management system

A contextually sensitive, user-centric database navigation and accessing software methodology controls navigation through and access to database domains of a medical (e.g., cardiovascular) image and information management system in accordance with the specific role of the user. Being user-centric, rather than patient-centric, the routine is operative to display to a user, upon logging on, a homepage that specifically pertains to the user's area of responsibility, with the information being displayed containing a contextual list of options that are germane to the user's workflow. This facilitates the ability of the user to rapidly navigate through and access one or more data domains specifically relevant to responsibilities and functions of the user, thereby improving the user's efficiency and reducing the time to complete a task.

FIELD OF THE INVENTION

The present invention relates in general to data storage and retrieval systems and user interfaces therefor, and is particularly directed to a contextually sensitive, user-centric methodology that facilitates the ability of a logged-on system user to rapidly navigate through and access one or more data domains of a medical information management system, such as a cardiovascular image and information management system, which data domains specifically pertain to the functions and responsibilities of the user.

BACKGROUND OF THE INVENTION

Today's medical facilities, such as hospitals, that perform procedures such as cardio-related procedures, employ a centralized information storage and management system, in which all information relating to the operation of the hospital and the patients it treats is maintained. Within this overall information storage and management system, there may be contained specific discipline-related information management systems, such as a cardiovascular image and information management system, in which information relating to all cardiology patients, procedures, diagnoses and the like is stored, and may be selectively retrieved by authorized personnel. To date, applications that run on these systems have been organized on the basis of what is commonly referred to as a ‘patient’-centric paradigm. As such, whenever any user logs on to a given application, the user's workstation will first display a patient census; then, through the manipulation of various function buttons and icons of the application's graphic user interface, the user may proceed to ‘hunt’ through the patient list, in an effort to reach a target database from which desired information may be extracted and displayed.

A fundamental drawback to such a patient-centric data retrieval process is the fact that it customarily requires the user to navigate through domains that have absolutely nothing to do with what the user is looking for. A respective user of the system is one to whom specific duties and functions have been assigned; as such, the user is essentially interested only in workflow information which pertains to those functions and duties. For example, a system administrator does not care about finalizing clinical reports, and a registry nurse is not concerned about inventory or scheduling patients. In other words, although it may be necessary for a given user to have access to more than one domain in the system, it is not necessary, nor is it expedient, for each and every user to have access to every domain, such as the patient census, in order for that user to carry out his or her specific function(s).

SUMMARY OF THE INVENTION

In accordance with the present invention, shortcomings of patient-centric data navigation and access schemes, such as, but not limited to, those described above, are effectively obviated by a new and improved contextually sensitive, user-centric database navigation methodology, that controls navigation through and provides access to one or more database domains of a medical information storage and retrieval system, such as a cardiovascular image and information management system, as a non-limiting example, based upon the specific role or function of the user. Being user-centric, rather than patient-centric, means that the methodology of the invention has a priori knowledge of the clinical duties of the user, so that it will automatically open to a workflow homepage that specifically pertains to the clinician's area of responsibility, when he or she logs on to a given application. The information displayed to the user comprises a contextual list of options that are germane to the user's workflow. This facilitates the ability of a logged-on system user to rapidly navigate through and access one or more data domains that are specifically relevant to the responsibilities and functions of the user, thereby improving the user's efficiency and reducing the time to complete a task, as it saves the user keystrokes and time, and effectively eliminates the frustration of trying to navigate through extraneous areas to the right place in the application. In fact, in many instances, the tasks assigned to a given user may not depend on a patient census at all. As will be described, the system administrator will have designated the user's role and permissions when the user was first entered into the system as a new user. Also, the system administrator may add functions to a user's role, that will allow a user to navigate to additional areas of an application, as necessary.

The computer network in which a workstation having access to user-centric information management system navigation and access routine of the present invention provides communication between the workstation and a Hospital Information System (HIS), in which patient-associated information (such as medical history, demographics, insurance information, indicated physical symptoms, etc.) is captured by hospital reception personnel, when a patient is initially checked into the healthcare facility for medical evaluation and treatment. By having access to the HIS, the user-centric information management system navigation and access routine of the present invention is readily able to provide the user with currently available information associated with every patient and any diagnosis or procedure performed.

In addition to providing a link coupled to the HIS, the computer network communicates with diagnostic and test equipment, through which symptomology parameter information of patients, and diagnostic information, that may indicate the need to schedule a procedure, may be obtained. Similarly, once a diagnosis has been completed and a procedure is scheduled, all information relating to the procedure, including the type of procedure, operating physician and attending staff, date of the procedure, the name of the patient on whom the procedure is to be performed, etc. is recorded and stored in the information system.

For purposes of providing illustrative examples of the application of the present description to a variety of respectively different clinical facility functions, the present description will address the manner in which the user-centric methodology of the invention streamlines the ability of a plurality of specifically identified types of users, whose clinical responsibilities are different from one another, to navigate through one or more data domains of a cardiovascular image and information management system. It should be understood, however, that although the invention will be described with respect to its application to the cardiology field, it is applicable to other specialties, such as, but not limited to radiology, oncology, orthopedics, etc.

The respectively different types of users, for whom associated user-centric functions will be described, include, but are not limited to, a physician, a holding area nurse, a clinician (lab tech), a scheduler, an Information Technologist or Chief Information Officer, a system administrator, a department administrator, a registry nurse, and a chief executive of the medical facility. The basic functions which may be generally performed by respectively different ones of the users include but are not limited to: scheduling; generating reports (clinical, administrative, financial); statistics (charge capture, Morbidity/Mortality reports, departmental supplies utilization, etc.); broken study tools; patient locator/search tools; registries/research datapoints; system status monitoring; and audit logs. The specific functions performed by each of the different classes of users will be detailed in the course of descriptions of workflow diagrams for those users. When a specific function is invoked, the user is then guided through one or more associated screens, that allow rapid navigation through databases, information contained within which the user may require to complete a given task.

When a user logs in to the system, via the manipulation of one or more buttons of a logon screen, a subroutine associated with that particular class of user will cause the user's workstation to automatically display a workflow homepage for that user. The system administrator will have designated the user's role and permissions when the user was first entered into the system as a new user. This a priori known role or class of the logged-on user serves to automatically display the appropriate workflow homepage screen for the user, which contains the roles or functions of a specific class of user, the tasks which that user performs in the discharge of his/her duties, and the features and functions in the application that relate to that particular user's respective needs.

DETAILED DESCRIPTION

Before describing the user-centric based methodology of the present invention for navigating through and accessing data domains of a medical information management system, such as, but not necessarily limited to, a cardiovascular image and information management system, it should be observed that the invention resides primarily in a set of contextually sensitive, user workflow and database search and retrieval software, that may be loaded into and executed on a conventional computer (e.g., laptop, desktop, server, and the like), plus associated graphic user interfaces, through which the software is controlled, with results of the execution of various subroutines of the software being displayed to a user of the system. Consequently, the configuration of the system and the manner in which it may be interfaced with conventional healthcare service provider data storage and processing systems, such as a Hospital Information System (HIS), and equipments employed by the health facility to test and gather symptomatic parameter information on patients have, for the most part, been depicted in the drawings by readily understandable functional block diagrams, and user interface display screens that display user function-associated menus and user workflow diagrams, which show only those specific aspects that are pertinent to the methodology of the present invention, so as not to obscure the disclosure with details which will be readily apparent to those skilled in the art having the benefit of the description herein. Thus, the block diagram and associated graphic user interface and user workflow diagrams are primarily intended to show the major components of a preferred embodiment of the invention in convenient functional groupings, whereby the present invention may be more readily understood.

Moreover, it is to be understood that the methodology of the present invention is applicable to expeditiously navigating through and retrieving a wide variety of information stored in one or more database domains of a medical service facility's information management system, and thus is not intended to be limited in its scope. For purposes of providing a non-limiting, but illustrative, example of its use, the following description will address the application of the invention to navigating through and retrieving information stored within a cardiovascular image and information management system by a plurality of users, whose functions and responsibilities are different from one another, and therefore require access to respectively different workflow-related domains of the information management system, in the course of carrying out their assigned tasks. As pointed out above, although the invention will be described with respect to its application to a cardiology related image and information management system, it is to be understood that it is applicable to other specialties, such as, but not limited to radiology, oncology, orthopedics, etc.

Attention is initially directed toFIG. 1, which is a reduced complexity block diagram illustration of a computer network, such as may be installed at a facility of a healthcare provider (e.g., hospital), in which the present invention may be employed. As shown therein, the service provider computer network includes a desktop computer or workstation10, in which the user-centric database navigation and data retrieval software of the present invention has been installed, and through which healthcare facility personnel are able to navigate among respective displayed windows of a graphics user interface and retrieve data, as necessary, in association with their predefined responsibilities and duties that require access to the network.

The computer network in which the workstation10is installed includes a link11between the workstation and a Hospital Information System (HIS)20, in which patient-associated information (such as medical history, demographics, insurance information, indicated physical symptoms (such as crushing chest pain, dizziness, fainting, chest palpitations), etc.) is captured by hospital reception personnel, when a patient is initially checked into the healthcare facility for medical evaluation and treatment. By having access to the HIS20, the user-centric information management system navigation and access routine of the present invention is readily able to provide the user with currently available information associated with every patient and any diagnosis or procedure performed.

In addition to providing a link coupled to the HIS20, the computer network includes a link12to diagnostic and test equipment30, through which symptomology parameter information of patients, and diagnostic information, that may indicate the need to schedule a procedure, may be obtained. Similarly, once a diagnosis has been completed and a procedure is scheduled, relevant information relating to the procedure, including the type of procedure, operating physician and attending staff, date of the procedure, the name of the patient on whom the procedure is to be performed, etc. is recorded and stored in the HIS.

As noted above, for purposes of providing non-limiting, but illustrative examples of the application of the present description to a variety of respectively different clinical facility functions, the present description will address the manner in which the user-centric database navigation methodology of the invention streamlines the ability of a plurality of specifically identified types of users, whose clinical responsibilities are different from one another, to navigate through one or more domains of a cardiovascular image and information management system. To this end, as an illustrative example,FIG. 2diagrammatically shows a set of nine different classes of users of the system and a listing for each user of some of their individual job functions. The users include a physician201, a holding area nurse202, a clinician (lab tech)203, a scheduler204, an Information Technologist or Chief Information Officer205, a system administrator206, a department administrator207, a registry nurse208, and a senior executive of the hospital (CXO)209.

Also shown inFIG. 2is a generic function block210, that lists a set of basic functions which may be generally performed by respectively different ones of the users201-209. These include: scheduling; generating reports (clinical, administrative, financial); statistics (charge capture, (see above clarifications) M/M, dept.); broken study tools; patient locator/search tools; registries/research datapoints; system status monitoring; and audit logs. The specific functions listed for each of the users201-209inFIG. 2will be referenced in the course of descriptions of workflow diagrams for those users, depicted inFIGS. 4, and6-13, to be described.FIG. 2further shows a user login function211, which, by virtue of the fact that the present invention is user-centric, is operative to automatically call up and display the functions listed for the particular one of the users201-209, as represented by the respective arrows emanating from the user login block211to the user blocks201-209, when that user logs on to the system.

The user login block211ofFIG. 2is more particularly depicted in the illustration of the graphic user interface ofFIG. 3, which shows respective components that are displayed by a logon screen on the user's workstation. The logon screen ofFIG. 3is shown as containing a login button301, and exit button302and traditional user name and password fields303and304, respectively. As pointed out above, the system administrator will have designated the user's role and permissions when the user was first entered into the system as a new user. This a priori known role of the logged-on user serves to automatically display the appropriate workflow-displaying homepage screen for the user, as will be described.

FIG. 4shows the homepage that is displayed by the workstation's display screen, for the case that the user logged into the system is a physician/cardiologist (shown at401), whose functions include those listed in block201inFIG. 2, described above, and repeated in the function block402inFIG. 4. The workflow diagram ofFIG. 4, as well as those subsequently described, graphically illustrates the roles or functions of a specific type of user, the tasks which that user performs in the discharge of his/her duties, and the features and functions in the application that relate to that particular user's respective needs.FIG. 4contains a workflow diagram that has commonality for both an interventional cardiologist and a non-interventional cardiologist.

Non-interventional cardiologists include physicians who perform echocardiology studies, nuclear medicine studies, non-invasive peripheral vascular examinations, and doctors who read EKG and holter exams. This type of physician often sits at a desk and uses a worklist to maximize his/her efficiency during the day. In other words, the non-interventional cardiologist can be expected to sit at a computer workstation, and read/interpret examination reports that have been prepared for them by technicians or interns in residence. Interventional physicians, on the other hand, are not worklist-driven, but move from one procedure to the next, and having to complete procedural reports rapidly before the next case starts. In spite of these differences, these two types of physicians have commonalities in their individual routines or functions, as depicted inFIG. 4. These tasks include scheduling411, unread studies412, annotating and finalizing studies413, patient searching414, reviewing statistics415, reviewing contents of folders (personal and public)416, and verification of medical necessity (VOMN)417.

By invoking the schedule function411, the physician may view a schedule or select a schedule item, as shown at421. From the schedule function421, the physician may proceed to call up a screen showing patient history, via a single click on the displayed patient name, as shown at431, or double click to open a study home page, as shown at432. Invoking the unread studies function412causes a list of unread studies to be automatically displayed, and the physician may select from the displayed list, as shown at422. Again, the physician may suitably single or double click to state431or state432. By invoking the annotate and finalize studies function413, the physician may have the studies automatically displayed for selection as shown at423, from which the physician may selectively single or double click to state431or state432. Invoking the patient search function414provides the physician with a patient list and displayed search criteria from which the physician may select for study, as shown at424. Again, the physician may suitably single or double click to state431or state432.

For the statistics function shown at415, the work flow proceeds to the statistics screen and filters the results for the currently logged-on physician, as shown at425, and allows the physician to select from an array of stored reports or to query the builder, as shown at state435. For the folders function at416, the work flow proceeds to open a selected folder at426, and allows the physician to view a patient folder or drag and drop new studies into the folder, as shown at state436.

The last listed function, verification of medical necessity, shown at417, involves an automated software routine that enables the user to readily capture and archive, in an audit file, patient and clinical information, that is effective to verify—comply with guidelines promulgated by the Center for Medicare/Medicaid Services (CMS) for—the medical necessity of performing a given medical procedure, and thereby ensure that the healthcare service provider and the physician will be properly reimbursed for the costs of performing the procedure and will be able to readily pass a CMS audit of its facility and associated medical personnel (physicians). Such a routine is preferably of the type described in U.S. patent application Ser. No. 11/273,790, published as U.S. Patent Application Publication No. 2007/0021977, filed on Nov. 15, 2005, by John F. Elsholz, entitled: “Automated System For Capturing And Archiving Information To Verify Medical Necessity Of Performing Medical Procedure,” assigned to the assignee of the present application and the disclosure of which is incorporated herein.

Briefly, in accordance with the invention described in that application, if the compilation of information regarding a patient and procedure reveals that the audit file lacks one or more pieces of information to satisfy medical necessity requirements, the inventive system will visually alert medical personnel to the extent of the shortcoming and specifically tag what is lacking. This will allow the system user to activate one or more objects of a user interface to initiate a search of available resources that contain the required information, or to manually enter the information into the system, so that the audit file may be completely filled in with whatever information is missing. Once the audit file complies with CMS requirements, the system will alert medical personnel to that fact by a colored (e.g. green) alert indicator of the workstation display screen.

When the VOMN function417is invoked, the work flow proceeds to the VOMN screen, an example of which is shown inFIG. 5C, and filters the results for the currently logged-on user, as shown at427, so that the physician may view his/her patient data, or view patients having missing data, so that any missing data may be accessed and stored pursuant to the functionality of the VOMN routine, and then allow the VOMN data to be exported or saved to an auxiliary storage, such as a compact disc, as shown at437.

FIG. 5shows an example of a physician's logon screen that may be displayed on the physician's workstation, in the course of the physician navigating through one or more functions of the workflow diagram of the physician's homepage screen ofFIG. 4. As shown inFIG. 5, for unread studies501, a selected patient has been highlighted at502by the physician, so that the physician may document the case currently in progress; also displayed are a “patient information” field503, a “finalize studies” field504, and a “user messages/to do” field505. As described above, any of these or other displayed functions may be readily performed by the physician with a single mouse click after logging on.

FIG. 5Ashows an example of a screen displaying patient search information, such as may be generated when invoking the patient search function at414, whileFIG. 5Bshows an example of a screen displaying export study information, such as may be generated in the course of saving the results of a finalized study.

FIG. 6shows the homepage that is displayed by the workstation's display screen, where the user logged into the system is a holding area nurse (shown at601), whose functions include those listed in block202inFIG. 2, described above, and repeated in the function block602inFIG. 6.FIG. 6Ashows various examples of screen fields of a holding area nurse's logon screen. A holding area nurse is involved with patients in catheterization (cath), echo, electrophysiology (EP), peripheral vascular (PV) and nuclear medicine labs, who are prepared for a procedure in a holding area. This is especially true for cath and EP labs, where the patient is received, shaved, prepped, sedated, and IVs are inserted pre-procedurally, and where arterial hemostasis occurs post-procedurally. Holding nurses must chart the patient, assess the patient on Aldrete or ASA scores, and report the patient's conscious sedation under mandate of many state laws. As shown inFIG. 6, the functions that may be performed by a holding nurse include scheduling611, pre-procedural charting of patients612, intra-procedural charting of patients613, post-procedural charting of patients614, checking whether there are any incomplete registry fields615, dosage calculation616, patient search617, and messaging618.

When the scheduling function611is invoked, the current day's schedule, grouped by work area/department, for the logged-on holding nurse, is called up and displayed on the holding nurse's workstation's display screen, as shown at621. Invoking the pre-proceduring patients function612causes a list of all monitored and scheduled patients awaiting a procedure to be displayed, as shown at622. By clicking on a particular patient in the list, the holding nurse may open that patient's study folder to begin charting, as shown at632. Invoking the intra-proceduring patients function613causes a list of all monitored patients in the acute care area (Cath/EP/PV/Stress Labs) to be displayed, as shown at623. By clicking on a particular patient in the list, the holding nurse may open that patient's study folder to continue charting, as shown at633. Invoking the post-proceduring patients function614causes a list of all monitored patients post procedure to be displayed, as shown at624. By clicking on a particular patient in the list, the holding nurse may open that patient's study folder to continue charting, as shown at634.

When the incomplete registry fields function615is invoked, counts of missing registry fields by study, on post procedure patients that meet registry criteria are displayed, as shown at625. Clicking on a particular study opens the study and displays the missing data fields, as shown at635. Invoking the dose calculator function616is accomplished by clicking on a dose calculator button, which opens the dose calculator, as shown at626. Invoking the patient search function617opens the patient search screen, as shown at627. Clicking on this screen then displays a window for patient search criteria, as shown at637. The last function, which is optional, is a messaging function618. If employed, then when invoked, it will cause the current e-mail count to be displayed, as shown at628. The holding nurse may then proceed to click on the e-mail open button, to open the web based mail viewer, which causes login credentials to be supplied automatically, as shown at638.

FIG. 7shows the workflow homepage that is displayed by the workstation's display screen, where the user logged into the system is a clinician or lab tech (shown at701), whose functions include those listed in block203inFIG. 2, described above, and repeated in the function block702inFIG. 7. The primary task of procedural documentation during a cardiac catheterization, echocardiology, electrophysiology, vascular or nuclear medicine exam falls to the lab technicians who, along with the nurses, are the workhorses in the patient charting world. Physicians always review their notes, add findings, complications, and interpretations, but the lab techs perform an indispensable and vital documentation function.

As shown inFIG. 7, the functions that may be performed by a lab technician include scheduling711, new study (admitting)712, patient search713, and messaging714. When the scheduling function711is invoked, the current day's schedule, grouped by work area/department/physician, for the logged-on clinician, is called up and displayed on the lab tech's workstation, as shown at721. Invoking the new study function712, by clicking on a new study button, opens the patients' demographics search dialog, as shown at722. The user may then select a search key, as shown at732, and supply search criteria and select a patient from a displayed list. The user then proceeds to state742, to start a new study, and open an ID screen. The case is then documented at733. Invoking the patient search function713opens the patient search screen, as shown at723. The case is then documented at733. The last function is an optional messaging function714. If included, then when invoked, it will cause the current e-mail count to be displayed, as shown at715. The lab tech may then proceed to click on the e-mail open button, so open the web based mail viewer, which causes login credentials to be supplied automatically, as shown at716.

FIG. 8shows the workflow homepage that is displayed by the workstation's display screen, where the user logged into the system is a scheduler (shown at801), whose functions include those listed in block204inFIG. 2, described above, and repeated in the function block802inFIG. 8. The first point of entry with any procedure is getting it scheduled in the system. The scheduler may be in the hospital, a unit, or in a remote setting, such as a doctor's office. To allow for remote access, the user-centric methodology of the invention employs web-based communications, thereby allowing a physician's office nurse to log on remotely, find an opening in the schedule, and schedule the physician and the patient for the case. For this purpose, as shown inFIG. 8, functions that may be performed by a scheduler include viewing the schedule811, scheduling a new patient procedure812, having the physician read the schedule813, personnel scheduling814, and resource scheduling815.

When the view schedule function811is invoked, the current day's schedule, grouped by work area/department/physician, for the logged-on scheduler, is called up and displayed on the scheduler's workstation, as shown at821. To schedule a new patient procedure (function812), the scheduler clicks on the displayed function, to open a new event tool. If the scheduler is a physician's employee, the available time slots in the schedule are filtered according to a prescribed rules engine, as shown at822. The identity of the patient may be located from a patient list, based on input search criteria; where the patient is found in the list, the workflow moves to state832—patient found. Where the patient is not found in the patient list, a new record is created at state836, and the patient's demographic data is forwarded to the Hospital Information System (HIS) to update the HIS database, at state837. Given the patient's identity, from states832or836, a new scheduled event is created at838, and an order for the procedure is sent to the HIS, at839. In addition, the physician's preference card with procedure requirements is displayed, at state846. This generates a prompt for pre-requisite tests from the physician's preferences, at847. In addition, the scheduler is instructed to verify insurability or to write an Advance Beneficiary Notice at848so the patient can arrange financing to pay for the procedure.

When the physician's reading schedule function813is invoked, a calendar with the reader of the day for each modality is displayed by an on-click, as shown at823. The reader's schedule may be modified at833, by using the workstation's mouse to drag and drop physicians from the displayed list. Also, at state843, reader rules are supplied to inbound interfaces, and studies are routed by modality, and by day to the correct reader's worklist. When the personnel scheduling function814is invoked, the user may drag and drop specific personnel to a specific study or assign personnel to a specific room, as shown at state824. The user may then click on a specific study to view whether any special equipment is required, as shown at834. If special equipment is required, the user invokes an icon to provide a visual prompt to show such a need. For resource scheduling (function815), the scheduler may drag and drop resources (e.g., special equipment) to a specific study, as shown at825. The user may then click on a specific study to view whether any special equipment is required, as shown at835and, if special equipment is required, the user invokes an icon to provide a visual prompt to show such a need.

FIG. 9shows the IT logon screen that is displayed by the workstation's display screen, whileFIG. 9Ashows the associated workflow, where the user logged into the system is an information technologist (IT) or CIO (shown at901), whose functions include those listed in block205inFIG. 2, described above, and repeated in the function block902inFIG. 9A. The burden of supporting and maintaining the system falls to the information technologist, and eventually to the CIO, who has ultimate responsibility for the compatibility of all systems. The functions ofFIGS. 9 and 9Ainclude diagnostic and monitoring tools that specifically address the needs of the IT staff to support and monitor the system.

More particularly, functions that may be performed by an IT/CIO include a system status check911, reports912, a broken study manager913, statistics914, maintenance and warranty info915, system history916, tools917, audit/error logs918, running upgrades and interface tests919, and messaging920. Invoking the system status function911calls up and displays an overview of system health, including parameters that include server free space, back-up status, archive status, free space, users logged on, and the like, as shown at921. The user may then click on the statistics screen and display system statistics or generate statistical reports, as shown at931.

The report function912involves opening an ad-hoc query tool, and the display of system level reports selectors (standard and custom), as shown at922. When the broken study manager913function is invoked, counts of broken studies are displayed according to modality, as shown at923. Via an on click the broken study manager may then be displayed, as shown at933. When the statistics function914is invoked, the statistics screen is called up and displayed as shown at924. Invoking the maintenance and warranty information function915displays current warranty status and availability of upgrades, patches, new releases, as shown at925.

Invoking the system history function916displays system history and open items, as shown at926. Clicking on the tools function917, brings up a list of system diagnostic tools, as shown at927. When the audit/error logs function918is invoked, the last ten system errors are displayed, together with a link to all errors and search tools, as shown at928. Invoking the run upgrades and interface test function919accesses the test system for upgrade and interface tests, as shown at929. Invoking an optional messaging function920, if employed, causes the current e-mail count to be displayed, as shown at930. The IT/CIO may then proceed to click on the e-mail open button, so open the web based mail viewer, which causes login credentials to be supplied automatically, as shown at940.

FIG. 10shows the logon screen that is displayed by the workstation's display screen, whileFIG. 10Ashows the associated workflow, where the user logged into the system is a system administrator (shown at1001), whose functions include those listed in block206inFIG. 2, described above, and repeated in the function block1002inFIG. 10. The system administrator controls user permissions and security, creates custom reports, resolves broken studies, and performs additional tasks, such as training the trainers. Functions that may be performed by a system administrator include a system status check1011, adding/deleting/editing users1012, reports1013, a broken study manager1014, statistics1015, conducting training1016, viewing schedule1017, patient search1018, menu/text/report editor1019, and messaging1020.

Invoking the system status function1011calls up and displays an overview of system health, including parameters that include server free space, back-up status, archive status, free space, users logged on, and the like, as shown at1021. The user may then click on the statistics screen and display system statistics, as shown at1031. To add, delete or edit users of the system (function1012), the system administrator opens the user editor utilities, as shown at1022.

The report function1013involves opening an ad-hoc query tool, and the display of system level reports selectors (standard and custom), as shown at1023. When the broken study manager1014function is invoked, counts of broken studies are displayed according to modality, as shown at1024. Via an on click the broken study manager may then be displayed, as shown at1034. When the statistics function1015is invoked, the statistics screen is called up and displayed, as shown at1025. To conduct training (function1016), the system administrator opens the test system database for a training session, as shown at1026.

When the view schedule function1017is invoked, the current day's schedule, grouped by work area/department, for the logged-on system administrator, is called up and displayed on the system administrator's workstation, as shown at1027. To conduct a search for a particular patient (function1018), the system administrator clicks on and thereby opens the patient search screen, as shown at1028. The menu/text/report editor function1019is invoked by opening the screen editor at1029; modality is selected at state1039. At state1049, the system administrator views editor choices for the selected modality; the system administrator then selects the section to be edited. Invoking an optional messaging function1020, if employed, causes the current e-mail count to be displayed, as shown at1030. The system administrator may then proceed to click on the e-mail open button, so open the web based mail viewer, which causes login credentials to be supplied automatically, as shown at1040.

FIG. 11shows the logon screen that is displayed by the workstation's display screen, where the user logged into the system is a department administrator (shown at1101), whose functions include those listed in block207inFIG. 2, described above, and repeated in the function block1102inFIG. 11.FIG. 11Ashows the associated workflow diagram. The manager or director of the cath lab, or of the cardiology department, is concerned with the efficiency and profitability of the lab or department, the reliability of all critical systems, the management of expensive inventory items, and with keeping the doctors satisfied. The functions of the department administrator include: system status1111, report status1112, reports1113, broken study manager1114, statistics1115, inventory management1116, view schedule1117, patient search1118, menu/text/report editor1119and view VOMN1120.

Invoking the system status function1111calls up and displays an overview of system health, including parameters than include server free space, back-up status, archive status, free space, users logged on, and the like, as shown at1121. The user may then click on the statistics screen and display system statistics, as shown at1131. When the report status function1112is invoked, the number of unsigned studies is displayed by physician, at1122. Clicking on an open button at state1132then opens a filtered list of unsigned studies. The report function1113involves opening an ad-hoc query tool, and the display of system level reports selectors (standard and custom), as shown at1123. When the broken study manager1114function is invoked, counts of broken studies are displayed according to modality, as shown at1124. Via an on click the broken study manager may then be displayed, as shown at1134. When the statistics function1115is invoked, the statistics screen is called up and displayed, as shown at1125.

Invoking the inventory management function1116opens an inventory module for the administrator's department, as shown at1126. When the view schedule function1117is invoked, the current day's schedule, for this department, is called up and displayed on the department administrator's workstation, as shown at1127. To conduct a search for a particular patient (function1118), the department administrator clicks on and thereby opens the patient search screen, as shown at1128. The menu/text/report editor function1119is invoked by opening the screen editor, and modality is selected at state1129. At state1139, the user/department administrator views editor choices for the selected modality; the department administrator then selects the section to be edited. Invoking the messaging function1120causes the current e-mail count to be displayed, as shown at1130. The department administrator may then proceed to click on the e-mail open button, so open the web based mail viewer, which causes login credentials to be supplied automatically, as shown at1140.

FIG. 12shows the logon screen that is displayed by the workstation's display screen, where the user logged into the system is a registry nurse (shown at1201), whose functions include those listed in block208inFIG. 2, described above, and repeated in the function block1202inFIG. 12B.FIG. 12Ashows an enlargement of the examples of screen fields of the logon screen ofFIG. 12, whileFIG. 12Bshows the workflow of a registry nurse associated with the logon screen ofFIG. 12. Hospitals that participate in state, regional, or national registries, employ nurses or technicians to complete the mandated registry fields in procedural reports. They then harvest the data, format it according to the unique registry instructions, and submit it on a regular basis. To this end, the functions to be performed by a registry nurse include identifying reports with incomplete data1211, patient search1212, harvesting1213, submit to registry1214, and research protocols1215.

To identify reports with incomplete data (function1211), a list of incomplete studies is displayed at1221. A stored database procedure is used to generate this data as it occurs. To perform a patient search (function1212), the patient search screen is opened and filtered for registry patients only, as shown at1222. This serves to support ACC, STS, State, ICAEL, ICAVL, ICANL registries, as shown at1232. To perform the harvest function1213, the harvest routine is run on the selected registry and the results are displayed, as shown at1223. This provides a list of harvested studies with associated harvest metrics, as shown at1233. Invoking the submit to registry function1214, the selected registry is supplied with data or package data according to registry rules, as shown at1224. The research protocols function1215is performed by selecting the protocol from a stored protocol list, at state1225. In addition, protocol criteria are run or qualifying patients are selected from the patient database. At1235, the editor is opened to create new protocols or edit existing protocols. This serves to start a new study, and open an ID screen, as shown at state1245.

FIG. 13shows the workflow diagram that is displayed by the workstation's display screen, where the user logged into the system is a chief executive CXO (shown at1301), whose functions include those listed in block209inFIG. 2, described above, and repeated in the function block1302inFIG. 13.FIG. 13Ashows an example of a VOMN screen for a CXO as may be displayed by invoking function1311in the workflow diagram ofFIG. 13. The chief executive may be the CEO, COO, CFO, VP, or risk management officer. The fiduciary nature of his/her position means that this individual is concerned with the profit/loss of his/her department, and/or the liability to which the hospital may be exposed. As a consequence, there are two principal functions listed on the homepage diagram ofFIG. 13, that appeal to the CXO: 1— the performance of the cardiology department as measured by metric reports; and 2— verification of medical necessity, which will assist in reducing the hospital's vulnerability to failed Medicare audits.

These functions are identified inFIG. 13as the view VOMN function1311and the performance metrics reports function1312. When the view VOMN function1311is invoked, the current count of unverified studies, as filtered by the physician who performed the procedure, is displayed as shown at1321. The CXO may then click open the filtered list of unverified studies, as shown at1331. As described above, if the compilation of information regarding a patient and procedure reveals that the VOMN's audit file lacks one or more pieces of information to satisfy medical necessity requirements, the VOMN routine will visually alert the system user to the extent of the shortcoming and specifically tag what is lacking. This will allow the user to activate one or more objects of a user interface to initiate a search of available resources that contain the required information, so that the audit file may be completely filled in with whatever information is missing. Once the audit file complies with CMS requirements, the system will alert hospital personnel to that fact. When the CXO invokes the performance metrics reports function1312, an overview of system performance metrics is displayed in graphical format (using a stored procedure to generate for instant access), as shown at1322.

As will be appreciated from the foregoing description, drawbacks of conventional patient-centric data navigation and access schemes are effectively obviated by the contextually sensitive, user-centric database navigation and accessing methodology of the present invention, which facilitates navigation through and access to one or more database domains of a medical information storage and retrieval system, in particular, a cardiovascular image and information management system, based upon the specific role or function of the user. As noted above, being user-centric, rather than patient-centric, the software routine of the invention is operative to display to the user, upon logging on, a homepage that specifically pertains to the user's area of responsibility, containing a contextual list of options that are germane to the user's workflow. This facilitates the ability of the user to rapidly navigate through and access one or more data domains that are specifically relevant to the responsibilities and functions of the user, thereby improving the user's efficiency and reducing the time to complete a task, as it saves the user keystrokes and time, and effectively eliminates the frustration of trying to navigate through extraneous areas to the right place in the application.