Method for generating a display utilizing objects in an object list

Input to the system is buffered by the forms manager to determine access to the tile/region and to check entered data. The tile/region will retain various information such as data entered, user, time, changes, etc. To display a form, the forms manager obtains a list of objects to be displayed. This list of objects is then edited to remove objects which are not utilized and to place the remaining objects in a prioritized order. The forms manager then generates the display.

RELATED INVENTIONS

The present invention is related to the following inventions, all assigned to the assignee of the present invention:

System Control Structure of a Hospital Information System and Method of Using Same, invented by John Brimm et al., having U.S. Ser. No. 116,614, and filed on Nov. 3, 1987, U.S. Pat. No. 4,878,175;

Medical Information System With Automatic Updating of Task List In Response to Charting Interventions On Task List Window Into An Associated Form invented by John Brimm et al., having U.S. Ser. No. 268,822, and filed on Nov. 7, 1988, now U.S. Pat. No. 5,077,666;

Clinical Task List with Charting onto Underlying Form and Automatic Updating of Task List, invented by John Brimm et al., having U.S. Ser. No. 268,323, and filed Nov. 7, 1988, now U.S. Pat. No. 5,072,383;

A Method for Displaying Information from an Information Based Computer System, having Ser. No. 07/407,979 and filed on Sep. 15, 1989;

Spreadsheet Cell having Multiple Data Fields, having Ser. No. 07/408,166 and filed on Sep. 15, 1989;

A Method for Displaying Information from an Information Based Computer System, having Ser. No. 07/407,836 and filed on Sep. 15, 1989;

Method for Updating Data in a Database, having Ser. No. 07/408,167 and filed on Sep. 27, 1989;

Method for Storing a Transaction in a Distributed Database System, having Ser. No. 07/408,169 and filed on Sep. 15, 1989;

A Method of Forming a Spreadsheet Display, having Ser. No. 07/407,972 and filed on Sep. 15, 1989; and

BACKGROUND OF THE INVENTION

The present invention relates, in general, to a process of controlling the input and output of data in a computing system and, more particularly, to a process of managing the form of input and output with the use of tiles consisting of one or more cells.

In the art, there are various types of input and output buffers. However, this is typically handled using two different buffers, one for inputs and one for outputs. A typical input is generated by some type of user interface such as a keyboard, mouse, track ball, or the like. The output is typically provided on a cathode ray tube (CRT), flat screen display, or like device generally classified as operator display modules (ODM)

The output function of a forms manager is to take the information to be displayed and arrange it in the order dictated by a form. In prior art forms managers, the form of the output is predetermined and stored somewhere in the system. The forms manager does not have the capability to modify the form dependent upon the user or information being displayed.

These types of prior art forms managers have the disadvantage of having to display an information field whether the field is used or not. By way of one specific example, in the area of medical records, there are numerous types of information that can be maintained for any one particular patient However, rarely does one patient require that all of the types of information be maintained. Therefore, it is a disadvantage for the forms manager to display blank spaces when that particular area is not being monitored. By displaying these blank areas, the size of the display is greatly increased making it impossible to display all of the information on one or two screens There may also be screen displays that have no data on them.

In addition, it is often necessary, for record keeping and security, to: limit access to particular portions of the display; keep track of who enters the data; and to insure that the data is entered correctly. Therefore, there is a requirement in the industry that the forms manager also interact with the input side of the systems.

Accordingly, it is an object of the present invention to provide a forms manager which overcomes the above deficiencies.

It is a further object of the present invention to provide a forms manager that acts as an input and output buffer.

Another object of the present invention is to provide a forms manager which customizes the form to the information being displayed.

Still another object of the present invention is to provide a forms manager which utilizes tiles, or windows, to display information.

Yet another object of the present invention is to provide a forms manager which may be used to provide data entry and access security to tiles

Another object of the present invention is to provide a forms manager which operates independently of the applications allowing the forms to be modified without requiring a change in the application.

SUMMARY OF THE INVENTION

A particular embodiment of the present invention consists of a forms manager which first obtains a list of objects to be displayed. The tiles associated with these objects are then obtained from a data base of various tiles. The tiles, and associated objects, are then ranked in order for display. Finally, the tiles and their associated objects and data are displayed.

DETAILED DESCRIPTION OF THE DRAWINGS

As used herein, the term “tile” will refer to a set of rules for displaying data of an object and a list of objects that it may display. A “group” is a collection of related tiles and a “form” is a collection of groups and/or tiles.

A tile is comprised of “cells” each cell having a related “object”. The object may be either text, numerical, or a combination thereof. A tile is similar to a window with the exception that tiles do not overlap as is permitted with windows. It should be understood that, if the application permits, the present invention may be utilized with windows and as such the term tile may be taken as synonymous with window. A description of windows is provided in Scheiflen & Gettys, “The X Window System”, ACM Transactions on Graphics, Vol. 5, No. 2, pg. 79-109 (April 1986).

Referring initially toFIG. 1, a block diagram, generally designated10, representing the function of the present invention within a data processing system is illustrated. A forms manager11is used as an interface, or buffer, among and between the input, output, and system applications and databases.

An input device12is coupled to forms manager11. Input device12is illustrated as a keyboard with a joy stick but may be any type of input device In general, the communication is from input device12to forms manager11. However, there may be a need for forms manager11to operate visual or acoustic devices on input device11. For this reason, there may be some communication from forms manager11to input device12.

Also coupled to forms manager11is an operator display module13. Display13is typically a cathode ray tube, but may be any of numerous types of displays such as the various types of flat panel displays Communication is generally from forms manager11to display13. However, a touch sensitive screen or other type of input device may be incorporated in the system requiring communication from display13to forms manager11.

Forms manager11also interacts with the application programs14and the databases. The databases, for this particular example, are broken into a general database15and a specific database16. It should be understood that while the database may be functionally separated, both may be contained in the same physical location

In operation, objects are entered through input device12to the forms manager. This input is checked and stored in database16for the particular patient. When a form is to be displayed, forms manager11obtains a list of objects to be displayed. One source of objects is application program14. The forms manager then retrieves the tiles associated with the objects from database15. The data to be placed in the tiles is then obtained from database16. Using these inputs, forms manager11develops a form which is displayed on display13.

The input operation of the present invention is illustrated inFIGS. 2A and 2B. A pseudo code listing of the keyboard operation is shown in Appendix A. The line numbers in parentheses refer to code lines in Appendix A. InFIG. 2A, a process flow diagram of a keyboard input process embodying the present invention is illustrated. The process commences with the depression of a key on the keyboard, step20. The process then proceeds to a decision block21where a determination is made as to whether an item on the form has been selected (line6). If an item has not been selected, the process moves to block22where an error message is printed (line7) and the process exits the routine.

If an item on the form has been selected, the process moves to decision block23. In decision block23, the forms manager determines whether the selected item is enterable by the user (line10). If the item is not enterable by the user, the process moves to block24where an error message is printed (line11). Following the error message, the process exits the routine.

If the item is enterable by the user, the process moves to a decision block25. In decision block25, the forms manager determines whether the key was a terminator (line14) such as a return key, enter key, tab key, or the like. If the key was not a terminator key, the process moves to decision block26. In decision block26, the forms manager determines if the key represented a valid character for that item (line19). By way of example, the item may be limited to numeric input only; in which case any alpha input would be rejected. If the key does not represent a valid character, the process moves to block27. In block27an error message is printed (line27) and the process exits the routine.

If the key represents a valid character, the process moves to block29. In block29, the valid character is appended to an item value for the selected item (line20-23). The process then exits the routine.

If the key was a terminator, the process moves from decision block25to block28. In block28the item value, created in block29, is stored in a buffer (line15). Following block28is block30where a “New Event” signal is generated (line16) to inform the application that a new item value is present.

A similar process takes place when a pointing device (i.e. mouse, joy stick, roller ball, etc.) is utilized as the input device. This process is illustrated inFIG. 2Bwhich is a flow chart of a pointer input process embodying the present invention. A pseudo code listing for performing this function is contained in Appendix B. The line numbers in parentheses refer to code lines in Appendix B. The processes commences at a block35where a pointer input is received.

The process then moves to a decision block36. In decision block36, the forms manager determines if the pointer is on an active form (line5). If the pointer is not in an active form, the process moves to block37. Block37causes an error message to be printed (line6). The process then exits the routine.

If the pointer is on an active form, the process moves from decision block36to decision block38. In decision block38the forms manager determines if the pointer is over a selectable item (line9). If the item is not selectable, either generally or by that user, the process moves to block39. Block39causes an error message to be printed (line10). The process then exits the routine.

If the pointer is over a selectable item the process moves from decision block38to decision block40. In decision block40, the forms manager determines whether the pointer is over a pop-up window (line13). If the pointer is not over a pop-up window, the process moves to a block41. In block41a “select” event is generated lines (18-27) indicating the item at which the pointer was directed. The select event may permit the entry of data into the item selected or may cause a pop-up menu to be formed.

If the pointer is over a pop-up menu, the process moves from decision block40to block42. Block42causes an event associated with the selected item to be generated (line14). This event may be the entry of data, the correction of previously entered data, a request to show more detail, or the like. Following block42, the process exits the routine.

The process of entering data by the user is classified as an event. More precisely, an event is a user action or set of user actions which are of interest to the application.

The events are placed in a queue by the forms manager, steps30and42ofFIGS. 2A and 2B, respectively. This queue of events is maintained by the forms manager until acted upon by the applications program. Periodically, the application program will request the next event from the forms manager.

In the output operation, the forms manager is directed to display a particular form containing objects (text/data). In the present invention, the text/data to be displayed dictate the shape of the form rather than the form dictating how the objects are displayed. A sample form, generally designated50, is illustrated in FIG.3. Form50illustrates two groups of tiles, a vitals group51and a labs group52. Vitals group51contains four tiles: a heart rate tile53, a blood pressure tile54, a temperature tile55, and a respiration rate tile56. The labs group consists of: a CBC/HGB (Complete Blood Count/HemoGloBin) tile57, a CBC/HCT (Complete Blood Count/HematoCriT) tile58, a K+(Potassium) tile59, a Na (Sodium) tile60, a BUN (Blood Urea Nitrogen) tile61, and a CREAT (CREATinine) tile62.

Each tile53-62comprises several cells. For example, heart rate tile53has a group cell53A and a title cell53B. In a group, such as group51, the name of the group may or may not be printed. Generally, only the first tile in the group, here tile53, will designate the group name. Cell53B contains the title; here the title is “Heart Rate”. The remaining cells of tile53are data cells53C. One cell53C is provided for every time period listed on the display. Cells53C are spreadsheet type cells in that they repeat with time whereas regions53A and53B are non-spreadsheet cells that do not repeat with time. In tile54, the group cell54A is left blank since the group is displayed previously. However, the object cell54B of tile54is labeled Blood Pressure. The data cells54C of tile54are then aligned with the time intervals.

There is generally more than one type of tile for each category. One tile53may be provided to display its regions in either a horizontal fashion, as inFIG. 3, or in a vertical fashion by a tile53′, as shown in FIG.4. In this particular embodiment, the tiles are formed of rectangles. Each region in a tile will have the same height in horizontal tiles and the same width in vertical tiles. The height (width) of a horizontal (vertical) tile is determined by the space required by the largest region of the tile. Typically, this cell will be the object region, such as region54′B, FIG.4.

In addition to the two standard types of tiles (horizontal and vertical) there may be other tiles displaying the data in different fashions. For example, blood pressure cell54C will typically display three types of data, X, Y, and Z, representing the high pressure (X), low pressure (Y), and the average pressure (Z). InFIGS. 5A-5C, three different ways are illustrated to display this data. The dimensions of the cells and tiles will vary depending on the display desired

Each tile may be designed to contain numerous types of information, both displayed and not displayed. For example, the basic type of information is whether a cell contains data or text. A text (data) cell of a tile can be set to prohibit the entrance of data (text). The physical size and shape of the cell and tile is also maintained in the tile definition. The display rules are in the tile definition indicating, for example, which cell display format (refer toFIGS. 5A-5C) will be used. Each tile also has an associated name and/or ID number with which it is referenced.

Various security measures are also contained within the tile/cells descriptions. These security measures take the form of whether a tile/cell may be accessed and by whom. For example, you would not ordinarily allow access to the group and title cells. These are preset and are to be changed only by the system administrator. In other areas, such as the data areas, you want the general nursing population of the hospital to be able to enter data. However, it would also be desirous to know who entered the data and exactly when it was entered. While the charts may be broken down into half-hour segments, the vitals may not be taken right on the half-hour, so you will want to keep a record of the exact time and who entered the data. An additional security measure is whether data may be changed once it has been entered. While you do not want to have data changed at a later date, it is important that the data illustrated is accurate. Therefore, a tile/cell will retain the original entry and who made it; and the changed data and who made the changes. When a cell is displayed that has had data changed, this region will be offset from the other data by a marker, different color, flashing display, or the like.

The time of the data may be broken down further into when the readings were made and when they were actually entered into the system. The tile/cell definitions may also perform a data integrity check to ensure the entered data is not obviously incorrect. For example, in temperature tile55, if the temperature 986° C. is accidently entered rather than 98.6° C., the system will recognize this as an error and alert the individual making the entry. In addition, if an entry is outside a normal range, but still valid, this entry may be offset from the rest of the data in a fashion described above with respect to the changed data.

In this particular embodiment, tiles are designed to display the various forms of objects. There is not one tile for each object but one tile for each form of object. When the forms manager seeks to display a particular object, it determines which tile is associated with this object and retrieves that tile. As an example, Potassium (K+) tile59and Sodium (Na) tile60would be the same form of tile. The difference would be the title displayed in title cells59B and60B and the data entered into spreadsheet data cells59C and60C.

Another feature of the tiles of the present invention is that a cell of a tile may be associated with a menu of possible actions with event codes. An example of this is provided in FIG.6. InFIG. 6, the operator has selected cell65of temperature tile55. When this is selected, a pop-up menu will appear, such as menu70, having the possible actions which may be undertaken in cell65of tile55.

As shown inFIG. 6, menu70is illustrated with three options. The first event is to make an entry. This is selected when an entry is first being made to the cell. The second event is to correct an entry. This is selected if the cell has been previously accessed. The third region is labeled “SHOW DETAIL”. This region is selected to show the details such as the time of entry, the person who made the entry, or other similar information. As an alternative to the pop-up menus, a series of soft keys may be utilized. This would provide a pop-up, or existing menu window, with a list of keys, generally function keys, that are assigned for one of the events listed above. These soft keys may have different functions assigned by the particular region being accessed A process for generating a form embodying the present invention is illustrated in the flow chart of FIG.7. This process is illustrated in pseudo code in Appendix C. The following lines contained in parentheses refer to the line numbers of Appendix C. Initially, a request, box80, for a new form is received by the process (line3). The system then goes to decision box81and decides if there is an object list in existence for this particular form (line If there is no list of objects associated with this form, the process moves to step82where an object list is built from the form definition (line10). An object list may come from three different sources: a list associated with the form; a list entered at the time of the form generation request; or a list provided by an application program.

Once the object list has been generated, the process moves on to step83where objects are assigned to tiles (lines12,13). For example, if the object is the “Heart Rate”, then the tiles would be checked to see which tile was associated with “Heart Rate”.

Next, in step84, the draw point is moved to the top, or some designated home point, of the display (lines15-17). A decision is then made in step85as to whether there are objects/tiles to be drawn (lines19-20). If there are no tiles to be drawn, the process moves to step86and ends. If there are tiles to be drawn, the process moves to step87where the object/tile is drawn (lines21-54). Once drawn, the process moves to step88where the draw point is moved to the next position (line55).

This process would generate a display such as that illustrated in FIG.3. However, there are generally so many objects which may be monitored for a particular patient, that not all of the objects may be displayed in one screen. Since it is unnecessary to display objects which are not being monitored, the elimination of these objects will leave more room on the display for objects that are being monitored.

As an example, of the objects displayed inFIG. 3, if temperature, CBC/HGB, and CBC/HCT are not being monitored, then display space is being taken up with empty, unutilized space. To avoid this and to provide a more efficient display, the forms manager will not display items that are not being monitored. The display would then appear as shown in FIG.8. Here, the three objects that are not being utilized have been eliminated and the form adjusted to remove the tiles associated with those objects. This will leave room at the bottom of the display for additional tiles that were not displayed in the form of FIG.3.

In addition to the above, the forms manager will place the objects in any order specified in the listing of objects that is provided or generated. For example, if a particular doctor prefers to view the blood pressure, tile54, as the first object, this can be indicated in the form description, and the forms manager, when the display is created, will place this tile first. In addition, the forms manager may be set to inter-mix objects from the various groups if desired. An example of this is illustrated in FIG.9.

InFIG. 9, the tiles have been arranged by the forms manager in order of a priority that was provided with the description of the form. In a medical setting, there may be one generally form for the hospital used by the nursing staff and a different form for doctors. Further, particularly for specialists who do not desire to see everything or who desire to see certain information (objects) first, there may be forms established for each doctor.

Therefore, the process ofFIG. 7may be provided with the additional steps shown in FIG.10. These steps may be inserted between decision step81and step84and may be in any order desired. Following step81is step89in which any objects which are not being monitored from the object list are eliminated from the object list. Next, in decision step90, the process looks to see if there is a priority list associated with the form. If there is no priority list, the process moves to step91where a default priority list is used to arrange the objects. If there is a priority list for the form, the process moves to step92where the objects are arranged according to the priority list. The process then moves to step83.

As indicated above, the assignment of objects to tiles, in step83, may occur before, during, or after the steps set out in FIG.10.

Therefore, as stated above, the present invention creates a form to fit the objects being displayed rather than fitting the objects to the form.

Thus, it will be apparent to one skilled in the art that there has been provided in accordance with the invention, a process and method that fully satisfy the objects, aims, and advantages set forth above.

While the invention has been described in conjunction with specific embodiments thereof, it is evident that many alterations, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description. Accordingly, it is intended to embrace all such alterations, modifications, and variations in the appended claims.

APPENDIX A234fm_click (key)56if item not selected7error - “Keyboard inactive when nothing selected”8exit910if selected item not enterable11error - “Item not enterable”12exit1314if key is a terminator15store item value in database16generate NEW event17exit1819else if key is a valid key20if this is the first key in this item21set item value to blank2223add key to item value24exit2526else27error - “Invalid key”28exit29

APPENDIX B23fm_point (position)45if position not on current form6error - “Not on active form”7exit89if position not on selectable item10error - “Item not selectable”11exit1213if position over popup menu14generate action associated with popup menu item15exit1617else18if there is a currently selected item19if position is over selected item20generate DESELECT action for item2122else23generate DESELECT action for selected item24generate SELECT action for item at position2526else27generate SELECT action for item at position2829exit30

APPENDIX C23fm_new (form_name, object_list)45read form definition67if object list supplied8make local copy of object list9else10create object list from form definition1112for each object in object list13find tile in form which displays object1415draw point = (0,0)16last tile = NONE17last group = NONE1819for each object on object list20do21set this tile to tile containg object22set this group to group containing tile2324if this group != last group2526if last tile != NONE27draw end of last tile28draw point = end of last tile2930if last group != NONE31draw end of last group32draw point = end of last group3334last group = this group35last tile = this tile3637draw beginning of this group38draw point = beginning of this group3940draw beginning of this tile41draw point = beginning of this tile4243else if this tile != last tile4445if last tile != NONE46draw end of last tile47draw point = end of last tile4849last tile = this tile50draw beginning of this tile51draw point = beginning of this tile525354draw this object55draw point = end of object56done5758if last tile != NONE59draw end of last tile60draw point = end of last tile6162if last group != NONE63draw end of last group6465exit