KR20240068561A - System and method for providing hospital customer relationship management - Google Patents

Abstract

A method and apparatus for transmitting CRM content from a medical institution client side assigned to a hospital or doctor are provided. CRM transmission is performed when CRM content to be sent is selected from the medical institution client side and input of identification information of a recipient who will receive the CRM content is received. Regardless of whether you sign up as a member or install a service application, CRM is sent by a means that can be sent and is managed later.

Description

Hospital customer relationship management provision system and method {SYSTEM AND METHOD FOR PROVIDING HOSPITAL CUSTOMER RELATIONSHIP MANAGEMENT}

The description below relates to a system and method for providing customer relationship management.

CRM (Customer Relationship Management) is an activity that manages communication with customers and provides customized marketing. Nowadays, hospitals and clinics (hereinafter referred to as 'hospitals') provide information to their customers through text messages or SNS, and use CRM to collect and process customer inquiries, requests, and claims for patient management. I'm doing it. CRM in these hospitals is used as a management tool to increase patient satisfaction by actively communicating with patients, ultimately increasing patient visit and return visit rates.

These hospital CRMs allow hospital staff to call, email, or text messages to patients at the time of need, or request an external service to send bulk SMS/MMS text messages, or app-based push messages or instant messaging. It is transmitted through (for example, KakaoTalk) and is mostly a one-way, one-time message.

Telemedicine, on the other hand, uses telecommunications and information technology to provide clinical health care at a distance. It eliminates the barrier of distance and makes it easier to access medical services. In many cases, telemedicine is used in rural areas where distance makes it difficult to receive consistent health care services. It is also used to manage critically ill patients or save lives in emergency situations. Telemedicine has been allowed under limited conditions to prevent infectious diseases, and recently, to treat patients with chronic diseases or returning patients.

Republic of Korea Patent Publication No. 2019-0135692 (published on December 9, 2019) is a hospital CRM that extracts and processes the information needed for patients using medical EMR data and sends it to customers in the form of a message or provides it to the hospital terminal. Present a system. Republic of Korea Patent No. 10-1250462 (announcement date: April 8, 2013) allows hospitals to provide consultation services to existing patients based on their electronic medical records, discover marketing targets, that is, potential medical service users, and provide new services. We present a hospital CRM system that allows you to actively attract patient customers. Republic of Korea Patent No. 10-0844543 (announcement date July 8, 2008) discloses a method and device for implementing web-based remote diagnosis. Republic of Korea Patent No. 10-0366816 (announcement date January 9, 2003) discloses a remote medical device and method.

By connecting hospitals and patients, patients become a channel of mutual communication with the hospital, and hospitals are presented with a CRM provision system that proactively manages patients and potential patients.

A CRM service optimized for hospitals is provided, providing appropriate information and alarms before treatment, providing patients with sufficient necessary information after treatment, and providing continuous care to patients.

In addition, the flow of messages, which is the basis of CRM, is continuously and continuously integrated and managed. Furthermore, CRM message flow through heterogeneous means is managed to be integrated immediately or later. CRM messages sent from hospital clients to specific patients (or, conversely, messages sent from patients to hospital clients) are integrated and managed regardless of whether the application (APP) is installed. Depending on situational needs, the flow of CRM information delivered through different channels to heterogeneous channels is also integrated and managed immediately or later.

Furthermore, content that has limitations as a general message (SMS or MMS) is composed of rich and helpful content along with pictures/videos, thereby contributing to increasing patients' satisfaction with the hospital and the completeness of treatment. do.

System configuration and CRM sending

A computer-implemented method comprising: receiving, from a hospital or a medical institution client side assigned to a doctor, an input of a selection of CRM content to be sent and identification information of a recipient to receive the CRM content, and in response to the input, A computer-implemented method is provided, comprising transmitting the CRM content by a first means to the recipient's terminal. A computer may be an electronic device that includes at least one processor, a communication interface, and storage. This computer is communicatively connected to the patient's terminal and the medical institution (hospital) terminal, and provides a service for transmitting CRM content from the client of the medical institution's terminal to the patient's terminal.

Integration of CRM transmissions through disparate means

According to one embodiment, when it is confirmed that the recipient is not a service subscriber using the recipient's identification information or that the service application is not installed on the recipient's terminal, the CRM is installed as a second means on the recipient's terminal. Send content. And transmissions through this second means are stored in a buffer.

According to one embodiment, when the recipient subscribes to the service and the service application is installed on the recipient's terminal, the buffered CRM content is merged with the CRM record in the service application and managed in an integrated manner. In this case, the previous buffer may be flushed.

Linkage or integration with hospital EMR

By way of example, but not limitation, a medical institution (hospital) client is linked or at least partially integrated with EMR (electronic medical record, electronic chart) software used in the hospital. In this embodiment, at least some of the recipient's identification information for the CRM to be sent may be extracted from the EMR software. This extraction can be performed automatically from the EMR treatment card opened at the treatment at the end of the treatment. In other cases, these extracts may be selected by searching by the patient's name, phone number (part of), disease name, etc. Meanwhile, the person receiving the CRM does not necessarily need to be one person, but may be multiple people depending on the embodiment.

Examples of CRM Information

The CRM information provided from the hospital to the patient includes various items. According to one embodiment, the CRM content includes information that guides the date and content of medical treatment at least one of the time before, on the day of, and after the scheduled medical treatment date.

According to another embodiment, the CRM content includes a survey on satisfaction with treatment after treatment.

According to another embodiment, the CRM content includes a digital prescription selected by the doctor, and the digital prescription includes a VAS (Visual Analogue Scale) recording module, body temperature measurement recording module, prescribed drug administration guidance module, and blood pressure. It includes at least one of a recording module and a blood sugar recording module.

In addition, CRM according to embodiments may include treatment or post-procedure management guidance and Mobidoc feed, a doctor's specialty column.

Telemedicine guidance included in CRM

According to one embodiment, guidance on telemedicine and/or a hyperlink to apply for telemedicine may optionally be inserted into the CRM to be sent at a time when legal conditions are met according to guidance permitted by law.

Illustratively, if the record of the recipient's treatment at the hospital is confirmed within a predetermined period calculated backward from the time of transmission, and remote medical treatment is allowed when the corresponding CRM message is sent, the information provided by the medical institution client is Application for telemedicine (link to apply for telemedicine) is included and provided in the above CRM content.

Meanwhile, even in the case of D+Day CRMs that are provided as a follow-up on days after treatment or procedures, rather than CRMs provided in advance in the form of D-Day for hospital reservation dates, the return visit condition is satisfied. In some cases, telemedicine guidance and registration links may be provided. For example, while composing CRM content, such as one day (D+1) or three days (D+3) after the date of treatment or procedure (D), a period of time when return visits are not permitted (more than 30 days from the last face-to-face treatment date) (e.g., as time passes), such telemedicine guidance and application links may be excluded.

According to embodiments, the hospital is actively connected to the patient, and the patient receives care while remaining connected to the hospital. As customers, patients are satisfied with mutual communication with the hospital, and hospitals can manage customers to increase patient safety, patient satisfaction with the hospital, and repeat visit rates.

A CRM service optimized for hospitals is provided by continuously caring for patients in advance, on the day, and afterward according to the patient's treatment and procedure schedule.

Pre-configured CRMs are prepared and sent for each patient's disease and/or for each procedure the patient will receive, making it easier for medical professionals/hospitals providing CRM, and patients also receive timely information, increasing convenience and satisfaction with treatment.

The various information and functions included in CRM contribute to increasing patients' satisfaction with the hospital and the completeness of treatment throughout the entire cycle. In particular, content that has limitations as a general message (SMS or MMS) is composed of rich and helpful content along with pictures/videos, contributing to increasing patient satisfaction with the hospital and completeness of treatment. .

Furthermore, the flow of messages, which is the basis of CRM, is continuously and continuously integrated and managed, so that patients who have not yet registered as members or who have not installed the application (APP) can be integrated with the previous CRM by later installing the APP as a member. .

In addition, various effects are provided by the embodiments and will be further mentioned along with a description of the embodiments throughout the specification.

Figure 1 is a diagram for explaining the connection between a CRM providing device, a patient terminal, and a doctor terminal.
Figure 2 shows a CRM providing device according to an embodiment.
Figure 3 is a diagram for explaining a CRM message transmission and processing method according to an embodiment.
Figure 4 shows a treatment guide CRM being transmitted according to one embodiment.
5 to 10 are reference screens for explaining the types of CRM content and their respective characteristics.
Figure 11 shows CRM transmitted to a patient terminal according to one embodiment.
Figure 12 shows a remote medical service being provided according to an embodiment.

Hereinafter, embodiments will be described in detail with reference to the attached drawings. However, the scope of rights is not limited or limited by these embodiments. The same reference numerals in each drawing indicate the same members.

The terms used in the description below have been selected as general and universal in the related technical field, but there may be different terms depending on technological developments and/or changes, customs, technicians' preferences, etc. Accordingly, the terms used in the description below should not be understood as limiting the technical idea, but should be understood as illustrative terms for describing embodiments.

In addition, in certain cases, there are terms arbitrarily selected by the applicant, and in this case, the detailed meaning will be described in the relevant description section. Therefore, the terms used in the description below should be understood based on the meaning of the term and the overall content of the specification, not just the name of the term.

The CRM providing device according to one embodiment may be an electronic device. Electronic devices include general-purpose computing devices implemented by hardware and/or application software in the form of a system-on-a-chip (SoC) as long as they provide service connection and implementation.

For example, electronic devices include smart phones, tablet personal computers, mobile phones, video phones, e-book readers, desktop personal computers, and laptops. Laptop personal computer (PC), netbook computer, personal digital assistant (PDA), portable multimedia player (PMP), MP3 player, mobile medical device, camera, or wearable device (e.g. It may include at least one of a head-mounted-device (HMD) such as electronic glasses, an electronic clothing, an electronic bracelet, an electronic necklace, an electronic accessory, an electronic tattoo, or a smart watch.

According to a further embodiment, the electronic device may include various medical devices (e.g., magnetic resonance angiography (MRA), magnetic resonance imaging (MRI), computed tomography (CT), imaging device, ultrasound machine, etc.), navigation device, GPS receiver ( global positioning system receiver, EDR (event data recorder), FDR (flight data recorder), automotive infotainment devices, marine electronic equipment (e.g. marine navigation system and gyro compass, etc.), avionics, security It may include at least one of a device, a head unit for a vehicle, an industrial or household robot, an automatic teller's machine (ATM) at a financial institution, or a point of sales (POS) at a hospital.

In addition, electronic terminals include intelligent furniture or parts of buildings/structures, electronic boards, electronic signature receiving devices, projectors, or various measuring devices for connecting remote medical services. It may include at least one of (e.g. water, electricity, gas, or radio wave measuring equipment, etc.). Electronic devices according to various embodiments of the present invention may be one or a combination of more than one of the various devices described above. Additionally, electronic devices according to various embodiments of the present invention may be flexible devices. As such, the forms of electronic devices themselves are diverse, and it is obvious to those skilled in the art that the forms and main uses (other than the function of providing remote medical services) of electronic devices are not limited to the above. Hereinafter, specific embodiments will be described with reference to the drawings.

Mobidoc according to embodiments ^TM CRM services provided by

The mobiDoc ^TM service provides CRM. Mobidoc satisfies the customized needs of patients, but aims for a hospital-centered service with a different perspective from existing services. Just as patients wander around looking for a doctor to cure their illness, doctors/hospitals also try to attract and manage patients who are suitable for their hospitals through various methods.

For example, hospitals and doctors send text messages (medical treatment information, closure information, hospital event/promotion information, reservation information, etc.) to encourage patients to return, and also send messages on SNS services such as KakaoTalk and introduce the hospital. I run a homepage, and recently, I even invest my time in running a blog and YouTube. However, costs are high for text messaging and promotional agencies, and there are no services optimized for doctors and hospitals.

Mobidoc offers advantages in these areas. When using the CRM function provided by Mobidoc, hospital clients (i.e., clients that doctors log in and use, and clients that hospital staff log in and use) collaborate with each other and complement their roles. Therefore, if a doctor wants to make a next appointment and provide special care to a patient immediately after completing the treatment, he or she can create or edit a CRM and apply it to the patient. Hospital staff can also set up a CRM in a time-efficient manner. As a result, delays in medical treatment are reduced, and hospital operations become smoother even in hospitals with fewer staff compared to the workload or when there is a temporary shortage of staff due to a surge in patients. In addition, by using the bulk text sending agent service, compared to sending CRM in bulk via SMS or MMS, it is possible to elaborately customize it to customer and hospital needs, actively respond to changing situations, and become more cost-effective. .

Mobidoc's CRM includes reservation creation notifications sent to patients, notifications before the reservation date, notifications on the day of reservation, test information, directions to the hospital, doctor's instructions, digital prescriptions after treatment, digital treatments, or treatment progress monitoring. It includes records/guides, treatment or post-procedure management information, Mobidoc feed, a doctor's specialized column, and telemedicine application information and application links. Types of CRM contents and corresponding processes will be described in more detail later with reference to various examples of FIGS. 3 to 10.

System and service configuration

Figure 1 is a diagram for explaining the connection between the CRM providing device 100, the patient terminal 101, and terminals 102 and 103 belonging to a medical institution.

In the schematic diagram shown, the device 100 is implemented by a server-class computer, workstation, desktop computer, laptop computer, mobile electronic device, etc., and may also be implemented by a plurality of devices among them.

The device 100 is connected to the patient terminal 101 through a network, and is also connected to the doctor terminal 102 and the hospital terminal 103. Each of the terminals 101 to 103 may also correspond to a desktop computer, laptop computer, mobile electronic device such as a smartphone or tablet PC. In each of the terminals 101 to 103, there is a software means called 'client' for convenience.

A patient client is executed on the patient terminal 101. The doctor client runs on the doctor terminal 102, and the hospital client runs on the hospital terminal 103. The doctor client corresponds to the counting part of the patient client and is installed in the hospital. There may also be an online cloud service in the form of SaaS (Software as a Service). In this case, the doctor client refers to a service type in which the cloud service is provided when accessed from the account of a doctor and/or hospital staff. And the hospital client is not a medical professional (doctor) who provides treatment, but rather a means by which the hospital's administrative staff or nurses perform treatment assistance tasks such as receiving treatment and collecting hospital fees.

The doctor client used by doctors and the hospital client 103 used by hospital staff other than doctors may be provided separately. However, according to one embodiment, the doctor client and the hospital client are integrated into one, and if the account signing in is that of a doctor user with a medical license, all functions are activated, and if the account signing in is that of an employee other than a doctor, Some features can be disabled. Some of the functions that are disabled are functions that only doctors should perform, such as 'starting telemedicine'. Since the time to start treatment for the next patient can be selected most accurately and appropriately by the doctor, the 'Start Treatment' function, which initiates a video connection with the patient client waiting in the treatment room, is implemented as a function available only to doctors. However, this is an example, and hereinafter, throughout the specification, the medical institution client may be understood to collectively include the doctor client and hospital staff client installed in the doctor terminal 102 and the hospital terminal 103.

The client installed on the terminals 101 to 103 may be installed original application software, may provide services through a page accessed through a web-based browser, or may combine the characteristics of the app and the web. It could also be a hybrid app. Furthermore, it may be a cloud-based service provided in the form of SaaS. Since this implementation can be implemented by a developer with ordinary knowledge in this field, further detailed description will be omitted, and even if the description of the embodiments mentions one example, it does not exclude other implementations. Implementation and operation of the device 100 will be described with reference to FIG. 2.

System configuration and CRM sending

Figure 2 shows a CRM providing device 100 according to an embodiment. The device may be an electronic device including at least one processor 120, a communication interface 110, and a storage unit 130. This device is communicatively connected to the patient's terminal 101 and the medical institution (hospital) terminal 102 and provides a service for transmitting CRM content from the client of the medical institution's terminal to the patient's terminal.

According to one embodiment, the CRM provision method provided by the device 100 receives, from the client side of a hospital or medical institution assigned to a doctor, selection of CRM content to be sent and input of identification information of a recipient who will receive the CRM content. and transmitting the CRM content to the recipient's terminal in response to the input.

According to one embodiment, a plurality of preset CRM templates are provided as selectable options on the medical institution client side. Then, CRM content to be sent through user interfacing on the medical institution client side can be selected from the options. The selected CRM may be appropriately modified and sent by the treating doctor or hospital staff depending on the patient and disease.

CRM sending process and integrated management

Figure 3 is a flowchart showing a CRM transmission process according to an embodiment.

A request to transmit CRM information is received by the service providing device 100 (step 310). This request may come from a hospital client of the hospital terminal 102.

The request includes identification information of the recipient who is the subject of CRM information transmission. In step 320, the device checks whether the Mobidoc ^TM app is installed on the patient's terminal 101. By way of example, but not limitation, this is possible by checking the patient's demographic information, customer number, phone number, etc. in the database of the storage unit 130.

If the app is installed, the first method (for example, sending a push message through the Mobidoc app) is performed (step 340), and the CRM transmission record for the patient is updated in the storage unit 130 (step 350).

In step 320, if it is determined that the app is not installed on the patient's terminal, push transmission through the app is not possible at this time, so in step 321, a second method (e.g., through a messaging service such as text message or KakaoTalk) CRM transfer) is performed (step 321). Then, the CRM transmission through the second means is stored in the storage means 130 (step 322). Here, the save in step 322 will later be integrated and managed as a CRM record within the app once the app is installed. Until then, CRM will be sent to patients who are temporarily non-members or have not installed the app, but the contents and log will be temporarily recorded. Since this was done, a table called buffering was used.

If the information is buffered and the patient later installs the app, past CRM messages that were buffered in step 322 before installation are integrated and updated as CRM records (step 350). And at that time, the CRM transmission records buffered in the storage means can be flushed.

In this way, even if you do not install the Mobidoc app or are a non-member, you are not excluded from receiving CRM shipments and are allowed to access Mobidoc CRM through a route other than the Mobidoc app. So, if a patient receives such a request via text message, he or she can access the Mobidoc service web-based via a hyperlink (apart from the process of recommending installation of the Mobidoc ^TM app) to check the content or respond to the question. there is. Through this process, non-members or customers who do not have the app installed are encouraged to sign up for Mobidoc and install the app in the future, and after installation, the CRM activities they previously did when they were non-members or before installing the app are confirmed so that there is no discrepancy.

According to these embodiments, the flow of messages, which is the basis of CRM, is integrated and managed continuously and continuously. CRM message flows through heterogeneous means can be integrated immediately or later, so even if distributed heterogeneously through different paths depending on whether an application (APP) is installed or situational needs, the information flow in CRM can be integrated immediately or later. can be managed integratedly. do. For example, various CRM information flow paths such as app-based, web-based, wired/wireless phone, or message-based information provision (including the transmission of messages and presentation of necessary information) may coexist, but these are integrated and managed at the hospital entrance. Longitudinal following and management of patient CRM is possible. From the patient's perspective, it is convenient because the information continuously communicated with one hospital is managed in an integrated manner, even if a specific app is deleted and reset later, or even if the app is managed by the hospital without installing the app and later installed the app.

Examples of CRM Information

CRM information provided from the hospital to the patient includes a variety of items. 4 to 10 are exemplary screen configurations for explaining various examples of CRM information and respective features. Explain in detail with reference to the drawings.

Information on treatment date (D-day information)

Figure 4 shows a treatment guide CRM being transmitted according to one embodiment.

For example, for patients who visit the hospital, information on the next visit schedule is provided through CRM after treatment is completed. For patients who have made a reservation for their first visit, information regarding the date and time of their first visit will be provided. An alarm informing busy office workers, elderly people with reduced memory, and parents who are busy raising children can be displayed in the form of a screen 410 to inform them of the scheduled medical treatment date (or vaccination date) so that they do not miss the next medical treatment or vaccination date. In addition, it is possible to send a CRM message from the patient side to the hospital that not only notifies the reservation date, but also confirms whether the reservation change is necessary and receives a reservation change request.

In the example shown, CRM is sent on the day of treatment (D-0), but CRMs can also be sent accordingly on days D-7, D-3, and D-1. In addition to simply providing information such as one day or three days before treatment, patients scheduled for a checkup or test can also be informed of medications to stop taking, time to fast, etc.

In addition, in cases where it is medically appropriate, for example, in the case of a return visit where the patient's progress can be questioned and whether the prescription has been changed, or in cases where the main treatment involves visiting the hospital in advance, informing the patient of the test results and issuing a prescription, etc., the screen ( 420), depending on the doctor and patient's choice, the visit appointment can be changed to remote video treatment (Mobidoc Clinic). In this case, the hospital's first treatment today can be video treatment, so it can send CRM information to the patient asking if they want to change to remote video treatment. Conversely, the patient who will visit the hospital can send the hospital to the hospital for remote video treatment (remote video treatment). It is also possible to transmit information requesting conversion to Mobidoc Clinic).

Medical Satisfaction Survey

Other examples of CRM information provided from the hospital to the patient include surveys on satisfaction with care. Figures 5 and 6 show this embodiment.

When the treatment is completed, as shown in the example of screen 510, a request for feedback on treatment satisfaction is sent to the patient's client, and when the patient responds, a survey screen 520 is provided and the survey begins. A push alarm may induce a survey response, as shown in screen 510 shown in FIG. 5, but if the patient runs the app first, the survey response may be included in the app screen 610.

As shown in screen 620, the survey may include multiple-choice and/or subjective surveys about overall satisfaction, as well as the current doctor, physical therapist, hospital staff, cost, and treatment time. This treatment satisfaction survey CRM can be an important reference for hospital management from the perspective of hospital managers. As patients experience this CRM, they can be satisfied that the hospital is reconfirming patient satisfaction. Compared to the previous experience of receiving promotional text-based CRM from hospitals, the CRM service according to the embodiment provides a much more immediate and improved customer experience.

This transmission of CRM information requesting feedback from the patient is also performed through the process previously described with reference to FIG. 3 depending on whether the patient has installed the Mobidoc app. It may be the case that the patient has not yet installed an app that provides the relevant CRM service, such as the Mobidoc app. In this case, even if the patient has not installed the Mobidoc app or is a non-member, they are not excluded from the treatment satisfaction survey, referring to Figure 3. As explained, first of all, it provides the experience of responding to Mobidoc CRM through a route other than the Mobidoc app.

As described above, when a patient receives such a request via text message, the patient responds by accessing the Mobidoc service web-based via a hyperlink (apart from the process of recommending installation of the Mobidoc ^TM app), which allows the patient to respond. It is stored and managed in the CRM database. Additionally, after the patient installs the Mobidoc ^TM app, the patient can check the transmission history and content of CRM information previously sent from the app at once through the above-mentioned process. Therefore, such non-members or customers who do not have the app installed will be encouraged to sign up for Mobidoc and install the app in the future, and after installation, the CRM activities they previously did when they were non-members or before installing the app will be confirmed so that there is no discrepancy.

mobiDoc Feed ^TM ) contents

Another example of CRM information provided from the hospital to the patient is mobiDoc Feed content provided through the MobiDoc ^TM app. Figures 7 and 8 show an example in which a feed about the content of treatment received today is transmitted after treatment.

According to one embodiment, a push alarm is provided in the same form as the screen 710. As a patient who came to the hospital and received shock wave therapy and returned home, you may wonder what role it plays and why it is helpful. In general medical settings, personnel such as doctors and physical therapists provide explanations, but each person's ability to explain is different, and if they are busy, there may be cases where the explanation is not thorough. Even if patients hear explanations during treatment or physical therapy (and sometimes procedures), they are so preoccupied that they quickly forget them. Some patients, due to their personality, may not be able to ask everything even if they have questions. Mobidoc satisfies both medical professionals and patients in these areas. It can save medical professionals' time while providing sufficient information to patients. Patients returning home after treatment can get to know the details of the treatment well just by checking the feed of the details of the day's treatment sent by the hospital where they were treated. In the screen 720, it is shown that the patient received a feed about the shock wave treatment received today, a feed about the spinal injection, and a feed containing precautions for receiving the injection today.

For reference, Mobidoc Feed is a content provision service for medical members with a medical license to provide to patient users who follow them or their affiliated hospitals through the doctor client or the separately provided Mobidoc web. By way of example, but not limitation, the Mobidoc feed includes the provision of content including text, images, videos, etc., such as disease information, treatment trends, medical common sense, and health management. Doctor members usually perform their own medical treatment. You can create these feeds about diseases, procedures, treatment methods, etc. and select and send what you need while treating patients.

Screen 810 is an example in which a doctor who frequently performs shock wave therapy has written a feed in advance of things patients may be curious about and then sent the feed to a patient who received shock wave treatment today. Screen 820 is an example of sending an explanation feed about the injection and the disease to a patient who received a spinal injection today. Precautions after injection treatment were displayed on the screen 830.

Meanwhile, within these feeds, a link may be included that provides a Mobidoc treatment appointment directly to the doctor who wrote the feed, or to a hospital or doctor recommended by the doctor for the disease in question. If the patient has completed any procedure or treatment, such as physical therapy, injection therapy, laser treatment, etc., provide additional information about the disease, future treatment plan, explanation of the treatment or procedure received today, precautions, and/or The means of providing detailed information about prescribed medicines to the patient in a customized manner can be delivered in the form of CRM information transmission under the name of Mobidoc Feed.

This customized provision of Mobidoc feed content is transmitted to CRM in the form of in-app push and content viewing for patients who have installed and used the Mobidoc ^TM app, but for patients who have not installed the Mobidoc ^TM app. The terminal first provides Mobidoc feed content as another means of contact identified by patient information, and later, after the patient installs the Mobidoc ^TM app, the existing CRM information exchange history is updated to enable continuous and continuous CRM management without any sense of heterogeneity. do.

Management of patients after treatment/procedure through CRM (D+Day CRM)

Going further from the embodiment previously referred to in FIGS. 7 and 8, according to another embodiment, D+Day is provided not only on the day of treatment but also for a certain period thereafter to track and manage the patient and provide information after the treatment or procedure. CRM may also be provided.

For example, if a dermatologist performs a procedure, what measures should be taken and what precautions should be taken one day after the procedure, what information should be provided three days after the procedure, and what checks should be made a week after the procedure and if there are any problems, contact the hospital, etc. There are cases where follow-up care must be performed according to a schedule. Previously, most dermatology clinics provided printed notices in these cases, causing various inconveniences. This need is met in most cases, including not only dermatological procedures, but also various surgical procedures including plastic surgery, general interventional procedures, cardiac interventional procedures, and medical measures for certain symptoms. There is. Even during the COVID-19 pandemic that has swept the world over the past few years, there is a need to provide systematic information to patients and help them manage their health by providing date-based guidance to infected patients. Mobidoc CRM will continue to work in this area in the future as well. can play a role.

Digital Prescription CRM Modules

Meanwhile, another example of CRM information provided from the hospital to the patient may be modules such as digital prescriptions, digital treatments, and pain or disease status surveys provided through the Mobidoc ^TM app. The difference from the previous healthcare app (Healthcare APP) that records weight, blood pressure, blood sugar, etc. is that Mobidoc CRM is not a health record that is installed and run separately by the patients themselves, but rather a ‘medical record of me’ within the Mobidoc platform. This is a function that a ‘doctor’ directly prescribes in a customized manner by setting the period and contents in ‘My Mobidoc Account’. In other words, as an extension of medical treatment and treatment, the 'doctor who treated me' directly executes some type of module through the Mobidoc doctor client (102) to record certain points, for a certain number of days, and at a certain frequency, and to conduct certain questionnaires. It is attached to 'My Mobidoc Account' and executed as prescribed through the patient terminal (101).

9 and 10 illustrate example screens executed on patient client 101 with a prescribed pain recording module according to one embodiment. In orthopedics, neurosurgery, pain medicine, etc., a digital prescription module that tracks the degree of pain may be provided to patients by the CRM according to this embodiment. Patients are not under the control of the hospital and doctors from the time they return home after completing hospital treatment. In the case of pain questionnaires (such as VAS: Visual Analogue Scale), if patients who have completed treatment continuously record them and the hospital can monitor them, it contributes to the patient's treatment and recovery.

An alarm 910 to record pain is provided at a period designated in advance by the doctor, and when the patient responds to the alarm 910, the VAS module 920 is executed. As long as patients passively respond without taking care of everything themselves, they can steadily record their pain as prescribed by the doctor who treated them, and this data over time is monitored by the hospital and/or abnormal situations due to data trends are monitored. is used to discover.

Please refer also to Figure 11. The pain level recorded by the patient in the VAS module 1010, which is executed according to the doctor's prescription, is managed as data over time by the patient and the hospital, and may be visually displayed on the screen 1020. If the level of pain improvement is significantly below expectations, the hospital will inquire whether the patient is taking the prescribed medication well and following the precautions prescribed by the doctor, and, if necessary, make an appointment for the next visit. It can also encourage you to move forward. Absolute values can also be considered, such as simply because the pain greatly exceeds the generally expected level, but abnormal values such as pain has become more severe than the previous measurement value or the pain is increasing while it is still time to take the prescribed painkiller. There may also be cases where it is questionable whether this is the case or not.

In such cases, according to one embodiment, a push alarm to alert people to check whether they are taking the prescribed medicine well and to continue taking the medicine may be delivered through the CRM. According to another embodiment, a CRM alarm is sent to intervene more actively and suggest remote video treatment through Mobidoc Clinic, as shown on screen 1030, so that the hospital can preemptively interrogate patients, change prescription drugs, or provide necessary treatment. It is also possible to provide additional instructions from the doctor.

There are many other examples of this digital prescription module provided by Mobidoc CRM.

In another embodiment, in the case of pediatrics, a digital prescription for temperature recording can be modularized to manage a child's fever and given to a specific patient in the form of a CRM for a certain period of time. From the perspective of a caregiver raising a child, simply responding to the CRM information communicated through the Mobidoc app after receiving treatment at a Mobidoc affiliated hospital can help with treatment and emergency situations by passively responding to the prescribed body temperature recorder for a certain period of time. can be prevented.

Furthermore, patients who need to regularly measure blood sugar or blood pressure simply respond to the record sheet prescribed to them in the Mobidoc ^TM app, and the hospital can manage the patient and make necessary suggestions.

Ensuring treatment integrity that contributes to patient recovery

This modularized CRM contributes to the emotional stability of patients and increases the completeness of treatment. In addition, the fact that the hospital takes care of patients who return home after completing in-patient treatment and cares for them 'outpatients as if they were inpatients', and if necessary, the hospital first asks if they are okay and makes necessary suggestions, according to the embodiments. This is a new medical service offered by Mobidoc CRM. This customer experience (CX: Customer eXperience), which is similar to receiving medical care from a family member or close acquaintance, not only helps patients recover and prevent dangerous situations, but also increases patient satisfaction and loyalty to the hospital. In other words, from the hospital's perspective, it contributes to increasing patient satisfaction with the hospital and thus increasing the return rate. Furthermore, patients with mild symptoms need to be discharged quickly due to a chronic shortage of beds, like in tertiary general hospitals, but if patients require management even after discharge, patients can be managed through Mobidoc CRM. Therefore, it helps manage patient health while lowering the hospitalization rate.

CRM screen configuration example

Figure 11 shows CRM transmitted to a patient terminal according to one embodiment.

Hospital and doctor information that sent the CRM from the patient terminal 101 is displayed in the upper field 1101, and a CRM message is provided in the lower field 1110. The layout of the fields 1101, 1110, and 1111 shown in FIG. 11 is merely illustrative. Therefore, any number of different sizes and layouts are possible. For example, unlike Figure 11, it is also possible to configure it like a smartphone's messaging app interface or SNS's DM (Direct message) interface.

The process and content of forming a CRM message are the same as described above.

Feed content included in CRM

As shown in Figure 11, the CRM message may include disease-related information, health information, and other specialized articles sent by the relevant doctor or hospital to the relevant patient. Articles may be inserted directly, but may also be presented in the form of hyperlinks, as shown. Hyperlinks link to the corresponding mobiDoc Feed article in the app and/or on the web. Since the Mobidoc feed is written only by licensed doctors, the content can be considered verified. Therefore, if the doctor who treated the patient inserts and sends specialized column articles tailored to the patient's disease and body in the CRM in this way in the form of a feed, the patient's attention and concentration on the CRM itself is high. As mentioned earlier, patients often perceive CRM messages in the form of SMS or MMS from hospitals as advertisements and do not pay attention to them. However, since the Mobidoc feed is provided together in the CRM field 1110 as shown in FIG. 11, patients can believe that the hospital and doctor who sent it truly treat them as customers and take care of them.

Therefore, the positive function of CRM can be exercised, allowing hospitals to manage and strengthen relationships with patients and customers. This enhanced functionality of CRM is further enhanced by combining it with Mobidoc's telemedicine service, 'Mobidoc Clinic'.

Telemedicine guidance included in CRM

Even when a patient makes a next medical appointment (re-visit appointment), there are cases where the reservation cancellation rate is not low. There may be a variety of reasons why patients who have made a reservation for a return visit miss the reservation, cancel the reservation, or no-show, but they are unsure whether a return visit is necessary and/or have difficulty visiting the hospital due to work or childcare reasons. Cases, etc. may be included. The remote medical treatment provided by Mobidoc ^TM at Mobidoc Clinic functions as a nudge that allows these patients to easily access return visits through CRM. The patient applies for remote treatment, even briefly, and once again consults with the doctor who attended the initial examination about the course of the disease, his or her current condition, and the side effects of the medicine he or she is taking, and decides whether or not he or she should make additional visits to the hospital. Positive effects, as judged by , are also expected.

Therefore, according to one embodiment, information that one can apply for Mobidoc telemedicine and/or a hyperlink to apply for telemedicine are provided as part of the CRM in field 1111 of FIG. 11 .

Meanwhile, the standards for allowing such telemedicine may vary depending on the country and time period. Therefore, according to one embodiment, guidance on telemedicine and/or a hyperlink for applying for telemedicine may optionally be inserted into the CRM to be sent at a time when legal conditions are met according to guidance permitted by law.

As an example, guidance on remote treatment and an application link may be provided in the field 1111 only when a return visit is made within a pre-specified period, for example, within 30 days when remote treatment is permitted, counting back from the time the illustrated CRM is transmitted. . For this purpose, the D-0 day (same day of the previous reservation date) information in the hospital's EMR and/or CRM according to the previous reservation information can be used and compared with the time when the CRM will be sent later. In other words, a distinction can be made between CRM sent 7 days after the previous treatment and CRM sent 2 months later. If the standard for allowing telemedicine is that only follow-up treatment for the same disease at the same hospital within 30 days is allowed, in the former case, the former (CRM sent 7 days later) includes telemedicine information and an application link, but the latter (CRM sent 7 days later) includes telemedicine information and an application link. In the case of CRM (sent two months later), this is not provided.

Meanwhile, even in the case of D+Day CRM, which provides follow-up management for previous treatment or procedures that have already occurred, such remote treatment guidance and application links may be provided only within a pre-designated standard period (such as 30 days). For example, while composing CRM content, such as one day (D+1) or three days (D+3) after the date of treatment or procedure (D), a period of time when return visits are not permitted (more than 30 days from the last face-to-face treatment date) (e.g., as time passes), such telemedicine guidance and application links may be excluded.

According to another embodiment, a CRM may be sent asking whether to conduct telemedicine for a return visit before the limit for allowing a return visit mentioned above has passed. For example, telemedicine information and links can be sent in CRM format to patients who have had their first consultation or procedure, once after 21 days and once after 28 days.

Mobidoc Clinic (remote medical treatment) starting through CRM

The start and progress of telemedicine using the link in the field 1111 is shown in FIG. 12.

Although not shown, the patient client completes treatment registration and requests access to the treatment room. The treatment room referred to here is a session in which patients wait for the doctor to begin treatment during the process of Mobidoc Clinic, a remote medical treatment service provided by Mobidoc. Rather than simply completing a remote medical treatment application, the clinic plays a role in ensuring that the patient waits for the doctor to begin treatment.

After the treatment reception is completed, the client of the patient's account is entered into a stage called the treatment room according to the approval of the hospital and/or doctor. This means that the service status of the patient client for the patient account is changed from the treatment reception process to the treatment waiting process, and the medical office is in a state where video and/or voice calls can begin immediately when the doctor begins treatment. This is the step. This is similar to how, in an offline real hospital, a nurse guides the patient into the examination room, makes the patient wait in the treatment area, reports to the doctor that the patient is ready, and when the doctor is ready, he comes in and immediately begins treatment with the patient. It's user experience. When you go to a university hospital, there are cases where doctors go back and forth between two adjacent (connected) clinics to provide treatment. While the doctor is providing treatment in one treatment room, a nurse prepares the next patient for treatment in the next treatment room. At this time, information such as charts, necessary medical images, and test results are prepared through the electronic medical record system (EMR) or other means, so that busy doctors do not waste time in the preparation process. The doctor goes back and forth between two treatment rooms, finishes treating the current patient in one room, performs necessary charting, and then moves to the next treatment room where preparations for the next treatment are made and the patient is also waiting to come in, and immediately begins the next treatment. You can do this, and Mobidoc Clinic ^TM provides this function.

This reduces unnecessary waste of time, allows doctors to actually stick to the essence of treatment even when seeing the same number of patients, reduces patient inconvenience due to delays in treatment, and provides medical services to more patients. Waiting after entering the ‘treatment room’ of the mentioned Mobidoc Clinic plays that role.

The improvement in treatment efficiency achieved by keeping patients waiting and ensuring the possibility of immediate start of treatment is important because it provides better service to both practitioners and patients. In most existing telemedicine services, when a patient applies for online (remote) medical treatment, the doctor (or hospital) attempts to connect to the patient. These connections may be video calls, voice calls, etc. However, since telemedicine is connected online and is not a situation where people actually meet face to face, while waiting for telemedicine with a doctor, patients do other things instead of waiting for treatment, or leave the terminal and go somewhere else. It may go away. In that case, the availability of immediate treatment is not guaranteed when the doctor (or hospital) wants to start treatment.

Mobidoc Clinic, shown in Figure 12, checks through the patient client whether the patient is actually ready for treatment and whether treatment is available immediately when the doctor starts the treatment procedure. It confirms that the patient is in standby status entering the treatment room and allows the doctor client to understand this situation.

As a result of checking on the patient client side, if the patient is on the phone, is away without looking at the screen, or is doing other work on the terminal 101, etc., when the doctor wants to start treatment, the treatment does not start immediately. If you have a situation that would make you wait for a doctor, you can let the doctor know. In addition to informing the patient, it can also remind the patient that the patient may not be ready for treatment and give the doctor the option to treat other patients first. A nudge effect can be created to ensure patients are prepared by giving patients an alarm that ‘treatment will not begin until you wait for treatment.’

Thanks to this consideration, the doctor knows which patients are ready to begin treatment among the patients who have registered for treatment and entered the waiting room, and can select well-prepared patients to begin treatment, thus allowing the doctor and the hospital to Avoid experiencing inefficiencies due to connection delays or connection failures. For patients who are not ready, hospital staff or telemedicine service providers must be prepared on the patient's terminal to prepare for treatment by notifying them that treatment is about to begin (without closing the app, without performing other tasks, and keeping an eye on the screen in the treatment room). can be induced to wait). According to the above embodiments, the possibility of a doctor providing immediate treatment to a patient increases.

Figure 12 shows the appearance of the patient terminal (1210) when treatment is started in this way. Patients are informed that remote medical treatment is available for return visits, so they can receive treatment without visiting the hospital in person. In these cases, when the need for a return visit is unclear, it is effective in deliberately taking the time to consult with a doctor about the progress of the disease and adjust medication intake without visiting the hospital. Therefore, it can serve as a medium for patients who were hesitant about whether to return for a second visit to continue their doctor's treatment without giving up. By doing so, gaps in treatment that may be overlooked by patients can be reduced and health can be prevented from deteriorating.

Linkage or integration with hospital EMR

Although not shown, by way of example, but not limitation, a medical institution (hospital) client is linked or at least partially integrated with EMR (electronic medical record, electronic chart) software used in the hospital. In this embodiment, at least some of the recipient's identification information for the CRM to be sent may be extracted from the EMR software. This extraction can be performed automatically from the EMR treatment card opened at the treatment at the end of the treatment. In other cases, these extracts may be selected by searching by the patient's name, phone number (part of), disease name, etc. Meanwhile, the person receiving the CRM does not necessarily need to be one person, but may be multiple people depending on the embodiment.

If the next medical appointment is created in the EMR during treatment without going through Mobidoc, or the patient's medical appointment is created by other means such as by phone, all or selected parts of these items are used to send reservation text messages in Mobidoc ^TM CRM. do. Here, Mobidoc ^TM CRM can be linked to EMR and API. In this case, when a patient reservation is created in EMR, an option is provided to send a reservation notification text message to Mobidoc ^TM CRM. This linkage between Mobidoc ^TM CRM and EMR minimizes the time of doctors and hospital staff used for CRM.

The device described above may be implemented with hardware components, software components, and/or a combination of hardware components and software components. For example, devices and components described in embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable array (FPA), It may be implemented using one or more general-purpose or special-purpose computers, such as a programmable logic unit (PLU), microprocessor, or any other device capable of executing and responding to instructions. A processing device may execute an operating system (OS) and one or more software applications that run on the operating system. Additionally, a processing device may access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, a single processing device may be described as being used; however, those skilled in the art will understand that a processing device includes multiple processing elements and/or multiple types of processing elements. It can be seen that it may include. For example, a processing device may include multiple processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are possible.

Software may include a computer program, code, instructions, or a combination of one or more of these, which may configure a processing unit to operate as desired, or may be processed independently or collectively. You can command the device. Software and/or data may be used on any type of machine, component, physical device, virtual equipment, computer storage medium or device to be interpreted by or to provide instructions or data to a processing device. , or may be permanently or temporarily embodied in a transmitted signal wave. Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., singly or in combination. Program instructions recorded on the medium may be specially designed and configured for the embodiment or may be known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. -Includes optical media (magneto-optical media) and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

Although the embodiments have been described with limited drawings, various modifications and variations can be made from the above description by those skilled in the art. For example, the described techniques are performed in a different order than the described method, and/or components of the described system, structure, device, circuit, etc. are combined or combined in a different form than the described method, or other components are used. Alternatively, appropriate results may be achieved even if substituted or substituted by an equivalent.

Therefore, other implementations, other embodiments, and equivalents of the claims also fall within the scope of the claims described below.

100: Service provision device
101: Patient terminal
102: Doctor terminal
103: Hospital terminal
110: communication interface
120: processor

Claims (12)

In the computer implementation method,
Receiving, from a client side of a hospital or medical institution assigned to a doctor, selection of CRM (Customer Relationship Management) content to be sent and input of identification information of a recipient who will receive the CRM content; and
In response to the input, transmitting the CRM content to the recipient's terminal by a first means
Including a computer implemented method. According to paragraph 1,
If it is confirmed that the recipient is not a service subscriber using the recipient's identification information or that the service application is not installed on the recipient's terminal,
Transmitting the CRM content to the recipient's terminal by a second means
A computer-implemented method further comprising: According to paragraph 2,
When transmitting the CRM content to the second means, buffering the CRM content in a storage means.
A computer-implemented method further comprising: According to paragraph 3,
When the recipient subscribes to the service and the service application is installed on the recipient's terminal, merging the buffered CRM content into a CRM record in the service application.
A computer-implemented method further comprising: According to paragraph 1,
The medical institution client is linked or integrated with the EMR software used in the hospital,
and wherein at least some of the recipient's identifying information is extracted from the EMR software. According to paragraph 1,
The CRM content includes information guiding the date and time of medical treatment at least one of the time before, on the day of, and after the scheduled medical treatment date. According to paragraph 1,
A computer-implemented method wherein the CRM content includes a survey on satisfaction with treatment after treatment. According to paragraph 1,
The CRM content includes a digital prescription selected by the doctor, and the digital prescription includes a Visual Analogue Scale (VAS) recording module, a body temperature measurement recording module, a prescribed drug administration guidance module, a blood pressure recording module, and a blood sugar recording module. A computer-implemented method comprising at least one of: According to paragraph 1,
The CRM content includes a link to apply for remote medical treatment, and when the link is selected, a remote medical treatment application process is initiated. According to clause 9,
A computer-implemented method of providing a link for applying for remote medical treatment by including in the CRM content when the time at which the CRM content is transmitted is within a predetermined period of time from the recipient's previous medical treatment. A non-transitory computer-readable storage medium comprising instructions for performing the method of any one of claims 1 to 10. One or more processors;
a communication interface operatively coupled to the one or more processors to provide communication with the medical institution client and the recipient's terminal; and
Storage unit for storing the CRM content
An electronic device comprising: wherein the one or more processors are configured to perform the method of any one of claims 1 to 10.