Method for providing information, information providing system, and program

Abstract

To make identity verification in a medical field more efficient as compared with a case where a patient account name alone is displayed in a region for displaying exchanges with a patient via a messaging application.SOLUTION: A method for providing information for providing a medical chart screen of a patient to a client terminal as a cloud service includes the processing of: receiving, as an instruction for a chart screen of a specific patient, display of exchanges on a messaging application between the specific patient and a medical institution; and displaying the account name and the name of the specific patient in a region on the chart screen for displaying the exchanges on the messaging application.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The present invention relates to an information providing method, an information providing system, and a program. [Background technology]

[0002] The LINE (registered trademark) app and other messaging apps are used not only for personal communication but also for business purposes. In messaging apps, the content of the communication between you and the other person is displayed, for example, in speech bubbles. In the case of the LINE app, the screen on which the communication takes place is called the chat screen or talk screen (hereinafter referred to as the "chat screen"). Incidentally, if there is only one person communicating with you, the other person's account name is displayed at the top of the chat screen. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6963331 Summary of the Invention [Problem to be solved by the invention]

[0004] Currently, a service is being put into practical use that links interactions on the LINE app between a medical institution's official account and a patient with an electronic medical record. This type of service allows patients to, for example, make appointments for medical treatment. It is also possible to display a patient chat screen in a section (pane) of the screen displaying patient information recorded in the electronic medical record. However, the current chat screen only displays the patient's account name as the other party's information, and does not display the patient's name. However, given the importance of patient identification in medical settings, it would be desirable to be able to confirm the patient's name on the chat screen.

[0005] The present invention aims to make identity verification more efficient in medical settings compared to when only the patient's account name is displayed in the area displaying interactions with the patient via a messaging app. [Means for solving the problem]

[0006] The invention described in claim 1 is an information provision method that provides a patient's medical record screen to a client terminal as a cloud service, and includes a process of accepting, as an instruction for the medical record screen related to a specific patient, the display of interactions on a messaging app between the specific patient and a medical institution, and a process of displaying the account name and name of the specific patient in the area on the medical record screen that displays the interactions on the messaging app. The invention described in claim 2 is the information providing method described in claim 1, in which an instruction to display the exchange on the messaging app is received through a selection operation of a display item provided on the medical record screen. The invention described in claim 3 is an information provision method described in claim 1, in which each time an exchange on the messaging app is displayed through the medical record screen, the account name of the specific patient is displayed in combination with the name of the specific patient in a display position indicating the other party of the exchange. The invention described in claim 4 is an information provision method described in claim 1, in which each time a display of an exchange on the messaging app is accepted through the medical record screen, the name of the specific patient is added to the account name of the specific patient displayed in a display position indicating the other party of the exchange. The invention described in claim 5 is an information provision system having one or more processors that provides a patient's medical record screen to a client terminal as a cloud service, wherein the one or more processors accept, as an instruction for the medical record screen related to a specific patient, the display of interactions on a messaging app between the specific patient and a medical institution, and display the account name and name of the specific patient in the area on the medical record screen that displays the interactions on the messaging app. The invention described in claim 6 is a program for enabling a computer that provides a patient's medical record screen as a cloud service to a client terminal to realize the following functions: a function to accept the display of interactions on a messaging app between a specific patient and a medical institution as an instruction for the medical record screen related to the specific patient; and a function to display the account name and name of the specific patient in the area on the medical record screen that displays the interactions on the messaging app. [Effects of the Invention]

[0007] According to the present invention, it is possible to make identity verification in medical settings more efficient than when only the patient's account name is displayed in the area displaying interactions with the patient via a messaging app. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram illustrating a schematic configuration of an information providing system assumed in an embodiment. [Figure 2] 1 is a diagram illustrating an example of the hardware configuration of an electronic medical record server. [Figure 3] 1 is a diagram illustrating the data structure of clinic information, the data structure of electronic medical record information, and the data structure of patient information. [Figure 4] 3A and 3B are diagrams illustrating the data structure of reservation information and the data structure of a message log. [Figure 5] FIG. 10 is a diagram illustrating an example of a processing sequence at the time of initial setting. [Figure 6] FIG. 10 is a diagram illustrating an example of a setting process sequence that starts when a patient accesses an official account of a medical institution. [Figure 7] FIG. 10 is a diagram illustrating an example of a setting process sequence that starts in response to a push notification from a medical institution to a patient. [Figure 8] 10 is a diagram illustrating the message log registration operation when a patient sends a message during a period when the patient's medical record screen is not displayed on the clinic terminal. FIG. [Figure 9] 10 is a diagram illustrating an example of a processing sequence executed when a chat screen of a messaging app is embedded and displayed on a medical record screen. FIG. [Figure 10] FIG. 10 is a diagram illustrating an example of a medical record screen displayed on a clinic terminal. [Figure 11] FIG. 10 is a diagram showing an example of a display when a chat screen is displayed using a Clinic X account from a terminal that is not logged in to the electronic medical record server. [Figure 12] FIG. 10 is a diagram illustrating a processing sequence when a message is sent and received while a patient's medical record screen is displayed on a clinic terminal. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example of a form for carrying out the present invention, and the embodiment of the present invention is not limited to the embodiment described below. Therefore, the technical scope of the present invention is not limited to the scope described in the following embodiments. For example, various modifications or improvements to the contents described in the embodiments are also included in the technical scope of the present invention. The various functional units described below are realized through the execution of programs by processors such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), GPU (Graphics Processing Unit), DSP (Digital Signal Processor), and other processors.

[0010] <Terminology> First, the terms used in the embodiments will be explained. "Program" is used as a general term for the OS (Operating System) and application programs. "Medical institutions" include hospitals and clinics. Medical institutions are not limited by their names. In the following, "clinics" will also be used to mean medical institutions. "Medical staff" means physicians and other staff of a medical institution. "Clinic terminal" refers to a terminal operated by medical staff. "Patient terminal" refers to a terminal operated by a patient receiving medical treatment or care at a medical institution.

[0011] "Medical record screen" refers to the electronic medical record screen displayed on a clinic terminal. The electronic medical record in the embodiment described below is provided as a cloud-based service (hereinafter referred to as "cloud service"). Cloud services are also known as SaaS (Software as a Service). A "message" refers to a character string or image sent and received between a patient terminal and a clinic terminal. Images include, for example, still images (so-called photographs) and moving images. Pre-prepared standard messages are called stickers or stamps. Messages are also called "comments" or "chats."

[0012] "Messaging App" means an application program specialized for sending and viewing messages. The messaging app runs on both the patient device and the clinic device. A "message server" is a server operated by a company that provides message sending and receiving services through messaging apps. Messages are displayed on the messaging app screen in the order they were posted. Messaging apps display your own and others' messages in different positions. For example, messages from others are displayed on the left side of the viewing screen, while your own messages are displayed on the right side of the viewing screen.

[0013] <Embodiment> <Overall system configuration> FIG. 1 is a diagram illustrating a schematic configuration of an information providing system 1 assumed in the embodiment. The information providing system 1 shown in FIG. 1 is made up of a patient terminal 10, a clinic terminal 20, a message server 30, an electronic medical record server 40, and a cloud network N. The patient terminal 10 in FIG. 1 is capable of exchanging messages with the clinic terminal 20 via the message server 30.

[0014] 1 can access the electronic medical records of patients managed by the electronic medical record server 40. By operating the clinic terminal 20, it is possible to create new electronic medical records, edit them, view them, etc. The clinic terminal 20 here operates as a client terminal for the electronic medical record server 40. The electronic medical record server 40 is a server that manages the electronic medical records of patients at each medical institution. The electronic medical record server 40 in this embodiment also has a function of linking messages exchanged between patients and medical staff via a messaging app to the patient's electronic medical record and managing them.

[0015] <Device configuration> The patient terminal 10 in this embodiment is, for example, a smartphone, although the patient terminal 10 may also be a tablet computer. Depending on the type of messaging app, a notebook computer, a desktop computer, a wearable terminal, or smart glasses can be used as the patient terminal 10. Incidentally, smart glasses refer to eyeglass-type terminals equipped with a small display and a light-guiding component that focuses the image displayed on the display on the retina.

[0016] The patient terminal 10 as a computer includes, for example, a processor, a semiconductor memory, an auxiliary storage device, a display, an input receiving device, a speaker, and a communication interface. The semiconductor memory stores UEFI (=Unified Extensible Firmware Interface) and the like. The semiconductor memory is also used as a program execution area. When the patient terminal 10 is a smartphone, a semiconductor storage is used as the auxiliary storage device. The auxiliary storage device stores firmware and other programs.

[0017] The display uses a liquid crystal display or an organic EL (Electro Luminescence) display. The input receiving device uses a capacitive touch sensor, a power button, or other physical buttons that are transparent and do not obstruct the visibility of the information displayed on the display. The communication interface may use, for example, a wireless LAN (Local Area Network), 5G, or other mobile communication systems.

[0018] For convenience of explanation, only one patient terminal 10 is depicted in FIG. 1, but in the actual information providing system 1, a plurality of patient terminals 10 are connected to the cloud network N. In this embodiment, the LINE application is assumed as the messaging application used by the patient terminal 10 for exchanging messages. In the case of FIG. 1, the patient terminal 10 is operated by a patient named "Tokyo Taro." In the case of FIG. 1, Tokyo Taro's account name is "Gotanda Taro." The account name can be freely set by the user (here, the patient) who uses the messaging app. In the case of FIG. 1, Tokyo Taro's account name is different from his name.

[0019] Your account name is the display name on the messaging service. Your account name is what appears in the messaging app. Your account name is associated with your account. An account is information used by the message server 30 to authenticate a user (hereinafter referred to as "authentication information"). The authentication information may include, for example, a user name, address, telephone number, email address, and other registered information. The authentication information is managed using an ID (=identifier) ​​and a password. The account is also used by the message server 30 to identify the sender and destination of a message. As will be described later, an account can also be associated with an account ID. In the case of Figure 1, the account ID is "SSSS".

[0020] The clinic terminal 20 is a terminal operated by medical staff at a medical institution. The clinic terminal 20 shown in Fig. 1 is a terminal operated at "Clinic X." In this embodiment, a desktop computer is assumed as the clinic terminal 20. However, the clinic terminal 20 may also be a notebook computer, a smartphone, or a tablet computer. Technically, a wearable device or smart glasses can also be used as the clinic terminal 20.

[0021] The clinic terminal 20 as a computer has, for example, a processor, a semiconductor memory, an auxiliary storage device, a display, an input receiving device, a speaker, and a communication interface. The semiconductor memory stores UEFI and the like. If the clinic terminal 20 is a desktop computer, a hard disk drive or semiconductor storage is used as the auxiliary storage device. The auxiliary storage device stores an OS (=Operating System) and programs.

[0022] When the clinic terminal 20 is a desktop computer, the display is a monitor connected to the terminal body, and the monitor may be, for example, a liquid crystal display or an organic EL display. When the clinic terminal 20 is a desktop computer, a keyboard and a mouse are used as input receiving devices.

[0023] The input receiving device may be a capacitive touch sensor that is integrally attached to the display surface of the display. A device in which a display and a capacitive touch sensor are integrated is called a touch panel. The input receiving device may also be a pen tablet that detects the operation of a stylus pen or the like. When the clinic terminal 20 is a smartphone or a tablet computer, a touch panel is used as a display and an input receiving device. The communication interface may use, for example, a wireless LAN (Local Area Network), 5G, or other mobile communication systems. For convenience of explanation, only one clinic terminal 20 is depicted in FIG. 1, but in an actual information providing system 1, a plurality of clinic terminals 20 are connected to the cloud network N.

[0024] The clinic terminal 20 shown in FIG. 1 can also exchange messages with the patient terminal 10 via the LINE app if configured in advance. In Figure 1, medical staff exchange messages with patients using the account name of "Clinic X," which is the same as the name of "Clinic X." The account name "Clinic X" is linked to the account of Clinic X. In the case of Figure 1, the account ID "XXXX" is linked to the account of Clinic X.

[0025] The message server 30 is one or more servers operated by a business that provides a messaging app. However, in addition to the message server 30, one or more servers (not shown) operated by the business that developed the patient terminal 10 are also involved in the exchange of messages between the patient terminal 10 and the clinic terminal 20. Furthermore, if the clinic terminal 20 is a smartphone or tablet computer, one or more servers operated by the business that developed the clinic terminal 20 are also involved.

[0026] The message server 30 is composed of, for example, a processor, a semiconductor memory, an auxiliary storage device, and a communication interface. The semiconductor memory stores UEFI and the like. A hard disk drive or semiconductor storage, for example, is used as the auxiliary storage device of the message server 30. The auxiliary storage device stores an OS (=Operating System) and programs. The communication interface may use, for example, a wireless LAN (Local Area Network), 5G, or other mobile communication systems.

[0027] The electronic medical record server 40 is one or more servers that provide a service of providing electronic medical records of patients to the clinic terminal 20 of the clinic X. FIG. 2 is a diagram illustrating an example of the hardware configuration of the electronic medical record server 40. As shown in FIG. The electronic medical record server 40 shown in FIG. 2 is composed of a processor 401 that controls the overall operation of the terminal, a semiconductor memory 402, an auxiliary storage device 403, and a communication interface 404.

[0028] The processor 401 is, for example, a CPU. The UEFI and the like are stored in the semiconductor memory 402. The semiconductor memory 402 is also used as an execution area for the electronic medical record application 411 and other programs. The auxiliary storage device 403 is, for example, a hard disk drive or semiconductor storage, and stores an OS and programs. The communication interface 404 is a device that enables communication with the patient terminal 10, the clinic terminal 20, the message server 30, and other terminals. The communication interface 404 is required to have a communication function that is compatible with the cloud network N used for communication.

[0029] The auxiliary storage device 403 shown in Figure 2 stores an electronic medical record application 411, clinic information 412, electronic medical record information by brand 413, patient information by brand 414, appointment information by brand 415, and message log by brand 416. Hereinafter, the clinic information 412, the electronic medical record information by brand 413, the patient information by brand 414, the appointment information by brand 415, and the message log by brand 416 are also referred to as management data.

[0030] The electronic medical record application 411 is an application program that realizes a service that provides a service for managing electronic medical records of patients for each clinic. The electronic medical record application 411 in this embodiment has a function of receiving operation input from the clinic terminal 20 and a function of displaying information corresponding to the received operation input on the clinic terminal 20. The electronic medical record application 411 also has a function of registering the electronic medical record of a new patient in response to an operation by a medical staff member.

[0031] The electronic medical record application 411 has a function of displaying on the display of the clinic terminal 20 a medical record screen of a specific patient designated by the medical staff. The electronic medical record application 411 has a function of recording medical records and the like through operation input by medical staff on the medical record screen. The electronic medical record application 411 has a function of switching the display items on the medical record screen through operation input by the medical staff on the medical record screen. Needless to say, these functions are examples and not all of the functions that the electronic medical record application 411 has.

[0032] Clinic information 412 is information used to manage clinics that use cloud services. The electronic medical record information 413 is a medical record of a patient. In this embodiment, the electronic medical record information 413 is managed by brand. The patient information 414 is personal information of the patient linked to the electronic medical record. In this embodiment, the patient information 414 is managed by brand.

[0033] The reservation information 415 is information relating to appointments for medical treatment at a clinic. In this embodiment, the reservation information 415 is managed by brand. The message log 416 is a log of messages exchanged between a clinic and a patient. That is, the message log 416 records messages exchanged between a clinic account (or account ID) and a patient account (or account ID) via the message server 30. In this embodiment, the message log 416 is managed by brand.

[0034] <Management data structure> FIG. 3 is a diagram for explaining the data structure of clinic information 412, the data structure of electronic medical record information 413, and the data structure of patient information 414. As shown in FIG. The clinic information 412 shown in FIG. 3 includes a "clinic ID" 412A, a "clinic name" 412B, a "brand ID" 412C, an "account ID" 412D, and an "API (=Application Programming Interface) key" 412E. "Clinic ID" 412A is an administrative identifier assigned to each clinic. "Clinic name" 412B is the name of the clinic that uses the cloud service. In practice, not only "Clinic name" 412B but also information such as the clinic's address and contact details are managed.

[0035] "Brand ID" 412C is an identification ID of the clinic. "Account ID" 412D is an identifier that identifies an individual linked to an account. "Account ID" 412D is uniquely assigned within the messaging service. If the messaging app is the LINE app, the LINE ID is stored in "account ID" 412D. The "API key" 412E is an identifier that enables the electronic medical record server 40 to access the messaging service provided by the message server 30 (see FIG. 1) for a specific account (e.g., Clinic X). As will be described later, the "API key" 412E is registered from the clinic terminal 20, for example, when starting to use the cloud service.

[0036] The electronic medical record information 413 shown in FIG. 3 includes a "medical record ID" 413A, a "patient ID" 413B, a "medical record 1" 413C, a "medical record 2" 413D, and a "medical record 3" 413E. "Medical record ID" 413A is an identifier of the electronic medical record linked to the patient. "Patient ID" 413B is the patient's identifier. "Medical Record 1" 413C, "Medical Record 2" 413D, and "Medical Record 3" 413E are records of medical treatment. In the case of Figure 3, each medical record stores the date of treatment, the doctor in charge, the staff in charge, the contents of the medical interview, images, test results, the contents of treatment, the contents of the procedure, accounting information, etc.

[0037] The patient information 414 shown in FIG. 3 includes a "patient ID" 414A, a "name" 414B, a "gender" 414C, a "date of birth" 414D, an "account name" 414E, an "account ID" 414F, and an "email address" 414G. "Patient ID" 414A is the patient's identifier. "Name" 414B is the patient's name. In the case of FIG. 3, "Tokyo Taro", "Yokohama Hanako", and "Osaka Jiro" are shown as examples.

[0038] "Gender" 414C is the gender of the patient. "M" in the figure means male, and "F" means female. Note that "Gender" 414C may be left unregistered or other information may be recorded. "Date of Birth" 414D is the patient's date of birth. "Account name" 414E is the display name for the message. The account name of "Tokyo Taro" shown in Figure 3 is "Gotanda Taro." "Account name" 414E can be freely registered by the patient. For this reason, "account name" 414E does not necessarily match the patient's name.

[0039] "Account ID" 414F is an identifier that identifies an individual linked to the patient's account. Therefore, "account ID" 414F is uniquely assigned within the messaging service. If the messaging app is the LINE app, the LINE ID is used as "account ID" 414F. "Email address" 414G is an email address registered for contacting the patient. Note that a telephone number may be registered instead of or together with "email address" 414G.

[0040] FIG. 4 is a diagram for explaining the data structure of the reservation information 415 and the data structure of the message log 416. As shown in FIG. The appointment information 415 shown in FIG. 4 includes an "appointment ID" 415A, a "patient ID" 415B, an "appointment date and time" 415C, a "desired treatment / procedure" 415D, and a "desired doctor / staff" 415E.

[0041] "Reservation ID" 415A is an identifier that is assigned when a reservation is accepted. "Patient ID" 415B is the patient's identifier. "Reservation date and time" 415C is the date and time of the reservation. "Desired Treatment / Procedure" 415D is the desired treatment or procedure. This item is used when the treatment or procedure can be reserved. Examples of treatment include prescription of medicine only, request for a preventive injection, or diagnosis of poor health accompanied by fever. Examples of treatment include treatment for spots or dullness, treatment to remove spots, and hair removal. "Desired Doctor / Staff" 415E is the content of the desired doctor or staff. This item is used when the doctor or staff involved in the treatment or procedure can be specified.

[0042] The message log 416 shown in FIG. 4 includes a "timestamp" 416A, a "patient account name" 416B, a "patient account ID" 416C, a "received message content" 416D, and a "sent message content" 416E. "Time stamp" 416A is the date and time when the message server 30 (see FIG. 1) received the message from the patient terminal 10 (see FIG. 1) or the clinic terminal 20 (see FIG. 1).

[0043] "Patient account name" 416B is information that identifies the patient exchanging messages with Clinic X. In the case of Figure 4, the patient's account name is "Gotanda Taro." As mentioned above, the account name may be different from the patient's "name" 414B (see Figure 3). "Patient account ID" 416C is an identifier that identifies an individual linked to a patient's account. "Patient account ID" 416C is uniquely assigned within the messaging service. If the messaging app is the LINE app, the LINE ID is stored in "Patient account ID" 416C.

[0044] The content of the message received from the patient is recorded in "Received message content" 416D. In the case of Figure 4, "I have made an appointment," "Hello, doctor," and "I will come in the evening / Thank you in advance" are recorded. The symbol " / " means a line break. The content of messages sent by medical staff to patients using the clinic's account name is recorded in "Message content sent" 416E. In the case of Figure 4, "Hello" and "Please contact me if you have any concerns" are recorded.

[0045] <Processing sequence> The processing sequence executed by the information providing system 1 will be described below with reference to FIGS.

[0046] <Initial settings> First, we will explain the initial settings required by the clinic when starting the cloud service. 5 is a diagram illustrating an example of a processing sequence at the time of initial setting. The symbol S in the diagram represents a step. It is assumed that the clinic terminal 20 shown in FIG. 5 is a terminal of Clinic X. First, the medical staff logs in to the message server 30 by operating the clinic terminal 20 (step 101). A login ID and a login password are sent from the clinic terminal 20 to the message server 30. The login ID and the login password are entered by the medical staff.

[0047] The message server 30 performs login authentication using the received login ID and login password (step 102). That is, the message server 30 verifies the user's identity using the login ID and login password. Figure 5 assumes that the login is successful. Next, the medical staff operates the clinic terminal 20 to request an API key from the message server 30 (step 103).

[0048] Upon receiving the request for the API key, the message server 30 transmits the API key dedicated to Clinic X to the requesting clinic terminal 20 (step 104). This API key is a character string required for Clinic X to access the services provided by the message server 30. The medical staff who has acquired the API key operates the clinic terminal 20 to register the API key in the electronic medical record server 40 (step 105). The electronic medical record server 40 registers the API key in association with, for example, the account ID of Clinic X (step 106). In the case of this embodiment, the API key is registered in the clinic information 412 (see FIG. 3).

[0049] Next, the electronic medical record server 40 issues a webhook parameter for receiving a notification from the message server 30 that a message addressed to Clinic X has been received, and notifies the clinic terminal 20 (step 107). The webhook parameter includes the account ID of Clinic X and the URL of the electronic medical record server 40. Thereafter, the medical staff operates the clinic terminal 20 to link the webhook parameters issued by the electronic medical record server 40 to the account ID of Clinic X and set them in the message server 30 (step 108). The message server 30 that has accepted the setting from the clinic terminal 20 registers the webhook parameters issued by the electronic medical record server 40 in the message server 30, linking them to the account ID of Clinic X (step 109).

[0050] <Message app settings> Next, we will explain the settings required for patients and clinics to exchange messages via messaging apps. There are two types of settings: one that is initiated when a patient accesses the medical institution's official account (hereinafter referred to as "Setting 1"), and one that is initiated when the medical institution sends a push notification to the patient (hereinafter referred to as "Setting 2").

[0051] <In the case of setting 1> Figure 6 is a diagram illustrating an example of a setting processing sequence that starts when a patient accesses the official account of a medical institution. In the case of Figure 6, it is assumed that the patient terminal 10 is a terminal operated by Tokyo Taro. It is also assumed that the clinic terminal 20 is a terminal of Clinic X. In the case of Fig. 6, the patient applies for registration with the account ID of Clinic X by operating the patient terminal 10 (step 201). If the messaging app is the LINE app, this application corresponds to a "friend request."

[0052] Upon receiving the request, the message server 30 notifies the electronic medical record server 40 of Tokyo Taro's registration request addressed to Clinic X's account ID (step 202). This notification includes Tokyo Taro's account ID and Clinic X's account ID. This notification is executed through the function of the webhook parameter registered in step 109 (see FIG. 5). Note that this notification is not recorded in the message log 416 (see FIG. 4).

[0053] Next, the message server 30 notifies the patient terminal 10 operated by Tokyo Taro of the menu screen for Tokyo Taro, who is registered as a friend of Clinic X (step 203). The menu screen here is called, for example, My Page. Through the menu screen, patients can set up appointments, fill out medical questionnaires, send messages, etc. Incidentally, the reservation button on the menu screen has the URL (Uniform Resource Locator) of the reservation site embedded in it.

[0054] In the case of Figure 6, Tokyo Taro sends reservation information to Clinic X from the menu screen (step 204). The reservation information is sent to the reservation site of electronic medical record server 40. The reservation information includes, for example, the URL of the reservation site, Tokyo Taro's account ID, the desired treatment or procedure, the desired date and time of the reservation, his name (Tokyo Taro), gender, email address, date of birth, and information about the desired doctor and staff. If the patient who sent the reservation information is a new patient, the electronic medical record server 40 registers Tokyo Taro's information in the electronic medical record information 413 (see FIG. 3) and patient information 414 (see FIG. 3) of Clinic X (step 205). Furthermore, the electronic medical record server 40 adds Tokyo Taro's reservation to the reservation information 415 of Clinic X (see FIG. 4) (step 206).

[0055] <In the case of setting 2> 7 is a diagram illustrating an example of a setting processing sequence that starts with a push notification from a medical institution to a patient. In the case of FIG. 7, it is assumed that the patient terminal 10 is a terminal operated by Tokyo Taro. It is also assumed that the clinic terminal 20 is a terminal of Clinic X. In the case of Figure 7, the electronic medical record server 40 refers to the patient information 414 (see Figure 3) and presents a QR code (registered trademark) to Tokyo Taro, who has no registered friends (a patient who has a patient ID but no registered account ID or account name) (step 301). For sending the email, the "email address" 414G (see FIG. 3) registered in the patient information 414 is used.

[0056] In the case of FIG. 7, the QR code contains the patient ID, the account ID of Clinic X, the URL of the message server 30, and the URL of the redirect destination. Tokyo Taro reads the QR code or the like and applies for registration with Clinic X via the message server 30 (step 302). After linking Tokyo Taro's account ID with Clinic X's account ID, the message server 30 notifies the clinic terminal 20 of Clinic X that Tokyo Taro has been added as a friend (step 303).

[0057] Upon receiving the request to register on the friend addition site, the message server 30 sends Tokyo Taro's request to the redirect destination URL (here, the URL of the electronic medical record server 40). The application here includes Clinic X's account ID, Tokyo Taro's account ID, and Tokyo Taro's patient ID. The electronic medical record server 40 uses the notified patient ID to add Tokyo Taro's account ID to the patient information 414 of Clinic X (see FIG. 3) (step 304).

[0058] <Message log recording> Figure 8 is a diagram illustrating the message log registration operation when a patient sends a message during a period when the patient's medical record screen is not displayed on the clinic terminal 20. In the case of Figure 8, it is also assumed that the patient terminal 10 is a terminal operated by Tokyo Taro. It is also assumed that the clinic terminal 20 is a terminal of Clinic X. Tokyo Taro sends message A addressed to Clinic X via the messaging app on the patient terminal 10 (step 401). Message A includes Tokyo Taro's account ID, Clinic X's account ID, and the content of message A. The message server 30 notifies the clinic terminal 20 of the receipt of message A addressed to clinic X (step 402).

[0059] In addition, the message server 30 notifies the electronic medical record server 40 of the receipt of message A from Tokyo Taro addressed to Clinic X and the contents of message A through the function of the webhook parameter registered for Clinic X (step 403). The electronic medical record server 40 registers the message A in the message log 416 (see FIG. 4) of the clinic X (step 404). Furthermore, the electronic medical record server 40 notifies the clinic terminal 20 of the receipt of message A addressed to clinic X (step 405).

[0060] <Viewing chats on the medical record screen> The following describes the processing operations when checking the chat between Clinic X and Tokyo Taro on the medical record screen.

[0061] <Chat screen display> FIG. 9 is a diagram illustrating an example of a processing sequence executed when a chat screen of a messaging app is embedded and displayed on a medical record screen. The chat screen here is an example of an area that displays interactions on a messaging app.

[0062] The processing sequence shown in FIG. 9 starts with the medical record screen of "Tokyo Taro" being displayed on the display of the clinic terminal 20. First, the medical staff operates the clinic terminal 20 and selects the "Chat" button on the tab bar to instruct the display of the chat screen (step 501). Selecting the "Chat" button is an example of a selection operation for a display item provided on the medical record screen. Operation inputs to the medical record screen are notified from the clinic terminal 20 to the electronic medical record server 40.

[0063] Upon receiving the notification, the electronic medical record server 40 reads Tokyo Taro's message log 416 (see FIG. 4) and switches the display of the main pane of the medical record screen to a chat screen (step 502). However, the title section of the chat screen displays Tokyo Taro's account name and name. The title section displays the recipient of the message displayed on the chat screen. In other words, the title section is an example of a display position that indicates the recipient of the exchange. In this embodiment, Tokyo Taro's account name is "Gotanda Taro." In this embodiment, the account name is linked to the account ID of the message sent from Tokyo Taro to the clinic and is stored in the patient information 414 (see FIG. 3) and the message log 416.

[0064] The electronic medical record server 40 displays the title section of the chat screen to be displayed in the main pane of the medical record screen by one of the processing operations shown below. (1) Operation 1: The electronic medical record server 40 reads the patient's "name" 414B (see FIG. 3) linked to the account name or account ID from the patient information 414 (see FIG. 3), and generates a title section that combines the account name with the patient's name. That is, when the electronic medical record server 40 receives an instruction from the clinic terminal 20 to display a chat screen with a specific patient, it generates a title section each time. For example, the title section is displayed in the format of "account name / patient name." For example, it generates a title section such as "Gotanda Taro / Tokyo Taro."

[0065] In this embodiment, the electronic medical record server 40 may replace the original title section with the generated title section. The electronic medical record server 40 may place the generated title section in a layer above the title section on the chat screen so that the original title section is not recognized. However, the order of names in the title section can be arbitrary, and it can be in the format of "Patient name / Account name." In this case, the title section will be displayed as "Tokyo Taro / Gotanda Taro."

[0066] (2) Operation 2: The electronic medical record server 40 reads the patient's name linked to the account name and account ID from the patient information 414 and adds it to the account name in the title section. That is, each time the electronic medical record server 40 receives an instruction from the clinic terminal 20 to display a chat screen with a specific patient, it adds the patient's name to the title section. The patient's name may be added after the account name or added (i.e., inserted) before the account name. For example, if you add the "Patient's Name" after the display position of the "Account Name," the title display will change from "Gotanda Taro" to "Gotanda Taro / Tokyo Taro." Also, if the "Patient's Name" is added before the display position of the "Account Name", the title display will change from "Gotanda Taro" to "Tokyo Taro / Gotanda Taro".

[0067] (3) Operation 3: The electronic medical record server 40 stores the title section including the account name and patient name generated for the chat screen on the medical record screen in the auxiliary storage device 403 (see Figure 2), and reads and uses it when displaying the chat screen for the second or subsequent time. The title section may be saved as one of the items in the patient information 414 (see FIG. 2) or the message log 416 (see FIG. 2), or may be saved as independent information linked to an account ID, a patient ID, or the like. In this operation, the title section is generated only once, but the title section is replaced each time an instruction to display a chat screen with a specific patient is received from the clinic terminal 20.

[0068] After the processing of step 502 described above, the clinic terminal 20 displays a chat screen with Tokyo Taro on the main pane of the electronic medical record (step 503). FIG. 10 is a diagram illustrating an example of a medical record screen 200 displayed on the clinic terminal 20. As shown in FIG. The medical record screen 200 is displayed on the display of the clinic terminal 20.

[0069] The medical record screen 200 shown in Fig. 10 is divided into three panes. In Fig. 10, patient information is displayed in pane 210 on the left side of the screen. A tab bar is displayed in pane 220 at the top of the screen. A chat screen is displayed in pane 230 in the center of the screen. In this embodiment, the display size of each pane can be changed by the medical staff while viewing the medical record screen.

[0070] In the case of FIG. 10, the pane 210 displaying the patient information displays the patient's name, patient ID, and date of birth registered in the electronic medical record. Note that the display of the pane 210 shown in FIG. 10 is an example, and other information such as gender, allergy information, special notes, medical examination history, and billing information may also be displayed. The pane 210 is also called a side pane. In addition, in relation to the main pane, the pane 210 is also called a sub-pane.

[0071] In the case of FIG. 10, the pane 220 where the tab bar is displayed displays buttons for selecting items to be displayed in the pane 230. In the case of FIG. 10, "Medical History," "Accounting," "Chat," "Inquiry," "Photos," "Documents," and "Notes" are listed. Other items can also be displayed on the selection buttons. In FIG. 10, the shaded area indicates that "Chat" has been selected. The pane 220 is also called a top pane. In addition, in relation to the main pane, the pane 220 is also called a sub-pane.

[0072] 10, as described above, the chat screen is displayed in pane 230. In relation to the sub-pane, the chat screen is also called the main pane. As described above, the display size of the pane 230 can be changed by the medical staff while viewing the medical record screen. In other words, the display size of the pane 230 has a high degree of freedom. The chat screen shown in FIG. 10 is made up of three areas 231, 232, and 233.

[0073] Area 231 is a title section that indicates the person you are chatting with. In the case of Figure 10, the title section displays "Gotanda Taro / Tokyo Taro," which is a combination of the account name "Gotanda Taro" and the patient's name "Tokyo Taro." By including the patient's name in the title of the chat screen, medical staff can confirm who is chatting with them without having to move their eyes to the area where the patient information is displayed (i.e., pane 210).

[0074] Furthermore, pane 230 is a display area that is long in the horizontal direction. Therefore, the patient's name can be displayed in a larger font size in the title section of the chat screen compared to the font size of pane 210, which has a limited horizontal display size. This increases the medical staff's ability to identify the person they are chatting with. In other words, the patient's name becomes more easily identifiable.

[0075] In addition, the account name will be displayed on the chat screen of all accounts using the messaging app unless individual display settings are in place. For this reason, the account name may not necessarily be the patient's name, and unlike the account ID, there is a possibility that it may be the same as another account. However, as in this embodiment, the patient's name is displayed in the title section of the chat screen on the medical record screen, where identity verification is important, so medical staff can confirm the patient's name without taking their eyes off the chat screen.

[0076] In area 232, the contents of messages recorded in message log 416 (see FIG. 4) are displayed in chronological order. Area 233 displays a message input field 233A and a "Send" button 233B. In the case of Fig. 10, the message before sending, "Don't forget your health insurance card," is displayed in input field 233A. This message is sent to the account name "Gotanda Taro" by operating "Send" button 233B.

[0077] Fig. 11 is a diagram showing an example of a display when a chat screen is displayed using an account for Clinic X from a terminal that is not logged in to the electronic medical record server 40 (see Fig. 1). In Fig. 11, parts corresponding to those in Fig. 10 are assigned the same reference numerals. The chat screen shown in FIG. 11 is assumed to be a smartphone 20A used with an account of Clinic X. The chat screen shown in Fig. 11 is displayed simultaneously with the medical record screen shown in Fig. 10. Therefore, the display content of the chat screen shown in Fig. 11 is the same as the display content of the chat screen shown in Fig. 10.

[0078] Incidentally, the chat screen shown in FIG. 11 is displayed not as a medical record screen but as a messaging app screen. 11, only the account name is displayed in the title section indicating the person with whom you are chatting. In other words, only "Gotanda Taro" is displayed. This is because only the message server 30 is involved in displaying the chat screen shown in Fig. 11. In other words, the electronic medical record server 40 is not involved in the process of notifying a message when displaying the chat screen shown in Fig. 11. In addition, in the case of a medical record screen that does not use the technology described in this embodiment, the same screen as the chat screen shown in Fig. 11 is displayed on the medical record screen. In other words, only the account name is displayed in the title section of the chat screen.

[0079] FIG. 12 is a diagram illustrating a processing sequence when a message is sent and received while the patient's medical record screen is displayed on the clinic terminal 20. In FIG. In FIG. 12, parts corresponding to those in FIG. 9 are denoted by the same reference numerals. Incidentally, steps 601 to 605 are a processing sequence when a message addressed to Clinic X is sent from the patient terminal 10. On the other hand, steps 701 to 705 are a processing sequence when a message addressed to Tokyo Taro is sent from the clinic terminal 20.

[0080] First, steps 601 to 605 will be described. Tokyo Taro operates the messaging app on the patient terminal 10 to send message A addressed to Clinic X (step 601). This message A is sent to the message server 30. Message A includes Tokyo Taro's account ID, Clinic X's account ID, and the content of message A. Upon receiving message A, message server 30 notifies clinic terminal 20 of clinic X of the receipt of message A from Tokyo Taro, in accordance with the account ID indicating the destination (step 602). When this notification is opened in the messaging app on smartphone 20A (see FIG. 11), the chat screen shown in FIG. 11 is displayed.

[0081] In the case of Figure 12, the message server 30 notifies the electronic medical record server 40 of the receipt of message A from Tokyo Taro addressed to Clinic X and the contents of message A (step 603). This notification is executed as a function of the webhook parameter. Upon receiving the notification from the message server 30, the electronic medical record server 40 registers the message A in the message log 416 (see FIG. 4) of the clinic X (step 604). Next, the electronic medical record server 40 reflects the message A on the chat screen with Tokyo Taro (step 605).

[0082] Next, steps 701 to 705 will be described. Here, it is assumed that a medical staff member at Clinic X is displaying a chat screen in pane 230 of Tokyo Taro's medical record screen. In this state, the clinic terminal 20 sends a message B addressed to Tokyo Taro from the chat screen on the medical record screen (step 701). This sending corresponds to, for example, accepting the operation of the "Send" button 233B (see FIG. 10) with "Don't forget your health insurance card" entered in the message input field 233A (see FIG. 10).

[0083] Since the medical record screen is displayed as a cloud service, message B addressed to Tokyo Taro is sent to the electronic medical record server 40. Message B includes the account ID of Clinic X, Tokyo Taro's account ID, and the content of message B. The electronic medical record server 40, which has received the message from Clinic X, uses the API key of Clinic X to send Message B to the message server 30 (step 702). The message server 30 that has received message B notifies Tokyo Taro's patient terminal 10 of the receipt of message B from Clinic X, according to the account ID indicating the destination (step 703). When Tokyo Taro opens this notification in the messaging app on his smartphone, message B is displayed on the chat screen.

[0084] The electronic medical record server 40 sends message B to the message server 30 and also registers message B in the message log 416 of clinic X (see FIG. 4) (step 704). The electronic medical record server 40 also reflects message B on the chat screen with Tokyo Taro (step 705). Specifically, the message "Don't forget your health insurance card" is added to the last line of the area 232 shown in FIG.

[0085] <Summary> As described above, the electronic medical record server 40 in this embodiment is a server that provides a patient's medical record screen on the display of the clinic terminal 20 as a cloud service. When the electronic medical record server 40 receives a request to display a chat screen with a specific patient as part of the medical record screen, it displays the account name and name of the specific patient in the title section of the chat screen.

[0086] Therefore, medical staff viewing the medical record screen can easily check the patient's name while keeping their eyes on the chat screen. Additionally, the display size of the chat screen title displayed in the main pane of the medical record screen is larger than the display size of the patient information displayed in the side pane. This allows medical staff to see the patient's name in a larger font than in the side pane. As a result, the patient's name is more easily recognizable. The display of the title section including the patient's account name and the patient's name described in this embodiment is only provided on the medical record screen provided as a cloud service.

[0087] <Other embodiments> (1) The electronic medical record described in the above embodiment may be provided to a clinic terminal as an on-premise service. That is, the display of the medical record screen described above may be realized as one of the functions of a program executed on a server installed in a medical institution. The electronic medical record described in the above embodiment may be displayed as a function of a program running on a clinic terminal. That is, the display of the medical record screen described above may be realized as one of the functions of a standalone program.

[0088] <Summary> The embodiments include the following information providing method, information providing system, and program. (((1))) One of the objectives of the present invention is to enable efficient identity verification when displaying interactions with a patient via a messaging app on the patient's medical record screen. The information provision method of the embodiment is an information provision method that provides a patient's medical record screen to a client terminal as a cloud service, and includes a process of accepting, as an instruction for the medical record screen related to a specific patient, the display of interactions on a messaging app between a specific patient and a medical institution, and a process of displaying the account name and name of the specific patient in the area on the medical record screen that displays the interactions on the messaging app. This information provision method makes it possible to efficiently verify the identity of a patient when displaying interactions with the patient via a messaging app on the patient's medical record screen.

[0089] (((2))) One of the objectives of the present invention is to enable interactions with patients via a messaging app to be displayed on the patient's medical record screen through operations on the patient's medical record screen. The information provision method described in (((1)))), in which an instruction to display the exchanges on the messaging app is received through a selection operation of a display item provided on the medical record screen. According to this information provision method, by operating the patient's medical record screen, interactions with the patient via the messaging app can be displayed on the medical record screen.

[0090] (((3))) One of the objectives of the present invention is to be able to display the patient's account name in combination with the patient's name each time the patient's medical record screen is displayed. An information provision method described in (((1))) or (((2))), in which, each time an exchange on a messaging app is accepted through the medical record screen, the account name of a specific patient is displayed in combination with the name of the specific patient in the display position indicating the other party of the exchange. According to this information providing method, each time the patient's medical record screen is displayed, the patient's account name and the patient's name can be displayed in combination.

[0091] (((4))) One of the objectives of the present invention is to be able to display the patient's account name in combination with the patient's name each time the patient's medical record screen is displayed. An information provision method described in (((1))) or (((2))), in which, each time an exchange on a messaging app is displayed via the medical record screen, the name of a specific patient is added to the account name of the specific patient displayed in the display position indicating the other party of the exchange. According to this information providing method, each time the patient's medical record screen is displayed, the patient's account name and the patient's name can be displayed in combination.

[0092] (((5))) One of the objectives of the present invention is to enable efficient identity verification when displaying interactions with a patient via a messaging app on the patient's medical record screen. The information provision system in the embodiment has one or more processors and provides patient medical record screens to client terminals as a cloud service, and the one or more processors accept, as an instruction for the medical record screen related to a specific patient, the display of interactions on a messaging app between a specific patient and a medical institution, and display the account name and name of the specific patient in the area on the medical record screen that displays the interactions on the messaging app. This information provision system makes it possible to efficiently verify the identity of a patient when displaying interactions with the patient via a messaging app on the patient's medical record screen.

[0093] (((6))) One of the objectives of the present invention is to enable efficient identity verification when displaying interactions with a patient via a messaging app on the patient's medical record screen. The program in the embodiment enables a computer that provides a patient's medical record screen as a cloud service to a client terminal to perform the following functions: accept the display of interactions on a messaging app between a specific patient and a medical institution as an instruction for the medical record screen related to a specific patient; and display the account name and name of the specific patient in the area on the medical record screen that displays the interactions on the messaging app. This program makes it possible to efficiently verify the identity of patients when displaying interactions with them via messaging apps on the patient's medical record screen. [Explanation of symbols]

[0094] 1...information provision system, 10...patient terminal, 20...clinic terminal, 20A...smartphone, 30...message server, 40...electronic medical record server

Claims

1. An information providing method for providing a patient's medical record screen to a client terminal as a cloud service, comprising: receiving, as an instruction to the medical record screen for a specific patient, a display of an exchange on a messaging app between the specific patient and a medical institution; a process of displaying the account name and the name of the specific patient in an area on the medical record screen that displays the exchanges on the messaging app; An information provision method having the above.

2. The information providing method according to claim 1 , wherein the instruction to display the exchange on the messaging app is received through a selection operation of a display item provided on the medical record screen.

3. The information provision method described in claim 1, wherein each time an exchange on the messaging app is displayed through the medical record screen, the account name of the specific patient is displayed in combination with the name of the specific patient in a display position indicating the other party of the exchange.

4. The information provision method of claim 1, wherein each time a display of an exchange on the messaging app is accepted through the medical record screen, the name of the specific patient is added to the account name of the specific patient displayed in a display position indicating the other party of the exchange.

5. An information providing system having one or more processors and providing a patient's medical record screen to a client terminal as a cloud service, the one or more processors: Accepting a display of an exchange on a messaging app between the specific patient and a medical institution as an instruction for the medical record screen regarding the specific patient; and displaying the account name and the name of the specific patient in an area on the medical record screen that displays the exchanges on the messaging app. Information provision system.

6. A computer that provides patient chart screens to client terminals as a cloud service. a function of receiving, as an instruction for the medical record screen relating to a specific patient, a display of an exchange on a messaging app between the specific patient and a medical institution; A function of displaying the account name and the name of the specific patient in an area on the medical record screen that displays interactions on the messaging app; A program to achieve this.

Images