KR20240093383A - System and method for providing hospital customer relationship management content - 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. Feed content created by a doctor is provided as at least part of the CRM content.

Description

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

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.

The hospital's CRM may include not only reservation information and hospital notices, but also medical or health information. In many cases, CRM can be used by hospital staff to call, email, or text patients, or to hire an external service to send bulk SMS/MMS texting, or to use app-based push messaging or instant messaging (such as KakaoTalk). It is transmitted through Talk) and is mostly a one-way, one-time message.

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-1875306 (announcement date July 5, 2018) proposes a system that provides disease information using medical terminology clusters. 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 system is provided that easily and conveniently integrates the process of doctors and/or hospital staff providing content containing medical information to patients into CRM. The content creation process also provides a user experience to the creator to make it convenient.

It helps create and deliver CRM content by allowing convenient use of medical images and illustrations when creating content.

The process of delivering content to patients and customers has also been improved to make it more convenient, and a system is provided to help patients manage their health and comply with treatment by allowing them to receive content they are interested in in connection with their treatment.

Furthermore, it suggests ways to increase trust between doctors (and hospitals) and patients, and to contribute to improving satisfaction with the hospital and completeness of treatment throughout the entire cycle.

A computer-implemented method comprising: providing a first interface for generating CRM content in connection with a medical institution client assigned to a hospital or doctor; Storing the generated CRM content in a storage unit; and transmitting the CRM content to be sent to the recipient according to selection of the recipient and the CRM content to be sent.

According to one embodiment, the method further includes providing a second interface that is linked to the first interface and provides image search and selection functions to be inserted into the CRM content. Here, results provided according to the image search may be filtered by at least one tag information related to the image.

According to one embodiment, the method is different from the second interface and further includes providing a third interface for requesting creation of a new image.

The method according to another embodiment further includes a step of having a processor extract a tag for an image included in the CRM content while storing the generated CRM content in a storage unit.

By way of example, but not limitation, the extraction involves obtaining at least one keyword for the image through a BERT (Bidirectional Encoder Representations from Transformers) model and extracting it as the tag. And in this case, when learning the BERT model, weight is given to the text within a predetermined number of words that follow the image.

The method according to another embodiment further includes the step of providing identification information about the patient who received the treatment at the end of the treatment and selecting whether to send the CRM content to the patient. If the CRM content further includes a link to apply for remote medical treatment, the remote medical treatment application process may be initiated when the link is selected.

According to embodiments, a doctor with a medical license may utilize his/her expertise to provide specialized medical columns to patients (including patients who visit the doctor, potential patients interested in his/her medical field, and other general subscribers). It becomes possible.

In the process of writing an article (Mobidoc feed), you can easily insert appropriate images into the article without fear of copyright infringement, and a process for evolving the image archive by communicating with the Mobidoc team is provided.

By publishing and transmitting CRM content including these feeds to patients, it connects doctors and patients, and hospitals and patients, and serves as a window for mutual communication between doctors and hospitals for patients, and for hospitals to actively and actively engage with patients and potential patients. It can be managed.

Furthermore, while providing a Mobidoc feed that only doctors can use (and therefore the content is reliable), it provides correct information to patients, saves precious treatment time for doctors who have to repeat the same explanation, and also from the patient's perspective. Rather than just listening to an explanation without any hesitation, the doctor who treated me would convey in writing what he wanted to tell me. Therefore, patients can read such content slowly and repeatedly, improving satisfaction with doctors, hospitals, and treatment, and further having a positive effect on the treatment of diseases.

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 content providing device according to an embodiment.
Figure 3 shows CRM content according to an embodiment being transmitted to a patient terminal and displayed through a patient client.
Figure 4 shows a pseudoclient screen according to one embodiment.
Figure 5 is an example screen showing a list of created feeds.
Figures 6 to 9 are diagrams to explain the process of creating a feed, selecting an image search, and requesting an image according to an embodiment.
Figure 10 shows example feed content.
Figures 11 and 12 are diagrams for explaining the process of extracting tags from images according to embodiments.
Figures 13 and 14 are diagrams for explaining the feed transmission process and features according to embodiments.
Figure 15 shows CRM transmitted to a patient terminal according to one embodiment.
Figure 16 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 content 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. The types of CRM contents and processes for creating, managing, and transmitting the contents will be described in more detail later with reference to FIG. 3 and below.

System and service configuration

Figure 1 is a diagram for explaining the connection between the CRM content 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.

And depending on the embodiment, the process of creating content that is promised to be used only by doctors, such as creating a Mobidoc feed, may also be allowed only when logged in with a doctor's account. 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 content 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 providing method provided by the device 100 includes providing a first interface for generating CRM content in connection with a medical institution client assigned to a hospital or doctor; Storing the generated CRM content in a storage unit; and transmitting the CRM content to be sent to the recipient according to selection of the recipient and CRM content to be sent.

According to one embodiment, the method further includes providing a second interface that is linked to the first interface and provides image search and selection functions to be inserted into the CRM content. Here, results provided according to the image search may be filtered by at least one tag information related to the image.

According to one embodiment, the method is different from the second interface and further includes providing a third interface for requesting creation of a new image.

The method according to another embodiment further includes a step of having a processor extract a tag for an image included in the CRM content while storing the generated CRM content in a storage unit.

CRM delivery path

The CRM transmission request includes identification information of the recipient who is the subject of CRM information transmission, and a process may be conducted to confirm whether the Mobidoc ^TM app is installed. 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, it is delivered by the first means. The first method is sending push messages through the Mobidoc app. However, if it is determined that the app is not installed on the patient's terminal, it is delivered through a second means. The second means is instant messaging services such as text messaging or KakaoTalk.

mobiDoc Feed ^TM ) contents

Figure 3 shows CRM content according to an embodiment being transmitted to a patient terminal and displayed through a patient client.

For example, the transmitted content may be content explaining the treatment received today after visiting the hospital and receiving face-to-face treatment and/or online video treatment.

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 a better understanding of the treatment just by checking the feed of the details of the day's treatment sent by the hospital where they were treated.

Screen 310 is an example in which a doctor who frequently performs shock wave treatment has prepared 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 320 is an example of sending an explanation feed about the injection and the corresponding disease to a patient who received a spinal injection today. Precautions after injection treatment were displayed on the screen 330.

For reference, mobiDoc Feed ^TM is a content provision service for medical members with a medical license to provide to patient users who follow them or their hospital through the doctor client or the separately provided MobiDoc web. am. 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, and 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.

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.

Other examples of CRM content

Although the Mobidoc feed is presented in FIG. 3, various other examples may be included in CRM content.

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 is provided informing busy office workers, elderly people with reduced memory, and parents who are busy raising children to inform them of the scheduled treatment date (or vaccination date) so that they do not miss the next treatment date or vaccination date. It can be. 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.

Treatment information CRM can be sent accordingly on the day of treatment (D-0), or a few days before treatment, 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 that only needs to be questioned about the patient's progress and check for changes in the prescription, or in cases where the main content of treatment is to visit the hospital in advance, inform the patient of the test results, and issue a prescription, etc., Figure 15 As shown in the example shown in Figures 16 through 16, remote video treatment (Mobidoc Clinic) can also be provided. 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).

In another embodiment, a survey on satisfaction with medical treatment may also be CRM content. In addition to surveying overall satisfaction with treatment, multiple-choice and/or subjective surveys may be included regarding the doctor, physical therapist, hospital staff, cost, treatment time, etc. 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.

According to another embodiment, D+Day CRM, which is provided to track patients and provide information for a certain period of time after treatment, rather than on the day of treatment, 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.

According to another embodiment, CRM content may include modules such as digital prescriptions, digital treatments, and pain or disease status surveys (e.g., Visual Analogue Scale (VAS)) 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. The point is that it is a function that is customized and prescribed directly by the ‘doctor’ 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).

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.

Configuration of pseudo clients and creation of feed content

Figure 4 shows a pseudoclient screen according to one embodiment. Doctors can provide CRM content for patients while improving treatment completeness by using the Mobidoc doctor client in the case of remote medical treatment or face-to-face treatment for patients visiting the hospital.

If you have access to the doctor client 100, such as when you have time or are in the middle of a medical appointment, the process of creating a feed can be started by pressing the create button 401 on the doctor client 100. . In this case, you can start writing the feed within the app or by opening Mobidoc Web (not shown) and selecting Write. Of course, it is also possible to directly access a separate Mobidoc web page rather than the doctor client (100) and select writing (401).

When the doctor client and hospital (nurses/administrative staff, etc.) clients are unified (integrated), feed creation (writing) is activated only when logging in with an authenticated doctor ID, and for other IDs, feed creation is not exposed and is used in CRM. The Send Only feature may be enabled.

Through the Mobidoc web page or the Mobidoc doctor client app (APP), you can view feeds (402) that have already been published (sent) by the doctor, and you can send the feeds (402) through the image-related request (403) button. When using , you can request the necessary images from Mobidoc.

According to this embodiment, when there is a gap between treatments, I frequently write articles (feeds) about insights that come to mind at the moment, things I want to say to patients while treating them, and information that needs to be repeatedly explained or understood to patients on a regular basis. Because it can be stored and issued (transmitted) to the desired person, the relationship between doctors and patients is maintained and developed, and the hospital's completeness of treatment for patients is improved.

Figure 5 shows a screen 500 presenting a list of created feeds.

A button 510 to search for existing writing and publishing feeds that you want to send to patients and a new feed writing button 520 are provided. When the write button 520 is pressed, the feed writing process described in Figure 6 and below begins.

Figure 6 is a screen 600 for starting to create a feed. On the page that has been created, the doctor can enter the title and subtitle of the feed, and enter a cover image through button 601. Then freely enter text in the edit window. It is similar to the interface for writing posts on SNS or writing new posts on blogs. However, the strengths provided differently by the embodiments are improved convenience in the process of finding and inserting images after selecting the cover image insertion button 601 or the body image insertion button 602, and providing the writer with information about image copyright. Removing the burden, etc.

According to embodiments, in this case, the differentiated service provided by Mobidoc provides an archive of pre-prepared images and pictures (potentially necessary for creating medical feeds) to the writing doctor. These archives are stored and managed in the storage unit 130 of the device 100.

Feed posts, which are content containing medical information in the Mobidoc client, are written by expert doctors, but there may not be enough images for each individual user, and general illustrations or photos may not be used due to copyright. there is. Furthermore, because medical images may be the patient's personal information, they cannot be used for any images or writing.

Accordingly, according to embodiments, Mobidoc builds an archive of medical images that it has produced in advance or has acquired the copyright for and has been processed so as not to be personal information, so that doctors who are individual users of Mobidoc can use the images/videos. We provide this content so that there are no problems.

The doctor can select and input images to be inserted into the cover image and main text by selecting the image insertion button (601 or 602, etc.) at the necessary time and location while writing.

Feed image search and selection interface

Figure 7 illustrates image search, selection, and insertion processes provided during feed creation according to one embodiment.

According to one embodiment, while creating a feed, the doctor selected the image insertion button 602 and an image selection window 700 popped up.

One of the distinctive functions provided by the embodiments is a group selection interface (710) that allows the doctor to select a group by grouping the images on the left according to certain criteria, for example, by body part, so that the doctor can easily and intuitively select the image to be inserted. ) is provided.

Selectable groups include body part (location), body function (role), type of disease, human body function (role), such as the whole body, upper limbs, lower limbs, spine, head and neck, digestive system, urinary system, respiratory system, cardiovascular system, and motor system. It includes a variety of behavioral categories related to activities (such as exercise, sleep, driving, brushing teeth, etc.).

Additionally, according to one embodiment, all illustrations/videos/images stored according to the group selected by the writing doctor are selectively exposed and presented at the viewing location 713. The group selection interface 710 may also be referred to as a filtering interface in this sense.

In the group selection interface 710, a specific group is selected first, and additional tags for secondary filtering are provided on the right side. For example, basic images, actual medical image tags (711) such as X-rays, CTs, and MRIs, and Mobidoc illustration tags (712) that draw and save body parts or diseases in Mobidoc can be presented for secondary filtering. there is. Accordingly, doctors writing feeds can easily and quickly find and select the images they want to use in their posts. In this way, Mobidoc provides the writing doctors with images drawn by themselves or holding the copyright in some way, so the writing doctors can intuitively select and use the illustrations they want without worrying about copyright.

Of course, if necessary, a button 720 to load an image stored on the doctor's PC is also provided. Additionally, if you determine that there is no suitable image in your PC or Mobidoc archive, you can request Mobidoc to draw an image through the Request Image (730) button.

Figure 8 shows the process of presenting and selecting images according to the embodiment described above. If the user selects the 'upper limb' part (810) from the left group, the entire screen of the upper body is presented, and if the Mobidoc illustration (8820) is selected from the right, it is not a medical image or general image, but is produced by Mobidoc. Only the provided illustrations are selected and provided.

In this way, the doctor writing the article can select an illustration that matches the 'upper limb' region to be inserted in the article he or she writes according to the purpose and content of the article without fear of copyright infringement. You can mark images you use frequently as favorites so you can easily use them later.

Feed image request

Meanwhile, in some embodiments, as described above, if the doctor determines that an appropriate image is not in the patient's PC or Mobidoc archive, he or she may press the Request Image 730 button to request image creation and provision. Figure 9 illustrates a process in which a doctor or the like who creates feed content explains the image he or she needs and requests an image from Mobidoc, according to one embodiment.

If a doctor applies (requests an image) by explaining the image he/she wants to Mobidoc's illustration production artists, the artists will create it, store it in the Mobidoc archive, and provide it to the requesting doctor. The request form uses the interface 910 to load or directly draw the image needed for explanation, and can also be drawn directly in the drawing field 920 if necessary. This part is a similar process to the Paint app, where you can paste images and draw. In order to explain the request in detail, you can write your request to the artist in the writing field 930, and the artist will use it as a reference in your work.

Granting and automatic granting of feed image tags

Meanwhile, according to some embodiments, when creating an image by request, the aforementioned filtering tags may be created and assigned to each image. Just as hashtags are assigned to posts or images and used for later searches, this is to provide convenience and accuracy when searching for images in the image archive in the future.

10 to 12 are diagrams for explaining a process of manually and/or automatically extracting tags of images from a feed created or being created according to an embodiment and using them for later image search.

Figure 10 shows the created and published feed. The front part 1010 and the back part 1020 of the feed are partial areas of one feed. In area 1010, there are the title 'Is disc disease really a disease that can be cured?', summary, and main text, through which the operator can manually extract tags. For example, the extracted tags may be ‘disk’, ‘waist’, etc.

In the right area 1020, tags for the image 1021 may be extracted from the text in the area before (1022) or behind (1023) the image 1021. Even at the stage when a Mobidoc artist first draws an image at the request of a doctor, tags can be provisionally entered, and experts such as the doctor who requested the image can review and confirm them to be saved as tags. there is.

Meanwhile, another differentiator of Mobidoc according to the embodiment is the 'image tag extraction function'. Assigning filter attributes such as hashtags to “Mobidoc illustrations” drawn by Mobidoc artists according to the request of the writing doctor is basically a manual process, so a lot of resources can be invested, and only medical personnel with medical knowledge can use hashtags. Because tag work can be confirmed, there are limits to the consistency and accuracy of tag classification and processing speed if it is done manually. Giving tags is important because if the tags are not accurate, it can cause problems when searching and using the image later. Therefore, according to embodiments, tag extraction and assignment are at least partially assisted by AI technology.

According to one embodiment, the created device 100 automatically recognizes the AI image of the Mobidoc illustration (such as Figure 1021) and/or extracts semantics from the text around the illustration (such as part 1022 or 1023). Extract hashtags. Therefore, it reduces the resources required for hashtag work when registering an image and makes it easier to find the image you want when writing a post.

There may be various models for extracting keywords to be tags from images and/or feed posts, but the processor 120 of the device 100 according to one embodiment utilizes BERT (Bidirectional Encoder Representations from Transformers). BERT is a transformer-based machine learning technique designed by Google in 2018 for natural language processing. The biggest feature of BERT is that it can understand the context by bidirectionally learning the structure of the entire sentence, and it was confirmed to be suitable for medical imaging and illustrations in the medical field according to the embodiments. Figure 11 shows this interactive learning process.

What plays a key role in BERT's interactive learning is the MLM (Masked Language Model) applied to Pre-Training (1110). MLM is the task of predicting key words given a set of words. To train bidirectional learning, we simply mask a percentage of the input tokens at random and then predict the masked tokens.

The MLM operation method and process (1111 and 1112) are explained as follows. 15% of the entire sequence is randomly selected as MASK tokens. Then, 80% of the changed MASK tokens are converted to MASK tokens, 10% are changed to random words, and 10% are left unchanged as the original words. Learning progresses as this process develops into a fine tuning (1120) process.

Referring to FIG. 12, a detailed example tested on medical images will be described. The texts included in the feed posts (1210 and 1220) about tendonitis/tenosinovitis were trained as follows.

Original text: The part at the end of a muscle that touches the bone is called a tendon.

(80%) The part where the muscle touches the bone is called [MASK].

(10%) The area where the muscle touches the bone is called the skin.

(10%) The part at the end of the muscle that touches the bone is called a tendon.

When applying this model, it was successful in extracting the necessary keywords from the entire context, but it was confirmed that it was not suitable as a hashtag for the actual image (1230) included in the corresponding part. In particular, in the case of articles with multiple images, the suitability was confirmed to be even lower. Therefore, according to the embodiment, a higher weight is given to sentences near the image, that is, immediately before or after, especially immediately after. And for keywords extracted from the entire article, the weight is lowered and re-trained. In this example experiment, the accuracy of extracted hashtags was greatly improved using this method. In the example of Figure 12, the words 'tendon' and 'DeQuerre's disease' were extracted for image 1230. At this level, automatic extraction will be sufficient to present a draft for later inspection by medical personnel.

Publishing (transmission) and management of feeds

The feed that has been completed and published is basically managed as the feed of the relevant doctor member. As the feed's original function, it is sent to customers who follow the doctor (existing patients, general Mobidoc customers, selected customers who want the doctor to send their feed, etc.).

There are many benefits that doctors gain from publishing articles using the Mobidoc feed provided by Mobidoc. As mentioned earlier, there are a lot of waiting patients and the treatment time available for that patient is short, but when you really want to tell the patient more about the disease or treatment, you can save time and provide enough information to the patient by sending a pre-written feed to the patient. I can explain. Even from the perspective of a patient lacking medical knowledge, a feed that can be viewed later, slowly and repeatedly if necessary, is more helpful than a verbal explanation from a doctor who speaks quickly while the patient is not in a state of panic. This creates trust and loyalty between the doctor and the patient.

According to one embodiment, in the doctor client 1300 of FIG. 13, in the area 1310 where the treatment is completed and the prescription is selected for delivery and payment, a pop-up 1320 asks whether the current treatment copy will be sent to the patient. When the area 1321 is selected to send the feed, a feed selection and delivery pop-up 1330 is provided to help send the feed.

In the interface for selecting patients to receive feeds, 'patients just treated' are listed by time period (in order of most recent), allowing you to quickly search for patients who have just seen patients and send an appropriate feed. In addition, by providing an interface to directly select the 'patient currently being treated' separately, the doctor can send a feed appropriate for that patient before or immediately after the patient's treatment ends.

For reference, if you look at the VOC (Voice of Customer) of many patients, there are many cases in which they do not remember or misunderstand what the doctor explained about their illness or what precautions they gave them during treatment. Mobidoc efficiently saves doctors' time and helps doctors provide continuous care to patients, thereby increasing patients' satisfaction with their doctors' treatment and further increasing their trust in doctors and hospitals. In this respect, Mobidoc Feed also functions as a service that forms an important axis of hospital CRM (Customer Relationship Management).

When 'Send Feed' is performed on a pseudo-client, selection of the object to be sent or the feed to be sent can either be made first.

When selecting a recipient (customer, patient) to send to, you can enter a part of the cell phone number that you remember, and the patient can be selected through search/autocomplete (recommendation). If you type the patient's name, the search results will be displayed during the search and you can enter everything. You can make a choice without having to do it. Furthermore, when there is a person with the same name, other information about the patient (such as residence, age/gender, diagnosis, visit date, reservation date, characteristics, etc.) can be additionally exposed to help the doctor make the right choice. Timely recommendations can also be made through different interfaces, such as patients who just left, patients who were seen a while ago, patients who were seen today, patients who have an appointment today, and patients who have a reservation for tomorrow.

Furthermore, it is also possible to group patients and select them as a group, such as ‘patients with cervical disc herniation at our hospital’, ‘patients who have revisited our hospital more than twice’, ‘patients subscribing to my column’, ‘patients living in Donae-dong, Deokyang-gu, Goyang-si’, etc. do. Just as you can select multiple feeds, you can also select multiple patients.

Sending the feed you are currently sending to patients who have already received it may result in spam. So, if a patient is selected, a feed is selected, and the specific feed selected has ever been sent to the patient selected to receive it, the message “This feed has already been sent to this patient has already been sent.” You can also prevent mistakes by giving a warning, such as “Do you still want to send it?” Options such as sending a feed without already sending a feed among multiple feeds, or sending a feed without a feed to a patient who has previously received a selected feed among multiple recipients are also possible.

See a specific example. According to one embodiment, when a patient to receive a feed is selected from the area 1410 and a feed to be sent is selected from the list 1420, a list of feeds 1430 previously sent to the selected patient is also displayed, so that the doctor can Confirm whether to repeatedly send the previously received feed. In some cases, a pop-up (1440) is provided to confirm whether to resend a feed that was recently sent. Even when the doctor selects the feed sending area 1450 through this process, if there are duplicate feeds, the device 100 removes the previously sent duplicate feeds and selects whether to send them in the area 1460. Then, the actual sending of the feed takes place.

What can be included in your feed and how it can be used

Figure 15 is an example of a feed screen sent to and displayed on the patient terminal 101.

In the feed, not only the above-mentioned images, but also YouTube videos (see area 1010 in Figure 10), the doctor's blog, and hospital website information (Mobidoc partnership) are exposed, so patients who are continuously visited by doctors can be made.

Furthermore, within the published feed, you can communicate between doctors and patients and between patients by leaving comments and DMs directly to the doctor who wrote the article, and you can also apply for direct treatment with the doctor through 'Mobidoc Clinic'. Doctors and hospitals build relationships with patients, such as by being able to follow the doctor.

According to the embodiment, in addition to the comment window within the feed published during the feed content transmission process, various networking may be possible. Social networking takes place in various relationships such as doctor-patient, doctor-doctor, and patient-patient, etc. You can also receive notifications about patients or other doctors who liked your post, and you can comment back on such feedback.

Meanwhile, doctors can transmit not only the feeds they have written, but also feeds written by other doctors to the patients they wish to send to. For this purpose, it also includes the ability to bookmark feeds that you need (such as those you need to send to your patients later).

Allowing someone else (another doctor) to send a feed can be optionally changed according to Mobidoc's policy. Since the original writer is retained and only forwarded, the doctor who wrote the original article can also inform patients (Mobidoc members) about themselves, their hospital, and their thoughts, so Mobidoc allows the issuance of such forwarding. However, depending on future policy changes, it may be changed in various ways, such as selectively allowing such forwarding issuance, obtaining permission from the doctor who wrote the original article, or distributing profits if any.

Separate feed contents that can be included as part of CRM configuration

As shown in FIG. 15, the CRM message may include disease-related information, health information, and other specialized articles sent by the relevant doctor 1501 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 1510 as shown in FIG. 15, 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 may be 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. By requesting remote treatment, even briefly, the patient consults once again 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 medication he or she is taking. The patient then 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 in field 1511 of FIG. 15 as part of the CRM.

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 1511 only when a return visit is made within a pre-specified period of time, for example, within 30 days when remote treatment is permitted, counting back from the time the shown 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 guidance 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 1511 is shown in FIG. 16.

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 is waiting 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 16, 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 the 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 16 shows the appearance of the patient terminal (1610) 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 care that may be overlooked by patients can be reduced and health can be prevented from deteriorating.

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: CRM content provision device
101: Patient terminal
102: Doctor terminal
103: Hospital terminal
110: communication interface
120: processor

Claims (11)

In the computer implementation method,
Providing a first interface for creating Customer Relationship Management (CRM) content in connection with a medical institution client assigned to a hospital or doctor;
Storing the generated CRM content in a storage unit; and
A step of transmitting the CRM content to be sent to the recipient according to the selection of the recipient and the CRM content to be sent.
Including a computer implemented method. According to paragraph 1,
Providing a second interface that is linked to the first interface and provides image search and selection functions for insertion into the CRM content.
A computer-implemented method further comprising: According to paragraph 2,
and wherein results provided upon the image search are filtered by at least one tag information associated with the image. According to paragraph 2,
Providing a third interface, distinct from the second interface, for requesting creation of a new image
A computer-implemented method further comprising: According to paragraph 1,
A step of a processor extracting a tag for an image included in the CRM content while storing the generated CRM content in a storage unit.
A computer-implemented method further comprising: According to clause 5,
The extraction is a computer-implemented method of obtaining at least one keyword for the image through a BERT (Bidirectional Encoder Representations from Transformers) model and extracting it as the tag. According to clause 5,
A computer-implemented method that assigns weight to text within a predetermined number of words after an image in learning the BERT model. According to paragraph 1,
A step of providing identification information about the patient who received the treatment at the end of the treatment and selecting whether to send the CRM content to the patient.
A computer-implemented method further comprising: 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. A non-transitory computer-readable storage medium containing instructions for performing the method of any one of claims 1 to 9. processor;
a communication interface operatively coupled to the processor 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 processor is configured to perform the method of any one of claims 1 to 9.