Customized chatbot generation for medical professionals

A system converts medical forms into customized chatbots to address the challenge of capturing patient data efficiently, reducing errors and enhancing EHR integration by auto-populating fields and validating responses.

WO2025151904A1PCT designated stage expired Publication Date: 2025-07-17MEDICALMINE
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
PCT/US2025/011473
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-01-11
Filing Date
2025-01-13
Publication Date
2025-07-17

AI Technical Summary

Technical Problem

Medical offices lack the skills to develop custom chatbots for efficiently capturing patient data from traditional paper-based intake forms, leading to tedious filling, errors, and language barriers.

Method used

A system that converts existing medical forms into a customized chatbot, capable of auto-populating fields, performing validation checks, and integrating with drug and lab databases to validate patient responses, while offering translation and speech-to-text options.

Benefits of technology

Facilitates efficient data capture with reduced errors, enhances patient engagement, and improves integration with EHR systems by automating the transition from paper to digital formats.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2025011473_17072025_PF_FP_ABST
    Figure US2025011473_17072025_PF_FP_ABST
Patent Text Reader

Abstract

While chatbots can be beneficial in efficiently capturing patient data, in practical EHR systems, medical offices may not have the skills to develop custom chatbots for the clinic. Techniques described in this paper solve that problem by presenting a system to take the existing forms used in clinical practice, and generate a custom chatbot corresponding to those forms, for that medical practice.
Need to check novelty before this filing date? Find Prior Art

Description

CUSTOMIZED CHATBOT GENERATION FOR MEDICAL PROFESSIONALSBACKGROUND

[0001] Intake forms and patient questionnaires are a requirement at all healthcare facilities and serve as vital documents for physicians to have a well-rounded picture of their patient's health. These forms contain information about patient demographics, insurance, past illnesses and hospitalizations, allergies, consent forms, payments, and other information for new / retuming patients before their visit.

[0002] The problem with the traditional forms is that they are tedious and require patients to fill them out on pen and paper. This can lead to fatigue and erroneous responses. Some questions can be difficult to understand - either due to the manner in which they are asked or due to language barriers. These forms must then be entered into digital portals, leading to potential errors.SUMMARY

[0003] While chatbots can be beneficial in efficiently capturing patient data, in practical EHR systems, medical offices may not have the skills to develop custom chatbots for the clinic. Techniques described in this paper solve that problem by presenting a system to take the existing forms used in clinical practice, and generate a custom chatbot corresponding to those forms, for that medical practice.

[0004] A chatbot interface is an alternative to structured questionnaires or forms. Engines convert a questionnaire / intake form into a chatbot and collect the required information from the patient. The chatbot can then be embedded into the practice's website or sent via a link to the patient.

[0005] A translation engine will take in a prepared format of a questionnaire from the medical office and generate a chatbot customized for the medical center. The chatbot will have the following features:

[0006] It can auto-populate fields that are already part of the digital record and verify with the patient if those fields are correct or if the patient would like to modify any of them.

[0007] It can auto-populate demographic / insurance information if given a picture of the driver's license / insurance card.

[0008] It also goes through the intake form, has the capability to understand the logic, and asks the patient only relevant follow-up questions if the patient has indicated that they have a condition.[009| To prevent common forms of error, it performs validation checks on patient responses and prompts the user to recheck the response.

[0010] It uses fuzzy search to match patient response to existing drugs and diagnoses and auto completes / suggests responses.

[0011] It is integrated with the drug and lab database to validate the dosage, frequency and names of the drugs.

[0012] It has a novel scale-based rating widget that accurately captures patients’ complaints (for e.g.: rating their pam / sensitivity).

[0013] The bot can also translate the questions into another language the patient prefers. It also has a speech-to-text option that allows patients to fill out sections verbally, thus catering to the needs of patients who have trouble with traditional visual-based forms.BRIEF DESCRIPTION OF DRAWINGS

[0014] FIG. 1 depicts a diagram of an example of a chatbot generator.DETAILED DESCRIPTION

[0015] FIG. 1 depicts a diagram 100 of an example of a chatbot generator. The diagram 100 includes a raw questionnaire parser 102, a template parser 104, an Optical Character Recognition (OCR) document parser 106, a generated chatbot engine 108. an Electronic Health Records system 110, an input review engine 112, a drug datastore 1 14, an address datastore 116, an LLM component datastore 118, and a web crawler datastore 120.

[0016] The diagram 100 indicates a raw questionnaire is provided to the raw questionnaire parser 102 and a JSON template questionnaire is provided from the raw questionnaire parser 102 to the template parser 104. The diagram 100 indicates optical documents are provided to the OCR document processor 106. Optical documents can include a driver’s license, insurance card, and other documents that may be provided in analog form to a healthcare provider or agent thereof, or that are collected in analog form by the healthcare provider or agent thereof. The diagram 100 illustrates the generated chatbot engine 108 receiving output from the template parser 104 and the OCR document processor 106 and being provided with medical data and demographic data. The medica data and demographic data may or may not be provided via the OCR document processor 106.

[0017] In the diagram 100, the generated chatbot engine 108 includes a procedurally generated UI 122, a JSON questionnaire instance 124, a fuzzy search subengine 126, and a validation subengine 128. The generated chatbot engine 108 is coupled to the EHR system 110, which includes a patient datastore 130, and the datastores 114-120. The input review engine 112 is also coupled to the generated chatbot engine 108.

[0018] The raw questionnaire parser 102 takes the raw questionnaire in any applicable format and converts it into a standardized JSON template. The template parser 104 takes in the JSON template and maps each question type to a User Interface (UI) element for representation in the procedurally generated UI 122. The backend of the generated chatbot engine 108 creates the JSON questionnaire instance 124 using the input review engine 112. The JSON questionnaire instance 124 is coupled to the drug, address, LLM component, and web crawler datastores 114- 120 to perform validation and fuzzy search via the fuzzy search subengine 126 on inputs to the generated chatbot engine 108. Information relevant to a patient is stored in the patient datastore 130 of the EHR system 110.

[0019] The components illustrated in diagram 100 can be connected via a network. The network and other networks discussed in this paper are intended to include all communicationpaths that are statutory (e.g., in the United States, under 35 U.S.C. 101), and to specifically exclude all communication paths that are non-statutory in nature to the extent that the exclusion is necessary7for a claim that includes the communication path to be valid. Known statutory communication paths include hardware (e.g., registers, random access memory (RAM), nonvolatile (NV) storage, to name a few), but may or may not be limited to hardw are.

[0020] The network and other communication paths discussed in this paper are intended to represent a variety of potentially applicable technologies. For example, the network can be used to form a network or part of a network. Where two components are co-located on a device, the network can include a bus or other data conduit or plane. Where a first component is co-located on one device and a second component is located on a different device, the netw ork can include a wireless or wired back-end network or LAN. The network can also encompass a relevant portion of a WAN or other network, if applicable.

[0021] The devices, systems, and communication paths described in this paper can be implemented as a computer system or parts of a computer system or a plurality of computer systems. In general, a computer system will include a processor, memory, non-volatile storage, and an interface. A typical computer system will usually include at least a processor, memory, and a device (e.g., a bus) coupling the memory to the processor. The processor can be, for example, a general-purpose central processing unit (CPU), such as a microprocessor, or a special-purpose processor, such as a microcontroller.

[0022] The memory can include, by way of example but not limitation, random access memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). The memory can be local, remote, or distributed. The bus can also couple the processor to non-volatile storage. The nonvolatile storage is often a magnetic floppy or hard disk, a magnetic-optical disk, an optical disk, a read-only memory (ROM), such as a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory during execution of software on the computer system. The non-volatile storage can be local, remote, or distributed. The non-volatile storage is optional because systems can be created with all applicable data available in memory.

[0023] Software is ty pically stored in the non-volatile storage. Indeed, for large programs, it may not even be possible to store the entire program in the memory. Nevertheless, it should be understood that for software to run, if necessary, it is moved to a computer-readable location appropriate for processing, and for illustrative purposes, that location is referred to as thememory in this paper. Even when software is moved to the memory' for execution, the processor will typically make use of hardware registers to store values associated with the software, and local cache that, ideally, serves to speed up execution. As used herein, a software program is assumed to be stored at an applicable known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as "implemented in a computer- readable storage medium." A processor is considered to be "configured to execute a program" when at least one value associated with the program is stored in a register readable by the processor.

[0024] In one example of operation, a computer system can be controlled by operating system software, which is a software program that includes a file management system, such as a disk operating system. One example of operating system software with associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond. Washington, and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux operating system and its associated file management system. The file management system is typically stored in the non-volatile storage and causes the processor to execute the various acts required by the operating system to input and output data and to store data in the memory . including storing files on the non-volatile storage.

[0025] The bus can also couple the processor to the interface. The interface can include one or more input and / or output (I / O) devices. Depending upon implementation-specific or other considerations, the I / O devices can include, by way of example but not limitation, a keyboard, a mouse or other pointing device, disk drives, printers, a scanner, and other I / O devices, including a display device. The display device can include, by way of example but not limitation, a cathode ray tube (CRT), liquid crystal display (LCD), or some other applicable known or convenient display device. The interface can include one or more of a modem or network interface. It will be appreciated that a modem or network interface can be considered to be part of the computer system. The interface can include an analog modem, ISDN modem, cable modem, token ring interface, satellite transmission interface (e.g., "direct PC"), or other interfaces for coupling a computer system to other computer systems. Interfaces enable computer systems and other devices to be coupled together in a network.

[0026] The computer systems can be compatible with or implemented as part of or through a cloud-based computing system. As used in this paper, a cloud-based computing system is a system that provides virtualized computing resources, software and / or information to end userdevices. The computing resources, software and / or information can be virtualized by maintaining centralized services and resources that the edge devices can access over a communication interface, such as a network. "Cloud" may be a marketing term and for the purposes of this paper can include any of the networks described herein. The cloud-based computing system can involve a subscription for services or use a utility pricing model. Users can access the protocols of the cloud-based computing system through a web browser or other container application located on their end user device.

[0027] A database management system (DBMS) can be used to manage a datastore. In such a case, the DBMS may be thought of as part of the datastore, as part of a server, and / or as a separate system. A DBMS is typically implemented as an engine that controls organization, storage, management, and retrieval of data in a database. DBMSs frequently provide the ability to query, backup and replicate, enforce rules, provide security, do computation, perform change and access logging, and automate optimization. Examples of DBMSs include Alpha Five. DataBase, Oracle database, IBM DB2, Adaptive Server Enterprise, FileMaker, Firebird, Ingres, Informix, Mark Logic, Microsoft Access, InterSystems Cache, Microsoft SQL Server, Microsoft Visual FoxPro, MonetDB, MySQL, PostgreSQL, Progress, SQLite, Teradata, CSQL, OpenLink Virtuoso, Daffodil DB, and OpenOffice.org Base, to name several.

[0028] Database servers can store databases, as well as the DBMS and related engines. Any of the repositories described in this paper could presumably be implemented as database servers. It should be noted that there are two logical views of data in a database, the logical (external) view and the physical (internal) view. In this paper, the logical view is generally assumed to be data found in a report, while the physical view is the data stored in a physical storage medium and available to a specifically programmed processor. With most DBMS implementations, there is one physical view and an almost unlimited number of logical views for the same data.

[0029] A DBMS typically includes a modeling language, data structure, database query language, and transaction mechanism. The modeling language is used to define the schema of each database in the DBMS, according to the database model, which may include a hierarchical model, network model, relational model, object model, or some other applicable known or convenient organization. An optimal structure may vary depending upon application requirements (e.g., speed, reliability, maintainability, scalability, and cost). One of the more common models in use today is the ad hoc model embedded in SQL. Data structures can include fields, records, files, objects, and any other applicable known or convenient structures for storing data. A database query language can enable users to query databases and can includereport writers and security mechanisms to prevent unauthorized access. A database transaction mechanism ideally ensures data integrity, even during concurrent user accesses, with fault tolerance. DBMSs can also include a metadata repository; metadata is data that describes other data.

[0030] As used in this paper, a data structure is associated with a particular way of storing and organizing data in a computer so that it can be used efficiently within a given context. Data structures are generally based on the ability of a computer to fetch and store data at any place in its memory’, specified by an address, a bit string that can be itself stored in memory and manipulated by the program. Thus, some data structures are based on computing the addresses of data items with arithmetic operations; while other data structures are based on storing addresses of data items within the structure itself. Many data structures use both principles, sometimes combined in non-trivial ways. The implementation of a data structure usually entails writing a set of procedures that create and manipulate instances of that structure. The datastores. described in this paper, can be cloud-based datastores. A cloud-based datastore is a datastore that is compatible with cloud-based computing systems and engines.

[0031] A computer system can be implemented as an engine, as part of an engine or through multiple engines. As used in this paper, an engine includes one or more processors or a portion thereof. A portion of one or more processors can include some portion of hardware less than all the hardware comprising any given one or more processors, such as a subset of registers, the portion of the processor dedicated to one or more threads of a multi -threaded processor, a time slice during which the processor is wholly or partially dedicated to carry ing out part of the engine's functionality, or the like. As such, a first engine and a second engine can have one or more dedicated processors or a first engine and a second engine can share one or more processors with one another or other engines. Depending upon implementation-specific or other considerations, an engine can be centralized or its functionality7distributed. An engine can include hardware, firmware, or software embodied in a computer-readable medium for execution by the processor that is a component of the engine. The processor transforms data into new data using implemented data structures and methods, such as is described with reference to the figures in this paper.

[0032] The engines described in this paper, or the engines through which the systems and devices described in this paper can be implemented, can be cloud-based engines. As used in this paper, a cloud-based engine is an engine that can run applications and / or functionalities using a cloud-based computing system. All or portions of the applications and / or functionalities can bedistributed across multiple computing devices and need not be restricted to only one computing device. In some embodiments, the cloud-based engines can execute functionalities and / or modules that end users access through a web browser or container application without having the functionalities and / or modules installed locally on the end-users' computing devices.

[0033] Medical offices require patients to fill out a multitude of paper-based healthcare, insurance related and privacy forms. These forms are later migrated into an electronic format to be able to integrate with EHR workflows. Advantageously, the chatbot generator engine 108 eliminates or ameliorates manual configuration, expediting onboarding to a healthcare system. Whether embedded in websites or within EHR systems, the techniques described provide a swift transition for each of these forms.

[0034] Advantageously a chatbot generated by taking in an existing questionnaire facilitates follow-up, error check, spelling, name, dosage, etc. For example, a healthcare provider can input a questionnaire and a chatbot can be generated for that specific healthcare provider or agent thereof. The chatbot could be accessible, e.g.. via a link on a website for the healthcare provider.

[0035] Advantageously, a chatbot generated using the described techniques can provide possible names and dosages of drugs because, as described above, the chatbot is coupled to drug and lab datastores for validation of dosage, frequency, methodology, names, etc. Moreover, fuzzy spellchecking is significant for drug names due to common misspelling.

[0036] The chatbot can also provide access to a rating system for complaints (e.g., pain), ask follow-ups, compare to past diagnosis, match lay terms to diagnosis, and provide data to a UI, touchscreen, or iterative UI. A standardized format for questionnaires can reduce error and improve efficiency, as well. The chatbot can also navigate through a decision tree to eliminate redundancies, save time, etc.

Claims

CLAIMSWhat is claimed is:

1. A method comprising: taking input from a form for a questionnaire and medical data; converting the form into an interactive chatbot interface; providing the interactive chatbot to interact in a conversational manner with a patient; interfacing with a datastore of patient health information and saving results of the interaction in an electronic health record (HER) system.

Citation Information

Patent Citations

  • System for providing chatbot-based nursing service and method thereof

    KR102543467B1

  • Artificial intelligence assisted service provisioning and modification for delivering message-based services

    US20200244605A1

  • Conversational virtual healthcare assistant

    US20210232361A1

  • Techniques for updating a health-related record of a user of an input / output device

    US20220108775A1