Information providing method, information providing system, and program

Abstract

It facilitates the understanding of the interaction with patients in the medical field as compared with the case where the poster of a message using the official account of a medical institution is unknown. 【Solution means】In an information providing method for providing a patient's medical record screen to a client terminal as a cloud service, a process of receiving a display of an interaction through a messaging app with a specific patient using the official account of a medical institution through the medical record screen regarding the specific patient, and a process of visibly displaying on the medical record screen the staff of the medical institution who posted each message linked to the official account of the medical institution are provided.

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, 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 the LINE app interactions between medical institutions' official accounts and patients with electronic medical records. This type of service allows patients to, for example, make appointments for medical treatment. It is also possible to display a chat screen with patients in a section (pane) of the screen displaying patient information recorded in the electronic medical record. Incidentally, the staff involved in interactions with patients include not only the attending physician, but also various other staff, such as reception staff and staff assisting with medical examinations and treatments. However, interactions on messaging apps are conducted using the official account of the medical institution. Therefore, even if you look at the chat screen, it is not possible to identify on the screen who within the medical institution is communicating with the patient.

[0005] The present invention aims to make it easier to understand interactions with patients in medical settings, compared to when the poster of a message using the official account of a medical institution is unknown. [Means for solving the problem]

[0006] The invention described in claim 1 is an information providing method for providing a patient's medical record screen to a client terminal as a cloud service, the method including: receiving a display of a message exchanged with a specific patient via a messaging app using an official account of a medical institution through the medical record screen of the specific patient; and identifying staff of the medical institution who posted each message linked to the official account of the medical institution. Based on the message log of the medical institution managed by the cloud service, On the medical record screen the area part for displaying the interaction of the messaging app and a process of displaying the information in a manner that makes it identifiable. The invention described in claim 2 is an information provision method described in claim 1, in which an input field for a new message and an input field for staff to post a new message are displayed in the area displaying the exchanges in the messaging app. The invention recited in claim 3 is the information providing method recited in claim 2, wherein a list of staff members is displayed in the staff member input field so that the staff member can be selected. The invention recited in claim 4 is the information providing method recited in claim 3, wherein the staff member input field displays staff members who are scheduled to come to work at the time of the selection operation. The invention described in claim 5 is an information provision method described in claim 3, in which staff members who are scheduled to work at the time of the selection operation are displayed in the staff input field in a manner that gives them a higher priority than staff members who are not scheduled to work at the time of the selection operation. The invention described in claim 6 is an information provision method described in claim 2, in which the staff member who posted the latest message linked to the medical institution's official account is displayed as the initial value in the staff member input field. The invention according to claim 7 is 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, wherein the one or more processors receive, through the medical record screen regarding a specific patient, a display of an interaction through a messaging app with the specific patient using an official account of a medical institution, and staff members of the medical institution who posted each message linked to the official account of the medical institution are Based on the message log of the medical institution managed by the cloud service, identifiably displayed the area part for displaying the interaction of the messaging app on the medical record screen. The invention according to claim 8 is a program for causing a computer that provides a patient's medical record screen to a client terminal as a cloud service to realize a function of receiving, through the medical record screen regarding a specific patient, a display of an interaction through a messaging app with the specific patient using an official account of a medical institution, and a function of Based on the message log of the medical institution managed by the cloud service, identifiably displaying the area part for displaying the interaction of the messaging app on the medical record screen staff members of the medical institution who posted each message linked to the official account of the medical institution.

Advantages of the Invention

[0007] According to the present invention, it is possible to more easily grasp the interaction with patients in the medical field as compared with the case where the poster of a message using an official account of a medical institution is unknown.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

[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] The "medical record screen" refers to the screen of the electronic medical record displayed on the clinic terminal. The electronic medical record in the embodiments described below is provided as a cloud-based service (hereinafter referred to as "cloud service"). The cloud service is also called SaaS (= Software as a Service). A "message" refers to a character string or image transmitted and received between the patient terminal and the clinic terminal. Images include, for example, still images (so-called photos) and moving images. Note that prepared standard messages are called stickers or stamps. A message is also called a "comment" or a "chat".

[0012] A "messaging app" refers to an application program specialized for sending and viewing messages. The messaging app is executed on the patient terminal and the clinic terminal. A "message server" is a server operated by a provider that provides a message transmission and reception service through the messaging app. On the screen of the messaging app, messages are displayed in the order in which they are posted. The messaging app displays messages from oneself and others in different positions. For example, the other party's message is displayed on the left side of the viewing screen. On the other hand, one's own message is displayed on the right side of the viewing screen.

[0013] <Embodiment> <Overall Configuration of the System> FIG. 1 is a diagram for explaining the schematic configuration of an information providing system 1 assumed in the embodiment. The information providing system 1 shown in FIG. 1 is composed 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 can exchange messages with the clinic terminal 20 through the message server 30.

[0014] The clinic terminal 20 in FIG. 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, edit, view, etc. the electronic medical records. Here, the clinic terminal 20 operates as a client terminal with respect to the electronic medical record server 40. The electronic medical record server 40 is a server that manages the electronic medical records of patients in each medical institution. The electronic medical record server 40 in the present embodiment is also provided with a function of associating and managing the messages exchanged between patients and medical staff through the messaging application with the electronic medical records of the patients.

[0015] <Configuration of Each Terminal> The patient terminal 10 in the present embodiment is, for example, a smartphone. However, the patient terminal 10 may also be a tablet-type computer. Depending on the type of the messaging application, as the patient terminal 10, it is also possible to use a notebook computer, a desktop computer, a wearable terminal, or smart glasses. Incidentally, smart glasses refer to a glasses-type terminal including a small display and a light guiding component that forms an image of the image displayed on the display on the retina.

[0016] The patient terminal 10 as a computer has, for example, a processor, a semiconductor memory, an auxiliary storage device, a display, an input reception device, a speaker, and a communication interface. The semiconductor memory stores UEFI (= Unified Extensible Firmware Interface), etc. The semiconductor memory is also used as an execution area for programs. 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] A liquid crystal display or an organic EL (= Electro Luminescence) display is used for the display. For the input reception device, a capacitive touch sensor having transparency that does not obstruct the visibility of the information displayed on the display, a power button, and other physical buttons are used. For the communication interface, for example, a wireless LAN (= Local Area Network), 5G, or other mobile communication systems are used.

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

[0019] The account name is the display name on the messaging service. The account name is displayed on the messaging app. The account name is associated with the account. The account is information (hereinafter referred to as "authentication information") used by the message server 30 for user authentication. For the authentication information, for example, user name, address, phone number, email address, and other registration information are used. The authentication information is managed by an ID (= identifier) and a password. The account is also used by the message server 30 to identify the sender and recipient of the message. As will be described later, it is also possible to associate an account ID with the account. In the case of FIG. 1, the account ID is "SSSS".

[0020] The clinic terminal 20 is a terminal operated by medical staff of a medical institution. The clinic terminal 20 shown in FIG. 1 is a terminal operated at "Clinic X". In the case of this embodiment, a desktop computer is assumed as the clinic terminal 20. However, the clinic terminal 20 may be a notebook computer, a smartphone, or a tablet computer. Technically, a wearable terminal or smart glasses can also be adopted 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 reception device, a speaker, and a communication interface. UEFI or the like is stored in the semiconductor memory. When the clinic terminal 20 is a desktop computer, a hard disk device or a 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 main body. For the monitor, for example, a liquid crystal display or an organic EL display is used. When the clinic terminal 20 is a desktop computer, a keyboard and a mouse are used as the input reception device.

[0023] Note that, as the input reception device, a capacitive touch sensor integrally attached to the display surface of the display may be used. A device in which the display and the electrostatic touch sensor are integrated is called a touch panel. Also, as the input reception device, a tablet that detects operations such as a stylus pen may be used. When the clinic terminal 20 is a smartphone or a tablet computer, a touch panel is used as the display and the input reception device. For the communication interface, for example, a wireless LAN (=Local Area Network), 5G, or other mobile communication systems are used. In FIG. 1, for the sake of explanation, only one clinic terminal 20 is depicted. However, in the actual information provision 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 through the LINE app according to prior settings. In the case of FIG. 1, medical staff use the account name of "Clinic X" to exchange messages with patients. This account name is the same as the name of "Clinic X". Note that the "Clinic X" of the account name is linked to the account of Clinic X. In the case of FIG. 1, the account ID of "XXXX" is linked to the account of Clinic X. In FIG. 1, T-san, N-san, M-san, and S-san are exemplified as medical staff operating the clinic terminal 20.

[0025] The message server 30 is one or more servers operated by an operator providing a messaging app. However, for message exchange between the patient terminal 10 and the clinic terminal 20, in addition to the message server 30, one or more servers (not shown) operated by the operator who developed the patient terminal 10 are also involved. Also, when the clinic terminal 20 is a smartphone or a tablet-type computer, one or more servers operated by the operator who developed the clinic terminal 20 are further involved.

[0026] The message server 30 is composed of, for example, a processor, a semiconductor memory, an auxiliary storage device, and a communication interface. UEFI etc. are stored in the semiconductor memory. For example, a hard disk device or a semiconductor storage is used for the auxiliary storage device of the message server 30. An OS (=Operating System) and programs are stored in the auxiliary storage device. For example, a wireless LAN (=Local Area Network), 5G, or other mobile communication systems are used for the communication interface.

[0027] The electronic medical record server 40 is one or more servers that provide a service of providing the electronic medical record of a patient to the clinic terminal 20 of Clinic X. FIG. 2 is a diagram for explaining an example of the hardware configuration of the electronic medical record server 40. The electronic medical record server 40 shown in FIG. 2 includes a processor 401 that controls the operation of the entire 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 semiconductor memory 402 stores UEFI or the like. 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 device or a semiconductor storage. The auxiliary storage device 403 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 compatible with the cloud network N used for communication.

[0029] The auxiliary storage device 403 shown in FIG. 2 stores an electronic medical record application 411, clinic information 412, brand-specific electronic medical record information 413, brand-specific patient information 414, brand-specific reservation information 415, brand-specific staff information 416, brand-specific work shift information 417, and brand-specific message logs 418. Hereinafter, the clinic information 412, the brand-specific electronic medical record information 413, the brand-specific patient information 414, the brand-specific reservation information 415, the brand-specific staff information 416, the brand-specific work shift information 417, and the brand-specific message logs 418 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. Staff information 416 is information about staff working at the clinic. In this embodiment, staff information 416 is managed by brand. The work shift information 417 is information on work shifts at the clinic. That is, the work shift information 417 is information on the working hours. In the case of this embodiment, the work shift information 417 is managed by brand. The message log 418 is a log of messages exchanged between the clinic and the patient. That is, the message log 418 records messages exchanged between the clinic's account (or account ID) and the patient's account (or account ID) via the message server 30. In the case of this embodiment, the message log 418 is managed by brand.

[0034] <Structure of management data> Figure 3 is a diagram for explaining the data structure of the clinic information 412, the electronic medical record information 413, and the patient information 414. The clinic information 412 shown in Figure 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. The "clinic ID" 412A is an administrative identifier assigned to each clinic. The "clinic name" 412B is the name of the clinic that uses the cloud service. In practice, not only the "clinic name" 412B but also information such as the address and contact information of the clinic is managed.

[0035] The "brand ID" 412C is an identification ID of the clinic. The "account ID" 412D is an identifier for identifying an individual associated with the account. The "account ID" 412D is uniquely assigned within the messaging service. When the messaging app is the LINE app, the LINE ID is stored in the "account ID" 412D. The "API key" 412E is an identifier for 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, at the start of using 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. The "Medical Record ID" 413A is an identifier for the electronic medical record linked to the patient. The "Patient ID" 413B is an identifier for the patient. The "Medical Record 1" 413C, the "Medical Record 2" 413D, and the "Medical Record 3" 413E are medical records. In the case of Fig. 3, each medical record stores the medical treatment date, the attending physician, the attending staff, the consultation content, images, examination results, treatment content, surgical content, 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. The "Patient ID" 414A is an identifier for the patient. The "Name" 414B is the name of the patient. In the case of Fig. 3, examples are Mr. Taro Tokyo, Ms. Hanako Yokohama, and Mr. Jiro Osaka.

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

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

[0040] Figure 4 is a diagram explaining the data structure of reservation information 415, the data structure of staff information 416, and the data structure of work shift information 417. The reservation information 415 shown in Figure 4 includes "Reservation ID" 415A, "Patient ID" 415B, "Reservation Date and Time" 415C, "Desired Treatment / Procedure" 415D, and "Desired Doctor / Staff" 415E.

[0041] "Reservation ID" 415A is an identifier assigned at the time of reservation acceptance. "Patient ID" 415B is an identifier of the patient. "Reservation Date and Time" 415C is the date and time of the reservation. "Desired Treatment / Procedure" 415D is the content of the desired treatment or procedure. This item is used when the content of the treatment or procedure can be reserved. Examples of the content of the treatment include only prescription of medicine, desire for preventive injection, and diagnosis of physical discomfort with fever. Examples of the content of the procedure include treatment of spots and freckles, treatment for removing 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 staff information 416 shown in FIG. 4 includes a "staff ID" 416A, a "name" 416B, an "abbreviation" 416C, an "occupation type" 416D, an "email address" 416E, and "applicable treatments" 416F. The "staff ID" 416A is an identifier for medical staff working at the clinic. The "name" 416B is the name of the medical staff. In the case of FIG. 4, examples include Mr. Saburo Tanaka, Ms. Sakura Nakamura, Ms. Ume Matsumoto, and Ms. Kiku Sato.

[0043] The "abbreviation" 416C is an abbreviation for medical staff within the clinic. For example, the abbreviation for Mr. Saburo Tanaka is "Mr. T". The "occupation type" 416D is information indicating the occupation type of the medical staff. In FIG. 4, examples of the "occupation type" 416D are "doctor", "nurse", and "receptionist". Occupation types not shown include, for example, "counselor", "owner", and "accounting". The "email address" 416E is an email address for communication. When using a messaging app for communication, the account name and account ID are also recorded. The "applicable treatments" 416F is information on treatments that medical staff other than doctors can be in charge of. Treatments include, for example, massage, hair removal, beauty drip, beauty injection, and beauty treatment.

[0044] The work shift information 417 shown in FIG. 4 includes a "staff ID" 417A, and "business days" 417B, 417C, 417D. The "staff ID" 417A is the same as the "staff ID" 416A in the staff information 416. That is, it is an identifier for medical staff working at the clinic. In the case of FIG. 4, “2024 / 3 / 28”, “2024 / 3 / 29”, and “2024 / 4 / 1” are exemplified as business days 417B, 417C, and 417D. In each column of the business days, the time periods when medical staff are present are recorded. For example, the working hours of Mr. “Tanaka Saburo” with “Staff ID” 417A being “500101” on “2024 / 3 / 28” are “8:30 - 19:00”.

[0045] FIG. 5 is a diagram for explaining the data structure of the message log 418. The message log 418 shown in FIG. 5 includes a “timestamp” 418A, a “patient's account name” 418B, a “patient's account ID” 418C, a “content of the received message” 418D, a “content of the sent message” 418E, and a “name etc. of the sending staff” 418F. The “timestamp” 418A is the date and time when the message server 30 (see FIG. 1) receives a message from the patient terminal 10 (see FIG. 1) or the clinic terminal 20 (see FIG. 1).

[0046] The “patient's account name” 418B is information for identifying the patient who exchanges messages with Clinic X. In the case of FIG. 5, the patient's account name is “Gotanda Taro”. As described above, the account name may be different from the patient's “name” 414B (see FIG. 3). The “patient's account ID” 418C is an identifier for identifying the individual associated with the patient's account. The “patient's account ID” 418C is uniquely assigned within the messaging service. When the messaging app is the LINE app, the LINE ID is stored in the “patient's account ID” 418C.

[0047] The “content of the received message” 418D records the content of the message received from the patient. In the case of FIG. 5, “Reserved”, “Hello, doctor”, and “I will visit in the evening. Thank you.” are recorded. Note that the symbol “ / ” means a line break. The content of the message sent, 418E, records the content of the message sent by the medical staff to the patient using the clinic's account name. In the case of Figure 5, "Let's check the current situation / reserve soon" is recorded.

[0048] The name etc. of the staff who sent, 418F, records the name or abbreviation of the staff who posted the message from the medical record screen of the clinic terminal 20. The information of the staff who posted the message is recorded by the staff themselves who posted the message. In the case of Figure 5, it is recorded that the message to "Taro Gotanda" is a post by "Staff T". The staff information recorded in "The name etc. of the staff who sent", 418F, is only displayed on the screen of the clinic terminal 20 (see Figure 1) accessing the electronic medical record server 40 (see Figure 1) (see Figure 13). In other words, the staff information recorded in "The name etc. of the staff who sent", 418F, is not displayed on the screen of the patient terminal 10 (see Figure 1) accessing the message server 30 (see Figure 1) or the clinic terminal 20A that is not logged in to the electronic medical record server 40 (see Figure 14).

[0049] <Staff Information and Work Shift Management Screen> Below, with reference to Figures 6 and 7, an example of the operation screen displayed on the clinic terminal 20 when setting the staff information 416 (see Figure 4) and the work shift information 417 (see Figure 4) will be described. Figure 6 is a diagram for explaining an example of the operation screen 200 used for registering the staff information 416 (see Figure 4). The operation screen 200 shown in Figure 6 is read from the electronic medical record server 40 (see Figure 1) by the operation of the medical staff on the clinic terminal 20 and is displayed on the display of the clinic terminal 20.

[0050] The operation screen 200 shown in Figure 6 is titled "New Registration of Staff". 6 shows the operation screen 200 in a state before staff member information has been entered. Therefore, the "Name input field" 201, "Abbreviation input field" 202, "Occupation input field" 203, "Email address input field" 204, and "Available treatment input field" 205 are all blank. When the “Register” button 206 is operated, the input information is registered in the staff information 416 . When changing or deleting staff information, the medical staff operates the clinic terminal 20 to select the relevant staff member from the staff list, and changes or deletes the information of the selected staff member.

[0051] FIG. 7 is a diagram illustrating an example of the work shift table 300 and the addition window 310. As shown in FIG. The work shift schedule 300 is also read from the electronic medical record server 40 (see FIG. 1) by the medical staff operating the clinic terminal 20, and is displayed on the display of the clinic terminal 20. At the top of the work shift table 300 shown in FIG. 7, a "corresponding month" selection field 301 is arranged, and the display month can be specified. The first row of the work shift schedule 300 shown in Figure 7 is "Business days and business hours" 302, and the first column is "Staff" 303. In the case of Figure 7, the second row displays the shift information for "Mr. T" by business day, and the third row displays the shift information for "Mr. N" by business day.

[0052] The addition window 310 is displayed on the front side of the work shift schedule 300 when adding a shift. The additional window 310 shown in FIG. 7 shows the shift information for "Mr. T." If the button labeled "Discard changes" is operated, the input information such as date and time is discarded without being reflected in work shift information 417 (see FIG. 4), and the addition window 310 is also closed. When the button labeled "Save" is operated, the input information such as date and time is reflected in the work shift information 417, and the addition window 310 is closed. In addition, the newly added work shift is reflected in the display of the work shift schedule 300.

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

[0054] <Initial settings> First, we will explain the initial settings required by the clinic when starting the cloud service. 8 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. 8 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.

[0055] 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 8 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).

[0056] 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 an API key in association with, for example, the account ID of Clinic X (step 106). In the case of the present embodiment, the API key is registered in the clinic information 412 (see FIG. 3).

[0057] Next, the electronic medical record server 40 issues webhook parameters for receiving, from the message server 30, a notification indicating that a message addressed to Clinic X has been received, and notifies the clinic terminal 20 (step 107). The webhook parameters include the account ID of Clinic X and the URL of the electronic medical record server 40. Thereafter, the medical staff sets, through the operation of the clinic terminal 20, the webhook parameters issued by the electronic medical record server 40 in association with the account ID of Clinic X in the message server 30 (step 108). The message server 30 that has received the setting from the clinic terminal 20 registers, in association with the account ID of Clinic X, the webhook parameters issued by the electronic medical record server 40 in the message server 30 (step 109).

[0058] <Settings of the messaging app> Next, the settings required for the patient and the clinic to exchange messages via the messaging app will be described. These settings include a setting that starts when the patient accesses the official account of the medical institution (hereinafter referred to as "Setting 1") and a setting that starts by a push notification from the medical institution side to the patient (hereinafter referred to as "Setting 2").

[0059] <In the case of Setting 1> FIG. 9 is a diagram for explaining an example of a processing sequence of a setting that starts when the patient accesses the official account of the medical institution. In the case of FIG. 9, it is assumed that the patient terminal 10 is the terminal operated by Mr. Taro Tokyo. Also, it is assumed that the clinic terminal 20 is the terminal of Clinic X. In the case of Fig. 9, the patient applies for registration with the account ID of Clinic X through the operation of the patient terminal 10 (step 201). When the messaging app is the LINE app, this application corresponds to a "friend application".

[0060] The message server 30 that has received the application notifies the electronic medical record server 40 of the registration application of Mr. Taro Tokyo addressed to the account ID of Clinic X (step 202). This notification includes Mr. Taro Tokyo's account ID and Clinic X's account ID. This notification is executed through the function of the webhook parameters registered in step 109 (see Fig. 8). Note that this notification is not recorded in the message log 418 (see Fig. 5).

[0061] Next, the message server 30 notifies the patient terminal 10 operated by Mr. Taro Tokyo of the menu screen for Mr. Taro Tokyo registered as a friend of Clinic X (step 203). The menu screen here is called, for example, My Page. Through the menu screen, the patient can set reservations, input consultation forms, send messages, etc. Incidentally, the reservation button on the menu screen embeds the URL (= Uniform Resource Locator) of the reservation site.

[0062] In the case of Fig. 9, Mr. Taro Tokyo sends reservation information for Clinic X from the menu screen (step 204). The destination for sending the reservation information is the reservation site of the electronic medical record server 40. The reservation information includes, for example, the URL of the reservation site, Mr. Taro Tokyo's account ID, the content of the desired treatment or procedure, the date and time when the reservation is desired, name (Taro Tokyo), gender, email address, date of birth, and information on the desired doctor or staff. When the patient who has sent the reservation information is a new patient, the electronic medical record server 40 registers Mr. Taro Tokyo'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).

[0063] <In the case of setting 2> 10 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. 10, 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 10, 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).

[0064] In the case of FIG. 10, 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).

[0065] Upon receiving the registration application, the message server 30 sends Tokyo Taro's application 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).

[0066] <Message log recording> Fig. 11 is a diagram illustrating the message log registration operation when a patient posts a message during a period when the patient's medical record screen is not displayed on the clinic terminal 20. In the case of Fig. 11, 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).

[0067] 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 418 (see FIG. 5) 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).

[0068] <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.

[0069] <Chat screen display> Fig. 12 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. In Fig. 12, parts corresponding to those in Fig. 11 are assigned the same reference numerals. The chat screen here is an example of an area that displays interactions on a messaging app.

[0070] The processing sequence shown in FIG. 12 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.

[0071] Upon receiving the notification, the electronic medical record server 40 reads Tokyo Taro's message log 418 (see FIG. 5) 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 418.

[0072] 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."

[0073] 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."

[0074] (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 (ie, 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".

[0075] (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 part may be saved as one of the items of, for example, patient information 414 (see FIG. 2) or message log 418 (see FIG. 2), or may be saved as independent information linked to an account ID, a patient ID, etc. In this operation, the generation of the title part is executed only once. However, the replacement of the title part is executed each time an instruction to display a chat screen with a specific patient is received from the clinic terminal 20.

[0076] After the process of step 502 described above, the clinic terminal 20 displays a chat screen with Mr. Taro Tokyo on the main pane of the electronic medical record (step 503). FIG. 13 is a diagram for explaining a display example of the medical record screen 500 displayed on the clinic terminal 20. The medical record screen 500 is displayed on the display of the clinic terminal 20.

[0077] The medical record screen 500 shown in FIG. 13 is divided into three panes. In the case of FIG. 13, patient information is displayed in the pane 510 on the left side of the screen. Also, a tab bar is displayed in the pane 520 at the upper part of the screen. Further, a chat screen is displayed in the pane 530 in the center of the screen. In the case of the present embodiment, the display size of each pane can be changed by the medical staff while browsing the medical record screen.

[0078] In the case of FIG. 13, the name of the patient registered in the electronic medical record, the patient ID, and the date of birth are displayed in the pane 510 where the patient information is displayed. Note that the display of the pane 510 shown in FIG. 13 is an example, and in addition, gender, allergy information, special notes, medical examination history, and accounting information are also displayed. The pane 510 is also referred to as a side pane. Also, in relation to the main pane, the pane 510 is also referred to as a sub-pane.

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

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

[0081] Area 531 is a title section that indicates the person with whom you are chatting. In the case of Fig. 13, 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 510).

[0082] Furthermore, pane 530 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 510, 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.

[0083] 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.

[0084] In area 532, the contents of messages recorded in message log 418 (see FIG. 5) are displayed in chronological order. In the case of Figure 13, it is displayed that on the previous day, "3 / 27", a message was sent by "Mr. T", a staff member of Clinic X, saying "It's about time to check the current situation / please make an appointment." Messages posted by staff members of Clinic X are made using official accounts, but in this embodiment, the person at Clinic X who posted each message is displayed on the chat screen. The mechanism for displaying the names of staff members, etc., will be described later.

[0085] Area 533 displays a "Message input field" 533A, a "Sender input field" 533B, and a "Send" button 533C. In the case of FIG. 13, the "Message input field" 533A is blank. The "sender input field" 533B is an example of an input field for a staff member posting a new message. The "sender input field" 533B initially displays the name or abbreviation of the medical staff member who is logged in to the electronic medical record server 40 via the clinic terminal 20. In the case of Figure 13, "Mr. T" is displayed in the "sender input field" 533B.

[0086] When a new message is posted by operating the "Send" button 533C, the medical staff member displayed in the "Sender input field" 533B is recorded in the "Name, etc. of sending staff member" 418F (see Figure 5) of the message log 418 (see Figure 5). However, the staff member posting a new message may not necessarily be the same as the initial value, so a pull-down menu is used in the "sender input field" 533B. When the pull-down menu is opened, a list of names and abbreviations of medical staff registered in staff information 416 (see FIG. 4) is displayed so that they can be selected.

[0087] In this embodiment, if the medical staff displayed in "sender's input field" 533B is changed from the initial value and a message is sent, the display in "sender's input field" 533B remains unchanged even after the message is sent. In other words, even if "send" button 533C is operated, the display in "sender's input field" 533B does not return to the initial value, and the staff information set when the previous message was sent is maintained. Therefore, even when posting multiple messages, medical staff can simply select their own name, etc. when sending the first message, and avoid having to enter sender information when sending subsequent messages.

[0088] Figure 14 shows 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 Figure 1). In Figure 14, parts corresponding to those in Figure 13 are assigned the same reference numerals. The chat screen shown in FIG. 14 is assumed to be a smartphone 20A used with a Clinic X account. The chat screen shown in Fig. 14 is displayed simultaneously with the medical record screen shown in Fig. 13. Therefore, the display content of the chat screen shown in Fig. 14 is the same as the display content of the chat screen shown in Fig. 13.

[0089] Incidentally, the chat screen shown in FIG. 14 is displayed not as a medical record screen but as a messaging app screen. 14, 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 the display of the chat screen shown in FIG. 14. In other words, this is because the electronic medical record server 40 does not intervene in the process of notifying messages for the display of the chat screen shown in FIG. 14.

[0090] In the case of the medical record screen that does not use the technology described in this embodiment, the same screen as the chat screen shown in FIG. 14 is displayed on the medical record screen. That is, only the account name is displayed in the title section of the chat screen. The electronic medical record server 40 is not involved in the display of the chat screen shown in FIG. 14. For this reason, the name of the staff who posted the message is not displayed beside the message "It's about time to check the current situation / Please make a reservation" posted using the official account of Clinic X. Incidentally, in the case of the patient terminal 10 (see FIG. 1), "Clinic X" is displayed in the title section of the chat screen in the messaging app. This is because the electronic medical record server 40 is not involved in the display of messages on the patient terminal 10 either.

[0091] FIG. 15 is a diagram for explaining the processing sequence when message transmission and reception are executed while the patient's medical record screen is being displayed on the clinic terminal 20. In FIG. 15, the corresponding reference numerals to those in FIG. 12 are shown. Incidentally, steps 601 to 605 are the processing sequence when a message addressed to Clinic X is sent from the patient terminal 10. On the other hand, steps 701 to 706 are the processing sequence when a message addressed to Mr. Taro Tokyo is sent from the clinic terminal 20.

[0092] First, steps 601 to 605 will be described. Mr. Taro Tokyo operates the messaging app on the patient terminal 10 and sends a message A addressed to Clinic X (step 601). This message A is sent to the message server 30. The message A includes Mr. Taro Tokyo's account ID, Clinic X's account ID, and the content of the message A. Upon receiving the message A, the message server 30 notifies the clinic terminal 20 of Clinic X that a message A from Mr. Taro Tokyo has been received, according to the account ID indicating the destination (step 602). When this notification is opened in the messaging app on the smartphone 20A (see Fig. 14), the chat screen shown in Fig. 14 is displayed.

[0093] In the case of Fig. 15, the message server 30 notifies the electronic medical record server 40 of the reception of the message A from Mr. Taro Tokyo addressed to Clinic X and the content of the message A (step 603). This notification is executed as a function of the webhook parameter. The electronic medical record server 40 that has received the notification from the message server 30 registers the message A in the message log 418 of Clinic X (see Fig. 5) (step 604). Subsequently, the electronic medical record server 40 reflects the message A on Mr. Taro Tokyo's chat screen (step 605).

[0094] Next, steps 701 to 706 will be described. Here, it is assumed that the chat screen with Mr. Taro Tokyo is displayed on the pane 530 of the medical record screen (see Fig. 13). Specifically, the chat screen described in Fig. 13 is displayed. In this state, the electronic medical record server 40 receives, through communication with the clinic terminal 20, the information of the staff who sends the message B (step 701). Fig. 16 is a diagram for explaining the processing operation executed in step 701. First, the electronic medical record server 40 determines whether there is a history of message posting after the last login (step 7011). Note that the history of message posting may be unrelated to the patient corresponding to the medical record screen being viewed.

[0095] If there is a history of message posting, an affirmative result is obtained in step 7011. In this case, the electronic medical record server 40 displays the staff member recorded at the end of the message log in the sender input field (step 7012). This is because the same staff member is likely to post a message subsequently. On the other hand, if there is no history of message posting, a negative result is obtained in step 7011. In this case, the electronic medical record server 40 reads the staff member logged in to the electronic medical record from the login log (not shown) and displays it in the sender input field (step 7013). This is because the logged-in staff member is likely to make a post.

[0096] After executing step 7012 or 7013, the electronic medical record server 40 determines whether it has received a change operation for the sending staff (step 7014). Specifically, it is determined whether an operation to open the pull-down menu of the "sender input field" 533B has been received. If it is not a change operation for the sending staff, a negative result is obtained in step 7014. In this case, the electronic medical record server 40 ends the processing operation of step 701.

[0097] On the other hand, if it is a change operation for the sending staff, an affirmative result is obtained in step 7014. In this case, the electronic medical record server 40 extracts the staff members who are on duty at the current date and time based on the staff information 416 (see FIG. 4) and the work shift information 417 (see FIG. 4) (step 7015). Next, the electronic medical record server 40 displays the names etc. of the staff members with a work shift at the current time at the top of the pull-down menu (step 7016). The staff members with a work shift at the current time are an example of the staff members who are scheduled to be on duty at the time of the selection operation.

[0098] FIG. 17 is a diagram for explaining a display example of the medical record screen 500 with the pull-down menu of the "sender input field" 533B opened. In FIG. 17, the parts corresponding to those in FIG. 13 are denoted by corresponding reference numerals. In the case of FIG. 17, the initial value of the "sender input field" 533B is "Mr. T". The display area of the pull-down menu shown in FIG. 17 is divided into three sections. The one displayed at the top among the three sections is "with work shift". In the case of FIG. 17, three names, "Mr. T", "Mr. N", and "Mr. S", are displayed by abbreviations.

[0099] The one displayed second from the top among the three sections is "without work shift". In the case of FIG. 17, one name, "Mr. M", is displayed by an abbreviation. Thus, in FIG. 17, the staff without a work shift is displayed lower than the staff with a work shift. In other words, the staff with a work shift is displayed higher than the staff without a work shift. This display mode corresponds to displaying the staff with a work shift in a mode with a higher priority than the staff without a work shift. Since the display area of the staff with a work shift is distinguished from the display area of the staff without a work shift, the staff who is the sender of the message can be easily found.

[0100] The one displayed at the bottom among the three sections is "all staff". In the case of FIG. 17, four names, "Mr. T", "Mr. N", "Mr. M", and "Mr. S", are displayed by abbreviations. Basically, the staff is classified into either "with a work shift" or "without a work shift", but the pull-down menu shown in FIG. 17 adopts a display mode that allows selection from all the staff members. Note that it may also be set to display the pull-down menu in two sections of "with a work shift" and "without a work shift".

[0101] Return to the description of FIG. 16. Following step 7016, the electronic medical record server 40 receives a selection of the staff member who will be the sender (step 7017). Next, the electronic medical record server 40 sets the selected staff member as the sender (step 7018). FIG. 18 is a diagram for explaining a display example of the medical record screen 500 in a state where the sender is set in the “sender input field” 533B. In FIG. 18, the corresponding parts to those in FIG. 13 are denoted by the same reference numerals.

[0102] In the chat screen shown in FIG. 18, it is assumed that “Mr. N” is selected in the pull-down menu shown in FIG. 17. Therefore, “Mr. N” is displayed in the “sender input field” 533B. Also, “Don't forget your insurance card” is input in the “message input field” 533A.

[0103] Return to the description of FIG. 15. When the process of step 701 shown in FIG. 15 ends, the clinic terminal 20 sends a message B addressed to Mr. Taro Tokyo from the chat screen of the electronic medical record (step 702). This transmission corresponds to the case where the “send” button 533C (see FIG. 18) is operated with “Don't forget your insurance card” input in the message input field 533A (see FIG. 18).

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

[0105] Note that the electronic medical record server 40 sends message B to the message server 30 and registers message B in the message log 418 of Clinic X (see Fig. 5) (step 705). In addition, the electronic medical record server 40 reflects message B on the chat screen with Mr. Taro Tokyo (step 706).

[0106] FIG. 19 is a diagram for explaining a chat screen on which a message posted by staff member N is reflected. In FIG. 19, corresponding reference numerals to those in FIG. 18 are shown. In FIG. 19, a message "Don't forget your insurance card" is added to the last line of area 532, and "Mr. N" and "12:15" are displayed beside it. Therefore, it can be seen that the sender of the latest message from the staff to Mr. Taro Gotanda with the account name is "Mr. N". It can also be seen that the staff member who sent a message to Mr. Taro Gotanda with the account name the day before was "Mr. T". In the case of FIG. 19, since it is the last staff member who operated the clinic terminal 20 to send a message, "Mr. N" is displayed in the "sender input field" 533B.

[0107] <Parentheses> As described above, the electronic medical record server 40 in the present embodiment is a server that provides the patient's medical record screen on the display of the clinic terminal 20 as a cloud service. When this electronic medical record server 40 displays a chat screen with a specific patient as part of the medical record screen, even for a message sent using the official account of Clinic X, each staff member who sent the message can be displayed on the medical record screen in an identifiable manner.

[0108] Therefore, compared with the case where the staff who posted a message using the official account of Clinic X cannot be confirmed on the chat screen, it becomes easier to grasp the interaction with patients in the medical field. In addition, the electronic medical record server 40 in the present embodiment displays a "sender input field" 533B on the chat screen of the medical record screen, and records the staff who sent a message using the official account in association with the sent message. Specifically, information on the staff who sent the message is recorded in the message log 418 (see FIG. 5) managed by the electronic medical record server 40. By this recording, it becomes possible to display on the chat screen shown on the medical record screen who posted the message of Clinic X.

[0109] In addition, the electronic medical record server 40 in the present embodiment displays, as an initial value, the name of the staff who last logged in to the corresponding electronic medical record or the name of the staff who sent a message the previous time in the "sender input field" 533B. When the staff who sends the message is the same as the staff displayed as the initial value, the input operation of the sender required at the time of sending the message can be reduced. In addition, even when the initial value displayed in the "sender input field" 533B is different from the staff who sends the message, the electronic medical record server 40 in the present embodiment enables the selection of staff in a pull-down menu format. Therefore, the operation burden is reduced compared to the case of manually entering the staff.

[0110] In addition, the electronic medical record server 40 in the present embodiment displays the staff who has a scheduled attendance at the time of sending the message above the staff who does not have a scheduled attendance at the same time. Since it is expected that the staff who sends the message to the patient is the one who is on duty, by facilitating identification on the pull-down menu, it becomes possible to efficiently select the staff who sends the message. In addition, in the case of the present embodiment, the title section of the chat screen is displayed including the account name of a specific patient and the name of the patient.

[0111] Therefore, the medical staff viewing the medical record screen can easily confirm the patient's name while keeping an eye on the chat screen. In addition, the display size of the title section of the chat screen 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. For this reason, the medical staff can confirm the patient's name in a font larger than that in the side pane. As a result, the distinctiveness of the patient's name is enhanced. Note that the display of the title section including the patient's account name and the patient's name described in this embodiment is provided only on the medical record screen provided as a cloud service.

[0112] <Other Embodiments> (1) As described above, the embodiments of the present invention have been described. However, the technical scope of the present invention is not limited to the scope described in the above-described embodiments. It is obvious from the description of the claims that various modifications or improvements added to the above-described embodiments are also included in the technical scope of the present invention.

[0113] (2) The electronic medical record described in the above-described embodiment may be provided to a clinic terminal as an on-premises type service. That is, as one of the functions of a program executed by a server installed in a medical institution, the display of the above-described medical record screen may be realized. Also, the electronic medical record described in the above-described embodiment may be displayed as a function of a program operating on a clinic terminal. That is, as one of the functions of a stand-alone type program, the display of the above-described medical record screen may be realized.

[0114] (3) In the case of the above-described embodiment, when posting a message from the medical record screen of the clinic terminal 20 (see FIG. 1), information of the staff sending the message can be selected from a pull-down menu. However, a method of text-inputting the name of the staff etc. to the "sender input field" 533B (see FIG. 13) may be adopted.

[0115] (4) In the above-described embodiment, the first step 7011 (see FIG. 16) of step 701 (see FIG. 15) determines whether there is a history of message posting since the last login. However, filtering may be performed by the patient to whom the message is to be sent. In cases where a fixed number of staff members exchange messages with each patient, filtering by patient makes it possible to display from the beginning in the "sender input field" 533B (see FIG. 13) the staff member who is likely to send a message. As a result, the number of times changes need to be made to the "sender input field" 533B can be reduced.

[0116] (5) In the above-described embodiment, in step 7015 (see FIG. 16), the staff who are working at the current date and time are extracted by referring to the work shift information 417 (see FIG. 4). However, for example, it is also possible to link with an attendance management system (not shown) at Clinic X via the clinic terminal 20. If staff arrival and departure times can be obtained from the attendance management system, staff who are currently working according to the work shift but have no record of arrival time can be displayed as "no work shift" rather than "on work shift." Also, staff who are currently clocked out according to the work shift but have no record of clocking out can be displayed as "on work shift" rather than "no work shift." In this way, by using attendance information, it is possible to display staff members that reflect their actual working status.

[0117] (6) In the above-described embodiment, in step 7016 (see FIG. 16), the names of staff members who have work shifts at the current time are displayed at the top of the pull-down menu. However, the names of staff members who have work shifts at the current time may be displayed in a more eye-catching color or brightness than staff members who do not have work shifts. By changing the color or brightness, it becomes easier to distinguish between staff members who have work shifts and staff members who do not have work shifts. Displaying in an eye-catching color or brightness is an example of a high-priority mode.

[0118] <Summary> The embodiments include the following information providing method, information providing system, and program. (((1))) One of the purposes of the present invention is to make it easier to understand interactions with patients in medical settings, compared to when the poster of a message using the official account of a medical institution is unknown. The information provision method according to 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, through the medical record screen relating to a specific patient, a display of interactions with a specific patient via a messaging app using the medical institution's official account, and a process of identifiably displaying on the medical record screen the staff of the medical institution who posted each message linked to the medical institution's official account. This information provision method makes it easier to understand interactions with patients in the medical field compared to when the poster of a message using the medical institution's official account is unknown.

[0119] (((2))) One of the objects of the present invention is to be able to record new messages in association with staff members who post them. The information provision method described in (((1))) displays an input field for a new message and an input field for a staff member posting a new message in the area displaying interactions in the messaging app. According to this information providing method, it is possible to record a new message in association with the staff member who posts it.

[0120] (((3))) One of the purposes of the present invention is to reduce the burden of record-keeping on contributors. The information providing method described in (((2)))), wherein a list of staff members is displayed in a selectable manner in the staff member input field. This information providing method reduces the burden on contributors of recording.

[0121] (((4))) One of the objects of the present invention is to facilitate the selection of staff who are likely to be recording targets. The information providing method described in (((3))), in which staff who are scheduled to arrive at work at the time of the selection operation are displayed in the staff input field. According to this information providing method, the selection of staff who are likely to be recording targets can be facilitated.

[0122] (((5))) One of the objects of the present invention is to facilitate the selection of staff who are likely to be recording targets. The information providing method described in (((3))), in which staff who are scheduled to arrive at work at the time of the selection operation are displayed in the staff input field in a manner with higher priority than staff who are not scheduled to arrive at work at the time of the selection operation. According to this information providing method, the selection of staff who are likely to be recording targets can be facilitated.

[0123] (((6))) One of the objects of the present invention is to improve the efficiency of the input work of staff who are likely to be recording targets. The information providing method described in (((2))), in which staff who have posted the latest message linked to the official account of the medical institution are displayed as the initial value in the staff input field. According to this information providing method, staff who have posted a new message can be efficiently input.

[0124] (((7))) One of the objects of the present invention is to facilitate the grasping of the interaction with patients in the medical field as compared with the case where the poster of the message using the official account of the medical institution is unknown. The information providing system in the embodiment has one or more processors and is an information providing system that provides a patient's medical record screen to a client terminal as a cloud service. The one or more processors receive a display of an interaction through a messaging app with a specific patient using the official account of a medical institution through the medical record screen regarding the specific patient, and display staff members of the medical institution who have posted each message linked to the official account of the medical institution in an identifiable manner on the medical record screen. According to this information providing system, compared to the case where the poster of a message using the official account of a medical institution is unknown, it is possible to easily grasp the interaction with patients in the medical field.

[0125] (((8))) One of the objects of the present invention is to facilitate the grasping of the interaction with patients in the medical field compared to the case where the poster of a message using the official account of a medical institution is unknown. The program in the embodiment causes a computer that provides a patient's medical record screen to a client terminal as a cloud service to realize a function of receiving a display of an interaction through a messaging app with a specific patient using the official account of a medical institution through the medical record screen regarding the specific patient, and a function of displaying staff members of the medical institution who have posted each message linked to the official account of the medical institution in an identifiable manner on the medical record screen. According to this program, compared to the case where the poster of a message using the official account of a medical institution is unknown, it is possible to easily grasp the interaction with patients in the medical field.

Explanation of Reference Numerals

[0126] 1... Information providing 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 medical record screen of a patient to a client terminal as a cloud service, comprising: receiving a display of an interaction through a messaging app with a specific patient using an official account of a medical institution through the medical record screen regarding the specific patient; displaying, in an area for displaying the interaction of the messaging app on the medical record screen, in an identifiable manner, staff members of the medical institution who posted each message linked to the official account of the medical institution, based on a message log of the medical institution managed by the cloud service; An information providing method having the above.

2. The information providing method according to claim 1, wherein an input field for a new message and an input field for a staff member who posts a new message are displayed in an area for displaying the interaction of the messaging app.

3. The information providing method according to claim 2, wherein a list of staff members is displayed in a selectable manner in the input field for the staff member.

4. The information providing method according to claim 3, wherein staff members who are scheduled to be on duty at the time of the selection operation are displayed in the input field for the staff member.

5. The information providing method according to claim 3, wherein staff members who are scheduled to be on duty at the time of the selection operation are displayed in a manner with higher priority than staff members who are not scheduled to be on duty at the time of the selection operation in the input field for the staff member.

6. The information providing method according to claim 2, wherein the staff member who posted the latest message linked to the official account of the medical institution is displayed as an initial value in the input field for the staff member.

7. An information providing system having one or more processors for providing a medical record screen of a patient to a client terminal as a cloud service, wherein the one or more processors receive a display of an interaction through a messaging app with a specific patient using an official account of a medical institution through the medical record screen regarding the specific patient; display, in an area for displaying the interaction of the messaging app on the medical record screen, in an identifiable manner, staff members of the medical institution who posted each message linked to the official account of the medical institution, based on a message log of the medical institution managed by the cloud service; An information providing system.

22. On a computer that provides a medical record screen of a patient to a client terminal as a cloud service A function to receive a display of interactions through a messaging app with a specific patient using the official account of a medical institution through the medical record screen for the specific patient, and A function to visibly display, in an area for displaying the interactions of the messaging app on the medical record screen, the staff of the medical institution who posted each message linked to the official account of the medical institution, based on the message log of the medical institution managed by the cloud service; and A program for realizing the above.

Images