Method for providing information, information provision system, and program

Abstract

To make understanding of interactions with patients in a medical setting simpler, as compared with a case where who posted a message using an official account of a medical institution is unknown.SOLUTION: A method for providing information for providing, as a cloud service, a medical record screen of a patient to a client terminal includes the processing of: accepting display of interactions through a messaging application with the specific patient using the official account of a medical institution via a medical record screen relating to a specific patient; and displaying a staff member of the medical institution who has posted a message associated with the official account of the medical institution on the medical record screen in an identifiable manner.SELECTED DRAWING: Figure 13

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 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 for a specific patient, a display of interactions with the 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. 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 described in claim 7 is an information provision system having one or more processors that provides patient medical record screens to client terminals as a cloud service, wherein the one or more processors accept, through the medical record screen for a specific patient, a display of interactions with the specific patient via a messaging app using the medical institution's official account, and identifiably display on the medical record screen the staff of the medical institution who posted each message linked to the medical institution's official account. The invention described in claim 8 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 a function of accepting, through the medical record screen for a specific patient, a display of interactions with the specific patient via a messaging app using the medical institution's official account, and a function 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. [Effects of the Invention]

[0007] According to the present invention, it is easier to understand interactions with patients in medical settings than when the poster of a message using the official account of a medical institution is unknown. [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, the data structure of staff information, and the data structure of work shift information. [Figure 5] FIG. 2 is a diagram illustrating the data structure of a message log. [Figure 6] FIG. 10 is a diagram illustrating an example of an operation screen used to register staff information. [Figure 7] 10A and 10B are diagrams illustrating an example of a work shift schedule and an addition window. [Figure 8] FIG. 10 is a diagram illustrating an example of a processing sequence at the time of initial setting. [Figure 9] 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 10] 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 11] 10 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. FIG. [Figure 12] 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 13] FIG. 10 is a diagram illustrating an example of a medical record screen displayed on a clinic terminal. [Figure 14] This is an example of the display when displaying a chat screen using a clinic account from a terminal that is not logged in to the electronic medical record server. [Figure 15] 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. [Figure 16] FIG. 16 is a diagram illustrating the processing operation executed in step 701 of FIG. [Figure 17] FIG. 10 is a diagram illustrating an example of the display of the medical record screen with the pull-down menu for the "sender input field" opened. [Figure 18] FIG. 10 is a diagram illustrating an example of a display of a medical record screen with a sender set in the "sender input field." [Figure 19] FIG. 10 is a diagram illustrating a chat screen on which a message posted by staff member N is reflected. 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 to exchange 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. FIG. 1 illustrates medical staff members T, N, M, and S who operate the clinic terminal 20.

[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, staff information by brand 416, work shift information by brand 417, and message log by brand 418. In the following, clinic information 412, electronic medical record information by brand 413, patient information by brand 414, appointment information by brand 415, staff information by brand 416, work shift information by brand 417, and message log by brand 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. Work shift information 417 is information about work shifts at a knic. In other words, work shift information 417 is information about working hours. In this embodiment, work shift information 417 is managed by brand. The message log 418 is a log of messages exchanged between a clinic and a patient. That is, the message log 418 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 418 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 reservation information 415, the data structure of staff information 416, and the data structure of work shift information 417. 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] Staff information 416 shown in FIG. 4 includes a "staff ID" 416A, a "name" 416B, an "abbreviation" 416C, a "job type" 416D, an "email address" 416E, and an "available treatment" 416F. "Staff ID" 416A is an identifier for medical staff working at the clinic. "Name" 416B is the name of the medical staff. In the case of FIG. 4, "Tanaka Saburo", "Nakamura Sakura", "Matsumoto Ume", and "Sato Kiku" are shown as examples.

[0043] "Abbreviation" 416C is the abbreviation of the medical staff in the clinic. For example, the abbreviation of "Tanaka Saburo" is "Mr. T." "Occupation" 416D is information indicating the occupation of the medical staff. In Fig. 4, "occupation" 416D is exemplified by "doctor," "nurse," and "receptionist." Occupations not shown include, for example, "counselor," "owner," and "accountant." "Email address" 416E is an email address for contact. If a messaging app is used for contact, the account name and account ID are also recorded. "Available treatments" 416F is information on treatments that can be performed by medical staff other than doctors. Treatments include, for example, massage, hair removal, cosmetic infusion, cosmetic injection, and skin care treatment.

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

[0045] FIG. 5 is a diagram illustrating the data structure of the message log 418. As shown in FIG. The message log 418 shown in Figure 5 includes a "timestamp" 418A, a "patient account name" 418B, a "patient account ID" 418C, "content of received message" 418D, "content of sent message" 418E, and "name of staff member who sent message, etc." 418F. "Time stamp" 418A 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).

[0046] "Patient account name" 418B is information that identifies the patient exchanging messages with Clinic X. In the case of Figure 5, 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" 418C is an identifier that identifies an individual linked to a patient account. "Patient account ID" 418C is uniquely assigned within the messaging service. If the messaging app is the LINE app, the LINE ID is stored in "Patient account ID" 418C.

[0047] The content of the message received from the patient is recorded in "Received message content" 418D. In the case of Figure 5, "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 the message sent by the medical staff to the patient using the clinic's account name is recorded in "Message sent" 418E. In the case of Figure 5, "Let's check the current situation soon / Make an appointment" is recorded.

[0048] The "Name, etc. of the staff member who sent the message" 418F records the name or abbreviation of the staff member who posted the message from the medical record screen of the clinic terminal 20. The information about the staff member who posted the message is recorded by the staff member who posted the message. In the case of Figure 5, it is recorded that the message to "Gotanda Taro" was posted by "Mr. T." The staff member information recorded in "Name of the staff member who sent the message, etc." 418F is displayed only on the screen of the clinic terminal 20 (see Figure 1) that is accessing the electronic medical record server 40 (see Figure 1) (see Figure 13). In other words, the staff member information recorded in "Name of the staff member who sent the message, etc." 418F is not displayed on the screen of the patient terminal 10 (see Figure 1) that is 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 FIGS. 6 and 7, an example of an operation screen displayed on the clinic terminal 20 when setting staff information 416 (see FIG. 4) and work shift information 417 (see FIG. 4) will be described. FIG. 6 is a diagram illustrating an example of the operation screen 200 used to register the staff information 416 (see FIG. 4). The operation screen 200 shown in FIG. 6 is read from the electronic medical record server 40 (see FIG. 1) by a medical staff member operating the clinic terminal 20, and is displayed on the display of the clinic terminal 20.

[0050] The operation screen 200 shown in FIG. 6 is titled "New Staff Registration." 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 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).

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

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

[0059] <In the case of setting 1> 9 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 FIG. 9, 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. 9, 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."

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

[0062] In the case of Figure 9, 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).

[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 section may be saved as one of the items in the patient information 414 (see FIG. 2) or the message log 418 (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.

[0076] 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. 13 is a diagram illustrating an example of a medical record screen 500 displayed on the clinic terminal 20. As shown in FIG. 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 Fig. 13, patient information is displayed in pane 510 on the left side of the screen. A tab bar is displayed in pane 520 at the top of the screen. A chat screen is displayed in pane 530 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.

[0078] In the case of FIG. 13, the pane 510 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 pane 510 shown in FIG. 13 is an example, and other information such as gender, allergy information, special notes, medical history, and billing information may also be displayed. The pane 510 is also called a side pane. In addition, in relation to the main pane, the pane 510 is also called 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 displaying the chat screen shown in Fig. 14. 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. 14.

[0090] 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. 14 is displayed on the medical record screen. In other words, 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 Figure 14. For this reason, the name of the staff member who posted the message, "Let's check the current situation soon / Make an appointment," which was posted using the official account of Clinic X, is not displayed next to it. 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.

[0091] FIG. 15 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. 15, the same reference numerals as in FIG. 12 are used. 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 706 are a processing sequence when a message addressed to Tokyo Taro is sent from the clinic terminal 20.

[0092] 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, according to the account ID indicating the destination (step 602). When this notification is opened in the messaging app on smartphone 20A (see FIG. 14), the chat screen shown in FIG. 14 is displayed.

[0093] In the case of Figure 15, 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 418 (see FIG. 5) of the clinic X (step 604). Next, the electronic medical record server 40 reflects the message A on Tokyo Taro's chat screen (step 605).

[0094] Next, steps 701 to 706 will be described. Here, it is assumed that a chat screen with Tokyo Taro is displayed in pane 530 (see FIG. 13) of the medical record screen. Specifically, the chat screen described in FIG. 13 is displayed. In this state, the electronic medical record server 40 receives information about the staff member who will send message B through communication with the clinic terminal 20 (step 701). FIG. 16 is a diagram illustrating the processing operations executed in step 701. First, the electronic medical record server 40 determines whether or not 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 currently being viewed.

[0095] If there is a history of message posting, a positive 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 there is a high possibility that the same staff member will continue to post messages. 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 out the staff member currently logged in to the electronic medical record from the login log (not shown) and displays the name in the sender's input field (step 7013). This is because there is a high possibility that the message was posted by the logged-in staff member.

[0096] After executing step 7012 or 7013, the electronic medical record server 40 determines whether or not an operation to change the sending staff member has been accepted (step 7014). Specifically, it determines whether or not an operation to open the pull-down menu of the "sender input field" 533B has been accepted. If the operation is not a change of 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 the operation is to change the sending staff, a positive result is obtained in step 7014. In this case, the electronic medical record server 40 extracts the staff who are working 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 of staff members who are on shift at the current time at the top of the pull-down menu (step 7016). Staff members who are on shift at the current time are an example of staff members who are scheduled to come to work at the time of the selection operation.

[0098] 17 is a diagram illustrating a display example of the medical record screen 500 when the pull-down menu of the "sender input field" 533B is opened. In FIG. 17, parts corresponding to those in FIG. 13 are assigned the same 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. Of the three categories, the one displayed at the top is "Work Shifts Available." In the case of Figure 17, three people, "Mr. T," "Mr. N," and "Mr. S," are displayed using their abbreviations.

[0099] Of the three categories, the second from the top is "No work shifts." In the example of Figure 17, one person, "Ms. M," is displayed by an abbreviation. In this way, in Figure 17, staff members with "no work shifts" are displayed lower than staff members with "work shifts." In other words, staff members with "work shifts" are displayed higher than staff members with "no work shifts." This display mode corresponds to displaying staff with "working shifts" in a mode in which they have a higher priority than staff with "no working shifts." The display area for staff who are "on shift" is distinguished from the display area for staff who are "off shift," so that the staff member who is the sender of the message can be easily found.

[0100] Of the three categories, the one displayed at the bottom is "All Staff." In the case of Figure 17, four people, "Mr. T," "Mr. N," "Mr. M," and "Mr. S," are displayed using their abbreviations. Staff are basically classified as either "working shifts" or "no staff on duty," but the pull-down menu shown in FIG. 17 employs a display format that allows selection from among all staff. Alternatively, the pull-down menu may be set to display two categories: "work shifts" and "no work shifts."

[0101] Returning to the explanation of FIG. Following step 7016, the electronic medical record server 40 accepts the 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 illustrating a display example of the medical record screen 500 in a state where a sender is set in the "sender input field" 533B. In Fig. 18, parts corresponding to those in Fig. 13 are assigned the same reference numerals.

[0102] The chat screen shown in Fig. 18 assumes that "Mr. N" has been selected in the pull-down menu shown in Fig. 17. Therefore, "Mr. N" is displayed in "sender input field" 533B. Additionally, "Don't forget your health insurance card" is entered in the "Message entry field" 533A.

[0103] Returning to the explanation of FIG. When the process of step 701 shown in FIG. 15 is completed, the clinic terminal 20 sends a message B addressed to Tokyo Taro from the chat screen of the electronic medical record (step 702). This transmission corresponds to the case where "Don't forget to bring your health insurance card" is entered in message input field 533A (see FIG. 18) and operation of "Send" button 533C (see FIG. 18) is accepted.

[0104] 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 703). 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 704). When Tokyo Taro opens this notification in the messaging app on his smartphone, message B is displayed on the chat screen.

[0105] The electronic medical record server 40 sends message B to the message server 30 and also registers message B in the message log 418 of clinic X (see FIG. 5) (step 705). Furthermore, the electronic medical record server 40 reflects message B on the chat screen with Tokyo Taro (step 706).

[0106] 19 is a diagram illustrating a chat screen that reflects a message posted by staff member N. In FIG. 19, the same reference numerals as in FIG. 18 are used. In Figure 19, the message "Don't forget your health insurance card" has been added to the last line of area 532, with "N-san" and "12:15" displayed next to it. This shows that the sender of the latest staff member message to the account named "Gotanda Taro" is "N-san." It has also been revealed that the staff member who sent a message to the account named "Gotanda Taro" the previous day was "Mr. T." In the case of FIG. 19, since the staff member was the last to operate the clinic terminal 20 to send a message, "Mr. N" is displayed in the "sender input field" 533B.

[0107] <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 this electronic medical record server 40 displays a chat screen with a specific patient as part of the medical record screen, it can display the staff member who sent each message on the medical record screen in an identifiable manner, even if the message was sent using Clinic X's official account.

[0108] This makes it easier to understand interactions with patients in the medical field compared to when it is not possible to check on the chat screen which staff member posted a message using Clinic X's official account. Furthermore, the electronic medical record server 40 in this embodiment displays a "sender input field" 533B on the chat screen of the medical record screen, and records the staff member who sent the message using the official account in association with the sent message. Specifically, information about the staff member who sent the message is recorded in the message log 418 (see FIG. 5) managed by the electronic medical record server 40. This record makes it possible to display on the chat screen displayed on the medical record screen who at Clinic X posted the message.

[0109] Furthermore, the electronic medical record server 40 in this embodiment displays, as an initial value, in the "sender input field" 533B, the name of the staff member who last logged in to the corresponding electronic medical record or the name of the staff member who sent the message immediately before. If the staff member who sends the message is the same as the staff member displayed as the initial value, the input operation by the sender required when sending a message can be reduced. Furthermore, in the electronic medical record server 40 of this embodiment, even if the initial value displayed in the "sender input field" 533B is different from the staff member who will send the message, the staff member can be selected using a pull-down menu. This reduces the operational burden compared to manually entering the staff member.

[0110] Furthermore, the electronic medical record server 40 in this embodiment displays staff who are scheduled to be at work at the time the message is sent higher than staff who are not scheduled to be at work at the same time. Since it is expected that the staff who will send the message to the patient will be the staff who are at work, making it easy to identify them on the pull-down menu makes it possible to efficiently select the staff member to send the message to. In addition, in this embodiment, the account name and name of a specific patient are displayed in the title section of the chat screen.

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

[0112] <Other embodiments> (1) Although the embodiments of the present invention have been described above, the technical scope of the present invention is not limited to the scope of the above-described embodiments. It is clear from the claims that various modifications and improvements 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 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.

[0114] (3) In the above-described embodiment, when posting a message from the medical record screen of the clinic terminal 20 (see FIG. 1), the information of the staff member who will send the message can be selected from a pull-down menu. However, a method of entering the name of the staff member, etc., as text in the "sender input field" 533B (see FIG. 13) may also 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 aims of the present invention is to facilitate the selection of staff who are likely to be recorded. In the information providing method described in (((3))), the staff member who is scheduled to be at work at the time of the selection operation is displayed in the staff member input field. This information provision method makes it easy to select staff who are likely to be recorded.

[0122] (((5))) One of the aims of the present invention is to facilitate the selection of staff who are likely to be recorded. The information provision method described in (((3)))), in which staff who are scheduled to work at the time of the selection operation are displayed in the staff input field with a higher priority than staff who are not scheduled to work at the time of the selection operation. This information provision method makes it easy to select staff who are likely to be recorded.

[0123] (((6))) One of the objects of the present invention is to improve the efficiency of input work by staff who are likely to be recorded. The information provision method described in (((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. According to this information providing method, the staff member who posted the new message can be efficiently entered.

[0124] (((7))) 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 system in one 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, through the medical record screen for a specific patient, displays interactions with a specific patient via a messaging app using the medical institution's official account, and displays the medical institution staff who posted each message linked to the medical institution's official account in an identifiable manner on the medical record screen. This information provision system makes it easier to understand interactions with patients in medical settings compared to when the sender of a message using the medical institution's official account is unknown.

[0125] (((8))) 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 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, through the medical record screen for a specific patient, the display of interactions with a specific patient via a messaging app using the medical institution's official account; and clearly display on the medical record screen the staff of the medical institution who posted each message linked to the medical institution's official account. This program makes it easier to understand interactions with patients in medical settings compared to when the sender of messages using the medical institution's official account is unknown. [Explanation of symbols]

[0126] 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: A process of accepting, through the medical record screen relating to a specific patient, a display of an exchange with the specific patient via a messaging app using an official account of a medical institution; a process of identifiably 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; An information provision method having the above.

2. The information providing method according to claim 1 , further comprising displaying an input field for a new message and an input field for a staff member posting a new message in the area displaying the exchanges in the messaging app.

3. The information providing method according to claim 2 , wherein a list of staff members is displayed in the staff member input field so that the staff member can be selected.

4. The information providing method according to claim 3 , wherein the staff member input field displays staff members who are scheduled to be at work at the time of the selection operation.

5. The information providing method according to claim 3, wherein the staff member input field displays staff members who are scheduled to be at work at the time of the selection operation in a manner that gives them a higher priority than staff members who are not scheduled to be at work at the time of the selection operation.

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 staff member input field.

7. 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: Through the medical record screen for a specific patient, a display of an exchange with the specific patient via a messaging app using an official account of a medical institution is accepted; and 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 in an identifiable manner. Information provision system.

8. A computer that provides patient chart screens to client terminals as a cloud service. A function of accepting, through the medical record screen relating to a specific patient, a display of an exchange with the specific patient via a messaging app using an official account of the medical institution; a function of identifiably 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; A program to achieve this.

Images