JP5593766B2 - Data management program and data management apparatus - Google Patents

Description

  The present invention relates to a data management program and a data management device, and more particularly to a data management program and a data management device for data operated by a plurality of users.

  In recent years, medical institutions have introduced a computer system called an electronic medical record system, and various information such as patient information, examination result information, examination result information, progress information, drug order information, accounting information, and application information for various examinations are available. It is managed electronically.

  As a characteristic of the electronic medical record system, there is a high possibility that a plurality of persons access the same data (record) in the database at the same time. Since examination, examination, accounting, etc. for a single patient are performed within a relatively short period of time, it is possible to input electronic medical records related to the same patient by multiple persons such as doctors, nurses, laboratory technicians, and medical clerks. This is because they tend to concentrate within a short period.

  In view of improving work efficiency, it is desirable that a plurality of operators can edit the electronic medical records of the same patient in parallel.

  For example, Patent Document 1 discloses a technique for simultaneously editing the same data.

JP 2001-256210 A

  However, the technique of Patent Document 1 is difficult to apply to a business system such as an electronic medical record system because the contents of simultaneous editing are unconditionally reflected in the data. For example, consider a case where a first user (doctor) and a second user (nurse) edit the same data (an electronic medical record of a patient). In that case, it is conceivable that the connection between the part edited by the first user and the part edited by the second user becomes strange when the editing by both parties is reflected. As in the electronic medical record system, it is not desirable that information managed in the future is accumulated as such unclear information. In addition, when editing by the second user is reflected in the data while the first user is editing, the first user is confused. In other words, a doctor who has been editing halfway has to change his / her input by editing by a nurse. Furthermore, if editing by the nurse is inappropriate, the doctor will need to correct it.

  The present invention has been made in view of the above points, and an object of the present invention is to provide a data management program and a data management apparatus capable of ensuring an appropriate order for parallel operations on the same data.

  Therefore, in order to solve the above problem, a data management program receives a start request reception procedure for receiving an operation start request for data stored in the data management means from a first terminal device used by a first user, A recording procedure for recording association information between the first user related to the received operation start request and the data to be operated in the operation information storage unit; and a second user different from the first user Update request reception procedure for receiving an update request for the data from the second terminal device to be used, and the presence or absence of the first user associated with the data to be updated included in the update request, When there is a duplicate operation determination procedure determined using the operation information storage means and the first user associated with the data to be updated Using superiority / inferiority information storage means storing information indicating the superiority or inferiority relationship between the first user and the second user regarding the update of the data by the second user, the first user and the second user A computer executes an superiority / inferiority determination procedure for determining an superiority / inferiority relationship with a second user and an update procedure for determining whether to accept the update request based on the determination result of the superiority / inferiority relationship.

  According to the disclosed technique, it is possible to ensure an appropriate order for parallel operations on the same data.

It is a figure which shows the structural example of the electronic medical chart system in embodiment of this invention. It is a figure which shows the hardware structural example of the electronic medical record server in embodiment of this invention. It is a figure which shows the function structural example of the electronic medical chart system in embodiment of this invention. It is a figure for demonstrating the process outline | summary in the electronic medical chart system of this Embodiment. It is a figure for demonstrating the process outline | summary in the electronic medical chart system of this Embodiment. It is a flowchart for demonstrating the process sequence at the time of the operation start of an electronic medical chart. It is a figure which shows the structural example of the operation information storage part. It is a flowchart for demonstrating the process sequence at the time of the update of an electronic medical chart. It is a figure which shows the structural example of a user information storage part. It is a figure which shows the structural example of an authority level memory | storage part. It is a figure which shows the structural example of an update notification method memory | storage part. It is a flowchart for demonstrating the process sequence at the time of completion | finish of operation of an electronic medical chart.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram illustrating a configuration example of an electronic medical chart system according to an embodiment of the present invention.

  The electronic medical chart system 1 is a computer system that electronically processes various medical information such as a so-called medical chart. Hereinafter, information processed in the electronic medical record system 1 is collectively referred to as an electronic medical record. In the electronic medical chart system 1 of FIG. 1, the electronic medical record server 10 and the plurality of user terminals 20 are connected via a network 30 (regardless of wired or wireless) such as a LAN (Local Area Network) or the Internet. It is connected.

  The electronic medical record server 10 is a computer that manages electronic medical records and the like. In the present embodiment, the electronic medical record server 10 functions as an example of a data management device.

  The user terminal 20 is a computer used for browsing and inputting electronic medical records. For example, the user terminal 20 is disposed in an examination room, a nurse station, a bedside, or an examination room in a medical institution, and is used by a doctor, a nurse, an examination engineer, or the like.

  FIG. 2 is a diagram illustrating a hardware configuration example of the electronic medical record server according to the embodiment of the present invention. The electronic medical record server 10 of FIG. 2 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, and an interface device 105 that are mutually connected by a bus B.

  A program for realizing processing in the electronic medical record server 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 on which the program is recorded is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program need not be installed from the recording medium 101 and may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program and also stores necessary files and data.

  The memory device 103 reads the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 executes a function related to the electronic medical record server 10 in accordance with a program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network.

  FIG. 3 is a diagram illustrating a functional configuration example of the electronic medical record system according to the embodiment of the present invention. In the figure, the electronic medical record server 10 includes an operation start processing unit 111, an overlapping operation determination unit 112, an dominance relationship determination unit 113, an update processing unit 114, an operation end processing unit 115, an operation information storage unit 116, and a user information storage unit 117. , An authority level storage unit 118, an update notification method storage unit 119, a main DB 120, a temporary DB 121, and the like. Each of these units is realized by processing executed by the CPU 104 by a program installed in the electronic medical record server 10.

  The main DB 120 is a database that stores electronic medical records using the auxiliary storage device 102. In the present embodiment, the data collectively referred to as an electronic medical record includes a plurality of types of data (eg, order information, finding information, medical history information, basic patient information, etc.). The main DB 120 stores data for each data type, even for the same patient data. For example, the main DB 120 stores data using a different table for each data type. Therefore, in this embodiment, each data (for example, a record in the table) is uniquely specified by the data type and the patient identifier (patient ID). The temporary DB 121 is a database that temporarily stores the updated contents of the main DB 120 using the auxiliary storage device 102 before reflecting the updated contents to the main DB 120.

  The operation start processing unit 111 executes a process according to an electronic medical record operation start request (access request). In the present embodiment, the electronic medical chart operation start request specifically corresponds to an electronic medical chart open request. The opening of the electronic medical record means that the electronic medical record is displayed on the display device of the user terminal 20 for the purpose of browsing or editing (updating) the electronic medical record. The operation start processing unit 111 also records association information between the operator (user) of the electronic medical record and the operation target data in the operation information storage unit 116 in response to a request to start the operation of the electronic medical record. The operation information storage unit 116 stores the association information using the auxiliary storage device 102.

  The duplicate operation determination unit 112 uses the operation information storage unit 116 to determine whether or not the data to be updated is being operated by a user other than the updater in response to a request to update the electronic medical record. That is, the duplicate operation determination unit 112 detects a duplicate operation (duplicate access) for one piece of data.

  The superiority or inferiority determination unit 113 determines the superiority or inferiority relationship between the operators related to the overlap operation using the user information storage unit 117 and the authority level storage unit 118 when the overlap operation determination unit 112 detects the overlap operation. Here, the superiority or inferiority relationship refers to an superiority or inferiority relationship or an up-and-down relationship with respect to the update of the electronic medical record. The user information storage unit 117 stores attribute information for each user of the electronic medical record system 1 using the auxiliary storage device 102. The attribute information includes the user's job type (type of doctor, nurse, laboratory technician, medical office worker, etc.) as one item. The authority level storage unit 118 stores the authority level in accordance with the data type for each job type using the auxiliary storage device 102. Therefore, in the present embodiment, the user information storage unit 117 and the authority level storage unit 118 are examples of superiority / inferiority information storage means.

  The update processing unit 114 determines whether or not the electronic medical record update request is accepted based on the determination result of the superiority / inferiority determination unit 113. The operation end processing unit 115 executes a process according to a request to end the operation of the electronic medical record. In the present embodiment, the end request for the operation of the electronic medical chart specifically corresponds to a request for closing the electronic medical chart. The closing of the electronic medical chart means that the displayed electronic medical chart is not displayed. The operation end processing unit 115 also deletes the association information between the operator (user) of the electronic medical record and the operation target data from the operation information storage unit 116 in response to a request to end the operation of the electronic medical record.

  The update notification method storage unit 119 uses the auxiliary storage device 102 to notify the update notification method to another person who operates the data when an update to the data by a certain operator is reflected in the main DB 120. Store for each type.

  The user terminal 20 has a client unit 21. The client unit 21 displays the electronic medical record on the user terminal 20. The client unit 21 transmits a request corresponding to the operation on the electronic medical record to the electronic medical record server 10.

  Hereinafter, the processing procedure of the electronic medical chart system 1 will be described. First, an overall processing overview will be described.

  4 and 5 are diagrams for explaining an outline of processing in the electronic medical chart system of the present embodiment.

  4 and 5, the occupation type of the operator A of the user terminal 20a is a doctor, and the occupation type of the operator B of the user terminal 20b is medical office work. In both user terminals 20, the same data is operated, and it is assumed that the doctor has higher authority (dominant) than the medical office for the data.

  FIG. 4 shows a case where the operator B tries to update (S2) the data being operated by the operator A (S1). In other words, this is a case where the lower-level authority attempts to reflect the updated contents in the main DB 120 for the data being operated by the higher-level authority. In this case, before the update content is reflected in the main DB 120, the update notification screen 210 is popped up (displayed) on the user terminal 20a of the operator A who is the higher authority (S3). On the update notification screen 210, a message indicating information about the updater is displayed, and a content confirmation button 211, a permission button 212, a rejection button 213, and the like are arranged. The operator A can confirm the updater by referring to the message on the update notification screen 210. The operator A can confirm the updated content by pressing the content confirmation button 211. When permitting the update contents to be reflected in the main DB 120, the operator A presses the permission button 212. In response to pressing of the permission button 212, the updated content is reflected in the main DB 120. When the update content is not permitted, the operator A presses the reject button 213. When the reject button 213 is pressed, the updated content is not reflected in the main DB 120.

  On the other hand, FIG. 5 shows a case where the operator B tries to update the data being operated by the operator B (S11) (S12). In other words, this is a case where the higher-level authority attempts to reflect the updated contents in the main DB 120 for the data being operated by the lower-level authority. In this case, the update content by the higher authority is reflected in the main DB 120 without requiring permission by the lower authority. The higher authority is expected to have more knowledge than the lower authority for the data type of the data to be updated. Therefore, by allowing the update contents to be reflected without the permission of the subordinate authority, it is possible to reflect the update of the user having a lot of knowledge earlier.

  As described above, in the present embodiment, the update contents of the lower authority are reflected only when the data operated (accessed) in parallel is permitted by the upper authority.

  Hereinafter, a detailed processing procedure for realizing the above processing outline will be described.

  FIG. 6 is a flowchart for explaining a processing procedure at the start of operation of the electronic medical chart.

  The operator logs in the electronic medical chart system 1 by inputting a user ID or the like at the user terminal 20. If the login is successful, the client unit 21 displays an electronic medical record screen on the user terminal 20. When the patient ID and the data type are designated or selected on the electronic medical record screen, the client unit 21 designates the user ID of the login user, the patient ID, and the data type, and sends an electronic medical record open request electronically. It transmits to the chart server 10.

  In step S101, the operation start processing unit 111 receives an electronic medical record open request. Subsequently, the operation start processing unit 111 acquires (searches) the data (record) specified by the patient ID from the table of the main DB 120 specified by the data type (S102). Subsequently, the operation start processing unit 111 records the user ID, the patient ID, and the data type related to the electronic medical record open request in the operation information storage unit 116.

  FIG. 7 is a diagram illustrating a configuration example of the operation information storage unit. As shown in the figure, the operation information storage unit 116 stores a user ID, a patient ID, a data type, and the like in association with an open electronic chart (accessed).

  Subsequently, the operation start processing unit 111 returns the data acquired in step S102 to the client unit 21 that is the electronic medical record open request source (S104). The client unit 21 displays the returned data on the electronic medical record screen. As a result, the operator can browse or update the data.

  Next, a processing procedure when updating the electronic medical chart will be described. FIG. 8 is a flowchart for explaining a processing procedure when updating the electronic medical chart.

  When reflecting the contents of the electronic medical record in the middle of editing or the contents of the electronic medical record after editing (hereinafter referred to as “update contents”) to the main system DB 120 on the electronic medical chart screen, it is updated by the operator via the update menu or the like. An instruction is entered. In response to the input of the update instruction, the client unit 21 transmits an update request including the update contents, the operator user ID, the patient ID, the data type, and the like to the electronic medical record server 10. For example, when the electronic medical record is opened, a session ID may be assigned to the exchange with the client unit 21 by the electronic medical record server 10. When the user ID, the patient ID, and the data type are managed in association with the session ID, the session ID may be specified in the update request instead of the user ID, the patient ID, and the data type. In this case, the session ID functions as operator identification information and data identification information.

  When the electronic medical record server 10 receives the update request (S201), the duplicate operation determination unit 112 determines the user ID, patient ID, and data type specified in the update request, and the operation information storage unit 116 (see FIG. 7). Is used to determine whether or not the data to be updated is being operated by another person (S202). Specifically, the patient ID and data type specified in the update request and related to the user ID other than the user ID specified in the update request are stored in the operation information storage unit 116. It is determined whether it is recorded.

  When there is no other person who is operating the data to be updated (hereinafter referred to as “same data operator”), that is, when the corresponding patient ID and data type are not recorded in the operation information storage unit 116 ( The update processing unit 114 reflects the update content (update information) in the data specified by the data type and patient ID in the main DB 120 (S203).

  On the other hand, when the same data operator exists, that is, when the corresponding patient ID and data type are recorded in the operation information storage unit 116 (Yes in S202), the update processing unit 114 stores the update contents in the temporary DB 121. Record (S204). Subsequently, the superiority / inferiority determination unit 113 acquires job types from the user information storage unit 117 for each of the same data operator and the updater (S205).

  FIG. 9 is a diagram illustrating a configuration example of the user information storage unit. As shown in the figure, the user information storage unit 117 stores a user ID, name, job title, terminal name, and the like for each user. The user ID is identification information of each user. The name is the name of the user. The job type is the job type of the user in the medical institution. In the figure, job types are classified into doctors, nurses, laboratory technicians, medical office work, and the like, but specific job type values (names) may be appropriately determined according to the operation. The terminal name is the name (host name) of the user terminal 20 used by each user. The terminal name may be anything that can identify each user terminal 20 in a predetermined communication protocol. Therefore, an IP address or URL may be managed instead of the terminal name.

  In step S <b> 204, job types associated with the respective user IDs of the same data operator and the updater are acquired from the user information storage unit 117.

  Subsequently, the superiority / inferiority determination unit 113 updates the same data operator with the same data operator using the job type of the same data operator, the job type of the updater, the data type of the data to be updated, and the authority level storage unit 118. The superiority or inferiority regarding the update of the data with the person is determined (S206).

  FIG. 10 is a diagram illustrating a configuration example of the authority level storage unit. As shown in the figure, the authority level storage unit 118 stores an authority level for each combination of job type and data type. The authority level is an index indicating the superiority or inferiority relationship (up-and-down relationship) between operators regarding data update. In the present embodiment, it is evaluated that the authority level value is relatively superior (higher).

  For example, if it is a doctor, the authority level about order information is "10". There is no other job category to which an authority level higher than “10” is assigned for the order information. Therefore, it can be understood that the doctor is most advantageous in updating the order information. On the other hand, regarding the patient basic information, the authority level of the nurse (“10”) is the highest. Therefore, it can be seen that the nurse has the most advantage in updating the patient basic level.

  Thus, in the present embodiment, it is possible to set superiority or inferiority relationships between job types according to data types. Therefore, it is possible to flexibly determine the superiority or inferiority relationship between operators in accordance with the actual situation of medical work. That is, even for the same patient's electronic medical record, the type of job to be responsible for data input may differ depending on the data type.

  In step S206, it is determined whether or not there is a person having an authority level higher than the authority level of the updater identified as described above (hereinafter referred to as “same data upper operator”) among the same data operators. The

  When the same data upper operator exists (Yes in S206), the update processing unit 114 transmits update notification information to the user terminal 20 of each same data upper operator (S207). The update notification information includes, for example, the job title, name, and update content of the updater. The user terminal 20 of each operator having the same data higher rank is determined based on the terminal name in the user information storage unit 117 (FIG. 9). Note that the difference between the data before update and the data after update may be transmitted as update contents. By doing so, the communication load can be reduced. Moreover, the updated location (for example, data item) can be easily determined on the side of receiving the update content. The difference may be determined by the update processing unit 114 comparing the update content specified in the update request with the update target data recorded in the main DB 120.

  The client unit 21 that has received the update notification information displays the update notification screen 210 shown in FIG. 4 on the display device of the user terminal 20. When the content confirmation button 211 is pressed, the client unit 21 displays the updated content. When the permission button 212 is pressed, the client unit 21 returns a response indicating permission to the electronic medical record server 10. When the reject button 213 is pressed, the client unit 21 returns a response indicating rejection to the electronic medical record server 10.

  Upon receiving a response indicating rejection from at least one user terminal 20 (Yes in S208), the update processing unit 114 of the electronic medical record server 10 transmits a message indicating rejection to the user terminal 20 of the updater (S209). . The client unit 21 that has received the message displays the message on the display device of the user terminal 20. As a result, the updater recognizes that his update request has been rejected.

  Subsequently, the update processing unit 114 deletes the update content recorded in the temporary DB 121 (S210).

  On the other hand, when it is determined that the same data upper operator does not exist (No in S206), or when a response indicating permission is received from all the same data upper operators (No in S208), the update processing unit 114 Then, the update contents recorded in the temporary DB 121 are reflected in the main DB 120 (S211). Subsequently, the update processing unit 114 distributes the update contents to the user terminals 20 of the same data operators (S212). The client unit 21 that has received the updated content reflects the updated content on the electronic medical record screen. Thereby, it is possible to prevent the update contents from being overwritten and erased by the update by the same data operator. Specifically, the update contents reflected on the electronic medical record screen are displayed by merging or overwriting the update contents corresponding to the input fields for each input field on the electronic medical record screen. In the case of merging, the edited contents up to that point can be retained.

  Note that the operator whose update contents are reflected on the update screen in step S212 is the same data operator. In other words, not only the higher authority but also the lower authority can be included. Accordingly, an operator who does not display the update notification screen 210 may be included. For such an operator, it is considered unfriendly that the updated content is suddenly reflected on the electronic medical record screen. Accordingly, in step S212, the update processing unit 114 may determine the update notification method by referring to the update notification method storage unit 119.

  FIG. 11 is a diagram illustrating a configuration example of the update notification method storage unit. In the figure, an update notification method storage unit 119 stores an update notification method for each data type. Examples of the update notification method include update content display, pop-up, and forced update. Since these are examples, other update notification methods may be defined.

  In step S212, the update processing unit 114 acquires an update notification method corresponding to the data type of the data to be updated, and distributes update notification information including the update notification method to the user terminal 20 of the same data operator. . The client unit 21 that has received the update notification information executes a process according to the update notification method specified in the update notification information. For example, if “update content display” is designated, the client unit 21 displays an update content display screen including the update content superimposed on the electronic medical record screen. If “pop-up”, a pop-up screen including a message notifying that the data being edited has been updated is superimposed on the electronic medical record screen and displayed. When the update content display screen or the pop-up screen is closed, the client unit 21 reflects the update content on the electronic medical record screen. When “forced display” is designated, the client unit 21 reflects the updated contents on the electronic medical chart screen without displaying the screen or the like.

  Note that the update notification method storage unit 119 may be used in step S207. However, in this case, each screen includes a permission button and a rejection button. The update notification method of forced display cannot be specified.

  Further, the update notification information in step S212 may be distributed to the user terminals 20 of all operators who are currently operating the electronic medical record (that is, operators other than the same data operator). In this case, each client unit 21 compares the patient ID and data type of the data currently being edited in the client unit 21 with the patient ID and data type of the data related to the update notification information, and the two do not match May ignore the update notification information. By doing so, in the unlikely event that a new same data operator occurs between steps S201 and S212, the occurrence of a situation in which the updated content is not reflected on the electronic medical record screen of the same data operator is prevented. be able to.

  Next, a processing procedure at the end of the operation of the electronic medical record will be described. FIG. 12 is a flowchart for explaining the processing procedure at the end of the operation of the electronic medical chart. After the update request, the operator can continue editing on the electronic medical record screen for the same data, and can make an update request again. When ending the operation related to the data, the operator instructs the electronic medical record to be closed via the electronic medical record screen. In response to the instruction, the client unit 21 transmits a request to close the electronic medical record to the electronic medical record server 10.

  In step S301, the operation end processing unit 115 of the electronic medical record server 10 receives the electronic medical record close request. Subsequently, the operation end processing unit 115 deletes the record relating to the user ID, patient ID, and data type specified in the close request from the operation information storage unit 116 (S302). Thereby, the restriction regarding the update of the data related to the patient ID and the data type due to the presence of the operator is released. In the close request, a session ID or the like may be specified instead of the user ID, patient ID, and data type.

  As described above, according to the present embodiment, the same data can be operated by a plurality of operators. Accordingly, it is possible to improve the efficiency of business. In addition, when an update by any operator is reflected, it is entrusted to the operator who is superior to the operator with respect to the data to be updated, and the update is permitted by the operator above the operator. The update is reflected when it is done. Therefore, updates by a plurality of operators are reflected in a disorderly manner, and as a result, it is possible to prevent troubles or confusion in the operations of each operator (especially, a higher-level operator).

  Note that the present embodiment may be applied to a computer system other than the electronic medical record system 10 that can be operated by a plurality of users on the same data.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

1 electronic medical record system 10 electronic medical record server 20 user terminal 21 client unit 100 drive device 101 recording medium 102 auxiliary storage device 103 memory device 104 CPU
105 Interface device 111 Operation start processing unit 112 Duplicate operation determination unit 113 Superiority / determination relationship determination unit 114 Update processing unit 115 Operation end processing unit 116 Operation information storage unit 117 User information storage unit 118 Authority level storage unit 119 Update notification method storage unit 120 System DB
121 Temporary DB
B bus

Claims (7)

A start request receiving procedure for receiving an operation start request for the data stored in the data management means from the first terminal device used by the first user;
A recording procedure for recording association information between the first user related to the received operation start request and the data to be operated in an operation information storage unit;
From the first second terminal device used by a second user that is different from the user, and the update request receiving step of receiving an update request for the data,
A duplicate operation determination procedure for determining the presence or absence of the first user associated with the data to be updated included in the update request using the operation information storage unit;
When there is the first user associated with the data to be updated, the superiority or inferiority relationship between the first user and the second user regarding the update of the data by the second user is shown. An superiority / inferiority determination procedure for determining an superiority / inferiority relationship between the first user and the second user using superiority / inferiority information storage means storing information;
A data management program that causes a computer to execute an update procedure for determining whether or not to accept the update request based on the determination result of the superiority or inferiority relationship. In the updating procedure, the computer compares the first user's authority to update the data with respect to the first user and the second user to have the second authority to update the data with respect to the data. A procedure and a procedure for transmitting the content of the update request to the first terminal device when the first update authority is greater than the second update authority;
The procedure for reflecting the update content by the second user in the data to be updated when a response indicating permission of update is received from the first terminal device. Data management program.   3. The data management program according to claim 2, wherein in the transmission step, the difference before and after the update request is transmitted to the first terminal device as the content of the update request with respect to the data to be updated. The superiority or inferiority information storage means stores information indicating the superiority or inferiority according to a data type that is information for classifying the data,
4. The superiority or inferiority determination procedure according to claim 1, wherein the superiority or inferiority relationship between the first user and the second user is determined with respect to the data type of the data to be updated. Data management program. In the update procedure, the computer
A procedure for referring to the superiority / inferiority information storage means and comparing the first update authority for the data of the first user and the second update authority for the data of the second user; and the first update authority 5 is executed, when the second update authority is smaller than the second update authority, the update content of the second user is reflected in the data to be updated. Data management program. An operation start request for the data stored in the data management means is received from the first terminal device used by the first user, and the first user and the operation target of the received operation start request are received. Operation start processing means for recording association information with the data in an operation information storage means;
From a second terminal device used by a second user that is different from said first user, receiving a request to update the data, the associated with the data of the update target included in the update request Duplicate operation determination means for determining the presence or absence of the first user using the operation information storage means;
When there is the first user associated with the data to be updated, the superiority or inferiority relationship between the first user and the second user regarding the update of the data by the second user is shown. Using superiority / inferiority information storage means storing information, superiority / inferiority determination means for determining superiority / inferiority relationship between the first user and the second user;
A data management apparatus comprising: update means for determining whether or not to accept the update request based on the determination result of the superiority or inferiority relationship.   A start request receiving procedure for receiving an operation start request for the data stored in the data management means from the first terminal device used by the first user;
  A recording procedure for recording association information between the first user related to the received operation start request and the data to be operated in an operation information storage unit;
  An update request receiving procedure for receiving an update request for the data from a second terminal device used by a second user different from the first user;
  A duplicate operation determination procedure for determining the presence or absence of the first user associated with the data to be updated included in the update request using the operation information storage unit;
  Referring to the superiority / inferiority information storage means storing the authority level for each user regarding the update of the data, the authority level of the first user and the second user's authority for the data stored in the operation information storage means A superiority / inferiority determination procedure for comparing the authority level and determining the superiority / inferiority relationship between the first user and the second user;
  An update procedure for executing an update process in response to the update request when the authority level of the second user is higher than the authority level of the first user based on the determination result of the superiority or inferiority;
Data management program that causes a computer to execute.

Images