JP4399085B2 - Medical data delivery system - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an information system for delivering medical data in response to a user request.
[0002]
[Prior art]
In recent years, there is a demand to refer to medical data such as examination results managed by a medical information system as electronic data from an examination room or a medical office. In response to such a request, the doctor may use a result reference client as in the sample testing system described in “Information network construction in Takasaki City Medical Association (Medical and Computer Vol.10 No.3 19999.3)”. There is a system that uses and refers to medical data such as test results managed by the medical information system.
[0003]
[Problems to be solved by the invention]
However, in the case of the above system, anyone can refer to medical data including patient privacy information, and there is a problem in that patient privacy information cannot be maintained. Even when security management is performed by user authentication using a user ID or password, there is a problem that the privacy of the patient cannot be maintained if the user ID or password is leaked.
[0004]
[Means for Solving the Problems]
The above problem can be solved by delivering medical data according to a user's request to a delivery destination address registered in advance for each user. Moreover, the said subject can be solved, improving the robustness of security management more by accepting a user's request | requirement only when it authenticates with a password.
[0005]
In addition, by delivering medical data by e-mail, the user can refer to the medical data regardless of time and place, and the above-described problems can be solved while improving user convenience. Further, by changing the display format according to the type of the user terminal, it becomes easy to refer to the medical data even in a user terminal with a small display screen such as a mobile phone, PHS, PDA, etc., so that convenience for the user can be improved.
[0006]
Moreover, the said subject can set the medical data which a user wants to refer regardless of time and a place by receiving a user's request | requirement with an email. Moreover, the risk of information leakage can be reduced by delivering the medical data requested by the user to a delivery destination set in advance regardless of the request source of the user.
[0007]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 shows a block diagram of a medical data delivery system that is an embodiment of the present invention. The system includes a delivery server 100, a medical DB 110 that stores medical data such as test results, a user information DB 120 that stores information for identifying a user, a delivery DB 130, a user terminal 200, and a communication such as a general public line. It is composed of a line 300.
[0008]
The user terminal 200 is assumed to be a portable wireless communication device such as a mobile phone, PHS, or PDA, but may be a stationary terminal such as a personal computer, a phone, or a FAX. The communication line 300 may be wired or wireless. The user of the user terminal 200 is assumed to be a doctor in a facility where the present system is installed, but may be a doctor outside the facility. Further, not only a doctor but also a nurse or other medical staff, or a patient who is an information source of medical data stored in the medical DB 110 may be used.
[0009]
The delivery server 100 includes a delivery order registration control unit 101, a delivery order reception unit 102, a user authentication unit 103, a delivery order registration unit 104, a delivery control unit 105, a delivery order acquisition unit 106, a delivery data shaping unit 107, and a delivery destination address. An acquisition unit 108 and a delivery unit 109 are included.
[0010]
The user information DB 120 includes a user ID field 121 for storing a user ID for identifying a user, a password field 122 for storing a password for authenticating the user, and a delivery destination for storing a delivery destination address for specifying a delivery destination of medical data. It has an address field 123 and a delivery destination (user terminal) type field 124 indicating the type of user terminal. Information stored in the user information DB 120 is registered in advance by the system operator before the operation of the system, but may be registered during operation as necessary.
[0011]
In the example of FIG. 1, the user with the user ID “1001” indicates that the password is “pw1001”, the delivery address is “1001 @...”, And the user terminal type is “mobile phone”. In FIG. 1, the delivery address is an e-mail address, but it may be an IP address, a telephone number, a FAX number, or the like. The user terminal type is a mobile phone, but it may be a PC, telephone, FAX, PHS, PDA, or the like.
[0012]
FIG. 4 shows an example of the medical DB 110. The medical DB 110 includes a patient ID field 401 that stores a patient ID that is information for identifying a patient, and a test result field 402 that stores a test result. FIG. 4 shows that the examination result of the patient ID “PID0001” is “GOT = 20”. In the medical DB 110, the examination result 402 is stored, but other medical data such as patient basic information, examination image information, medical treatment information, and medical accounting information may be stored.
[0013]
FIG. 2 shows an operation flow of the system when the delivery order requested by the user is registered in the system. When a user uses the user terminal 200 and requests a delivery order via the communication line 300, the delivery order registration control unit 101 activates the delivery order acceptance unit 102 and accepts a delivery order. Step 201 is executed.
[0014]
FIG. 6 shows delivery order A as an example when requesting a delivery order by electronic mail. The delivery order A includes a requester user ID 601, a requester password 602, and a request content 603. The delivery order A indicates that the user with the user ID “1001” requests delivery of the GOT value of the patient ID “PID0001” using the authentication password “pw1001”.
[0015]
Here, an example in which a delivery order is requested by e-mail has been shown. However, a delivery order may be requested from a telephone, a mobile phone, or the like according to voice guidance. In addition, a delivery order may be requested from a WWW browser via the Internet or an intranet. As a result, it is possible to request a delivery order regardless of whether it is in the hospital or outside the hospital, and even while moving, so that convenience for the user is improved.
[0016]
Next, the delivery order registration control unit 101 activates the user authentication unit 103 and executes a user authentication step 202 for authenticating the user who requested the delivery order received in the delivery order reception step 201. When the user authentication is performed in the user authentication step 202, the delivery order registration control unit 101 activates the delivery order registration unit 106 and registers the delivery order authenticated in the user authentication step 202 in the delivery DB 130. The order registration step 203 is executed. As a result, only the user registered in advance can register the delivery order, so that the security of the medical data can be ensured.
[0017]
Also, when a request is received by e-mail, it is not sent back to the e-mail address of the e-mail transmission source, but is delivered to a pre-registered delivery address, reducing the risk of information leakage be able to.
[0018]
FIG. 5 shows an example of the delivery DB 130 created as a result of the delivery order registration step 203. The delivery DB 130 includes a delivery ID field 501, a user ID field 502, a request content field 503, and a delivery option field 504 for storing auxiliary information related to delivery such as delivery time and delivery conditions. In FIG. 5, the contents of the delivery order A are registered as the delivery order 510 with the delivery ID “01”. Further, since the delivery option is “NOW”, it indicates that delivery is performed immediately.
[0019]
In the above delivery option, it is possible to set a reserved delivery to be delivered at a frequency and time designated in advance, such as “Every 0700” meaning delivery every day at 7 am. Thereby, since the user can refer to the medical data at his / her free time, the convenience of the user can be improved.
[0020]
In addition, it is also possible to set a conditional reserved delivery that delivers only when a certain condition is satisfied, such as “ASAP” which means that delivery is made when the inspection result is confirmed. Thereby, since the user can refer to the inspection result requested by the user as soon as it is confirmed, the time until the inspection result report can be shortened.
[0021]
In the delivery option, "DEFAULT" which means a default setting for delivery unless there is another delivery order can be set. For example, in the delivery order 540 with the delivery ID “04”, the default setting is that the user “2001” delivers all the examination results “AllTest” of the patient “PID0002” to “ASAP” when the examination results are confirmed. It shows that In addition, the delivery order 550 with the delivery ID “05” indicates that the default setting is that the user “2002” delivers all the inspection results “MyTestOrder” requested by the user “2002” when the inspection results are confirmed. ing.
[0022]
As described above, since delivery can be performed to a delivery address registered in advance by default setting, it is possible to easily realize cooperation with other facilities such as always delivering inspection results requested by users of other facilities to the facility.
[0023]
FIG. 3 is a flowchart showing the operation of this system when delivering medical data. When this system is activated, the delivery control unit 105 activates the delivery order obtaining unit 104 and executes a delivery order obtaining step 301 for obtaining a delivery order from the delivery DB 130.
[0024]
Next, the delivery control unit 105 executes a delivery determination step 302 for determining whether or not the delivery order acquired in the delivery order acquisition step 301 is deliverable.
[0025]
For example, in the case of the delivery order 510 of FIG. 5, it is determined that delivery is possible because the delivery option is “NOW”. Further, in the case of the delivery order 520 in the figure, since the delivery option is “Every 0700”, it is judged that delivery is possible only at 7:00 am, and otherwise delivery is judged to be impossible. In the case of the delivery order 530, since the delivery option is “ASAP”, it is judged that delivery is possible only when the examination result “CRP” of the patient ID “PID0001” described in the request content is confirmed, and otherwise delivery Judged to be impossible.
[0026]
In the case of the delivery order 540, since “ASAP” is included in the delivery option and “AllTest” is included in the request content, all examination results of the patient ID “PID0002” described in the request content are included. It is determined that delivery is possible only when it is confirmed, and otherwise it is determined that delivery is not possible. In the case of the delivery order 550, since “ASAP” is included in the delivery option and “MyTestOrder” is included in the request content, for all inspection orders requested by the user with the user ID “2002”. It is determined that delivery is possible only when all the inspection results for each inspection order are confirmed, and otherwise, it is determined that delivery is not possible.
[0027]
When it is determined that delivery is possible in the delivery determination step 302, the delivery control unit 105 activates the delivery data shaping unit 107, acquires the data requested in the delivery order from the medical DB 110, and acquires the user acquired from the user information DB 120. Based on the terminal type, a format that can be displayed on the user terminal 200 is selected, and a delivery data shaping step 303 for shaping the display format and generating delivery data is executed.
[0028]
In this way, by changing the display format according to the type of user terminal, it becomes easier to refer to medical data even on a user terminal with a small display screen such as a mobile phone, PHS, PDA, etc., so that convenience for the user can be improved. it can.
[0029]
Next, the delivery control unit 105 activates the delivery destination address acquisition unit 108 and executes a delivery destination address acquisition step 304 for acquiring a delivery destination address from the user information DB 120. Next, the delivery control unit 105 activates the delivery unit 109 and executes a delivery step 305 for delivering the delivery data generated in the delivery data shaping step 303 to the delivery destination address obtained in the delivery destination address obtaining step 304. .
[0030]
FIG. 7 shows delivery information A as an example of electronic mail delivered as a result of the above steps 301 to 305. The delivery information A is composed of an e-mail address 701, a subject 702, and a body 703. The delivery information A indicates that the delivery data “GOT = 20” created in the delivery data shaping step 303 is delivered to the delivery destination address “1001 @...” Obtained in the delivery destination address obtaining step 304. .
[0031]
【The invention's effect】
As described above, in this system, medical data such as a test result according to a user's request is not delivered directly to the user terminal to which the request is inputted, but delivered to a delivery address registered in advance. . As a result, regardless of the user terminal that requested the delivery order, the medical data cannot be referred to other than the user terminal specified by the delivery destination address, and thus leakage of patient privacy information can be prevented.
[0032]
Further, by accepting a user request only when authenticated by a password, leakage of patient privacy information can be prevented while further improving the robustness of security management.
[0033]
In addition, since the medical data is delivered by e-mail, the user can refer to the medical data regardless of time and place, thereby improving the convenience for the user and preventing leakage of the patient's privacy information. .
[0034]
In addition, by changing the display format according to the type of user terminal, it becomes easier to refer to medical data even on a user terminal with a small display screen such as a mobile phone, PHS, PDA, etc. Leakage of privacy information.
[0035]
In addition, by accepting the user's request by e-mail, it is possible to set the medical data that the user wants to refer to regardless of time and place, so that the user's convenience is improved and the leakage of the patient's privacy information is prevented Can do.
[0036]
In addition, by delivering the medical data requested by the user to a delivery destination set in advance regardless of the request source of the user, it is possible to prevent the leakage of patient privacy information while reducing the risk of information leakage Can do.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of a medical data delivery system that is an embodiment of the present invention.
FIG. 2 is a flowchart showing the operation of the system at the time of delivery order registration.
FIG. 3 is a flowchart showing the operation of the system when delivering medical data.
FIG. 4 is an explanatory diagram showing a configuration example of a medical DB.
FIG. 5 is an explanatory diagram showing a configuration example of a delivery DB.
FIG. 6 is an explanatory diagram showing a description example when requesting a delivery order by electronic mail.
FIG. 7 is an explanatory diagram showing an example of delivered electronic mail.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 100 ... Delivery server, 110 ... Medical DB, 120 ... User information DB, 130 ... Delivery DB, 200 ... User terminal, 300 ... Communication line, 101 ... Delivery order registration control part, 102 ... Delivery order reception part, 103 ... User authentication 104: Delivery order registration unit, 105 ... Delivery control unit, 106 ... Delivery order acquisition unit, 107 ... Delivery data shaping unit, 108 ... Delivery destination address acquisition unit, 109 ... Delivery unit, 121 ... User ID field, 122 ... Password field, 123 ... delivery address field, 124 ... user terminal type, 401 ... patient ID field, 402 ... examination result field, 501 ... delivery ID field, 502 ... user ID field, 503 ... request content field, 504 ... delivery option Field, 510... Example of delivery order.

Claims (3)

A user who stores a user ID for identifying a user, a password for authenticating the user identified by the user ID, and a delivery destination user address for specifying a delivery destination when delivering medical data in response to the user's request A medical data delivery system having an information database and a medical database for storing medical data,
Receiving a delivery order to the password request content as the previous SL user ID is described by any e-mail, it means for receiving a request of a user,
In response to the received request, means for performing user authentication using the user ID and the password, which is information other than a source email address,
Means for acquiring the medical data from the medical database according to the request content included in the request and generating delivery data;
Means for obtaining the delivery destination user address from the user information database based on the user ID;
Means for delivering the delivery data to a user address specified by the delivery destination user address.   2. The medical data delivery system according to claim 1, wherein the delivery destination user address is an e-mail address, and the delivery means delivers the delivery data by e-mail.   The medical data delivery system according to claim 1, further comprising means for determining a delivery timing of delivery data, and delivering the delivery data according to a set timing.

Images