WO2011001248A1

WO2011001248A1 - A graphical user interface displaying data relating to the family of a patient in a medical information system

Info

Publication number: WO2011001248A1
Application number: PCT/IB2010/001568
Authority: WO
Inventors: Mahendra Kumar
Original assignee: Isoft Applications Limited
Priority date: 2009-06-30
Filing date: 2010-06-29
Publication date: 2011-01-06
Also published as: AU2009208058B1

Abstract

Disclosed is a graphical user interface (600) displayed on a computer display of a medical information system (100). The graphical user interface comprises: a graphical object forming a main node (650) corresponding to a patient in the medical information system; and graphical objects forming a plurality of nodes (e.g. 630) corresponding to family members of the patient arranged in a tree structure reflecting the family tree of the patient. Hovering, by a user of the graphical user interface, a cursor over a node (e.g. 630) causes additional data about the corresponding patient or family member to be displayed,

Description

A GRAPHICAL USER INTERFACE DISPLAYING DATA RELATING TO THE

FAMILY OF A PATIENT IN A MEDICAL INFORMATION SYSTEM

Technical Field of the Invention

The present invention relates generally to medical information and, in particular, to graphical user interfaces for medical information systems.

Background

Computers are now ubiquitous in modern society. They are used in many different applications, including by individuals in their homes and their places of work. In many commercial applications there is a need for computer systems which efficiently receive, process and store data. In many applications it is important that data is handled resiliently, reliably and securely. The security requirements of many applications require not only that access to data is closely controlled, but also that data is handled in such a way as to avoid data corruption.

In recent years, much attention has been focussed on the way in which humans interact with computers. Indeed, much research has been carried out in an area known as human-computer interaction. When computers first became popular, they provided interfaces which were primarily or solely text based. More recently graphical user interfaces have become widely used. Considerable research continues to be carried out so as to devise user interfaces which allow users to more efficiently interact with computers.

Medical information systems are one instance where graphical user interfaces

(GUIs) have been applied to improve ease of use by medical practitioners. However, GUIs for conventional medical information systems are primarily focused on display and update of information pertaining to a single patient (referred to herein as the "Electronic Patient

Record", or EPR, of the patient). This can be a disadvantage when dealing with medical conditions with a genetic element where knowledge of that patient's family history would be beneficial to the practitioner.

Summary

It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

According to a first aspect of the present invention, there is provided a graphical user interface displayed on a computer display of a medical information system, the graphical user interface comprising:

a graphical object forming a main node corresponding to a patient in the medical information system; and

graphical objects forming a plurality of nodes corresponding to family members of the patient arranged in a tree structure reflecting the family tree of the patient; _

wherein hovering, by a user of the graphical user interface, a cursor over a node causes additional data about the corresponding patient or family member to be displayed.

According to a second aspect of the present invention, there is provided a medical information system displaying a graphical user interface on a computer display of said system, said system comprising:

a memory for storing data and a computer program; and

a processor coupled to said memory for executing said computer program, said computer program comprising instructions for:

displaying a graphical object forming a main node corresponding to a patient in said medical information system; and

displaying graphical objects forming a plurality of nodes corresponding to family members of the patient arranged in a tree structure reflecting the family tree of the patient; wherein hovering, by a user of the graphical user interface, a cursor over a node causes additional data about the corresponding patient or family member to be displayed.

According to a third aspect of the present invention, there is provided a method of displaying data related to the family of a patient on a computer display of a medical information system, the method comprising:

displaying, as a graphical object on said display, a main node corresponding to a patient in said medical information system; and

displaying, as graphical objects on said display, a plurality of nodes corresponding to family members of the patient arranged in a tree structure reflecting the family tree of the patient;

wherein hovering, by a user of the medical information system, a cursor over a said node causes additional data about the corresponding patient or family member to be displayed.

According to a fourth aspect of the present invention, there is provided a computer readable medium having a computer program recorded therein for displaying data related to the family of a patient on a computer display of a medical information system, said computer program comprising:

code for displaying, as a graphical object on said display, a main node corresponding to a patient in said medical information system; and

code for displaying, as graphical objects on said display, a plurality of nodes corresponding to family members of the patient arranged in a tree structure reflecting the family tree of the patient;

wherein hovering, by a user of the medical information system, a cursor over a said node causes additional data about the corresponding patient or family member to be displayed. Other aspects of the invention are also disclosed.

Brief Description of the Drawings

At least one embodiment of the present invention will now be described with reference to the drawings, in which:

Figure 1 is an overview of a network of computers on which embodiments of the present invention may be practised;

Figure 2 is a schematic illustration showing the server and the data store of Figure 1 in further detail;

Figure 3 is a schematic illustration of a database access control architecture suitable for managing access to healthcare data;

Figure 4 is a schematic illustration of a hash algorithm used in the architecture of Figure 3;

Figure 5 is a partial illustration of a database schema;

Figure 6 illustrates a Graphical User Interface (GUI) used to display data relating to the family of an person;

Figures 7a, 7b, and 7c illustrate a Sticky Notes portion of a GUI;

Figures 8a, 8b, and 8c illustrate an Image Browser portion of a GUI;

Figures 9a and 9b form a schematic block diagram of a general purpose computer system that may be used to implement the clients and server of Figure 1 ;

Figure 10 is a flowchart illustrating a method of implementing the GUI used to display data relating to the family of a person;

Figure 1 1 is a flowchart illustrating a method of implementing a Sticky Notes portion of the GUI; and Figure 12 is a flowchart illustrating a method of implementing an Image Browser portion of the GUI.

Detailed Description

Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

It is to be noted that the discussions contained in the "Background" section and that above relating to prior art arrangements relate to discussions of documents or devices which form public knowledge through their respective publication and/or use. Such should not be interpreted as a representation by the present inventor(s) or the patent applicant that such documents or devices in any way form part of the common general knowledge in the art.

Referring to Figure 1 , there is illustrated a medical information system 100 on which embodiments of the present invention may be implemented. It can be seen that three client computers 1 , 2, 3 access services provided by a server 4 over a network 5.

The client computers 1, 2, 3 can take any convenient form. For example in some embodiments some client computers 1 , 2, 3 take the form of desktop computers, others take the form of laptops, while others take the form of tablet PCs. As described in detail below, each of the client computers 1 , 2 and 3 may be implemented as a general purpose computer system 900 collectively shown in Figures 9a and 9b. However the client computers can also take the form of mobile devices such as mobile telephony devices or personal data assistants (PDAs). The network 5 can be any suitable network which provides effective communication between the client computers 1 , 2, 3 and the server 4. For example the network 5 can be a wired or wireless local area network (LAN). Alternatively the network 5 may comprise a wide area network such as the Internet. In such a case, the network 5 may further comprise a plurality of LANs connected to the wide area network, the client computers 1 , 2, 3 in turn being connected to the LANs, and through the LANs being able to communicate over the wide area network.

The server 4 can be a single computer (e.g., the computer 900 of Figures 9a and 9b) or more typically a plurality of computers. It will be appreciated that where a plurality of computers are provided to form the server 4, services provided by the server 4 can be distributed between the computers in any convenient manner.

The client computers 1 , 2, 3 run client applications which communicate with the server 4. For example, the server 4 may provide a logical data store 6. Access to the logical data store 6 may be controlled by the server 4, such that by communicating with the programs running on the server 4, the client computers 1 , 2, 3 are able to access the logical data store 6. Figure 2 illustrates an example architecture for the server 4 and the logical data store 6.

Referring to Figure 2, it can be seen that the server computer 4 communicates with and controls access to the logical data store 6. It can be seen that the logical data store 6 is provided in three data stores 8a, 8b, 8c, each of which is connected to a respective database server 9a, 9b, 9c. The server computer 4 communicates with the database servers

9a, 9b, 9c to access and amend data stored in the data stores 8a, 8b, 8c.

The described embodiments have particular applicability in healthcare environments. In such environments (as in many others), data security is very important, both from the point of view of controlling data access, and from the point of view of ensuring that data is not lost or corrupted. An architecture suitable for managing access to healthcare data is now described with reference to Figure 3.

Referring to Figure 3, it can be seen that the logical data store 6 here comprises five individual data stores 8a, 8b, 8c, 8d, 8e. These data stores are arranged so as to provide efficient and effective access to data stored in the logical data store 6. For example, where patient data is stored, it is preferred that all data relating to a particular patient (i.e., the patient's EPR) is stored within a single one of the data stores 8a to 8e. It can be seen that a data access engine (DAE) 10 is provided to control access to the data stores 8a to 8e. Client applications wishing to access data stored in the data stores 8a to 8e use the DAE 10 to achieve such access. Such client applications can be run on the client computers 1 , 2, 3 of Figure 1. It can be seen that client applications can include business components 1 1 and enterprise components 12, both of which access data using the data access engine 10.

Components of the data access engine 10 are now described. In preferred embodiments, the DAE is implemented using Microsoft® .NET framework. The .NET framework provides a set of classes referred to as ADO.NET which provide convenient functionality for database access. The DAE 10 accesses the data stores 8a to 8e using functionality provided by the ADO.NET classes. The DAE 10 abstracts the data persistence and data retrieval mechanisms of ADO.NET. To achieve this generic ADO.NET data access methods are wrapped so as to encapsulate the execution functionality for Oracle databases and SQL Server databases as appropriate. It will be appreciated that other databases could also be used.

It can be seen that the DAE 10 comprises an interface 13, and it is through this interface that both business components 1 1 and enterprise components 12 communicate with the DAE to access data. The interface 13 defines constants and provides business components 1 1 and enterprise components 12 with access to a DAE manager 14. The DAE manager 14 is responsible for managing data access operations. The DAE manager 14 interacts with a resolution manager component 15, a configuration manager component 16, a data access component 17 and a data aggregator component 18. The function of these components is now described.

The configuration manager component 16 is responsible for providing configuration information. The configuration manager is a singleton class, that is a class having a single instance for a particular physical server. The configuration manager component 16 receives as input two Extensible Markup Language (XML) files containing configuration information.

The resolution manager component 15 is invoked to obtain details of a database server on which a particular query should be executed. This process can be carried out in a number of ways. For example, configuration files provided to the configuration manager component 16 can specify a database server to be associated with each class. By obtaining the identifier of the class associated with a particular query, the configuration manager can be used by the resolution manager component 15 to determine which database server should be accessed.

Alternatively, a router database 19 can be user as an index to the data stores 8a to 8e. Where data is stored in a patient centric manner (i.e. in a manner associated with a particular patient), the router database 19 will use data associated with a particular patient to identify one or more of the data stores 8a to 8e on which relevant data is stored. In this way, the resolution manager component 15 uses the router database 19 to determine which of the data stores should be used to obtain necessary information.

The router database 19 can function well where data to be retrieved is patient centric data. Given that some information in healthcare systems is not patient centric (e.g. information relating to the healthcare institution) data can have an associated attribute indicating whether or not it is patient centric data. This attribute is referred to as a Partition Qualifier. By using the Partition Qualifier the resolution manager component 15 is able to first determine whether required data is patient centric data. If this is not the case, one or more data stores holding non-patient centric data are queried. If however the data is patient centric data, the router database 19 can be used in the manner described above to identify appropriate data stores to be queried.

Although using the router database 19 in the manner described above provides effective access to data stored within the logical data store 6, it will be appreciated that repeated access to the router database 19 can be a source of inefficiency. The resolution manager 15 can therefore use a cache to prevent over- frequent access of the router database 19. A cache is used to store connection strings for each data store of interest. The cache stores . a map which, maps bucket identifiers generated by a hashing algorithm (described below) to connection strings. An appropriate connection string is identified using a bucket identifier generated by a hashing algorithm as is described below with reference to Figure 4.

Referring to Figure 4 it can be seen that a patient identifier (ID) 20 is input to a hashing algorithm 21. The output of the hashing algorithm 21 is a bucket identifier 22. The cache described above stores a map mapping bucket identifiers 22 to connection strings 23, each connection string 23 being configured to connect to a particular data store. Each bucket identifier is associated with a single data store, although more than one bucket can be associated with any one data store.

The patient identifier 20 input to the hashing algorithm 21, and more generally the patient identifier used to process patient centric requests, can take any convenient form. For example, a numeric or alphanumeric identifier uniquely allocated to each patient by a healthcare institution or a health service (such as the National Health Service in the UK) can suitably be used. Having determined an identifier which is to be used as the patient identifier 20, the hashing algorithm is configured to work with this identifier.

Referring back to Figure 3, the data aggregator component 18 of the DAE 10 is an optional component. When a client application makes a data request which requires data to be retrieved from a plurality of data stores, the DAE manager 14 interacts with the data aggregator component 18 to ensure that appropriate data requests are made to appropriate data stores. The data aggregator component is a multi-threaded component, with a user configurable number of threads.

The data access component 17 is responsible for all communications with the data stores, and appropriately wraps ADO.NET execution methods. The data access component

17 is implemented using an abstract factory pattern. Helper instances are implemented which are specific to databases which are to be accessed. Helper instances can execute stored procedures or ad-hoc queries for update, select and delete database operations.

It can be seen that the DAE 10 further communicates with a caching engine 24 and an Application Monitoring Service (AMS) instrumentation client 25. The caching engine 24 provides a cache for use by the configuration manager component 16. The AMS instrumentation client 25 provides facilities to instrument the operations for various concerns, as specified by requirements.

It will be appreciated that patient centric data stored in the data stores 8a to 8e stores a wide variety of data relating to patients whose data is to be processed. Data is stored in database tables in a manner which will be well known to those skilled in the art. Figure 5 shows part of a database schema centred around a patient table 26. It can be seen that relationships are illustrated between the patient table 26 and various other tables (e.g. citizen table 28, patient care provider table 30) which store patient demographic data. The patient table 26 stores data relevant to particular patients such as name data, date of birth data and gender data.

Other tables (e.g. 28, 30) of the database (some of which are illustrated in Figure

5) also store data relating to particular patients. These tables relate their data to a particular patient by having a foreign key field which targets the primary key of the patient table.

Another example is the Notes table 29 which stores data relating to Sticky Notes (see below) associated with the patient.

Figure 6 illustrates a portion 600 of a Graphical User Interface (GUI) displayed by the medical information system 100. For example, the GUI portion 600 may be displayed on a display 914 (see Fig. 9) of one of the client computers 1 , 2 and/or 3. The GUI portion

600 displays data relating to the family of a patient. The GUI portion 600 is herein referred to as the Family Tree viewer. . _ ... ._ . .. .. .

The Family Tree viewer 600 comprises an image area 610 and a text area 620.

The text area 620 of the Family Tree viewer 600 displays demographic information related to a patient. The image area 610 of the Family Tree viewer 600 displays the data relating to the family of the patient arranged in a tree structure, formed by a plurality of graphical objects, reflecting the family tree of the patient. The tree comprises graphical objects referred to herein as nodes (e.g. 630), each node corresponding to a family member. The nodes are connected through relationship connectors (e.g. 640) corresponding to family relationships.

The "main node" 650 corresponding to the patient whose family data is displayed in the image area 610 is displayed according to the following rules:

• Square nodes (e.g. 650) correspond to male patients, circular nodes (e.g. 630) to female patients, and diamond shaped nodes (not illustrated) to persons of unknown gender. • A slash (e.g. 675) through a node indicates the patient is deceased. • The patient's name (Dabin Jameson, as illustrated in Figure 6) and age (50 years), either current or age at demise, are represented as text 655 below the main node 650.

Nodes (e.g. 630) corresponding to family members of the patient are displayed in relation to the main node 650 according to the above rules, and the following further rules: • A person's familial relationship (e.g. father, sister, grandmother) to the patient is represented as text (e.g. 645) below the node corresponding to the person, alongside the text representing the person's name and age.

• A marriage between two persons, one male and one female, is represented by a horizontal line (e.g. 640) joining the centres of the nodes corresponding to those persons.

• A divorce is indicated by a double forward slash (not illustrated) over the line representing the corresponding marriage.

• A node corresponding to a child of a marriage is positioned below the centre of the horizontal line representing the marriage, joined to it by a vertical line (e.g. 690).

• A non-twin sibling relationship between multiple children of a marriage is indicated by a horizontal line (e.g. 660) joined by a vertical line (e.g. 665) extending upwards to the centre of the horizontal line representing the marriage. Vertical lines (e.g. 670) extend downward from the horizontal line to the centre of each node corresponding to a sibling.

• A twin relationship is indicated by an inverted "V" (e.g. 685) joining the two nodes corresponding to the twins, and joining a vertical line extending upwards to the horizontal line representing the marriage that produced the twins.

• An adopted child (either adopted in or adopted out) is represented by a pair of square brackets (e.g. 680) around the corresponding node. If the child is "adopted in", the vertical line joining the bracketed node to the parents or the sibling relationship is represented as dashed (e.g. 695); otherwise, the vertical line is solid.

In one implementation, the nodes are represented on a horizontally striped background. The colour of the stripes alternates from dark to light with each successive generation, to enhance the visual grouping of nodes representing persons in the same generation. For example, nodes 630, 631 , 632 and 633 representing one generation are all represented on a light stripe 601 , while nodes 671 , 672, 673 and 674 representing the next generation are all represented on a dark stripe 602. Again, these light and dark stripes enhance visual grouping of nodes representing persons in the same generation. The main node 650 is always displayed on the central stripe of the odd number of stripes in the image area 610. The odd number of stripes, and hence the number of generations displayed, is controlled by the user of the system 100 by means of a slider (not shown) displayed adjacent to the image area 610.

The Family Tree Viewer 600 allows a user to quickly and easily navigate through the data relating to the family of a person. Hovering the cursor over a node for a predetermined period causes the display of additional data such as the corresponding patient's blood group and other hereditary conditions about the corresponding patient in a pop-up box, in the manner of a tooltip, depending on the user's access rights. Activating the cursor over a node opens the EPR of the corresponding patient, if the EPR exists on the medical information system 100 and the user has the appropriate access rights.

Figure 7a illustrates an active control 700 forming another part of the graphical user interface (GUI) displayed by the medical information system 100. The active control

700 may be displayed as one or more graphical objects on the display 914 of one of the client computers 1 , 2 and/or 3. The active control 700 may be referred to herein as an electronic sticky note. As described below, the electronic sticky note 700 displayed as a graphical object on the display 914 may have an associated text file stored within the logical data store 6 of the server 4 for entering free text into the sticky note 700. Accordingly, the sticky note 700 is implemented as at least one graphical object and an associated text file.

The electronic sticky note 700 facilitates informal, asynchronous communication of non-clinical information (or data)_between users of the system 100, in analogous fashion to paper sticky notes that are commonly attached to paper file records for this purpose.

A user, while viewing the EPR of a particular patient in the GUI displayed on the computer display 914, may activate a control (not shown) that creates and displays a new sticky note 700 on the computer display 914. The default dimensions of a new displayed sticky note are preferably 230 pixels wide .and 180 pixels, high. These dimensions are alterable by the user during runtime if an attribute isResizable of the sticky note 700 has the value "true".

The current time and date are shown in a header portion 710 of the new sticky note 700. A pencil icon 735 is displayed dependent on the value of an attribute Readonly of the sticky note 700. The presence of the pencil icon 735 in the sticky note 700 indicates that the value of Readonly is "false", so free text (e.g. 740) may be entered in a central large portion 715 of the sticky note 700. The free text associated with the sticky note 700 may be stored in the logical data store 6 of the server 4

Activation of the "New" control 750 in a footer portion 725 of the sticky note 700 causes a new sticky note to be created in association with the current sticky note 700, thus allowing the generation of a sequence of sticky notes, each associated with its predecessor, to form a bilateral or multilateral conversation. The resulting sequence of sticky notes is associated with the EPR of the patient and is stored and maintained within the logical data store 6, for example, as one or more text files associated with the sticky notes. Arrow controls 720 in the header portion 710 may be activated to navigate through the sequence of sticky notes associated with the EPR, while activation of an "X" control 730 closes the view of the sticky note 700 and hence the sequence to which the sticky note 700 belongs. Activation of a "Delete" control 755 in the footer portion 725 causes the currently displayed sticky note 700 to be deleted.

At the bottom of the text entry portion 715 of the sticky note 700 is a signature line 745, indicating the identity of the user who created the sticky note 700 and the date on which the sticky note 700 was created.

On opening a view 780 of the EPR in the GUI and activating a "Sticky Notes" control 785 as illustrated in Figure 7b, if a sequence of sticky notes is associated with that EPR, the sticky notes in the sequence are displayed 790 as a plurality of graphical objects superimposed on the view 780 of the EPR.

Figure 7c illustrates a sticky note 760 with the Readonly attribute set to "true". The pencil icon 735 has been replaced by a note icon 765 indicating that the sticky note

760 is not available for further text entry. A header portion 770 of the sticky note 760 displays a title for the sticky note 760 rather than the current date and time as for the sticky note 700 (for which Readonly is "false").

Figure 8a illustrates a portion 800 of the graphical user interface (GUI) displayed by the medical information system 100. Again, the portion 800 may be displayed as one or more graphical objects on the display 914 of one of the client computers 1 , 2 and/or 3. The portion 800 is adapted to display hierarchically organised, heterogeneous data in a patient's

EPR stored in the logical data store 6. The portion 800 is referred to herein as the "image browser". The image browser 800 displays a "filmstrip" view of the hierarchically organised, heterogeneous data. The data to be displayed is located at a "root path" that is displayed as text in a "combo box" 805 portion of the image browser 800. The root path refers to a folder and/or file stored in the logical data store 6. The user can set, via a "User Preferences" setting module, a default root path to be loaded every time the image browser is invoked. The default root path may be altered by manual text entry into the combo box 805. The image browser provides an "auto-complete" feature that suggests available paths starting with the so-far entered text. When the user presses the Enter key, the image browser is refreshed to display the contents of the root path.

If the root path is not empty, icons (or graphical objects) representing each of the images and / or folders located at the root path are arranged horizontally along a row within a window 810. A horizontal scroll bar 815 allows navigation along the window 810 containing the row of icons representing the folders and images. Each image is represented as a thumbnail representation, e.g. 825, while each folder is represented as a folder icon, e.g. 820. The name of each image or folder is displayed as text below the corresponding icon.

Activating a folder icon by the user causes the root path to change to the corresponding folder. The combo box 805 is updated to display the name of the corresponding folder as the new root path, and the window 810 is updated to display the contents of the new root path as described above.

"Hovering" the cursor over one of the folder icons by the user causes a pop-up display of information about the contents of the corresponding folder in the manner of a tooltip. In the example illustrated in Figure 8a, hovering the cursor over the folder icon 820 results in the display of a pop-up 835 indicating that the corresponding folder (named "Folder with Images") contains five (5) images.

If the root path is empty, a text message "No files / folders found" 860, as seen in Figure 8c, is displayed in the window 810. The user can change the root path to the parent path of the root path by activating the "Up" control 830. On activation of the "Up" control 830, the combo box 805 is updated to display the name of the parent path as the new root path, and the window 810 is updated to display the contents of the new root path as described above. The "Up" control 830 is disabled once the user reaches the highest level in the hierarchy of the EPR for the patient.

The user can navigate to folders within the root path by activating a "down arrow" control 845, as seen in Figure 8b, at the end of the combo box 805. On activation of the

"down arrow" control 845, folder icons (or graphical objects) accompanied by folder names representing the folders located at the current root path are displayed arranged vertically in a drop-down box 855, as see in Figure 8b. A vertical scroll box 850 allows the user to navigate up and down the column of folder icons in the drop-down box 855.

Any displayed folder icon in the drop-down box 855 may be selected, upon which the folder corresponding to the selected folder icon becomes the new root path. The contents of the combo box 805 and the window 810 are then updated accordingly as described above.

Figures 9a and 9b collectively form a schematic block diagram of a general purpose computer system 900, which may be identified with the computers 1 , 2, and 3 and/or the server 4 in the medical information system 100 of Figure 1. Accordingly, each of the computers 1 , 2 and 3 and the server 4 may have a similar configuration to the computer system 900.

As seen in Figure. 9a, the computer system 900 is formed by a computer module

901 , input devices such as a keyboard 902, a mouse pointer device 903, a scanner 926, a camera 927, and a microphone 980, and output devices including a printer 915, a display device 914 and loudspeakers 917. An external Modulator-Demodulator (Modem) transceiver device 916 may be used by the computer module 901 for communicating with a wide-area communications network 920, which is one embodiment of the network 5 of Figure 1 , via a connection 921. The connection 921 may be a telephone line, and the modem 916 may be a "dial-up" modem. Alternatively, the connection 921 may be a high capacity (eg: cable) connection, and the modem 916 may be a broadband modem. A wireless modem may also be used for wireless connection to the wide-area network 920.

The computer module 901 typically includes at least one processor unit 905, and a memory unit 906 for example formed from semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The module 901 also includes an number of input/output (I/O) interfaces including an audio-video interface 907 that couples to the video display 914, loudspeakers 917 and microphone 980, an I/O interface 913 for the keyboard 902, mouse 903, scanner 926_r camera 927 and optionally a joystick (not illustrated), and an interface 908 for the external modem 916 and printer 915. In some implementations, the modem 916 may be incorporated within the computer module 901 , for example within the interface 908. The computer module 901 also has a local network interface 91 1 which, via a connection 923, permits coupling of the computer system 900 to a local area computer network 922, which is another embodiment of the network 5 of Figure 1. The interface 91 1 may be formed by an EthernetTM circuit card, a BluetoothTM wireless arrangement or an IEEE 802.1 1 wireless arrangement.

The interfaces 908 and 913 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices 909 are provided and typically include a hard disk drive (HDD) 910. The HDD 901 implemented on the server 4 contains the logical data store 6. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 912 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (eg: CD-ROM, DVD), USB-RAM, and floppy disks for example may then be used as appropriate sources of data to the system 900.

The components 905 to 913 of the computer module 901 typically communicate via an interconnected bus 904 and in a manner which results in a conventional mode of operation of the computer system 900 known to those in the relevant art. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple MacTM or alike computer systems evolved therefrom.

The applications running on the client computers 1 , 2, and 3 and the programs running on the server 4 of Figure 1 are illustrated in Fig. 9a as a software application program 933 executable within the computer system 900. The software 933 comprises instructions 931 that are carried out within the computer system 900. The software instructions 931 may be formed as one or more code modules, each for performing one or more particular tasks. The software 933 of the client computers 1 , 2, and 3 and the server 4 may be divided into two separate parts, in which the code modules in a first part implement the components 1 1 and 12 described above and the code modules of a second part manage the GUI, including the Family Tree viewer 600, the Sticky Note 700 and the Image Browser 800, described above between the modules of the first part and the user of the client computers 1 , 2, 3 or the server 4.

The software 933 is generally loaded into the computer system 900 from a computer readable medium, and is then typically stored in the HDD 910, as illustrated in Fig. 9a, or the memory 906, after which the software 933 can be executed by the computer system 900. In some instances, the application programs 933 may be supplied to the user encoded on one or more CD-ROM 925 and read via the corresponding drive 912 prior to storage in the memory 910 or 906. Alternatively the software 933 may be read by the computer system 900 from the networks 920 or 922 or loaded into the computer system 900 from other computer readable media. Computer readable storage media refers to any storage medium that participates in providing instructions and/or data to the computer system 900 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 901. Examples of computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 901 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

The second part of the application programs 933 and the corresponding code modules mentioned above may be executed to implement one or more GUIs to be rendered or otherwise represented upon the display 914. Through manipulation of typically the keyboard 902 and the mouse 903, a user of the computer system 900 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the code modules of the first part. Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers 917 and user voice commands input via the microphone 980.

Figure 9b is a detailed schematic block diagram of the processor 905 and a "memory" 934. The memory 934 represents a logical aggregation of all the memory devices (including the HDD 910 and semiconductor memory 906) that can be accessed by the computer module 901 in Figure 9a.

When the computer module 901 is initially powered up, a power-on self-test (POST) program 950 executes. The POST program 950 is typically stored in a ROM 949 of the semiconductor memory 906. A program permanently stored in a hardware device such as the ROM 949 is sometimes referred to as firmware. The POST program 950 examines hardware within the computer module 901 to ensure proper functioning, and typically checks the processor 905, the memory (909, 906), and a basic input-output systems software (BIOS) module 951 , also typically stored in the ROM 949, for correct operation. Once the POST program 950 has run successfully, the BIOS 951 activates the hard disk drive 910. Activation of the hard disk drive 910 causes a bootstrap loader program 952 that is resident on the hard disk drive 910 to execute via the processor 905. This loads an operating system 953 into the RAM memory 906 upon which the operating system 953 commences operation. The operating system 953 is a system level application, executable by the processor 905, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

The operating system 953 manages the memory (909, 906) in order to ensure that each process or application running on the computer module 901 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system 900 must be used properly so that each process can run effectively. Accordingly, the aggregated memory 934 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 900 and how such is used. The processor 905 includes a number of functional modules including a control unit 939, an arithmetic logic unit (ALU) 940, and a local or internal memory 948, sometimes called a cache memory. The cache memory 948 typically includes a number of storage registers 944 - 946 in a register section. One or more internal buses 941 functionally interconnect these functional modules. The processor 905 typically also has one or more interfaces 942 for communicating with external devices via the system bus 904, using a connection 918.

The application program 933 includes a sequence of instructions 931 that may include conditional branch and loop instructions. The program 933 may also include data 932 which is used in execution of the program 933. The instructions 931 and the data 932 are stored in memory locations 928-930 and 935-937 respectively. Depending upon the relative size of the instructions 931 and the memory locations 928-930, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 930. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 928-929.

In general, the processor 905 is given a set of instructions which are executed therein. The processor 905 then waits for a subsequent input, to which it reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 902, 903, data received from an external source across one of the networks 920, 922, data retrieved from one of the storage devices 906, 909 or data retrieved from a storage medium 925 inserted into the corresponding reader 912. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 934. The disclosed arrangements use input variables 954, that are stored in the memory 934 in corresponding memory locations 955-958. The arrangements produce output variables 961 , that are stored in the memory 934 in corresponding memory locations 962- 965. Intermediate variables may be stored in memory locations 959, 960, 966 and 967.

The register section 944-946, the arithmetic logic unit (ALU) 940, and the control unit 939 of the processor 905 work together to perform sequences of micro-operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 933. Each fetch, decode, and execute cycle comprises:

(a) a fetch operation, which fetches or reads an instruction 931 from a memory location 928;

(b) a . decode operation in which the control unit 939 determines which instruction has been fetched; and

(c) an execute operation in which the control unit 939 and/or the ALU 940 execute the instruction.

Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 939 stores or writes a value to a memory location 932.

Each step or sub-process in the code modules described above is associated with one or more segments of the program 933, and is performed by the register section 944-

947, the ALU 940, and the control unit 939 in the processor 905 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 933.

Figure 10 is a flowchart illustrating a method 1000 of implementing the GUI portion 600 used to display data relating to the family of a person. The method 1000 may be implemented as one or more code modules of the software 933 being resident on the hard disk drive 910 of the client computer 1 and being controlled in its execution by the processor 905 of the client computer 1. The method 1000 will be described with reference to the example of Figure 6 and the client computer 1.

The method 1000 starts at step 1010, where the processor 905 of the client computer 1 generates the main node 650 corresponding to a patient (i.e., Dabin Jameson, 50 years) in the medical information system 100. Then at step 1015, the processor 905 displays the main node 550 as a graphical object, as seen in Figure 6, on the display 914 of the client computer 1.

At the next step 1020, the processor 905 of the client computer 1 generates a plurality of nodes (e.g. 670) corresponding to family members of the patient. The processor 905 may determine the family members of the patient and how many nodes are required to be generated at step 1020 by querying the logical data store 6 resident on the server 4.

At the final step 1030, the processor 905 displays the plurality of nodes as a plurality of graphical objects, as generated in step 1020, arranged in the tree structure seen in Figure 6 reflecting the family tree of the patient. Again, the processor 905 may determine the position of each of the plurality of nodes in the tree structure by querying the logical data store 6 of the server 4. As described above, the nodes are connected through relationship connectors (e.g. 640) corresponding to family relationships. The nodes are displayed such that hovering, by a user of the graphical user interface (i.e., the family tree viewer 600), a cursor over a node causes additional data about the corresponding patient or family member to be displayed in a pop-up box. As described above, in one implementation, the nodes of the tree structure are represented on a horizontally striped background. The colour of the stripes alternates from dark to light with each successive generation, to enhance the visual grouping of nodes representing persons in the same generation.

Figure 1 1 is a flowchart illustrating a method 1 100 of implementing a Sticky Notes portion of the GUI. The method 1 100 will be described with reference to the example of Figures 7a-c and the client computer 1. The method 1000 may be implemented as one or more code modules of the software 933 being resident on the hard disk drive 910 of the client computer 1 and being controlled in its execution by the processor 905 of the client computer 1.

The method 1 100 starts at step 1 1 10 where the processor 905 generates and displays, on activation of a first control (not shown), an electronic sticky note 700, as seen in Figure 7a, associated with an electronic patient record in the medical information system 100. The control and created sticky note 700 may be displayed as one or more graphical objects on the display 914 of the client computer 1. As described above, the sticky note 700 is adapted to display non-clinical information as text (e.g., "Patient has a hearing Aid. Talk Loudly", as seen in Fig. 7c) entered by a user of the medical information system 100. The text associated with such a created sticky note 700 is stored in the logical data store 6 of the server 4 (e.g., as a text file) together with an association to the created sticky note 700.

At the next step 1 120 the processor 905 generates and displays, on activation of a second control 750, a further sticky note associated with the created sticky note 700, thereby creating a sequence of sticky notes. Again, the control 750 and the further sticky note are displayed as one or more graphical objects on the display 914 of the client computer 1. The control 750 may be located in the footer portion 725 of the created sticky note 700 as seen in Fig. 7a. The created sequence of sticky notes is navigable, on activation of a pair of third controls 720, forward and backward along the created sequence of sticky notes. The created sticky note 700 is deletable on activation of a fourth control 730 (i.e., the "X" control) . Again, the controls 720 and 730 are displayed as graphical objects on the display 914 of the client computer 1.

Figure 12 is a flowchart illustrating a method 1200 of implementing an Image Browser portion 800 of the GUI. The method 1200 will be described with reference to the example of Figures 8a-c and the client computer 1.

The method 1200 may be implemented as one or more code modules of the software 933 being resident on the hard disk drive 910 of the client computer 1 and being controlled in its execution by the processor 905 of the client computer 1.

The method 1200 starts at step 1210 where the processor 905 of the client computer 1 generates and displays one or more graphical objects representing a combo box control 805 adapted to receive the name of a root path in the medical information system 100. As described above, the user can set, via a "User Preferences" setting module, a default root path to be loaded every time the Image Browser 800 is invoked. The default root path may be altered by manual text entry into the combo box 805.

At the final step 1220, the processor 905 generates and displays one or more icon graphical objects, e.g. 820, arranged along a horizontal row within a window, each icon (e.g., 820) representing a folder or an image stored in the logical data store 6 and located at the root path. The icons are generated such that hovering, by a user of the image browser 800, a cursor over an icon representing a folder causes the pop-up display of information about the contents of the folder. For example, the folder may contain one or more images stored in the logical data store 6 and associated with the EPR of a patient.

Although embodiments of the invention have been described above, it will be appreciated that various modifications can be made to the described embodiments without departing from the spirit and scope of the appended claims, in particular, where embodiments of the invention have been described as having particular applicability in healthcare, the invention is not restricted to such applications, but is instead widely applicable.

The arrangements described are applicable to the computer and data processing industries and particularly for the processing of medical records.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings. . . . .

Claims

Claims:

1. A graphical user interface displayed on a computer display of a medical information system, the graphical user interface comprising:

a graphical object forming a main node corresponding to a patient in said medical information system; and

graphical objects forming a plurality of nodes corresponding to family members of the patient arranged in a tree structure reflecting the family tree of the patient;

2. The graphical user interface of claim 1 , wherein a shape of a node depends on the gender of the corresponding patient or family member.

3. The graphical user interface of claim 1 , wherein a node corresponding to an adopted family member is displayed enclosed by brackets.

4. The graphical user interface of claim 1 , wherein nodes corresponding to persons in each generation of said family tree are arranged horizontally within a background stripe.

5. The graphical user interface of claim 4, wherein a stripe corresponding to a generation is of a different colour to a stripe corresponding to a preceding or succeeding generation.

6. The graphical user interface of claim 1 , wherein a marriage between two persons in the family tree is represented by a horizontal line joining the two nodes corresponding to the two persons.

7. The graphical user interface of claim 6, wherein a marriage terminated by divorce is represented by a double slash through the horizontal line representing the marriage.

8. The graphical user interface of claim 1 , wherein a node corresponding to a deceased person is displayed with a slash through it.

9. The graphical user interface of claim 1 wherein each nodes is adapted, on activation by the user, to open an electronic patient record of the corresponding person.

10. The graphical user interface of claim 1 wherein the additional data is displayed in a pop-up box.

1 1. A medical information system displaying a graphical user interface on a computer display of said system, said system comprising:

a memory for storing data and a computer program; and

12. A method of displaying data related to the family of a patient on a computer display of a medical information system, the method comprising:

13. A computer readable medium having a computer program recorded therein for displaying data related to the family of a patient on a computer display of a medical information system, said computer program comprising: