JP2004157794A - Electronic chart system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an electronic chart system which secures system operation by storing data without failure when a trouble occurs. <P>SOLUTION: The electronic chart system comprises a terminal 30 which indicates medical information and generates new medical information, a medical information database means storing medical information, an order server 10 which has a generation means of medical information to be stored from the medical information, a chart server 20 which has a medical information history database means for storing the medical information associated with past medical information. The electronic chart system allows carrying out normal system operation without losing any data even when one of a couple of servers happens to stop working by accident. Because both of a first and a second servers store the same electronic chart data, required data can be output from either server to be indicated and printed out. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an electronic medical record system, and more particularly to an electronic medical record system capable of securely storing data and operating the system even if a failure occurs.
[0002]
[Prior art]
2. Description of the Related Art Conventionally, various proposals have been made regarding electronic medical records. JP-A-09-179908, JP-A-2000-048107, JP-A-2000-293594, JP-A-2000-298692, JP-A-2000-325314, and JP-A-2001-005890.
[0003]
[Problems to be solved by the invention]
Functions required for electronic medical records include ensuring authenticity, legibility, and preservation. Further, it is necessary for the system to prevent the loss of electronic medical record data even if a failure occurs, and to continue the operation of the system. The authenticity is ensured by storing all data before correction and deletion data, checking the authority of the creator and corrector, and storing records (logs) of all operations.
[0004]
However, in the conventional electronic medical record system, if the electronic medical record is stored as code data, it is necessary to separately store the master corresponding to the code to ensure readability. In some cases, there is a problem that it is necessary to manage the generation of the master accompanying the change.
[0005]
In addition, since medical records need to be saved and restored (printed) for a certain legal period, a function is required to prevent the loss of electronic medical record data even if a system failure occurs. If this is the case, medical treatment at the hospital will not be possible, so it is necessary to have a function to continue medical treatment at the hospital even in the event of a system failure, but these functions are not efficiently integrated and realized in the conventional system. There was a problem.
[0006]
SUMMARY OF THE INVENTION It is an object of the present invention to provide an electronic medical record system that solves the above-described problems of the related art, reliably stores data, and can operate the system even if a failure occurs.
[0007]
[Means for Solving the Problems]
The electronic medical record system of the present invention reads out and displays past medical information from a server, and generates a new medical information; a medical information database means for storing medical information input from the terminal; A first server having storage data generation means for generating storage medical information from information, and storing the storage medical information generated by the storage data generation means of the first server in association with past medical information; And a communication network for connecting the terminal and the server.
[0008]
According to the present invention, electronic medical record data (medical information) is basically stored in both the first and second servers. Therefore, even if one server is stopped or damaged due to a failure or the like, the other server is stored. The data can be read out from the server to display or print the chart, thereby preventing data loss and continuing system operation. Further, since character data is added to the code data of the electronic medical record and stored, the data can be easily and accurately reproduced and read.
[0009]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail. FIG. 1 is an explanatory diagram showing the relationship between data and processing functions of the electronic medical record system of the present invention. The order server 10, which is the first server, includes a database management system 14, in which various master DBs 13, latest medical information DBs 11, and spool DBs 12 are constructed. Then, based on a database processing instruction (SQL) from the terminal 30 or the chart server 20, the designated processing is executed. As the database management system 14, any known database management system can be used.
[0010]
In the various master DBs 13, there are a large number of masters such as a master related to staff, a master related to a patient, a disease name master, and a medicine master. The latest medical information DB 11 stores electronic medical record data, which is medical information for each patient, and is read in response to a request from a terminal. In the latest medical information DB 11, at least a part of the information is recorded by a code. Therefore, processing and transmission are fast, and response delay at the terminal is reduced.
Also, “latest” means that when the previously entered chart data is corrected, only the data after the correction is stored, and the data before correction or the deleted data is not stored. As for the old thing is preserved.
[0011]
Data to be stored in the chart server 20 is temporarily stored in the spool DB 12. This storage data is generated by SQL from the terminal, and is obtained by adding character string data corresponding to the code data to the code data of the medical care data stored in the latest medical care information DB 11.
[0012]
The chart server 20, which is the second server, includes the same database management system 22 as the order server 10, and has a chart history DB 21 for storing stored medical care information. Further, a chart storage processing means 23 (program) is mounted. As will be described in detail later, the chart storage processing unit 23 periodically issues a spool data read request to the order server 10, reads the spool data, and stores the spool data in the chart history DB 21.
[0013]
The terminal 30 includes a keyboard, a mouse 31, a card reader 32, a display device 33, a printer 34, and the like, and has a terminal processing means (program) 35 for executing input / display processing, database registration / search processing, and the like. . The terminal processing means 35 reads necessary data from the order server 10 and displays an electronic medical record, and transmits the input medical data to the order server 10 and registers it in the database 11, which will be described in detail later. In addition, the electronic medical record data can be read from the medical record server 20 and displayed / printed as necessary, for example, when a failure occurs.
[0014]
FIG. 2 is a block diagram showing a hardware configuration example of the electronic medical record system of the present invention. As the hardware and the OS of the order server 10 and the chart server 20, well-known commercially available server devices and OSs can be used. The data storage devices 15 and 25 of the server include, for example, a plurality of hard disk devices (HDDs), and data is not lost even if one HDD fails due to a well-known redundant configuration such as full duplex (mirror) or RAID system. It is configured as follows. Power is supplied from an uninterruptible power supply (not shown).
Further, backup data 16 and 26 are taken once a week, for example, for all data in the system, and differential backup data is taken once a day, for example. The following three types of server failure modes are conceivable, and a recovery method according to each state is described below.
[0015]
If only the order server fails, apply (read) full backup data once a week and differential backup data thereafter (up to the previous day) in order to return to the state up to the previous day. For the current day, an archive log of a known database system is used to return to the state immediately before the failure. Note that no backup has to be applied to the chart server since no failure has occurred.
When the order server is stopped, the electronic medical record information can be read out from the medical record server 20 and displayed / printed, but new medical information cannot be added / changed to the electronic medical record. Therefore, in this case, the doctor can print the patient's medical record and write the contents of the medical treatment on the medical record as in the related art so that the medical treatment can be continued. As for the data used in the paper chart during the failure, the data including the chart information is automatically created by inputting the post-event data.
[0016]
-When only the chart server fails The full backup data once a week and the differential backup data thereafter (up to the previous day) are applied in the same manner as the order server. For the current day, the archive log of the database system is used to return to the state immediately before the failure. Normal operation is possible using the order server even while the chart server cannot be used due to a failure. Further, the chart information during the chart server failure is automatically restored by the spool program running on the chart server after the chart server is restored.
If both the order server and the chart server fail, in order to return the order server and the chart server to the state up to the previous day, full backup data once a week and differential backup data thereafter (up to the previous day) are applied. For the current day, the archive log of the database system is used to return to the state immediately before the failure. In addition, for a portion operated using a paper chart during a failure, the post-data is automatically created including the chart information by inputting post-data.
[0017]
The HDD 36 provided in the terminal 30 is used as a cache memory, and the terminal 30 reads out frequently used data or data known to be used in advance from the order server 10 and stores it in the HDD. This function reduces the response delay of the terminal 30.
[0018]
FIG. 3 is a flowchart showing terminal processing in the system of the present invention. In S10, for example, the user ID is read from an IC card or the like, which is an ID card of a staff, and the user is authenticated by comparing it with a password. In S11, an initial screen and an outpatient list (for an outpatient department terminal) are displayed. In S12, the operation input information of the user is analyzed. If the instruction is to specify a patient, the process proceeds to S13. If the instruction is to display information independent of a specific patient, the process proceeds to S16.
[0019]
In S16, the data is requested from the server storing the data specified by the user. In S17, the data is received from the server. In S18, the data is displayed on the terminal screen, and the process returns to S12.
[0020]
In S13, information for specifying a patient is input by selecting the patient from, for example, an outpatient list. In S14, basic patient information such as name, age, and gender and medical information for the latest predetermined period (for example, one week) are read from the order server 10. In S15, the electronic medical record is displayed on the screen, and the process proceeds to S19.
[0021]
FIG. 6 is an explanatory diagram illustrating a display example of an electronic medical record. The left side of the electronic medical record screen is used as a treatment plan display area 71, and the right side is used as a treatment instruction display area 72. This form is the same as the No. 2 paper chart specified by the Ministry of Health, Labor and Welfare. At the top of the screen, basic patient information and the terminal user are displayed.
[0022]
At the left end of the screen, various function buttons 73 are arranged. For example, when inputting an inquiry finding, clicking the inquiry finding button 74 with a mouse and inputting various instructions displayed in the treatment instruction display area 72. Clicks the corresponding button 75-80, and inputs the instruction content. In the DO area 81, the content of an instruction issued in the past is displayed. When the same instruction is issued, the information can be referred to and copied.
[0023]
In S19, the operation input information performed by the user is analyzed. If the instruction is to update the chart, the process proceeds to S20. If the instruction is to display information about a specific patient such as an X-ray photograph or examination result data, the process proceeds to S24. In S20, data to be added, corrected, or deleted to the chart is input. In S21, the input data is checked for data such as medication inspection. In S22, as will be described later, database processing instruction data (SQL) for registration in the DB is generated. In S23, the generated SQL is transmitted to the order server 10 to update the DB.
[0024]
In S24, a request for desired data is made to the server storing the data. In S25, the data is received from the server, and in S26, the data is displayed on the terminal screen.
[0025]
FIG. 4 is a flowchart showing a chart data storing process in the chart server of the present invention. In S30, it is determined whether or not a predetermined time, for example, one minute to several minutes, has elapsed since the previous storage process. If the determination result is affirmative, the process proceeds to S31. In S31, database processing instruction data (SQL) for reading spool data from the spool DB 12 of the order server 10 is transmitted to the order server 10. In S32, the data read from the spool DB 12 is stored in the medical record history DB 21 with a link to the data already stored in the medical record history DB 21. In S33, database processing instruction data (SQL) for deleting the spool data read in S31 from the spool DB 12 of the order server 10 is transmitted to the order server 10.
[0026]
FIG. 5 is a flowchart showing the details of the SQL generation process in S22 of FIG. In S40, it is determined whether or not the process is data deletion. If the determination result is affirmative, the process proceeds to S47, but if the result is negative, the process proceeds to S41. In S41, it is determined whether or not the process is a data correction. If the determination result is affirmative, the process proceeds to S44, but if negative (new or additional), the process proceeds to S42. In FIG. 5, the processing contents of SQL are described in S42 to S48, but the actual processing is the generation of SQL for performing these processing.
[0027]
In S42, the medical care data is registered in the latest medical care information DB11. In S43, the data represented by the code data in the medical treatment data is added to the corresponding master database by referring to various master databases, and the data is stored in the spool DB 12.
For example, as information common to all, the latest medical information DB 11 stores only the codes of the staff and doctor who input the medical information and the like, while the spool DB 12 stores the corresponding names together with the codes of the staff and doctor. Is stored.
[0028]
In S44, the corresponding pre-change data is deleted from the latest medical information DB11. In S45, the correction data is registered in the latest medical information DB11. In S46, the data represented by the code data in the modified medical treatment data is added to the corresponding master database by referring to various master databases, and the data is stored in the spool DB 12.
In S47, the corresponding data is deleted from the latest medical information DB. In S48, the deleted data is moved to the spool DB 12.
[0029]
Although the embodiments of the present invention have been disclosed above, the present invention may have the following modifications. In the embodiment, the handling of old data is not particularly considered, but old data that has passed a predetermined period may be moved to a data storage device having slow access but large storage capacity.
In the embodiment, the example in which the server and the terminal are connected via the LAN is disclosed. However, for example, the present invention can be implemented even if only the chart server or both servers are located at remote locations.
In the embodiment, the example in which the terminal gives an instruction to the server by SQL is disclosed, but any known method can be adopted as a method of registering in the database or realizing the search function.
[0030]
【The invention's effect】
As described above, according to the present invention, electronic medical record data (medical information) is basically stored in both the first and second servers, so that one of the servers is stopped or damaged due to a failure or the like. However, it is possible to read out the data from the other server and display or print the medical record, thereby preventing data loss and continuing the system operation.
In the terminal and the first server, a part of the medical data is managed by the code, so that the processing efficiency is improved and the response delay is reduced. Further, in the second server, since the character string is added to the code and stored, the generation management of the code master is not required, and the data can be easily and accurately reproduced and read.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing the relationship between data and processing functions of a system according to the present invention.
FIG. 2 is a block diagram illustrating an example of a hardware configuration of a system according to the present invention.
FIG. 3 is a flowchart showing terminal processing in the system of the present invention.
FIG. 4 is a flowchart showing a chart data storage process in a chart server.
FIG. 5 is a flowchart illustrating details of an SQL generation process in S22 of FIG. 3;
FIG. 6 is an explanatory diagram showing a display example of an electronic medical record.
[Explanation of symbols]
10 order server, 11 latest medical information DB, 12 spool DB, 13 various master DBs, 14, 22 database management system, 15, 25 data storage device, 16, 26 backup data, 20 chart server , 21: medical record history DB, 23: medical record storage processing means, 30: terminal, 31: keyboard, mouse, 32: card reader, 33: display device, 34: printer, 35: terminal processing means, 36: HDD

Claims (4)

A terminal that reads and displays past medical information from a server and generates new medical information,
A first server comprising: a medical information database means for storing medical information input from the terminal; and a storage data generating means for generating medical information for storage from the medical information;
A second server comprising a medical information history database means for storing the medical care information for storage generated by the storage data generating means of the first server in association with past medical information;
An electronic medical record system comprising a communication network for connecting a terminal and a server. 2. The electronic medical record system according to claim 1, wherein the storage medical information is generated by adding corresponding character string data to code data of the medical information. 2. The electronic medical record system according to claim 1, wherein, when the medical information is deleted or changed, the medical information database unit does not store the medical information before the deletion or the change. 2. The electronic medical record system according to claim 1, wherein the terminal is capable of displaying or printing a medical record as long as the terminal can access one of the first server and the second server.

Images