Method and System for Navigation and Data Entry in Heirarchically-Organized Database Views

1. Field of the Invention This invention relates to computer database systems in general and to the entry, update, and review of data in hierarchically-organized database views in particular.

2. Background of the Invention

One of the most challenging problems a software developer faces when designing a database system is creating a data entry mechanism that allows users to efficiently record information. In many environments, users operate under significant time pressures and are unwilling or unable to spend time on laborious data entry procedures. In order for a data entry mechanism to be effective, it must be fast, complete, and reconfigurable. In many cases, the data entry mechanism must also map onto small display screens or onto limited space within larger screens. This requirement has become increasingly important as more and more users take their computer systems with them as they move between work environments throughout the day. These highly mobile computing systems (e.g., hand-held computers) require data entry mechanisms that use screen space very economically. The same is true when data entry is performed within the context of screen-intensive imaging and graphics applications--when entering data while viewing digitized X-ray images, for example.

Most existing database systems use a forms-based data entry mechanism. Unfortunately, forms-based techniques fail to satisfy the requirements listed above. Most databases include a large number of fields (categories) and elements. Since the number of fields that can be displayed on a form at any one time is very small, a user must navigate through multiple complex forms in order to enter data. In addition, forms-based systems are difficult, if not impossible, to reconfigure without programming.

Some existing database systems use data navigation mechanisms that are based on hierarchically-organized views of the data. Note that we are discussing how the data is viewed, not how the data is structured within the database. Hierarchical views can be created for a variety of data structures (e.g., relational tables, hierarchical data structures, and network data structures).

One set of prior art techniques for navigating through hierarchically-organized database views is based on a diagrammatic representation of the hierarchy as a whole (FIG. 1). In these techniques, a user moves around the hierarchy by selecting nodes on the diagram using a mouse or other pointing device. Since the hierarchy is very large, only those nodes that lie near the last node selected are displayed (FIG. 2). The user can manually move the viewing window around (using scroll bars, for instance) and can reveal or hide levels of the hierarchy diagram by manually opening or closing nodes.

These techniques are designed to allow a user to view data elements in the context of the overall structure of the hierarchy and to visualize the logical relationships between data elements. However, the emphasis on overall structure makes these approaches ill-suited to the task of data entry. As the user moves down the hierarchy, he sees not only the nodes that represent possible choices for the next selection, but also large amounts of information that are irrelevant to the current data being entered. In addition, because much of the hierarchy diagram must, by necessity, be off-screen at any point in time, it is often difficult for the user to ascertain how he has reached a particular point in the hierarchy or how the displayed information fits within the overall structure.

A second set of prior art techniques for navigating through hierarchically-organized database views restrict navigation to movement up and down along the branches in the hierarchy. The contents of the levels that lie along the current branch are then displayed as cascading windows 31 or menu lists 32 (FIG. 3). An example of this kind of system can be found in U.S. Pat. No. 5,715,449 to Peters et al., which discloses a browser tree structure for limiting how information is entered into a medical database. In the preferred mode, the system presents the person inputting the data with a limited number of choices of data to be entered, from which the operator selects specific phrases descriptive, for example, of the health care provider's observations or instructions. These techniques improve somewhat the ease with which a user can identify the current set of choices by placing possible candidates in the topmost window or rightmost list. However, these techniques are still unnecessarily wasteful of screen space. Much of the screen is cluttered with unselected choices at each of the levels that lie along the current branch. Equally important, navigation remains difficult because important navigational guides for moving back up the hierarchy--the nodes selected along the current path, for instance--are frequently hidden under a window or pushed off-screen entirely.

Also, present navigational techniques for hierarchical file directory structures that display the names of the files in a selected directory along with the path to that directory are limited to file selection, and do not address the entry or review of database information.

An object of the present invention is to enhance the entry, update, and review of data in hierarchically-organized database views by presenting a user with a compact navigation display in which the current set of choices is clearly identified, along with the path through the hierarchy leading to these choices.

Another object of the present invention is to allow a user to create and access multiple instances (values) of the nodes and subhierarchies in a database view using this navigation process and display.

Another object of the present invention is to support the creation of individual database entries from multiple nodes by allowing a user to use this navigation process and display to enter data for a set of nodes and to compose this data into a single database entry.

Another object of the present invention is to support the navigation of links between nodes that occur on separate branches in the hierarchy (and which transform the hierarchy tree into a directed acyclic graph), where this navigation can be done in either a serial or parallel manner.

Another object of the present invention is to allow a user to use this navigation process and display to efficiently integrate, navigate, and comment upon information that includes a wide range of data types--e.g., text files, HTML (Hyper-Text Markup Language) documents, audio data, and image data--where this information can reside on a local area network, a corporate intranet, or the world-wide Internet.

These and other objects are achieved in the present invention by a set of integrated navigation, display generation, data entry, and data review methods. These methods work in concert to allow a user to move efficiently through a hierarchically-organized database view for the purposes of entering, reviewing, and updating data. Equally important, these methods produce a screen display that is highly economical in its use of screen real estate.

At each step in the data entry process (FIG. 9), the user sees buttons 91 corresponding to the choices she has made along with buttons 93 corresponding to the candidates for the next choice to be made. As a result, the screen is free of the clutter characteristic of existing techniques (FIG. 2 and FIG. 3). In particular, the user does not see--and screen space is not wasted on--the display of unselected (and unselectable) choices. The user's ability to navigate the hierarchy is unhindered, however. At any point in the data entry and review process, the user can move back up the hierarchy (i.e., retrace her steps) simply by reselecting a button 91 corresponding to a previously made choice or move down the hierarchy by selecting a button 93 from among the current set of choices.

Note that these methods do not simply support the navigation of static data structures. A hierarchical database view contains multiple instances of various subhierarchies. FIG. 4, for example, shows a view containing multiple echocardiographic reports (42 and 44)--each with its own unique date-stamp. The methods in the present invention seamlessly blend the selection of subhierarchy instances (e.g., echocardiographic reports) into the navigation process and display outlined above. In other words, these methods support navigation of both the structural (FIG. 9) and the temporal (FIG. 10) components of a database.

Nor are these methods limited to use with hierarchical views in which each entry in the database corresponds to a single node in the hierarchy. Such views can easily become quite large and unwieldy (both for the database system and the user). The methods in the present invention support hierarchical views in which the values assigned to several nodes combine to define a single database entry. The user simply inputs values for the nodes and the database entry is automatically constructed and stored.

In addition, the methods in the present invention are not restricted to database views that are trees (i.e., limited to having only a single path between nodes). These methods fully support database views that are directed acyclic graphs by allowing for additional links between nodes. These links can then be traversed--and displayed--as either serial or parallel structures, as shown in FIGS. 18 and 19, respectively.

Finally, the methods in the present invention are not limited to marked/unmarked (i.e., yes/no) data items. The preferred embodiment of the present invention, for example, supports a diverse set of data types--including numbers, dates, prescription doses, file names, Universal Resource Locators (URLs), and free-text comments. All of these data types may be input and reviewed within the context of the hierarchical navigation process and display outlined above.

FIG. 1 shows a hierarchically-organized database view. Consistent with the accepted terminology in the field, we will refer to the hierarchy as a tree, to the topmost node in the hierarchy as the root node, to the path from the root node to any other node as a branch, and to a subset of the hierarchy that is itself a hierarchy as a subtree.

FIG. 4 shows sample database contents for the hierarchically-organized database view depicted in FIG. 1. The database contents are depicted as nodes or subtrees. Consistent with the accepted terminology in the field, we will refer to the data values for a node as instances of that node and the data values for a subtree as instances of that subtree. For example, node instance 41 represents the Warfarin dose recorded on 9/1/97 and subtree instance 42 represents the data recorded for the echocardiogram given on 5/1/97. Although date stamps are used to distinguish instances in the preferred embodiment of the invention, alternative schemes for uniquely identifying node and subtree instances could easily be used instead.

FIG. 1 is a schematic diagram showing the hierarchical relationships in a database view.

FIG. 2 is a schematic diagram of a computer screen showing how a first prior art technique might be used to navigate the hierarchical database view depicted in FIG. 1.

FIGS. 3a and 3b are schematic diagrams of a computer screen showing how a second prior art technique might be used to navigate the hierarchical database view depicted in FIG. 1.

FIG. 4 is a diagram showing a set of node and subtree instances (database contents) for the database view depicted in FIG. 1.

FIG. 5 is a diagram showing the node tuple set used in the preferred embodiment of the present invention to represent the database view depicted in FIG. 1.

FIGS. 6a and 6b are schematic diagrams showing the event and result tuple sets used in the preferred embodiment of the present invention to store the node and subtree instances depicted in FIG. 4.

FIG. 7 is a schematic diagram of a computer screen showing the initial data navigation structure generated by the preferred embodiment of the present invention for the database view depicted in FIG. 1.

FIG. 8 is a schematic diagram of a computer screen showing how the data navigation structure is changed by the invention as the user moves downward in the database hierarchy.

FIG. 9 is a schematic diagram of a computer screen showing how the data navigation structure is changed by the invention as the user moves downward in the database hierarchy.

FIG. 10 is a schematic diagram of a computer screen instance selection tool.

FIG. 11 is a schematic diagram of a computer screen representing the data navigation structure after an instance has been opened (selected).

FIGS. 12a and 12b are schematic diagrams of a computer screen representing the data navigation structure before and during the recording of information about an open instance.

FIG. 13 is a schematic diagram of a computer screen representing the data navigation structure after the recording of information about an open instance.

FIG. 14 is a schematic diagram of a computer screen representing a set of input forms embedded within the data navigation structure.

FIG. 15 is a schematic diagram of a computer screen representing a summary report generated by the preferred embodiment of the present invention.

FIG. 16 is a schematic diagram showing the relationships in a database view in which multiple nodes are used to specify a single database entry.

FIGS. 17a, 17b and 17c are schematic diagrams of a set of screen representations that show how values for multiple nodes are input and composed to form a single database entry.

FIGS. 18a, 18b and 18c are schematic diagrams of a database view that includes serial links (FIG. 18a) and a pair of screen representations (FIGS. 18b and 18c) that show how a serial link is presented and traversed by the invention.

FIG. 19a is a schematic diagram showing a database view that includes a parallel link;

FIG. 19b is a schematic diagram of a screen showing how a parallel link is presented and traversed by the invention.

FIG. 20 is a pseudocode example showing how the navigation process can be initiated and continued.

FIG. 21 is a pseudocode example showing how the navigation process can be initiated and continued.

In presenting a detailed description of the preferred embodiment of the invention, we will make use of examples based on a very simple clinical database. These examples are provided to illustrate certain elements of the invention. They are not to be construed as limiting the invention in any way.

In the preferred embodiment of the invention, each node in the tree representing a database view is assigned a unique identifier that encodes the path from the root node to that node. The nodes themselves are stored as a set of tuples (FIG. 5), with each tuple containing a node's identifier 51, a label 52, a descriptive phrase 53, the type of node (e.g., number, date, dose, text, file name, URL, etc.) 54, and a flag indicating whether the node automatically triggers the opening of an instance 55. This set of tuples completely describes the structure of the tree. Note that neither the tuple representation scheme, nor the node identification scheme is novel. Nor are these schemes required by the invention. Other embodiments of the invention could be easily constructed using different methods for representing a hierarchically-organized database view.

The instances (database contents) are stored using two sets of tuples: results and events (FIG. 6). Each tuple in the event tuple set 61 consists of an event identifier 62, the identifier of the corresponding node 63, and a date 64. The result tuple set 68 contains the data values themselves. Each tuple in this set consists of a node identifier 69, the identifier of the associated event 610, and a result (value) 611.

The purpose of the result tuple set is to record the entries made by the user. The event tuple set serves two purposes. First, it stores the date stamps that distinguish instances from one another. Referring to the example, FIGS. 6a and 6b show two instances of the Warfarin node. The instance corresponding to a Warfarin dose of 2.0 mg (617) is associated with event tuple 3 (66) and thus is date-stamped as occurring on 9/1/97. The instance corresponding to a Warfarin dose of 2.5 mg (618), on the other hand, is date stamped 11/4/97 because it is associated with event tuple 5 (67). In addition to providing a date stamp, event tuples are used to group data values that occur in the same subtree instance. In the example shown in FIG. 6, the result tuples corresponding to the phrases "LV size 50 cm" 612, "LV thickness 10 mm" 613, "LV function hypokinetic" 614, "RV size 20 cm" 615, and "RV function normal" 616 are all associated with event tuple 2 65 indicating that this subtree instance was recorded as part of the echocardiogram given on 5/1/97 (the node identifier "122" in event tuple 2 is the identifier of the Echo node 43 that is the root of this subtree instance 42). Note that the event and tuple representation schemes are not required by the invention. Other embodiments of the invention could be easily constructed using different methods for representing and storing the database contents (instances).

FIG. 7 is a screen representation of the initial navigation display created by the preferred embodiment of the invention. This display consists of a set of buttons: one button 72 corresponding to the root node of the database view (1 in FIG. 1) and a set of buttons 74 corresponding to the root node's children (2 in FIG. 1). These buttons are displayed below the root node's button and each is labeled with the corresponding node's label.

The user begins the data entry process by selecting from among the child buttons using a mouse, pen, or other pointing device; by entering input from the keyboard; or by issuing voice commands. When a child button is selected, the display is updated, as shown by the following example: selecting the button labeled "Tests" 73 in FIG. 7, produces the display shown in FIG. 8. The buttons for the root node's children are erased and are replaced by the button the user selected 81. A new set of buttons is then displayed 82--one button for each of the children of the selected node. In the preferred embodiment of the invention, these buttons are displayed below the root node button and offset slightly to the right--however, this offset is not necessary.

Movement further down the hierarchy continues in this same manner. At each step, a button is selected from among the latest set of choices. This button is retained, the other choices are erased, and the selected button's children are displayed. FIG. 9 shows a screen representation of the display resulting from continued movement down the hierarchy. Note that the display contains a set of buttons for the current choices 93 and a set of buttons that corresponds to the path from root node to these choices 91. In the preferred embodiment of the invention these sets are displayed using visual cues to further differentiate them (black on white for the current choices, reverse video for the path to these choices).

The path buttons 91 are used to move back up the hierarchy. At any time, the user can select one of these buttons, at which point the display is updated as follows: All of the buttons that lie below the selected button (or, more precisely, all of the buttons that lie in the subtree below the node that corresponds to the selected button) are erased and a new set of buttons is displayed--one button for each of the children of the selected node. In effect, the display is restored to that which existed when the selected button was initially chosen on the way down the hierarchy. For example, selecting the Tests button 92, restores the display to that shown in FIG. 8. Everything below the Tests button 92 is erased and the Tests node's children 82 are redisplayed. The user is then free to continue down another path in the tree by selecting the appropriate child button.

In the present invention, instances are created and updated within the framework of the navigation process and display described above. In the preferred embodiment of the present invention, instances are created as follows: The user first opens an instance--that is, creates an event tuple. She then creates the result tuples that form the instance. These result tuples are automatically associated with the event tuple.

Instances can be opened automatically or manually. We will consider the automatic case first. Each node tuple (FIG. 5) contains a flag 55 that indicates whether the node automatically triggers the opening of an instance. Selecting a button that corresponds to a node for which this flag is marked "Auto" triggers the opening of an instance of the subtree that has this node at its root. Referring to the example (FIG. 8); selecting the Echo button 83 triggers the opening of an instance of the Echo subtree--that is, the subtree which has the Echo node at its root--because the Echo node's instance flag 56 is marked as "Auto" (FIG. 5).

When the opening of an instance is triggered, the instance selection tool 101 is displayed (FIG. 10). This tool contains a button labeled "New Event" 102 and a set of buttons 103 that correspond to previously entered instances of this subtree. Selecting the New Event button 102 initiates the display of a calendar tool into which the user inputs the date stamp for the new instance. This date stamp is then used to create a new event tuple to which subsequent results tuples will be associated and the display is modified as follows (FIG. 11): The Echo button 111 is updated to include the specified date stamp and buttons corresponding to the Echo node's children are displayed 113. For example, selecting the New Event button 102 in FIG. 10 and entering the date "12/17/97" adds the tuple (8,122,12/17/97) to the event tuple set and produces the display depicted in FIG. 11.

Once an instance has been opened, data values can be entered and stored in the result tuple set. This can be done in several ways depending on the type of node.

If a node is a finding--that is, a leaf node that does not require an input value, but that is simply chosen--then selecting the button corresponding to the node results in the creation of a result tuple for that node. Referring to the example begun above, selecting the Cardiomyopathy button 114 results in the addition of the tuple (1223,"Cardiomyopathy",8) to the result tuple set, where event tuple 8 specifies the open instance of the Echo subtree. Negative information (the absence of a symptom, for instance) can be recorded using the "-" button. For example, selecting the Cardiomyopathy "-" button 115 results in the addition of the tuple (1223,"No cardiomyopathy",8) to the result tuple set.

If a node is a designated type (e.g., number, date, dose, URL, free text), then selecting the button corresponding to the node results in the display of the specialized input tool for that type of data. In the preferred embodiment of the present invention these tools are designed to fit within the physical constraints of the data navigation structure. Once the user has input a value, a result tuple is created for that node using the input value. The input tool is then erased, the input value is displayed on the button, and the data entry process continues. Referring again to the example (FIG. 12), selecting the Size button 121 results in the display of a number input tool 122. If the user inputs the number "56", then the tuple (12211,"LV size 56 cm",8) is added to the result tuple set. The Size button 134 is then modified by the addition of the result value "56 cm" (FIG. 13). In this way, the navigation structure can be used both to enter data and to provide feedback to the user regarding previously entered data.

Note that the various button markings (labels, recorded values, and so forth) are restored each time a button is displayed. For example, selecting the Echo and Left Ventricle buttons in succession will repeat the progression down the hierarchy performed above and will restore the display to that shown in FIG. 13.

The invention includes support for hierarchically-structured forms-based data entry. In the preferred embodiment of the invention, a node can be designated as a "form" node. When a form node is selected, its children's buttons include concise "fill in the blanks" input boxes that are embedded within the navigation structure and into which the user can enter data. For example, if the node corresponding to the Right Ventricle button 112 is a form node, then selecting this button generates the display shown in FIG. 14. The Size button 141 requires numeric input and thus incorporates a numeric input box 142 into which the user can enter a numeric value. Nodes that have children generate a selection box (or combo box) that is populated with these children. For example, the Function button 143 corresponds to the Right Ventricle Function node (3 in FIG. 1), which has three children: Normal 4, Hypo 5, and Hyper 6 (in FIG. 1). These children provide the options listed in the Function button's selection box 144 (shown with the box expanded to reveal the options). The user then selects from among these options.

The present invention also provides for the inclusion of free text comments, graphics, and voice annotations about a node or, more precisely, about the subtree rooted at a node--as well as the inclusion of the names of related data files and the URLs of related HTML documents. This allows the invention to integrate multiple data sources by combining structured information (entered by the user via the data entry process described above) with unstructured commentary and links to supporting materials. In the preferred embodiment of the invention, freeform input is limited to text. Voice and graphical annotations are obvious extensions to this embodiment, however.

In the preferred embodiment of the present invention, a report summary listing the information stored on a patient is automatically generated and updated as data is entered (FIG. 15). This report displays the stored information in a structured form in which the recorded subtree instances 155, 156, 157, 158 are shown within appropriate categories 151, 152, 153, 154. All of the information recorded about an instance is displayed, including, all findings and results, as well as any text commentary, file names, and URLs.

The data entry navigation process can be controlled (in part) from within the report summary. Selecting an entry in the report unrolls the navigation structure to the node associated with selected report entry. Referring back to the example, selecting the entry "LV size 56 cm" 159 in the report display results in the navigation structure opening automatically to reveal the Left Ventricle Size button 1511--including opening the Echo subtree instance for 12/17/97 1510.

In the present invention, an instance is closed whenever the user selects a button that is higher in the hierarchy than the button that corresponds to the root of the instance subtree. For example, selecting the Tests button 132 in FIG. 13 closes the Echo subtree instance corresponding to event tuple 8 (Echo 12/17/97). This results in a return to the display shown in FIG. 8. Similarly, selecting the Cardiac button 131 results in a return to the display shown in FIG. 7. A new instance must then be opened before any new information can be recorded.

An instance can also be closed using the "instance folder" button 133. Selecting this button closes the current instance and prompts the user to open another instance of the same subtree. Referring back to the example, selecting the Echo node's "instance folder" button 133 closes the current Echo subtree instance (event tuple 8) and results in a return to a display similar to that shown in FIG. 10 (with the addition of the event "Echo 12/17/97"), at which point the user is prompted to open another (new or existing) instance of the Echo subtree.

The invention also allows instances to be opened manually. In the preferred embodiment of the invention, if an instance is not already open, then selecting a node's "+" or "-" button will manually trigger the opening of an instance of the subtree rooted at that node. Selecting the Symptoms button's "+" button 75 (FIG. 7), for instance, results in the display of the instance selection tool for the Symptoms node. The user then opens a subtree instance whose root is the Symptoms node in precisely the same manner as was done with the Echo node above. For example, entering the date 12/21/97 would add the tuple (9,11,12/21/97) to the event tuple set. The user could then add information about the patient's cardiac symptoms to this open Symptoms instance using the processes outlined above.

Once an instance has been closed, the information associated with the instance can be updated by simply reopening the instance and adding new results or deleting existing results. Referring back to the example, selecting the button labeled with the date "11/16/97" 104 in FIG. 10 will open the existing Echo subtree instance associated with the event tuple (7,122,11/16/97) for review and updating. New results can then be added using the processes described above.

Up to this point, we have assumed that each entry in the database corresponds to a single node in the database view. In many cases, it will be necessary--or, at a minimum, significantly more efficient--to synthesize a database entry based on information from several nodes in the database view. FIG. 16, for example, shows a simple coronary lesion subtree. Fully describing a single lesion requires selecting one node from each of the Artery 161, Location 162, and Severity 163 subtrees. The information in these nodes is then composed to form the database entry for a lesion. Collectively, for example, the LAD 164, Proximal 165, and Moderate 166 nodes specify the lesion "moderate stenosis of the proximal left anterior descending coronary artery" and it is this entry that is stored in the database. Note that in this case, the individual nodes are not meaningful unto themselves, but are only meaningful when included as part of the context in which they are embedded. For example, "Moderate Stenosis" is only meaningful when used within a context that includes an artery and a location.

Hierarchical database views of this form dramatically reduce the number of nodes required to represent a given set of database relationships. Converting the Lesion tree to one in which each database entry corresponds to a single node would entail placing the Severity subtree below each leaf node in the Location subtree and placing this nested Location/Severity subtree below each leaf node in the Artery subtree--thereby producing a tree with more than twice as many nodes (3.sup.3 +1=28 nodes, to be precise). Note that as options are added to the Artery, Location, and Severity subtrees, the size of this tree will increase exponentially. The Lesion tree shown in FIG. 16, on the other hand, will only increase linearly in size.

In the preferred embodiment of the present invention, nodes can be designated as "compound findings". Entering the data that comprises a compound finding is done by selecting one node in each of the subtrees of the compound finding node. FIG. 17 shows the display 171 generated from the Lesion subtree in FIG. 16. The buttons corresponding to the Lesion compound finding node's children 172 are grouped together to visually communicate that these buttons are part of a compound finding. Note that although there are no horizontal divisions between them, these are still separate buttons. Navigation further down the hierarchy 173 proceeds in precisely the manner discussed above, with one significant exception: as soon as a result is selected within a subtree--say, for instance, the user selects the LAD button 174--control immediately returns back to the compound finding level 175. A checkmark 178 is used to indicate that a value has been selected for the Artery subtree and the phrase "Lesion: left anterior descending coronary artery" is displayed 177. The compound finding is recorded to the database (as a single result) either when a value has been selected for each of the subtrees or when the user selects a button above the Lesion button 176 that delineates the compound finding.

The present invention also supports database views that are not pure hierarchies, but which contain multiple paths between nodes (or hierarchies). Such views are referred to as directed acyclic graphs and are commonly used in database systems to reduce the need for the entry (and storage) of redundant data and to allow data to be viewed within multiple contexts. The database view shown in FIG. 18, for example, contains the Chest X-ray hierarchy 183 within both the Cardiac Tests 181 and Pulmonary Tests 182 hierarchies reflecting its use in diagnosing conditions in both medical specialties.

In the preferred embodiment of the present invention, these non-hierarchical links 184, 185 are represented using a designated set of serial links. Whenever a node that is the source of a serial link is encountered, the serial link's target node is automatically displayed in place of the link's source node. Suppose, for example, that the user is entering information about Cardiac Tests 186. In this case, the Chest X-ray button 187 is automatically associated with the root node of the Chest X-ray subtree 183 that is the target of the serial link 184. Selecting the Chest X-ray button 187 results in the display of a set of buttons 188 that correspond to the children of the root node of the Chest X-ray hierarchy 183. Similarly, if the user were to encounter Chest X-ray within the Pulmonary Tests hierarchy, the Chest X-ray hierarchy would be displayed as though it were part of Pulmonary Tests. Note that information recorded as part of the Chest X-ray hierarchy can be reviewed or updated at a later date using either the Cardiac Tests or Pulmonary Tests hierarchy--regardless of which hierarchy was originally used to record the Chest X-ray data.

The present invention also supports the parallel traversal of multiple branches. These parallel traversals can be triggered automatically (as parallel navigation structures), thereby providing a means for signaling that a relationship exists between data items and a method for reviewing related data items in context.

In the preferred embodiment of the invention, a designated set of parallel links is maintained. Whenever a node that is the source of a parallel link is traversed, a new navigation structure that contains the link's target node is automatically displayed beside the original navigation structure. The user is then free to move up and down either navigation structure. The new (parallel) navigation structure is closed (and no longer displayed) whenever the user selects a node that is higher in the hierarchy than the node that originally triggered the display of the parallel structure.

The database view shown in FIG. 19, for example, includes a parallel link 193 from the Warfarin node 192 to the Protime node 191 reflecting the relationship between the medication Warfarin and the laboratory test for Protime. Whenever the user traverses the Warfarin node 194, the navigation structure containing the Protime node 195 is automatically generated. Selecting a node above the Warfarin node 194 automatically closes the Protime navigation structure 195. Note that a node can be the source of multiple parallel links. However, in the preferred embodiment of the invention, only one parallel navigation structure is displayed at a time. The user moves between the parallel navigation structures using a simple slider control 196.

The methods forming the present invention are depicted in pseudocode form in FIG. 20 and FIG. 21.

The navigate() function 201 controls the generation and processing of the navigation structure. Assignment statements 202 initialize path set P={root node of the database view} and child set C={children of the root node}. Loop-until structure 203 then makes repeated calls to the generate.sub.-- structure() function 204, with each call reflecting user-initiated changes in set P, set C, and the underlying database (i.e., the event and result tuple sets). These calls terminate when the user selects the Close button on the root node 71.

The generate.sub.-- structure() function 204 creates the navigation structure for the current set of path nodes (P) and child nodes (C). For-loop structure 205 displays the cascading set of buttons--one button for each node in set P. The buttons are displayed one below the other, with each button slightly offset to the right from the button above

For-loop structure 206 displays a linear set of buttons--one button for each node in set C. The buttons are displayed in a column, one below the other. If a child node is the source of a serial link, then if-selection structure 207 replaces the child node with the node that is the target of the serial link. The remaining code then processes this target node in place of the child node. If-selection structure 208 displays a stored value on a button if the open subtree instance contains a result tuple for the corresponding node.

Loop-until structure 209 waits for the user to select a button. A call 2010 to the update.sub.-- sets() function 211 is then made to update sets P and C in response to the button the user selected.

The update.sub.-- sets() function 211 updates set P, set C, and the underlying database based on the button selected by the user (button.sub.-- pressed) in the generate.sub.-- structure() routine 204.

If-selection structure 212 determines whether the button selected corresponds to one of the path nodes (P). If it does, then assignment statement 213 truncates set P to include only those nodes leading up to and including the selected node. If-selection structure 214 then checks whether the button selected is above the root node of the open subtree instance. If so, then the open instance is closed and if selection structure 215 is used to close any parallel navigation structures that may also be open.

Else-if-selection structure 216 determines whether the button selected corresponds to one of the child nodes (C). If it does, then a variety of tests are performed to determine the consequences of selecting this child node. Note that the following tests are performed sequentially and are not mutually exclusive.

If-selection structure 217 determines whether the selected child node is an automatic trigger for opening an instance (based on the information in the corresponding node tuple). If it is, then the instance selection tool is displayed and a (new or existing) subtree instance is opened based on the input date. Note that this may entail creating a new event tuple or referencing an existing tuple. Assignment statement 218 moves the selected child node to the path set, assignment statement 219 creates a new child set containing the children of the selected node, and assignment statement 2110 marks the relative position of the selected node (which defines the open subtree instance) within the path set.

If the selected child node corresponds to a finding, then if-selection structure 2111 stores the corresponding result in the database (as a result tuple). If the selected child node corresponds to a predefined type, then else-if-selection structure 2112 displays the corresponding data input tool and stores the input value in the database (as a result tuple).

If-selection structure 2113 determines whether the selected child node has children of its own. If it does and if the selected child did not open a new instance through if-selection structure 217, then assignment statement 2114 moves the selected child node to the path set and assignment statement 2115 creates a new child set containing the children of the selected node.

Finally, if-selection structure 2116 checks whether the selected node is the source of a parallel link. If it is, then a new parallel navigation structure is displayed with path node set Q={Q.sub.1,Q.sub.2, . . . , Q.sub.k' } and child node set D={D.sub.1,D.sub.2, . . . ,D.sub.m' }, where {Q.sub.1,Q.sub.2, . . . , Q.sub.k'-1 } is the set of nodes on the path to the node Q.sub.k' that is the target of the parallel link and {D.sub.1,D.sub.2, . . . , D.sub.m' } is the set of children of node Q.sub.k'.

The foregoing disclosure of embodiments of the invention has been presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many variations and modifications of the embodiments described herein will be obvious to one of ordinary skill in the art in light of the above disclosure. The scope of the invention is to be defined only by the claims appended hereto, and by their equivalents.