SYSTEM AND METHOD FOR DISTRIBUTED DATA STORAGE
AND UPDATE IN A COMPUTER NETWORK
This application was made by the Centers for Disease Control and Prevention, an agency of the United States of Ameπca.
FIELD OF THE INVENTION
The invention relates generally to data storage in a computer network, and, more particularly, relates to distπbuted storage and update of data records across multiple nodes of a computer network.
BACKGROUND OF THE INVENTION
Over the past several years in the United States, a great amount of effort has been directed toward the development of immunization registπes to assist physicians in the management of immunization services provided by them to their patients. These efforts are intended to allow physicians access to complete and accurate immunization histories for their patients, even when immunizations have been received from different sources. This information would help physicians ensure that their patients receive the immunizations they need. Current immunization registπes use a "hub and spoke" configuration where the hub is a database containing immunization records for multiple patients and spokes are remote computers able to access the information in the hub over a network. Rather than a single national database, there are typically many immunization registπes in different communities. There may even be multiple immunization registπes in a single community maintained by different entities, such as a hospital and a health maintenance organization (HMO) Due to this organizational structure, updating one hub will not automatically update other hubs. Hence, an immunization record for a patient in one hub may differ from an immunization record for that same patient in another hub This poses a problem for healthcare providers in tracking and accessing the most current information
Furthermore, it is frequently difficult to transfer records from one hub to another because of hub incompatibilities. Thus, there is a need in the art for an improved method for giving healthcare providers access to current patient immunization records. Another problem with current immunization registries is that distinct individuals may have identical names (i.e., many people with the name John Smith). In such instances, it becomes difficult, if not impossible, for a doctor to uniquely identify the pertinent patient record. A corollary to this is that patient information becomes accessible to anyone who can correctly and uniquely identify an individual. This is undesirable because patient files contain sensitive information that should not be accessible to the general public. Thus, there is a further need in the art for a method giving healthcare providers access to current patient immunization records while maintaining appropriate safeguards for patient privacy. One attempt to solve the described problems is a portable storage device for electronically storing complete patient data. Typically, a patient is responsible for storing the device and bringing the device to the patient's doctor during office visits. During the office visit, the doctor may use a reader to access the data on the device. After deciding on an appropriate course of action, the doctor updates the information on the storage device and returns it to the patient. This storage device is problematic for several reasons. First, in order for the doctor to access the information, a reader compatible with the storage device is necessary. Second, if the patient visits multiple doctors, then only the last visited doctor will have the most recent version of the patient's medical records. Third, in order for such a device to be functional, it must be carried on the patient at all times. This leads to the possibility that the storage device may be lost or stolen, in which instance the information also becomes unavailable. Finally, such a storage medium is vulnerable to erasure or malfunction.
Thus, there is a need in the art for a method of storing a patient's immunization records that improves the ability of healthcare workers to get current copies of those records. There is also a need for this method to give the patient more control over the records so that the patient can better protect his or her privacy.
SUMMARY OF THE INVENTION
The present invention meets the needs descπbed above by use of a computer network for distributing information records and automatically updating the multiple copies of a record when the record is modified. Moreover, this invention provides greater protection of records by allowing a user of a network node that created the record (also referred to as the control node or the home system) to restπct access of the information to a controlled audience. This can be accomplished by designating the nodes of the computer network which receive a copy of the record and any modifications made by a node of the network to that record. The control node may create a list of nodes, or recipient list, listing the nodes that receive a copy of the record and modifications to the record The control node can further control access to the record by designating the nodes forming the mesh for that record, which are the network nodes that can modify the record and distπbute copies of the modified record. If the nodes of the mesh always distribute modifications they make to their copies of the record to the other nodes on the recipient list, then all nodes on the recipient list will always have the most current copy of the record The control node may also indicate in the recipient list which nodes on the recipient list are in the mesh.
Another advantage of the present invention over conventional "hub and spoke" methods for record storage in a network is that each node on the recipient list for a record maintains a copy of that record at the node itself Thus, the node does not have to access a central database over the network in order to access a current copy of the record. Retπeving a copy of a locally stored record is typically faster than retπeving a record from a remote location over a network. Furthermore, a node which needs to retπeve a record from a remote location over a network may be temporanly unable to access the record if the network crashes or is otherwise temporanly disabled at the time the node needs the record. This situation cannot occur if the node stores the record locally.
For one aspect of the present invention, a first node of a network may receive a record of information sent to it over the network. The first node may also receive a list of nodes sent to it over the network The list of nodes includes a mesh, which in turn includes those nodes of the network that both store the record and have been granted authoπty by a control node that oπginally created the record to modify the information in the record. The nodes of the mesh are also authoπzed to send the record containing the modified information to other nodes in the network.
The list of nodes may include additional nodes that are not m the mesh because they are prohibited by the control node from modifying the information in the record Thus, these additional nodes receive copies of the record and any modifications made by a mesh node to the record, but they cannot themselves modify the record
If the first node is in the mesh, the first node may then modify the information contained in the record The first node may then send the record containing the modified information to other nodes on the list of nodes so that the other nodes can replace their records with the record containing the modified information.
The vanous aspects of the present invention may be more clearly understood and appreciated from a review of the following detailed descnption of the disclosed embodiments and by reference to the appended drawings and claims.
BRIEF DESCRIPTION OF THE DRAWINGS
FIGS 1A-1D are block diagrams illustrating a typical implementation of the present invention within an exemplary operating environment of a network of nodes.
FIG 2 is a flow chart of the steps in a program enabling nodes of a computer network to practice distnbuted data storage and data updates in accordance with an exemplary embodiment of the present invention.
FIG. 3 is a flow chart of the steps in a routine for creating a new record in accordance with an exemplary embodiment of the present invention.
FIG. 4 is a flow chart of the steps in a routine for selecting and processing a record stored on a network node running a database program m accordance with an exemplary embodiment of the present invention.
FIG. 5 is a flow chart for processing a manipulation option the user has selected for a record in accordance with an exemplary embodiment of the present invention. FIG. 6 is a flow chart of the steps for modifying a selected record at a network node running a database program and distπbuting the modified record to nodes of the network stoπng a copy of the unmodified record m accordance with an exemplary embodiment of the present invention
FIG 7 is a flow chart of the steps for adding a new recipient to the recipient list for a selected record stored on a network node running a database program m accordance with an exemplary embodiment of the present invention
FIG. 8 is a flow chart of the steps followed by a selected record's control node when updating the recipient status of a network node on the selected record's recipient list in accordance with an exemplary embodiment of the present invention. FIG. 9 is a flow chart of the steps for processing a new status chosen by the user of a record's control node for another network node on the record's recipient list in accordance with an exemplary embodiment of the present invention
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
The present invention is typically embodied in a network of computer nodes that each run software containing program modules that implement a method for distnbuted storage and update of records in a network. Each record may conespond to a patient and contain information about that patient and the patient's immunization history.
Each node of the network typically restncts user access to the information stored on that node. One way to limit user access is to require a user of a node to log into the node using a specified password. Another way to limit user access to a node is to require a user to be physically present at the node. If the user needs a key to enter the building housing the node, the user will likely only have access to the node if his use of the node is authonzed. Certain nodes of the network allow a user at that node to create a new record of information A node at which a user creates a new record is called a "home system" or a "control node" with respect to the new record. At the time of creation, the control node assigns the new record a globally unique identifier (GUID) which differentiates the new record from every other record stored on the network.
In creating a new record at a control node, the user may create a list of nodes, also called a recipient list, that designates all the nodes of the network that the user of the control node wishes to maintain a current copy of the record. Once the user creates the new record, the control node sends a copy of the new record to all the nodes on the list of nodes for that record, allowing all the nodes on the list of nodes to store a copy of the newly created record.
After sending a copy of the record to all the nodes on the list of nodes, the user who created the record may also choose a subset of the nodes on the list of nodes to form a "mesh" for the record. A node of the mesh can modify its copy of the record and send the modified record to the other nodes on the list of nodes so
that the nodes receiving the modified record can replace their old copy of the record with the modified record This allows authonzed nodes (the mesh) to make changes to the record while ensuπng that the nodes designated by the list of nodes have the most recently modified copy of the record at any time. The control node is always included in the mesh. The software on the control node may store an indication of the mesh nodes in the recipient list created by the user for the record.
Once the user chooses the nodes of the mesh, the control node sends a command to the nodes of the mesh authoπzmg them to update the record and distnbute the updated record to the nodes on the list of nodes. The control node also sends the list of nodes to the nodes of the mesh so that any node of the mesh which modifies a record knows which nodes are supposed to receive the modified record The sending of the list of nodes from the control node to a node of the mesh may serve as the command that authoπzes the mesh node to update the record and to distnbute the updated record to the nodes of the mesh. One skilled in the art will recognize that the list of nodes may contain nodes that are not in the mesh. Such nodes are called non-mesh nodes. By virtue of being on the list of nodes, these nodes will maintain a current copy of the record and receive modifications of that record produced by nodes of the mesh. However, nodes that are on the list of nodes but that are not in the mesh have no authonty to modify the record themselves or to transmit their modifications to other nodes.
For any record in the network, there is typically only one control node associated with that record. The term "control node" has been used to descnbe the unique control that this node maintains over access to the record created at the control node. In addition to the responsibilities of the control node that have already been descπbed, the control node also has control powers over the record. The user of the control node can direct the control node to exercise these powers after the initial distπbution of the record and list of nodes. For example, the control node can add a new node to the list of nodes and, optionally, add the new node to the mesh.
The control node can also update the recipient status of a node that is on the list of nodes. One way to update the recipient status of a node is to remove it from the list of nodes so that the node no longer receives modifications to the record made by nodes of the mesh. If the node removed from the list of nodes was in the mesh, the control node can inform it not to modify the record or distnbute modified copies of the record anymore. The control node may optionally instruct
the node that was removed from the list of nodes to delete the removed node's locally stored copy of the record Alternatively, the control node may allow the removed node to keep the copy of the record it currently has even though the removed node will no longer receive modifications to that record made by mesh nodes If a node is in the list of nodes but not in the mesh, the control node can update that node's recipient status by adding that node to the mesh If a node is in both the list of nodes and the mesh, the control node can update that node's recipient status by removing it from the mesh but not from the list of nodes
Another control power that a user of the control node can direct the control node to exercise is the ability to authonze another node to add a new node to the list of nodes Optionally, the control node may further be able to authonze another node to add the new node to the mesh The control node also can have the power to relinquish its control status by transfernng these control powers to another node of the network In an embodiment of the invention where the records are medical records, the control node also may have the power to send portions of the record to a remote computer of the network that needs the information for an epidemiology study Typically, the control node protects the patient's identity from being revealed by sending only the pertinent medical data needed for the study. A node of the network which is not the control node for a record has only the powers with respect to the record granted to that node by the control node If granted the authonty, a node of the network may be part of the mesh for the record, meaning that the node can modify the record and distnbute the modified record to the nodes on the list of nodes. If granted the authonty, a node of the network can also add a new node to the list of nodes and distnbute the modified list of nodes to the nodes of the mesh
A node which is not the control node for a given record typically cannot remove a node from the list of nodes for that record There is, however, one exception. Suppose a node that is in the mesh modifies a record and sends that modified record to the list of nodes If the node that sent the modified record (the "sending node") receives an indication that the modified record could not be delivered to one of the nodes on the list of nodes (the "destination node"), then the sending node can remove the destination node from the list of nodes and distnbute the modified list of nodes to the nodes of the mesh Furthermore, if the node removed from the list of nodes was the control node for the record, then the sending node may assume control status by assuming the control powers
Each node of the network may have typical features of a computer system, such as processing unit, a system memory containing random access memory (RAM) and read only memory (ROM), and a system bus that couples the system memory to the processing unit The computer may also include various memory storage devices, such as a hard disk dnve, a magnetic disk dnve (e.g., to read from or wπte to a removable magnetic disk), and an optical disk dπve (e.g., to read from or wπte to optical media such as a CD-ROM).
A number of program modules may be stored the dnves and RAM of the computer system. Program modules control how the computer system functions and interacts with the user, with input/output devices, or with other computers. Program modules include routines, an operating system, application program modules, data structures, browsers, and other software or firmware components. The invention may conveniently be implemented in one or more program modules that are stored on each computer of the network and implement the methods descnbed in the detailed descnption.
No particular programming language will be descnbed for carrying out the vanous procedures descnbed in the detailed descnption because it is considered that the operations, steps, and procedures descnbed and illustrated in the accompanying drawings are sufficiently disclosed to permit one of ordinary skill in the art to practice an exemplary embodiment of the present invention. Moreover, there are many computers and operating systems which may be used in practicing an exemplary embodiment, and therefore no detailed computer program could be provided which would be applicable to all of these many different systems. Each user of a particular computer will be aware of the language and tools which are most useful for that user's needs and purposes.
One skilled in the art will appreciate that the network practicing an embodiment of the present invention may take vanous forms. The network may, for example, be any type of wide area network (WAN), including an enterpnse- wide computer network or the Internet. A computer forming a node of the network may include a modem or other means for establishing communications over the network.
In an embodiment of the present invention for stonng immunization data, each record may correspond to a single patient. The record may store a globally unique identifier that can differentiate that record from all other records that may be stored on the network. The globally unique identifier may also be used to access
the associated record at a node of the database using search tools known to those skilled in the art.
In addition, standard database access tools may provide a user of a database stoπng the record the ability to find the record based on certain fields in the record. For example, the user of the database may be able to access the record directly through a search based on the patient's name. If the database user cannot remember the patient name but does know that the patient visited a particular doctor on a particular date, the database user could request records for all patients who visited that doctor on the specified date. Such a request should produce a list of records that includes the desired patient record. Similarly, a user of the database at a node may use standard database interfaces to update information in the record.
The record may also store identifying information about the patient, including the patient's name, nickname, address, work phone, home phone, and e- mail address. The record may also contain links to records for other patients related to the patient. Or, the record may store family information within the record itself.
The record may contain immunization data. For instance, the record may include each vaccine the patient has been given, including the date given, the brand, the lot number, the injection site, and any adverse reactions. The record may provide sufficient information about the patient to permit another computer module to determine which vaccines the patient should be given at an office visit on a particular date. Such a program module could even automatically order vaccines that the program module determines should be given to the patient. The ordenng program module could then track the progress of the order, including the vaccine's arrival, by stonng such information in the patient record.
Though the detailed descnption has descnbed an embodiment of the invention in which each record is a medical record containing immunization data for a patient, one skilled in the art should recognize that the present invention could also be applied to the storage and maintenance of different kinds of records. Multiple data structures for stonng records in a database are also known to those skilled in the art.
Exemplary Record System Architecture
Turning now to the figures, in which like numerals refer to like elements throughout the several figures, aspects of a typical embodiment of the present invention will be descnbed
FIGs. 1A-1D illustrate the concept of distnbuted storage and update of records m a network as defined by exemplary embodiments of the present invention. FIG. 1A shows an exemplary record system 100 compπsmg a network 190 and typical nodes which may be linked through the network A node 1 10, which may be a computer at the office of a patient's pnmary care physician, has created a patient record 105 for that patient and stored the record on a local dnve of that computer. Because a node which creates a record is known as the home system or control node for that record, node 110 is the control node for patient record 105. Node 120 may be a computer at the patient's preferred hospital. Node 130 may be a computer at the office of a specialist doctor who has responsibility for treating the patient. Node 140 may be a computer at the patient's HMO. Node 150 may be a computer at the patient's school. Node 160 may be a computer serving as a repository that stores patient records for back-up purposes for node 140. Node 170 may be a computer that stores patient records so that it can automatically produce epidemiology studies on a peπodic basis.
Outside node 180 can be any computer attached to the network that shares the network with the other descnbed nodes, so long as that computer has no need to share information with them. In other words, outside node 180 shares no responsibility for providing services to the patient, and the outside node may not even perform functions related to medical care for anyone. There may be other nodes (not shown) attached to network 190 which are similarly unrelated to nodes 110, 120, 130, 140, 150, 160, and 170.
For the medical record application supported by the record system 100, nodes 120, 130, 140, 150, 160, and 170 have a need for current medical information about the patient. As shown in FIG. IB, a user at control node 110 can create a list of nodes 175 which determines the nodes connected to network 190 that will maintain a current copy of patient record 105. After creating a list of nodes 175, the control node 110 sends a copy of patient record 105 to the nodes on the list of nodes 175.
A user at control node 110 can also determine which nodes in the list of nodes 175 form a mesh 145 for patient record 105. Any mesh node 145 may modify patient record 105. For example, the patient's specialist doctor may update the patient's history in patient record 105 after the specialist doctor examines the patient dunng an office visit FIG. IC shows that node 130 has modified its patient record 105 to become modified record 115.
Because node 130 has modified patient record 105, node 130 is required to distribute modified record 1 15 to the nodes on the list of nodes 175 so that each node that peπodically needs information about the patient will have a current copy of that information FIG. ID shows that modified record 115 replaces patient record 105 at each node in the list of nodes 175 after distnbution of that modified record by the record system 100.
Exemplary Program Enabling Nodes of a Network to Practice Distnbuted Record Storage and Update
FIG. 2 shows the steps of an exemplary database program 200 for implementing the present invention. Database program 200, or a vaπation thereof, preferably operates on a computer at each node participating in the distnbuted storage and maintenance of records by the record system 100. For example, program 200 may run on node 110 and allow a user of that node to create a new record, distnbute the new record to a recipient list, and designate a mesh for the new record. The program 200 running on node 110 typically includes a database of records compnsmg new records created by the program at node 110 and records received by node 1 10 from other network nodes which have placed node 110 on the recipient list for records they have created.
Program 200 may also allow a user at node 110 to select a record from its database for processing. If node 110 is the control node for the selected record, then the program 200 provides the user with the opportunity to exercise the control powers over the record. If the mesh for the selected record includes node 110, then the program 200 may provide the user with the opportunity to modify the selected record and distnbute the modified record to the other nodes of the mesh. If the selected record's mesh does not include node 110 but the selected record's recipient list does include node 110, then the program 200 may limit the user to viewing the selected record. Database program 200 begins at step 220 when the user accesses a node containing the program and instructs the program to start. Step 230 effectively begins a loop for receiving and processing commands from the user for manipulating the contents of the database at that node. The program 200 can present the user with a main menu that includes three options: create a new record, select a record for processing, and exit the program. In step 240, the program 200 receives the user's menu choice
In step 250, the program 200 evaluates the user's choice to determine if the user wishes to exit the program. If the user wishes to exit, then the "YES" branch is followed to step 290, where the database program 200 shuts dow n before the program ends in step 295 If the program 200 determines in step 250 that the user does not wish to exit, then the "NO" branch is followed to step 260, where the program determines whether the user wishes to create a new record If the user wishes to create a new record, then the "YES" branch is followed to step 280 Step 280 allows the user to create a new record before the program 200 loops back to step 230 to present the user with the mam menu again.
If the program 200 determines in step 260 that the user does not to want to create a new record, then the "NO" branch is followed to step 270, which allows the user to select and manipulate a record stored in the database at that node. The program 200 then loops back to step 230 to present the user with the main menu again.
FIG. 3 is a logical flow diagram illustrating exemplary steps completed by routine 280 of FIG. 2. This routine allows the user to create a new record in the database at a node of the record system 100. It begins with step 320. in which the user enters information for the fields of the new record The program 200 may prompt the user for this record information through typical database graphical user interfaces.
In step 330, the program 200 indicates in the record that the node at which the user is creating the new record is the control node for that record. In step 340, the program 200 assigns a globally unique identifier to the record and stores that identifier in the record.
In step 350, the program 200 directs the user to create a recipient list, or list of nodes, for the new record. In step 360, the program 200 sends copies of the new record to all the nodes on the recipient list. In step 370, the program 200 directs the user to specify the nodes in the recipient list that form the mesh for the new record. In step 375, the program 200 stores an indication of the mesh nodes in the recipient list. In step 380, the program 200 sends the recipient list to the mesh nodes before the routine returns in step 390
FIG. 4 is a logical flow diagram illustrating exemplary steps completed by routine 270 of FIG. 2. This routine allows the user to select a record from the database of a node of the record system 100 and perform authoπzed operations on that record
The routine begins with step 410, in which the program 200 presents the user with a record retneval interface Record retneval interfaces are well known to those skilled in the art Different interfaces may allow a user to retneve a record through different search cntena. In step 420, the program 200 receives the user's selection of a particular record through the record retneval interface
Step 430 effectively begins a loop for allowing the user to manipulate the selected record until the user is finished processing the record The program 200 presents the user with a menu of record manipulation options based on the status of the node with respect to the selected record. Because the user can only select a record for manipulation if the database at the node where he is working stores a copy of that record, the menu will include the option to display the record The menu preferably includes the option to end processing of the selected record
The program 200 also determines if the node on which it is running stores a recipient list for the selected record. If the node stores a recipient list for the selected record, then that node is in the mesh. Accordingly, the menu should include the option to modify the record. If the node running the program 200 is in the mesh and has been authoπzed to add a new recipient to the recipient list for the selected record, then the menu should also include that option.
The program 200 also examines the selected record to determine if the node running the program is the control node for the selected record. If the node running the program is the control node, then the menu should also include options allowing the user to exercise the control powers of the control node. These control power options include adding a new recipient to the recipient list, updating the recipient status of a node on the recipient list, authoπzing another node to add a new node to the recipient list, transfemng home status to another node, and transfemng portions of the selected record to a node conducting an epidemiology study.
Once the program 200 presents the user with a menu of options for manipulating the selected record, the program receives the user's selection from the menu in step 440 In step 450, the program 200 determines if the selected option is to end processing of the record. If the selected option is to end processing, then the "YES" branch is followed to step 470, where the routine returns
If, in step 450, the program 200 determines that the selected option is not to end processing, then the "NO" branch is followed to step 460, in which the program executes the selected option for manipulating the record. The routine then
loops back to step 430 to present the user once again with options for further manipulating the selected record.
FIG. 5 is a logical flow diagram illustrating exemplary steps completed by routine 460 of FIG. 4. This routine contains instructions for executing on a node of the record system 100 an option the user has chosen for manipulating the selected record.
The routine begins at step 505 with the program 200 determining if the user has chosen the option of displaying the selected record. If the user has chosen to display the selected record, then the "YES" branch is followed to step 510, where the program 200 displays the record. The user may have the choice of specifying different display formats for the record. The program 200 may provide the user an interface for viewing different groups of information within the record. After the program 200 displays the record, the routine returns m step 575.
If, in step 505, the user has not chosen to display the record, then the "NO" branch is followed to step 515. In step 515, the program 200 determines if the user has chosen the option of modifying the selected record. If the user has chosen to modify the selected record, then the "YES" branch is followed to step 520, which allows the user to do this. The routine then returns in step 575. If, in step 515, the user has not chosen to modify the selected record, then the "NO" branch is followed to step 525.
In step 525, the program 200 determines if the user has chosen the option of adding a new node to the recipient list for the selected record. If the user has chosen the option of adding a new recipient, then the "YES" branch is followed to step 530, which allows the user to do this. The routine then returns in step 575. If, in step 525, the user has not chosen to add a new recipient to the selected record, then the "NO" branch is followed to step 535.
In step 535, the program 200 determines if the user has chosen the option of updating the recipient status of a node on the recipient list for the selected record. If the user has chosen this option, then the "YES" branch is followed to step 540, which allows the user to do this. The routine then returns in step 575. If, in step 535, the user has not chosen to update the recipient status of a node on the recipient list, then the "NO" branch is followed to step 545
In step 545, the program 200 determines if the user has chosen the option of authonzing another node to add new nodes to the recipient list. If the user has chosen this option, then the "YES" branch is followed to step 550. In step 550, the program 200 first queπes the user in order to determine which node the user
wishes to authonze The program 200 may also query the user in oidei to determine if the user wishes the newly authoπzed node to also have the ability to add to the mesh any new nodes the newly authoπzed node adds to the recipient list The node running the program 200 then authoπzes the newly authoπzed node by sending the newly authonzed node a special command informing it of its new abilities The database program running on the newly authoπzed node then stores the authoπzation in an appropnate manner for retneval in step 430 when determining which record manipulation options to present to a user at that node After the authoπzation is complete, the routine ends in step 575 If, in step 545, the program 200 determines that the user has not chosen to authonze another node to add new nodes to the recipient list, then the "NO" branch is followed to step 555 In step 555, the program 200 determines if the user has chosen the option of relinquishing home status by transfemng home status to another node If the user has selected this option, then the "YES" branch is followed to step 560, which performs the transfer This transfer of control status may include modifying the selected record to indicate the new control node for the record and sending the modified record to the nodes on the recipient list The routine then returns in step 575 If, in step 555, the user has not chosen to transfer home status, then the "NO" branch is followed to step 565 In step 565, the program 200 determines if the user has chosen the option of transfemng portions of the selected record to a node conducting an epidemiology study If the user has selected this option, then the "YES" branch is followed to step 570, which performs the transfer Typically, the information transferred does not include the patient's identity The routine then returns in step 575 If, in step 565, the user has not chosen to transfer portions of the selected record to a node conducting an epidemiology study, then the "NO" branch is followed to step 575, and the routine returns because the user has not chosen a valid option for manipulating the record
FIG 6 is a logical flow diagram illustrating exemplary steps completed by routine 520 of FIG 5 This routine allows the user of a mesh node for a selected record to modify the selected record and distnbute the modified record to the nodes on the record's recipient list via the network 190 of the record system 100
The routine begins with step 605, in which the program 200 provides graphical user interfaces through which the user modifies the selected record In step 610, the program 200 determines if the user wishes to save the modified record If the user does not wish to save the modified record, then the "NO"
branch is followed to step 650, in which the routine returns If the user wishes to save the modified record in step 610, then the "YES" branch is followed to step 615.
In step 615, the program 200 sends a copy of the modified record to all the nodes on the recipient list, which then replace their copy of the record with the copy of the modified record. Each node completing this replacement preferably sends a delivery confirmation over the network 190 to the node at which the record was modified. In step 620, the program 200 receives the confirmations.
In step 625, the program 200 determines if all the nodes on the recipient list successfully received the modified record. If confirmations were received from all nodes on the recipient list, then the "YES" branch is followed to step 650, and the routine returns. If the program 200 determines that m step 625 confirmations were not received from all nodes on the recipient list, then the "NO" branch is followed to step 630. In step 630, the program 200 determines if it did not receive a confirmation from the control node for the selected record. If the program 200 did not receive a confirmation from the control node, then the "YES" branch is followed to step 635. In step 635, the program 200 asserts control status for the node on which it is running. This may involve updating the modified record to indicate that the node on which program 200 is running is now the control node and distnbuting the modified record to the nodes on the recipient list for the record Program 200 then performs step 640. Step 640 is also performed if the "NO" branch is followed in step 630 after the program 200 determines that it received a confirmation from the control node. In step 640, program 200 removes from the recipient list the nodes to which delivery of the modified record was unsuccessful. In step 645, the program 200 sends the modified recipient list to the mesh nodes. The program 200 determines the mesh nodes by refernng to the recipient list. The routine then returns in step 650. FIG. 7 is a logical flow diagram illustrating exemplary steps completed by routine 530 of FIG. 5. This routine contains steps the program 200 follows to allow an authonzed user to add a new node of the record system 100 to the recipient list for the selected record. An authoπzed user is a user of the control node for the selected record or of a node authonzed by the control node to add a new recipient to the recipient list for the selected record
The routine begins with step 705, in which the program 200 requires the user to identify the new node to place on the recipient list for the selected record. In step 710, the program 200 adds the new node to the recipient list to form a modified recipient list. In step 715, the program 200 determines if node on which it is running is authonzed to add the new node to the mesh for the selected record. If the node on which program 200 is running is not authonzed, then the "NO" branch is followed to step 735, which shall be discussed shortly. If the node on which program 200 is running is authonzed, then the "YES" branch is followed to step 720, in which the program 200 quenes the user about whether the user wants to also add the new node to the mesh for the selected record.
If the program 200 determines in step 725 that the new node should not be added the mesh for the selected record, then the "NO" branch is followed to step 735, which shall be discussed shortly. If the program 200 determines in step 725 that the new node should be in the mesh, then the "YES" branch is followed to step 730, in which the program indicates in the recipient list that the new node is in the mesh. Program 200 then executes step 735.
In step 735, the program 200 sends a copy of the selected record to the new node over the network 190. In step 740, the program 200 sends the modified recipient list to the mesh nodes. The program 200 determines the mesh nodes by refernng to the recipient list. The routine then returns in step 745.
FIG. 8 is a logical flow diagram illustrating exemplary steps completed by routine 540 of FIG. 5. This routine descnbes steps that the program 200 follows to update the recipient status of a node of the record system 100 that is on the recipient list for the selected record.
The routine begins at step 810 with the program 200 determining the node on the recipient list whose recipient status is to be updated. Typically, the program 200 prompts the user for this information. In step 820, the program 200 selects the node whose recipient status will be updated. In step 830, the program 200 determines the new status for the selected node. The program 200 can offer the user three possibilities for updating the recipient status of the selected node: remove the selected node from the recipient list entirely, add the selected node to the mesh if the selected node is on the recipient list but not cunently in the mesh, and remove the selected node from the mesh but leave the selected node on the recipient list. The new status chosen for the selected node is processed in step 840 before the routine returns in step 850
FIG 9 is a logical flow diagram illustrating exemplaiy steps completed by routine 840 of FIG 8. This routine includes steps that the program 200 follows to update the recipient status of the node of the record system 100 that was selected in step 820 The routine begins at step 905 with the program 200 determining if the user has chosen to remove the selected node from the recipient list If the user has chosen to remove the selected node from the recipient list, then the "YES" branch is followed to step 910. In step 910, the program 200 removes the selected node from the recipient list. In step 915, the program 200 sends the revised recipient list to the mesh nodes. The program 200 determines the mesh nodes by refemng to the recipient list.
In step 920, the program 200 sends a command over the network 190 to the selected node informing the selected node of its removal from the recipient list. Upon receiving this information, the database program running on the selected node can pass this information on to users of the selected node. If the selected node was previously in the mesh for the selected record, the command sent from program 200 to the selected node serves to disable the selected node from further updating the record and sending the modified record to nodes on the recipient list.
Step 925 has been emphasized with dashed lines to indicate the optional nature of this step. In step 925, the program 200 may further instruct the selected node to delete the selected node's copy of the record Such deletion offers the advantage of ensunng that a node does not store an old version of a record. However, one should recognize that there may be instances in which a node has a legitimate need for information in a record that is satisfied by maintaining a local copy of that record which is never updated. The routine then returns in step 960.
Refemng again to step 905, if the program 200 determines that the user has not chosen the option of removing the selected node from the recipient list, then the
"NO" branch is followed to step 930. In step 930, the program 200 determines if the user has chosen to add the selected node to the mesh If the user has chosen this option, then the "YES" branch is followed to step 935. In this case, the selected node is currently on the recipient list, so the selected node has a current copy of the record. In step 935, the program 200 indicates in the recipient list the addition of the selected node to the mesh. In step 940, the program 200 sends the revised recipient list to the mesh, including the selected node The program 200 determines the mesh nodes by refe ng to the recipient list Receipt of the revised recipient list by the selected node serves to inform and enable the selected node to
modify the lecoid and distnbute copies of the modified recoid to nodes on the recipient list The routine then ends in step 960.
Refemng again to step 930, if the program 200 determines that the user has not chosen the option of adding the selected node to the mesh, then the "NO" branch is followed to step 945. In this case, the selected node was in the mesh pπor to routine 540, and the user has chosen to remove the selected node from the mesh but to leave the selected node on the recipient list. In step 945, the program
200 sends a command to the selected node informing the selected node of its removal from the mesh. The command also serves to disable the selected node from further modifying the record or distnbuting modified copies of the record to nodes on the recipient list.
In step 950, the program 200 indicates in the recipient list the removal of the selected node from the mesh. In step 955, the program 200 sends the revised recipient list to the mesh nodes The program 200 determines the mesh nodes by refemng to the recipient list. The routine then returns in step 960.
Thus, the detailed descnption has descnbed an exemplary system for distnbuted data storage and data updates. As descnbed, the system could be used to store data compnsing medical records containing immunization information.
However, data structures other than records could be used to implement the present invention. Similarly, the present invention could be used to store records containing different types of data, thereby expanding the applications to which the present invention can be applied.
Other alternative embodiments will become apparent to those skilled in the art to which an exemplary embodiment pertains without departing from its spint and scope Accordingly, the scope of the present invention is defined by the appended claims rather than the foregoing descnption.