JP2001337856A - Information management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reserve backup data in which updated data in system distribution is constantly reflected, and also to secure data saving when a failure occurs. SOLUTION: A backup system is provided with a main system server 51 distributing a system to clients in the normal operation, the first storage means 52 storing a database A used for system distribution by the main server 51, a communication file 55 temporarily storing updated data in updating the database A stored in the first storage means 52, a subsystem server 53 distributing the system to clients in an abnormal operation in the main server 51, and the second storage means 54 used for the system distribution by the subsystem server 53, storing a database A' on which the updated data in the communication file 55 is sequentially reflected.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an information management system, and more particularly, to a failure management for an information management system including a database for medical information, a server for managing other databases, and a client capable of accessing the database. About technology.

[0002]

2. Description of the Related Art In an information management system including a server for managing a database and a client capable of accessing the database,
Authenticity, readability, and storability of data are required. For this reason, it is necessary to take measures against various software failures and hardware failures occurring in the server, the network, and the client.

[0003] In recent years, in a medical facility such as a hospital, many computers have been introduced in all departments such as patient reception work, input / output of medical information and audit information, and accounting work.
In order to ensure the consistency of data handled by each department and improve the efficiency of work, such medical information can be managed collectively on the server, and clients installed in each department can access the database managed by the server. Conceivable.

When the medical information is digitized, it is necessary to secure the above-mentioned authenticity, readability and preservability, as well as privacy protection. In order to ensure readability and storability, it is possible to output to a terminal monitor or a printer, and it is possible to refer to it promptly as needed, and it is possible to refer to data continuously. It is necessary to satisfy the requirement that a simple backup is possible.
In addition, user authentication, falsification prevention,
Requirements such as confusion prevention and history preservation must be met.
Further, from the viewpoint of privacy protection, it is necessary to satisfy requirements such as system security, network security, access control, and logging (storage of history).

[0005] Based on such a viewpoint, the prior art and its problems will be discussed below. There is a clustering system in which a plurality of systems are combined to increase system redundancy so that even if a failure occurs in a part of the system, the entire system can be operated without being down. For example,
The server group that functions as if it were a single server system is composed of the primary server and the secondary server. If a failure occurs in the primary server that provides the system during normal operation, the failed primary server is replaced. Disconnect, and in place of this, the processing is continued on the secondary server in the cluster. This allows the client to continue processing without being aware of the failure of the primary server.

However, usually, in the system of the master server and the slave server, the database stored in the same storage means is often used. As a storage unit for storing the database, a storage medium such as a disk array is used. However, if a disk failure occurs in the storage unit, data cannot be rescued. A backup of the disk storing the database is also created and stored at predetermined intervals, but in this case, although the data at the time of the backup can be guaranteed, it is updated sequentially. Since the data is not stored, the data at the time of the failure occurrence cannot be guaranteed.

SUMMARY OF THE INVENTION Accordingly, it is an object of the present invention to secure backup data that always reflects updated data when a system is provided, and to reliably perform data recovery when a failure occurs. In a clustering system having a master server and a slave server as described above, if a failure occurs in the master server currently providing the system, the failed master server is disconnected from the network and the slave server is disconnected. Switch the system to the system server. Switching processing of such a system takes time, and it is necessary to stop the business at a level of several tens of minutes during this processing.

[0008] When the degree of failure that has occurred in the primary server is low, it is possible that the primary server can be recovered before the system switching process to the secondary server is completed. In this case, since the system switching process to the slave server is not performed, the operation is stopped until the master server is restored. In a system related to medical information at a hospital, a medical record cannot be referred to during processing for these disorders, which impairs medical treatment.

An object of the present invention is to make it possible to refer to data in a database during recovery processing for a failure when a failure occurs in the primary server, thereby preventing business stagnation. When hospital medical information is digitized, reception information and appointment information of patients who visit the hospital are also digitized, and the list of patient reception information and appointment information is displayed on the display screen of each client terminal. The staff can check the patient's visit, the order of medical treatment and treatment, and notify the patient of the order of medical examination using a display board or the like.

[0010] However, if a failure occurs in such a medical information management system, there is no physical slip as a guide for the patient's visit and the order of medical treatment, so that the patient's reception information and reservation information can be referred to. As a result, it is not possible to grasp the patient's visit status and the order of medical examinations, so that the work of medical examination and treatment is hindered. An object of the present invention is to make it possible to refer to the reception patient information even when a failure occurs in the medical care information management system. The client terminal of the information management system accepts edit data for the data based on the data obtained from the server, and transmits update data to the server when the edit data is determined.

When a momentary power failure, power outage, or other failure occurs while editing data at the client terminal,
In many cases, the data being edited is not guaranteed. In particular, in the case of a medical care information management system, data to be referred to is acquired from a server, and writing processing of data such as an electronic medical record is performed with reference to the acquired data. If the device fails,
Most of the data being referred to is basically written on the disk such as the server, so the data is guaranteed as long as there is no accident such as disk crash, but the data being edited on the client is usually erased. So
In many cases, data input up to that point is not guaranteed. In a medical information management system such as an electronic medical record, there are data that are input during an interview or consultation with a patient, so it may be difficult to input data again. Cause.

An object of the present invention is to save data being edited at the time of occurrence of a failure and to guarantee the data being edited. In an information management system having a server and a client, it is difficult for the server to manage login information from the client. In particular, it is difficult to obtain what kind of data in the database was referred to, the ID of the person who operated the terminal, and other detailed data.

In an information management system that handles medical information at hospitals, it is absolutely necessary to prevent data from being tampered with or illegally added or deleted. However, from the viewpoint of privacy protection, illegal reference to data is also required. Need to be prevented. Therefore, it is desired that the history information of what operation was performed from the client terminal is left, and that if any problem occurs, the history information can be analyzed.

Further, by grasping the operating status of the client terminals, it is possible to determine whether or not the arrangement of each terminal is appropriate. It is desired to collect information on the operation history of the terminal. An object of the present invention is to provide a system capable of collecting an operation history of what operation has been performed from a client terminal and analyzing the operation history. At the time of system login, it is often the case that a user ID and a password set for each user ID are required to be entered, and login is permitted only when the passwords match. Once set, the password is rarely changed, and if this password is leaked in any way, it is difficult to prevent improper activities such as so-called "spoofing". In particular, in medical facilities such as hospitals, the staffs are frequently switched, and there is a possibility that the user IDs and passwords of the staffs who are not present in the hospital may remain usable. in this way,
It is necessary to prevent information leakage and data falsification due to unauthorized access.

An object of the present invention is to change a password used at the time of system login in a predetermined period to prevent access by an illegally obtained password.

[0016]

A backup system for a clustering system according to the present invention stores a main server that provides a system to a client during normal operation, and a database used when the main server provides the system. A first storage unit, a contact file for temporarily storing update determination information at the time of updating the database stored in the first storage unit, a slave server for providing a system to the client when the main server is abnormal, Used when the system server provides the system,
Second storage means for storing a database in which the update determination information in the contact file is sequentially reflected.

Here, it is possible to adopt a configuration further comprising a third storage means for backing up a database stored in the second storage means. Further, a configuration may further be provided that further includes a fourth storage unit that stores the data portion of the database backed up by the third storage unit.
The database can be a database for medical information.

[0018] A backup method for a clustering system according to the present invention comprises: a primary server for providing a system to a client during normal operation; a first storage means for storing a database used when the primary server provides the system; A contact file for temporarily storing update data when the database stored in the first storage means is updated, a slave server for providing a system to the client when an error occurs in the master server, and a slave server for providing the system. In a clustering system including a second storage unit that stores a database that is used at the time of performing and that sequentially reflects the contents of a communication file, and a third storage unit that backs up the database stored in the second storage unit, During normal operation, the primary server is stored in the first storage unit. It was when updating the database,
Writing the update data in the contact file at the same time; reading the update data stored in the contact file by the slave server and updating the database stored in the second storage means; Stopping the updating of the database stored in the second storage means and storing a backup of the database stored in the second storage means in the third storage means; Restarting the update of the database stored in the database.

Here, it is possible to further comprise a step of storing the data portion of the database backed up by the third storage means in an external storage medium at a timing different from online. Further, the database may be a database regarding medical care information. Further, the present invention proposes a recording medium for recording a program related to the above-described backup method of the clustering system.

The clustering system according to the present invention comprises:
A storage unit that stores a database, a main server that provides a system to a client using the database stored in the storage unit during normal operation, and a database that is stored in the storage unit when the main server fails. The system includes a slave server that provides a system for the client, and a data reference unit that causes the client to browse data in a database stored in the storage unit via the slave server when a failure occurs in the master server.

Here, during the occurrence of a failure in the primary server, data update input from the client is received and stored in the local database of the client, and the contents of the local database are stored when the primary server is restored. The local data updating means for reflecting the data in the database stored in the means may be further provided.

The storage means stores a database used when the main server provides the system.
Storage means, and a second storage means for storing a database used when the slave server provides the system,
It is possible to adopt a configuration in which update data when the database stored in the first storage means is updated is sequentially reflected in the database stored in the second storage means.

[0023] Further, a communication file for temporarily storing update data at the time of updating the database stored in the first storage means is further provided, and the data is sequentially reflected in the database stored in the second storage means. Is also possible. The database in this case can also be a database relating to medical treatment information.

[0024] The failure guarantee method for a clustering system according to the present invention comprises: a storage unit for storing a database;
A main server that provides a system to the client using a database stored in the storage unit during normal operation; and a subordinate server that provides a system to the client using the database stored in the storage unit when the main server fails. In the clustering system including the above, when a failure occurs in the primary server, a step of activating the data reference means for allowing the client to browse the data of the database stored in the storage means via the secondary server is provided.

Here, when a failure that has occurred in the primary server can be recovered in a short time, the data reference unit can be activated without performing system migration to the secondary server. Also, during the occurrence of a failure in the primary server, data update input from the client is received and stored in the local database of the client, and when the primary server is restored, the contents of the local database are stored in the storage means. The configuration may further include a step of reflecting the data in the database.

Here, the database may be a database relating to medical treatment information. In addition, the present invention proposes a recording medium for recording a program relating to such a failure guarantee method for a clustering system.
The medical information management system according to the present invention includes: a server that manages a reception database in which reception patient information is registered; a master terminal that collects necessary data in the reception database from the server and stores the data in a storage unit; Reception information display means for displaying reception information based on data stored in the storage means of the master terminal when an access failure occurs.

Here, the master terminal is provided for each medical department, and can be configured to collect reception patient information related to each medical department. Also, the reception information display method of the medical care information management system according to the present invention includes a step of collecting necessary data in a reception database in which reception patient information is registered from a server and storing the collected data in a storage unit of the master terminal. And displaying reception information based on data stored in the storage means of the master terminal when a failure occurs in access to the master terminal.

Here, the master terminal is connected to a medical terminal installed in the medical office and can be configured to display reception information on this medical terminal. Further, it is also possible to configure so that the reception information is output to the printer based on the data stored in the storage means of the master terminal. The present invention proposes a recording medium for recording a program related to the reception information display method of such a medical care information management system.

[0029] An information management system according to the present invention comprises a first storage means for storing data for one or a plurality of records, and an edit for receiving input of edit data for each record of the data stored in the first storage means. A receiving unit, a nonvolatile second storage unit for sequentially storing the editing data received by the editing receiving unit, and a set of the editing data received by the editing receiving unit for each record; Data updating means for updating data stored in the storage means.

Here, the first storage means is a client system for storing data obtained from a database managed by the server, transmitting data updated by the data updating means to the server, and updating data on the database. Can be. If a system failure occurs while editing data is being received by the editing receiving means, the second
It is possible to adopt a configuration further including an edit data return means for continuing to accept input of edit data based on the edit data stored in the storage means.

Further, the data used here can be data relating to medical treatment information. According to the method for assuring a failure of an information management system according to the present invention, each data of one or a plurality of records is stored in a first storage means, and the data stored in the first storage means is edited for each record. A step of receiving data, a step of sequentially storing the received edit data in the nonvolatile second storage means, and a step of determining the received edit data for each record and updating the data stored in the first storage means And a step of, if a system failure occurs during reception of the edit data, continuing to accept input of the edit data based on the edit data stored in the second storage unit after recovery.

Here, the step of acquiring each data for one or a plurality of records from the database managed by the server, the step of transmitting the updated data in the first storage means to the server, and the step of acquiring the data in the database managed by the server. And a step of updating.
Further, the data used here can be data relating to medical treatment information.

The present invention proposes a recording medium for recording a program relating to such an information management system failure guarantee method. An information management system according to the present invention is an information management system including a server that manages a database and a client that can access the database managed by the server. The information management system is provided in the client and operates on the client including the access history to the database. Operation history storage means for storing the history, history collection means for collecting the operation history stored in the operation history storage means, and display means for displaying the operation history collected by the history collection means.

Here, the history collection means and the display means can be provided in a server, and it is also possible to provide a specific client terminal with such a function. Further, the database here may be a database relating to medical treatment information.

According to a terminal usage monitoring method of an information management system according to the present invention, an operation history including an access history to a database managed by a server is stored in each client, and an operation history stored in each client is stored. And a step of displaying the collected operation history. The database used here can be a database relating to medical care information.

The present invention proposes a recording medium for recording a program for such a method of monitoring a terminal use state of an information management system. An information management system according to the present invention includes: a first password setting unit configured to set a first password used at the time of system login; a second password setting unit configured to set a second password for changing the first password; Expiration date management means for counting the time elapsed since the password was set or changed; and a forgotten flag when the elapsed time counted by the expiration date management device exceeds a predetermined value and when the first password is incorrectly input a predetermined number of times. Flag setting means for setting the second password and copying the second password to the first password; and when the forgoing flag is set, the expiration date management means counts the first password before the elapsed time exceeds the predetermined value. Reset the forgotten flag when the reset is performed, and the elapsed time counted by the expiration date management means And a first password reset means for disabling the first password if exceeded value.

Here, the first password can be used to log in to a system for medical information. A password management method for an information management system according to the present invention includes the steps of: setting a first password to be used at the time of system login and a second password for changing the first password; and setting or changing the first password. Starting the counting of the elapsed time from that time, and setting the forgotten flag when the elapsed time from the setting or change of the first password exceeds a predetermined value and when the input of the first password is incorrect by a predetermined number of times. And copying the second password to the first password;
Resetting the forgotten flag if the forgotten flag is set and the first password is changed before the elapsed time since the second password was copied to the first password exceeds a predetermined value; Invalidating the first password if the forgotten flag is set and the elapsed time since the second password was copied to the first password exceeds a predetermined value.

Here, the first password can be used to log in to a system for medical information. The present invention proposes a recording medium for recording a program for such a password management method for an information management system. Here, the recording medium may be a computer-readable / writable floppy (registered trademark) disk, hard disk, semiconductor memory, CD-ROM, DVD, magneto-optical disk (MO), or the like.

[0039]

DESCRIPTION OF THE PREFERRED EMBODIMENTS [Schematic Configuration] FIG. 1 shows a schematic configuration of a medical information management system to which an embodiment of the present invention is applied. In the hospital, there is provided a main LAN 1 composed of, for example, Gigabit Ethernet (registered trademark). Various servers and client terminals are connected to the main LAN 1.

The main servers include an IIMS server 11, which manages medical information including electronic medical records, a medical accounting server 12, an intranet server 13, and a radiology service (RI
S) The server 14, the physical distribution management server 15, the resource / LAN management server 16, the report server 17, etc.
It is connected to the. In addition, client terminals such as an office client 21, a medical client 22, and an image client 23 are connected.

The backbone LAN 1 is further connected with a re-visit automatic accepting machine 25, a firewall 26 for connecting to the Internet via a router 27, and the like. Another system 30 is connected to the main LAN 1 so that data can be shared between the servers. Other systems 30 include, for example, a pathology system 31, an in-hospital display system 32, a nutrition management system 33, an injection management system 34, a dispensing system 35, a test system 36 including a blood transfusion management system, a financial management system 37, a labor management system 38, and the like. Is included.

The report server 17 is connected to the non-CR image server 18 and the CR image server 19 via the image LAN 2.
It is connected to the. An image interpretation client 24 is further connected to the image system LAN 2. Further, the non-CR system image server 18 and the CR system image server 19 are connected to a system of various photographing apparatuses 39 in the other system 30 via the modality LAN 3.

[Backup of Clustering System] The IIMS server 11 that manages medical information provides a system using medical information data to client terminals such as an office client 21, a medical client 22, and an image client 23. It has a cluster structure including a main server used during normal operation and a subordinate server used when the main server is abnormal. FIG. 2 shows a schematic configuration of this clustering system.

As shown in FIG. 2, the IIMS server 11 includes a main server 51 used during normal operation and a subordinate server 53 used when the main server 51 is abnormal. The main server 51 is connected to a storage unit 52 that stores the core database A. The storage unit 52 is configured by a recording medium such as a disk array, and stores a core database A including a database of medical information and the like. The main server 51 includes the business client 21,
The data in the main database A in the storage unit 52 is referred to in response to a request from the medical client 22, the image client 23, and the like, and the updated data transmitted from each client is reflected in the main database in the storage unit 52. It is configured to

The subordinate server 53 has a core database A ′.
Is connected to the storage means 54 for storing Storage means 5
Reference numeral 4 denotes a storage medium such as a disk array similar to the storage means 52. The backbone database A ′ stored in the storage unit 54 is a copy of the backbone database A stored in the storage unit 52. Primary server 5
A common disk 55 composed of a recording medium such as a disk array is connected to the first server 53 and the slave server 53. In the common disk 55, a communication file in which update data when the main server 51 updates the content of the core database A in the storage means 52 is written.
The update data written in the communication file is reflected by the slave server 53 in the backbone database A 'of the sequential storage means 54.

The backbone database A 'stored in the storage means 54 is stored as a backup A "in a storage means 56 constituted by a recording medium such as a disk array. The backup A ″ of the core database A ′ is stored at predetermined time intervals (for example, once a day). At this time, the transfer of the update data from the contact file on the common disk 55 to the core database A 'of the storage means 54 stops. During this time, the update data from the primary server 51 is stored in the contact file on the common disk 55, and when the backup A ″ of the core database A ′ is stored in the storage unit 55, the update file is transferred from the contact file to the storage unit 54. The transfer of the update data to the core database A 'is restarted.

When any trouble occurs in the main server 51, the system is switched to the sub server 53, and
The system is provided using the backbone database A 'in the storage means 54 controlled by the slave server 53. In this case, the updated data when the system was provided by the main server 51 is sequentially reflected in the main database A ′ via the contact file, and the main server 51
The system can be provided by the data at the time when the failure occurs.

When a failure occurs in the master server 51 and the server is switched, the master and the slave are switched. Update data to the core database from the server currently providing the system is simultaneously transmitted to the communication file and This is updated data of the core database under the server that does not provide the system. Storage means 5
The backup A ″ of the core database A ′ stored in the database 6 is disconnected from the online state, and can be appropriately backed up. For example, for inactive data in the database, a magnetic tape, a magnetic disk It is conceivable to create a backup in the external medium 57, and this backup operation can be performed at any time except during the backup operation from the core database A '.

The operation of the above system will be described with reference to FIG. Here, the operation will be described assuming that the master server 51 and the slave server 53 in the IIMS server 11 are regarded as one body. In the step S11, it is determined whether or not there is an access from the client terminal. If there is an access from the office client 21, the medical client 22, the image client 23, or the like, the process proceeds to step S12. In step S12,
The main system server 51 executes system provision using the backbone database A in the storage means 52.

In step S13, it is determined whether or not data has been updated from the client terminal. If data has been updated from the client terminal to the core database A, the process proceeds to step S14. Step S
At 14, the main database A in the storage unit 52 is updated by receiving update data from the client terminal.
At this time, at the same time, it is confirmed that the update has been completed normally, and the update data is written to the communication file on the common disk 55.

Examples of the update data written in the contact file include medical record information (medical record of patient, etc.), instruction information (examination, prescription, etc.), department operation information (execution contents for instruction information), disease name information, profile information (Personal information of patient, etc.), template information (template such as medical certificate), reception information (information on visiting patients), summary information (summary of medical records of inpatients at the time of discharge from hospital, etc.) and so on. The unit of such information can be changed according to the configuration of the core database.

In step S15, the backbone server 53 updates the core database A 'stored in the storage means 54 with the update data in the communication file on the common disk 55. In step S16, it is determined whether the backup time has been reached. Backup time is
This is the time when the backup A ″ of the backbone database A ′ in the storage unit 54 is stored in the storage unit 56.
It can be set at a predetermined time once a day. If it is determined that it is this backup time, the process proceeds to step S17. In step S17, the transfer of the update data from the communication file on the common disk 55 to the core database A 'of the storage unit 54 is stopped. In step S18,
The backup A ″ of the core database A ′ in the storage unit 54 is stored in the storage unit 56. In step S19,
The transfer of the update data from the contact file on the common disk 55 to the core database A ′ of the storage unit 54 is resumed.

In step S20, it is determined whether a failure has occurred in the main server 51. If a failure has occurred in the main server 51, the process proceeds to step S21. In step S21, server switching processing is performed so that the main server 51 is disconnected from the network and the system provided by the subordinate server 53 is executed. With such a configuration, even if a failure occurs in the primary server 51 during normal operation, the online system can be provided continuously, and the business is not stopped when a backup is created.

[Data Reference Function] In the clustering system including the master server 51 and the slave server 53 as described above, if a failure occurs in the master server 51, the system is transferred to the slave server 53. In the meantime, access to the core database becomes unavailable. Even if the failure that occurred in the primary server 51 is minor and it is not necessary to migrate the system to the secondary server 53, access to the core database until the recovery of the primary server 51 is completed. Can not be done. As described above, a data reference tool is provided that allows at least data in the main database to be browsed when a failure occurs in the main server 51. FIG. 4 shows a schematic configuration diagram of this data reference tool.

Here, for example, when a failure occurs in the main server 51, the medical record such as a medical record is stored in the storage means 54 of the subordinate server 53 instead of the data in the storage means 52 of the main server 51. By switching to access the data in the above, the configuration is such that the reference of the past medical record is guaranteed to a minimum. The IIMS server 11
It has a main server 51 and storage means 52 controlled by the main server 51, and a subordinate server 53 and a storage means 54 controlled by the subordinate server 53. The storage means 52 stores a backbone database A, and the storage means 54 stores a backbone database A 'in which updated data of the backbone database A is sequentially reflected. Also, the IIMS server 11
Is provided with a notifying unit 62 for notifying the client of the occurrence of a failure in the main server 53 and its recovery. This notifying means 62 can be constituted by SymfoNET or the like.

The slave server 53 has a data reference tool 61 for allowing the connected client 60 to browse the data of the core database A 'stored in the storage means 54. The data reference tool 61 is configured so that the client 60 can refer to the data in the storage unit 54 without using the system in the subordinate server 53.

FIG. 5 shows an operation using the data reference tool.
This will be described with reference to the flowchart shown in FIG. Step S3
In step 1, it is determined whether a failure has occurred in the main server 51. If it is determined that a failure has occurred in the main server 51, the process proceeds to step S32. In step S32,
It is determined whether or not the failure that has occurred in the main server 51 is minor and can be recovered in a short time. If it is determined that the recovery can be performed in a short time, the process shifts to step S33 to wait for the failure to be cleared by the recovery work. Step S
If it is determined in 32 that it is difficult to recover in a short time, the process proceeds to step S34. In step S34, a switching process for switching the system from the master server 51 to the slave server 53 is started.

In step S35, the message "The primary server has gone down, only temporary reference is available. Do you want to connect to the reference server?" Send.
In step S36, the system waits for confirmation from the client 60 for the transmitted message. Client 60
When the "OK" button displayed on the message screen is operated, the flow shifts to step S37.

In step S37, the connection with the client 60 is switched to the slave server 53, the data reference tool 61 is activated, and a data reference dedicated screen is displayed. On the data reference screen, for example, a patient selection screen 101 is displayed as shown in FIG. The patient selection screen 101
A list display unit 102 for receiving a patient list, a reserved patient list, a ward / recipient patient list, a patient kana search, etc., and a patient ID input unit 10 for receiving an input of a patient ID whose detailed information is to be referred to.
3 is provided. The patient I is selected from the patient data displayed on the list display unit 102 and the patient I is input to the patient ID input unit 103.
When D is input, a chart history display screen 111 of the patient as shown in FIG. 7 is displayed. Chart history display screen 111
Is mainly composed of an SOA column 112 and a P column 113. The SOA section 112 contains the subject of the patient,
A column in which objective results such as test results (Objective), doctor's findings (Assessment), and the like are described.
Is a column in which measures (Plan) such as a prescription and reservation for re-examination are described. The data displayed in the SOA column 112 and the P column 113 is recorded when a medical examination was performed in the past, and cannot be updated.

In step S38, it is determined whether the recovery work of the master server 51 has been completed or the switching processing to the slave server 53 has been completed. If it is determined that the restoration work or the switching work has been completed, the process proceeds to step S39. In step S39, the notification unit 62 transmits a message of the restoration or the switching completion to the client 60. In step S40, the process waits for confirmation from the client 60. When the “OK” button displayed on the message screen is operated on the client 60, the process proceeds to step S41. In step S41, the system is restored by the restored main server 51 or the subordinate server 53 whose switching has been completed.

While the data reference tool 61 is running, a part of the data referred to by the client 60 is held in the client 60 as a local reference table. FIG. 8 shows an example of the local reference table. Here, the local reference table 201 stores the patient I
D (PID), patient name Kana (PNAMEK), patient name (PNAME), gender (SEX), date of birth (BIR)
TH). When the system is restored in step S41, the local reference table 201 held by the client 60 is acquired from the server side, and the corresponding data can be automatically expanded based on the patient ID and the like.

Also, update data for the data referred to by the client 60 is received, and the client 6
It is also possible to configure so as to store it in the local database on the 0 side. Also in this case, when the system returns in step S41, the client 6
It is possible to acquire the update data of the local database of No. 0 and make the update data reflected on the main database after the main server 51 is restored.

With this configuration, even if a failure occurs in the main server 51, it becomes possible to maintain the readability of the main database continuously, and it is possible to prevent delays in medical care work. [Reception Information Display] The IIMS server 11 manages, as a reception database, patient reception information, reservation information, and the like received by the administrative client 21 and the automatic return machine 25. If a failure occurs in the IIMS server 11 or the backbone LAN 1 and the reception database cannot be browsed, the business will be hindered. In order to prepare for such a case, there is provided a reception display system capable of collecting data in the reception database as necessary and displaying the collected data. FIG. 9 shows a schematic configuration of the reception display system.

The core database in the IIMS server 11 includes a reception database 71 that manages reception information and reservation information input from the business client 21 or the automatic return machine 25. Main LAN1 for each department
Terminal 7 connected to IIMS server 11 via
2 are installed. This master terminal 72 has IIM
A collection tool 73 for collecting necessary data from a reception database 71 in the S server 11 and a storage unit 74 for storing data collected by the collection tool 73 in a text file format.

Medical terminal 7 such as medical client 22
5 is connected to the master terminal 72 of the same medical department,
A reception information display tool 76 for displaying data in the storage means 74 of the master terminal 72 is provided. The collection tool 73 of the master terminal 72 periodically collects reception data from the reception database 71 on the server 11. For example, the reception database 71 may be accessed at 5-minute intervals via a database access routine to obtain today's reception information on the medical department.
The reception information collected by the collection tool 73 is stored in the storage unit 74 in a text file format.

During normal operation, each client sends
It is possible to access the MS server 11 and display a list of reception information from the reception database 71. If a failure occurs in the IIMS server 11,
Access to the reception database 71 becomes impossible. In this case, it is possible to activate the reception information display tool 76 to access the master terminal 72 of the same medical department, obtain the latest reception information from the storage unit 74, and display the latest reception information on the medical terminal 75. .

When the IIMS server 11 is down, it is not possible to use medical information such as an electronic medical record. Therefore, based on the reception information obtained from the master terminal 72, the patient attribute and the patient identification bar code are used. The medical terminal 75 prints the format of the medical chart format and the format of the instruction slip including the patient identification data.

When a failure has occurred in the network including the backbone LAN 1, the master terminal 72 and the medical care terminal 7
5 may not be able to input data. In such a case, the reception information is displayed on the master terminal 72, and the format of the chart format and the format of the instruction slip are printed by the printer. FIG. 10 shows an example of a display screen of the reception information acquired from the master terminal 72 by the reception information display tool 76.

The reception information list screen 121 displays the master terminal 7
The second collection tool 73 has a data collection date / time column 122 for displaying the date and time when data was collected from the reception database 71. Also, a tag 123 for a list of patients accepted, a tag 124 for a list of patients accepted for medical treatment, and a tag 1 for a list of emergency medical treatment status
25, a tag 126 for a nurse consultation room and the like, and each list can be displayed by clicking each tag.

A list display section 129 is provided at the center of the reception information list screen 121, and is configured to display information on reception patients matching the display conditions. In the list display section 129, the reception number, the reservation time, the reception time,
Items such as status, patient name, patient ID, classification, reception content, gender, age, reservation person, reservation destination medical department, and consultation comment are displayed.

At the top of the reception information list screen 121, a print button 127 is provided. By clicking the print button 128, a list of the displayed reception information can be printed. Although not shown here, it is also possible to provide an instruction button so that printing in the form of a chart format or printing in the form of an instruction slip can be collectively instructed for each patient data or for the displayed patient data. It is.

The master terminal 72 can be set for each medical department, can be set for each floor, or can be set for each department. In addition, the collection tool 73 of each master terminal 72 can be configured to collect all the reception information for today, and can be configured to collect only the reception information required depending on the installation location. It is possible.

The reception information is periodically collected by the collection tool 73 provided in the master terminal 72, so that when the server goes down such as when a server failure or a network failure occurs. Also, at least the reception information up to the time of occurrence of the failure can be reproduced, and the medical care operation can be continued. [Restoration of Edited Data] If a failure occurs in the client while editing the patient data on the client side, there is a possibility that the contents of the data input so far may be lost. An edited data restoring function for restoring such edited data at the time of client restoration will be described with reference to FIG.

The client terminal includes a patient selecting section 81 for accessing the database of the server to select a patient and obtaining the selected patient data, and a tool box 82 for referring to and updating the selected patient data. Have. The registry information of the patient data obtained by the patient selecting unit 81 is stored in the registry storage area 83 in the hard disk of the client terminal.

The registry information stored in the registry storage area 83 can be, for example, a registry table 211 as shown in FIG. Here, items such as a currently open active window configuration, currently open active patient data, and a user ID of a user who is editing data are provided. In the tool box 82, the patient data selected by the patient selecting section 81 is managed in an internal memory, and editing by a user is accepted. At this time, a list of selected patients selected in the tool box 82 and a common table corresponding to each patient data are stored in the work table 84 in the hard disk of the client terminal.

The tool box 82 receives an input of edit data via a chart editing screen 141 as shown in FIG. 14, for example. The medical record editing screen 141 displays the patient ID
Display section 142, SOA display section 143, P display section 144,
It comprises an instruction selection unit 145, an edit data input unit 146, and the like. Patient I displayed on patient ID display section 142
Data such as D and patient name are stored in the selected patient list,
Edit data input by the edit data input unit 146 is stored in a common table.

For the selected patient list, the local reference table 201 shown in FIG. 8 can be used.
D (PID), patient name Kana (PNAMEK), patient name (PNAME) and the like can be configured.
FIG. 13 shows an example of the common table. Here, the common table 221 has an item name (INAME) and a content (TE
XT_T), quantity (NUM), and the like.

The edited data for the patient data input via the tool box 82 is sequentially reflected on the common table 221 in the work table 84. When a patient is newly added, the registry information is stored in the internal memory and also in the work table 84. When the editing is completed and the patient data is closed, the edited contents of the closed patient data are reflected in the database on the server side. At this time, the data of the selected patient list and the common table stored in the work table 84 are deleted.

When the client terminal goes down during data editing, the registry information such as the active window opened at the time of the failure and the patient data opened at the time of the failure is stored in the registry storage area 8.
3 and the data being edited is stored in the work table 84 as a common table.

When the failed client terminal is recovered, the tool box 82 searches the registry storage area 83 and the work table 84 at the time of startup, and if data remains, stores all information in the memory. Then, continuation of editing can be accepted. With this configuration, even if the system is restarted due to a power supply or system failure, and the system is restarted online, the data held immediately before can be reproduced. It can be omitted.

[Terminal Usage Monitoring] A terminal usage monitoring function for collecting the operation history of the client terminal and displaying / analyzing it will be described. FIG. 15 shows a schematic configuration diagram thereof. The client 91 includes an initial screen tool 92 for displaying an initial screen when the system is started. The initial screen tool 92 displays an initial screen when accepting a login to the online system and when logging off from the online system. In addition, the client 91 stores an operating status storage area 9 for storing operating status data on the hard disk.
3 is provided. The initial screen tool 92 is used when starting the system, logging on to the online system, and logging off.
Obtains information managed by the OS, obtains user information such as user ID and name, and stores the date and time information at that time as operating status data in the operating status storage area 93 in a text file format. I do.

The operation status monitoring terminal 94 can use a client terminal connected online and has a terminal operation status list tool 95 mounted thereon. The operation status monitoring terminal 94 includes a terminal master 96 having a machine name of each client terminal, and a machine name-address correspondence file 97 storing correspondence between the machine name and the IP address.

When collecting the operating status of the client, processing is performed based on the flowchart shown in FIG. In step S51, the terminal operation status list tool 95
Is started, and the floor on which data collection is to be performed is specified based on the input from the operator. In step S52, the machine name installed on the selected floor is acquired from the terminal master 96. The terminal master 96 manages the machine names of the clients installed on each floor, and can obtain the selected machine name from this data.

In step S53, the IP address of each client is obtained from the machine name-address correspondence file 97. The machine name-address correspondence file 97 has a correspondence between each machine name and an IP address, and can acquire an IP address from the machine name acquired from the terminal master 96. In step S54, it is determined whether or not the acquired client IP address is logged in to the network. For example, by using the PING command, it is possible to determine whether or not the client terminal associated with the IP address is in an active state.

In step S55, the operating status data is transmitted to the client whose activation has been confirmed. Here, the operation status data stored in the operation status storage area 93 of the client 91 is stored in the terminal operation status list tool 9.
5 will be collected. In step S56, the operation status of each client collected by the terminal operation status list tool 95 is displayed in a list. In the step S57, it is determined whether or not a list of operation statuses of other floors is to be displayed. When the operator gives an instruction to display the operation status list of another floor, the process shifts to step S51 to similarly display the operation status of the other floor.

The initial screen tool 92 of the client 91 collects OS information and user information at the time of startup, log-in, and log-off. Therefore, it is possible to determine when and what operation is performed by what user ID. The history can be collected by the terminal operation status list tool 95. Therefore, when a trouble occurs in the network, the usage status of each client can be easily analyzed.

Further, by grasping the operation rate of each client terminal, it is possible to plan an efficient terminal arrangement. As described above, one of the client terminals connected online can be provided with a terminal use status monitoring function and used as the operation status monitoring terminal 94.
It is also possible to provide such a function on the side of the S server 11 so that it can be operated and displayed on a terminal directly connected to the IIMS server 11.

[Password Management Function] The password management function used when logging in to the online system will be described. The user master of this online system is a user master table 231 as shown in FIG.
It has. The user master table 231 includes items such as a user ID, a first password, a second password, the number of elapsed days, and a forgotten flag.

The second password is of a type that has no particular rules and is difficult for each user to forget, and is set in advance by the user in a sealed letter. The first password is
The password can be changed by a password change tool set on the client terminal, and the first password can be changed using the second password. The elapsed days are
The first password counts the number of days elapsed since the setting / change, and is reset when the first password is changed. The expiration date for invalidating the first password is set to three months. When the value of the number of elapsed days is two weeks before the expiration date, a warning is displayed when the user uses online.

If the value of the elapsed days exceeds three months or if the first password is incorrectly entered three or more times when using online, the user ID is disabled. When the user contacts the administrator, the administrator sets the forgotten flag and copies the value of the second password to the first password using the master management tool. When the forgotten flag is set, the period for invalidating the first password is set to one day, and when the first password is changed by the user, the forgotten flag is reset and the first password is invalidated. Deadline for 3
Set to months. If the elapsed days exceed one day with the forgotten flag set, the first password is invalidated and the online use by this user ID is prohibited thereafter.

This operation will be described with reference to the flowchart of FIG. In step S61, the first password,
The second password is set. As described above, the setting of the second password is made by letting the user submit in advance a letter that has no specific rules and is difficult for the user to forget. The first password can be changed using the second password, and the value of the elapsed days is reset each time the user makes a change.

In step S62, it is determined whether the value of the number of elapsed days has passed three months, or whether there has been a mistake in inputting the first password three or more times for online use. In such a case, the flow shifts to step S63. Step S63
In this example, the online use is disabled by the user ID, and when there is a contact from the user, the forgotten flag is set. In step S64, the contents of the second password are copied to the first password. In step S65, the first
Set the password expiration date to one day.

In step S66, it is determined whether or not the user has changed the first password. Step S6 when the first password is changed by the user
Move to 7. In step S67, the term for invalidating the first password is set to three months, and the elapsed days are reset. If the first password has not been changed by the user in step S66, the process proceeds to step S68. In step S68, it is determined whether or not the period for invalidating the first password has passed. Here, if the time limit of one day has passed, the process proceeds to step S69. In step S69, the first password is invalidated, and online use by this user ID is prohibited.

In the case of such a configuration, the first password can be changed periodically by the user.
It is possible to prevent "spoofing" due to leakage of a password.

[0095]

According to the present invention, backup data always reflecting updated data when the system is provided is secured, and data can be reliably rescued when a failure occurs. According to the present invention, when a failure occurs in the primary server, data in the database can be referred to during recovery processing for the failure, thereby preventing business stagnation. In particular, it is possible to refer to the medical information of a patient, which is important in the medical system, in any case, and to continue the medical care work without stopping. According to the present invention, it is possible to refer to the reception patient information even when a failure occurs in the medical care information management system. According to the present invention, data being edited at the time of occurrence of a failure is saved, and data being edited can be guaranteed. In particular, even if a failure occurs due to a flash or program trouble while a medical doctor is inputting medical records such as medical records, it becomes easy to restart the input. According to the present invention, it is possible to collect an operation history of what operation has been performed from the client terminal and analyze the collected operation history. In particular, the present invention is effective for detecting unauthorized access to medical records related to patient privacy. According to the present invention, the password used at the time of system login can be changed in a predetermined period to prevent access by an illegally obtained password. By updating the first password using the second password registered in advance, it is possible to prevent a person who has illegally acquired the first password from updating the first password.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a schematic configuration.

FIG. 2 is a control block diagram of the clustering system.

FIG. 3 is a flowchart of a backup system.

FIG. 4 is an explanatory diagram of a data reference tool.

FIG. 5 is a flowchart of a data reference tool.

FIG. 6 is an explanatory diagram of a reference-only screen.

FIG. 7 is an explanatory diagram of a reference-only screen.

FIG. 8 is an explanatory diagram of a local reference table.

FIG. 9 is an explanatory diagram of a reception information display tool.

FIG. 10 is an explanatory diagram of a reception information list screen.

FIG. 11 is an explanatory diagram of an edit data restoring function.

FIG. 12 is an explanatory diagram of a registry table.

FIG. 13 is an explanatory diagram of a common table.

FIG. 14 is an explanatory diagram of a chart editing screen.

FIG. 15 is an explanatory diagram of a terminal use status monitoring function.

FIG. 16 is a flowchart of a terminal use status monitoring function.

FIG. 17 is an explanatory diagram of a user master table.

FIG. 18 is a flowchart of a password management function.

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor: Okaichi Oki, Shimane Prefectural Central Hospital, Himehara-cho, Izumo-shi, Shimane Prefecture F term (reference) 5B034 AA01 BB17 CC04 DD07 5B082 DE02 DE06 FA11

Claims (43)

[Claims] 1. A primary server that provides a system to a client during normal operation; a first storage unit that stores a database used when the primary server provides a system; and a first storage unit that stores the database. A contact file for temporarily storing update finalized information at the time of updating the database, a slave server for providing a system to the client when the master server is abnormal, and a slave server for providing a system to the slave server. And a second storage unit for storing a database in which the update determination information in the communication file is sequentially reflected. 2. The clustering system backup system according to claim 1, further comprising a third storage unit for backing up a database stored in said second storage unit. 3. The clustering system backup system according to claim 2, further comprising fourth storage means for storing a data portion of the database backed up by said third storage means. 4. The backup system for a cluster system according to claim 1, wherein said database is a database relating to medical information. 5. A primary server that provides a system to a client during normal operation; a first storage unit that stores a database used when the primary server provides the system; and a first storage unit that stores the database. A contact file for temporarily storing update data at the time of updating the database, a slave server for providing a system to the client when the master server is abnormal, and a slave server for providing a system to the slave server. A clustering system comprising: a second storage unit for storing a database in which the contents of the contact file are sequentially reflected; and a third storage unit for backing up the database stored in the second storage unit. The main server updates the database stored in the first storage means at the time. Simultaneously writing the update data in the contact file; reading the update data stored in the contact file by the slave server and updating the database stored in the second storage means; Stopping updating the database stored in the second storage means with the update data in the communication file, and storing a backup of the database stored in the second storage means in the third storage means; Restarting the update of the database stored in the second storage means with the update data in the communication file. 6. The method according to claim 5, further comprising the step of storing the data portion of the database backed up by the third storage means in an external storage medium at a timing different from online. 7. The clustering system backup method according to claim 5, wherein the database is a database relating to medical information. 8. A recording medium for recording a program relating to the backup method for a clustering system according to claim 5. 9. A storage means for storing a database, a main server for providing a system to a client using the database stored in the storage means during normal operation, and a storage in the storage means when the main server fails. A slave server that provides a system for the client using the selected database; and, when a failure occurs in the master server, the data of the database stored in the storage unit via the slave server. And a data reference means for allowing the user to browse the data. 10. When a failure occurs in the primary server,
A local update that accepts data update input from the client, stores it in the client's local database, and reflects the contents of the local database in the database stored in the storage means when the primary server is restored. The clustering system according to claim 9, further comprising a data updating unit. 11. The storage means stores a first storage means for storing a database used when the master server provides a system, and a database used when the slave server provides a system. The storage device according to claim 10, further comprising a second storage unit, wherein update data when a database stored in the first storage unit is updated is sequentially reflected in the database stored in the second storage unit. Clustering system. 12. A communication system according to claim 1, further comprising a contact file for temporarily storing update data when updating the database stored in said first storage means, wherein the communication file is sequentially reflected in the database stored in said second storage means. Item 12. The clustering system according to item 11. 13. The clustering system according to claim 9, wherein said database is a database relating to medical treatment information. 14. A storage means for storing a database, a main server for providing a system to a client using the database stored in the storage means during normal operation, and a storage in the storage means when the main server fails. And a subordinate server that provides a system for the client using the selected database. If a failure occurs in the main server, the failure is stored in the storage unit from the client via the subordinate server. A failure guarantee method for a clustering system, comprising a step of activating a data reference unit for browsing data of a selected database. 15. The data referencing means according to claim 14, wherein when a failure occurred in said primary server is one which can be recovered in a short time, data reference means is started without performing system migration to said secondary server. Of the clustering system in case of failure. 16. During the occurrence of a failure in the primary server,
Accepting a data update input from the client, storing the data update in a local database of the client, and reflecting the contents of the local database in a database stored in the storage unit when the primary server is restored The failure guarantee method for a clustering system according to claim 14, further comprising: 17. The failure guarantee method for a clustering system according to claim 14, wherein said database is a database relating to medical information. 18. A recording medium for recording a program related to the failure guarantee method for a clustering system according to claim 14. 19. A server that manages a reception database in which reception patient information is registered, a master terminal that collects necessary data in the reception database from the server and stores the collected data in storage means, and an access failure to the reception database occurs. Sometimes
A reception information display unit that displays the reception information based on data stored in a storage unit of the master terminal. 20. The master terminal is provided for each medical department,
2. Collecting reception patient information related to each medical department.
9. The medical information management system according to 9. 21. A step of collecting necessary data in a reception database, in which reception patient information is registered, from a server and storing the collected data in a storage means of the master terminal. Displaying the reception information based on the data stored in the storage means. 22. The reception information display method of the medical information management system according to claim 21, wherein the master terminal is connected to a medical terminal installed in a medical office, and displays the reception information on the medical terminal. . 23. The reception information display method of the medical care information management system according to claim 21, wherein the reception information is output to a printer based on data stored in the storage means of the master terminal. 24. A recording medium for recording a program relating to the reception information display method of the medical information management system according to claim 21. 25. A first storage means for storing each data for one or a plurality of records; an edit receiving means for receiving an input of edit data for each record for the data stored in the first storage means; A nonvolatile second storage unit for sequentially storing the edited data received by the receiving unit, and the edit data received by the edit receiving unit is determined for each record, and the first storage unit is determined based on the determined edited data. Data updating means for updating data stored in the information management system. 26. A client system for storing data obtained from a database managed by a server, transmitting the data updated by the data updating means to the server, and updating the data on the database. The information management system according to claim 25, comprising: 27. If a system failure occurs during reception of edit data by said edit receiving means, said second data is recovered after recovery.
27. The information management system according to claim 25, further comprising an edit data return unit that continues to accept input of edit data based on the edit data stored in the storage unit. 28. The information management system according to claim 25, wherein said data is data relating to medical treatment information. 29. A step of storing each data for one or a plurality of records in the first storage means, a step of receiving edited data for each record of the data stored in the first storage means, Sequentially storing the edited data in the nonvolatile second storage means, determining the received edited data for each record, and updating the data stored in the first storage means; And a step of continuing to accept input of edit data based on the edit data stored in the second storage unit after recovery if a system fault occurs in the information management system. 30. Acquiring each data for one or a plurality of records from a database managed by the server; transmitting updated data in the first storage means to the server; 30. The method according to claim 29, further comprising: updating the data of the information management system. 31. The failure assurance method for an information management system according to claim 29, wherein the data is data relating to medical treatment information. 32. A recording medium for recording a program relating to the method for assuring a failure of the information management system according to claim 29. 33. An information management system, comprising: a server for managing a database; and a client capable of accessing the database managed by the server, wherein the operation is provided in the client and includes an access history to the database. An information management system comprising: an operation history storage unit for storing a history; a history collection unit for collecting the operation history stored in the operation history storage unit; and a display unit for displaying the operation history collected by the history collection unit. . 34. The information management system according to claim 33, wherein said history collection means and display means are provided in said server. 35. The information management system according to claim 33, wherein said database is a database relating to medical treatment information. 36. A step of storing, on each client side, an operation history including an access history to a database managed by a server; a step of collecting an operation history stored in each of said clients; And displaying the terminal usage status monitoring method of the information management system. 37. The method according to claim 36, wherein the database is a database relating to medical care information. 38. A recording medium for recording a program for the method of monitoring terminal usage of the information management system according to claim 36. 39. First password setting means for setting a first password to be used at the time of system login; second password setting means for setting a second password for changing the first password; Expiration date management means for counting an elapsed time since the setting or change; and an forgotten flag when the elapsed time counted by the expiration date management device exceeds a predetermined value and when the input of the first password is incorrect by a predetermined number of times. Forgoing flag setting means for setting the second password and copying the second password to the first password; and when the forgoing flag is set, before the elapsed time counted by the expiration date managing means exceeds a predetermined value. Resetting the forgotten flag when the first password is reset, and An information management system comprising: first password resetting means for invalidating the first password when the elapsed time counted by the means exceeds a predetermined value. 40. The first password for logging in to a system related to medical information.
Information management system described in. 41. A step of setting a first password to be used at the time of system login and a second password for changing the first password, and an elapsed time from when the first password is set or changed. Setting a forgotten flag when the elapsed time from the setting or change of the first password exceeds a predetermined value and when the input of the first password is incorrect a predetermined number of times. Copying a password to a first password; and changing the first password before the time elapsed since the second password was copied to the first password when the forgotten flag was set and the second password was copied to the first password. Resetting the forgotten flag when the forgotten flag has been set; and Invalidating the first password when the time elapsed since the password was copied to the first password exceeds a predetermined value. 42. The first password for logging in to a system for medical information.
Information management system password management method described in. 43. A recording medium for recording a program for a password management method for an information management system according to claim 41 or 42.