Abstract: Systems and methods for to optimize healthcare services based on context and constraints are disclosed. The system enables registration and appointments of users with medical professional(s) across networked healthcare facilities for healthcare support services. Based on appointment type, the system segregates and intelligently guide the routing of patients using navigation map(s), wherein the segregation logic apply out-patient department/clinical process protocol to identify appropriate department for a patient based on symptom(s). The system further provides real time information on appointments including waiting time, resource availabilities and current status of appointments. The system further learns the pattern of appointments, scheduling(s), and consultations, and further enables appointments based on historical data and generates a recommendation on health and safety measures (or epidemic alerts), thereby providing enhanced patient experience or reduced anxiety level with reduced wait time where there is a huge footfall of patients, particularly people with diverse needs, and who are illiterate.
DESC:FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention:
SYSTEMS AND METHODS TO OPTIMIZE HEALTHCARE SERVICES BASED ON CONTEXT AND CONSTRAINTS
Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India
The following specification particularly describes the invention and the manner in which it is to be performed.
CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY
[001] The present application claims priority from Indian patent application no. (201721002309), filed on January 20, 2017, the complete disclosure of which, in its entirety is herein incorporated by reference.
TECHNICAL FIELD
[002] The disclosure herein generally relates to healthcare service management, and, more particularly, to systems and methods to optimize healthcare services based on context and constraints.
BACKGROUND
[003] In the current scenario, people are typically on the go, and the way appointments are being made, are either modified and/or confirmed. It is also noticed at times that appointments are uncertainly postponed causing unnecessary delay. Further, it is not always that immediate appointments are confirmed and it may be seen that there is typically a time lag between appointment requests being made and appointment times being confirmed.
[004] One such scenario where appointments are made is in medical domain, particularly in hospitals and/or clinics. Typically, a patient (or user) is required to book or seek a prior appointment with a medical professional (e.g., a physician/doctor). Such appointments may be influenced by other appointments and availability of the medical professional. And although, users often make appointments with a known medical professional (or hospital/family doctor), it is not unusual for users to repeat basic information all over again. Various attempts have been made to improve appointment scheduling. However, with an increase in huge patient footfalls in out-patient departments (e.g., approximately 10,000 patients per day), this has simply resulted in crowd gathering and inconveniences. Patients have to wait for days to seek appointments. Due to a significant increase in wait times for appointments, this has resulted in higher anxiety for patients. Moreover, majority of the patients typically belong to rural areas, they may not have sought prior appointments indicating relevant conditions / symptoms, and may not know which department or doctor to visit. Such patients may have varied needs and are many a times found visiting incorrect departments or doctors. Lack of availability of medical professionals, in-time consultations, infrastructural issues, and missing information have further led to chaos in public and care provider management.
SUMMARY
[005] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, there is provided a processor implemented method optimizing healthcare services based on context and constraints. The method comprises registering at a healthcare services management system, one or more patients using a corresponding unique identifier associated with each of the one or more patients; obtaining a request from a computing device associated with at least one patient from the one or more patients, wherein the request comprises at least one of a healthcare related query and one or more vital signs obtained pertaining to the at least one patient; querying, based on the request, a centralized healthcare database associated with the healthcare services management system, to obtain an availability status of at least one of one or more healthcare support services and one or more medical professionals associated with one or more networked healthcare facilities integrated with the healthcare services management system; generating based on the availability status, a list comprising at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals associated with the one or more networked healthcare facilities, wherein the list further comprises corresponding one or more available appointment times associated with the least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals and corresponding one or more appointment types; enabling, using a single window exit counter (SWEC) interface, a selection of the at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals, the corresponding one or more available appointment times, and the corresponding one or more appointment types from the list; upon the selection by the at least one patient, allocating at least one available appointment with an expected time to the at least one patient from the one or more available appointment times; and facilitating the allocated at least one available appointment between (i) at least one of the one or more medical professionals and the one or more healthcare support services and (ii) the at least one patient based on the selection of at least one appointment type.
[006] In an embodiment, the method may further comprise dynamically computing, based on one or more criteria, an updated expected time of the allocated at least one available appointment, wherein the one or more criteria comprises information pertaining to one or more prior appointments and one or more statuses associated with the one or more prior appointments.
[007] In an embodiment, the method may further comprise storing in the centralized healthcare database, information pertaining to one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient.
[008] In an embodiment, the method may further comprising facilitating, using the single window exit counter (SWEC) interface, the information pertaining to the one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient across the one or more networked healthcare facilities for subsequent requests obtained from the at least one patient for subsequent appointments.
[009] In an embodiment, wherein the list is generated based on historical data comprising at least one of a feedback associated with at least one of the one or more medical professionals and the one or more healthcare support services across the one or more networked healthcare facilities, wherein the historical data is stored in the centralized healthcare database.
[010] In an embodiment, the method may further comprise dynamically updating the centralized healthcare database based on one or more feedback submitted by one or more users.
[011] In another aspect, there is provided a healthcare service management system optimizing healthcare services based on context and constraints. The system comprises a memory storing instructions and a centralized healthcare database; one or more communication interfaces; and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to execute one or more modules comprising: a registering module that is configured to register at the healthcare services management system, one or more patients using a corresponding unique identifier associated with each of the one or more patients; and an appointment module that is configured to: obtain a request from a computing device associated with at least one patient from the one or more patients, wherein the request comprises at least one of a healthcare related query and one or more vital signs obtained pertaining to the at least one patient; query, based on the request, the centralized healthcare database associated with the healthcare services management system, to obtain an availability status of at least one of one or more healthcare support services and one or more medical professionals associated with one or more networked healthcare facilities integrated with the healthcare services management system; generate based on the availability status, a list comprising at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals associated with the one or more networked healthcare facilities, wherein the list further comprises corresponding one or more available appointment times associated with the least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals and corresponding one or more appointment types; enable, using a single window exit counter (SWEC) interface, a selection of the at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals, the corresponding one or more available appointment times, and the corresponding one or more appointment types from the list; upon the selection by the at least one patient, allocate at least one available appointment with an expected time to the at least one patient from the one or more available appointment times; and facilitate the allocated at least one available appointment between (i) at least one of the one or more medical professionals and the one or more healthcare support services and (ii) the at least one patient based on the selection of at least one appointment type.
[012] In an embodiment, the system may further comprise a queue management module that is configured to dynamically compute, based on one or more criteria, an updated expected time of the allocated at least one available appointment, wherein the one or more criteria comprises information pertaining to one or more prior appointments and one or more statuses associated with the one or more prior appointments.
[013] In an embodiment information pertaining to one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient is stored in the centralized healthcare database.
[014] In an embodiment, the system may further comprise a communication module that is configured to facilitate, using the single window exit counter (SWEC) interface, the information pertaining to the one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient across the one or more networked healthcare facilities for subsequent requests obtained from the at least one patient for subsequent appointments.
[015] In an embodiment, the appointment module is configured to generate the list based on historical data comprising at least one of a feedback associated with at least one of the one or more medical professionals and the one or more healthcare support services across the one or more networked healthcare facilities, wherein the historical data is stored in the centralized healthcare database.
[016] In an embodiment, the centralized healthcare database is dynamically updated based on one or more feedback submitted by one or more users.
[017] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[018] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[019] FIG. 1 illustrates an exemplary block diagram of a system for optimizing healthcare services based on context and constraints in accordance with an embodiment of the present disclosure.
[020] FIG. 2 is a block diagram that depicts various modules stored in a memory of the system of FIG. 1 for optimizing healthcare services based on context and constraints in accordance with an embodiment of the present disclosure.
[021] FIG. 3 is an exemplary interaction diagram of the system of FIG. 1 in accordance with an embodiment of the present disclosure.
[022] FIG. 4 is an exemplary user interface view illustrating a patient appointment system in accordance with an embodiment of the present disclosure.
[023] FIG. 5 is an exemplary user interface view depicting information pertaining to patient(s) being made available to referral medical professionals in accordance with an embodiment of the present disclosure.
[024] FIG. 6 is a graphical representation of a patient queue depicting real time patient volume in accordance with an embodiment of the present disclosure.
[025] FIG. 7 is an exemplary user interface view of a patient queue management illustrating new appointments availability in accordance with an embodiment of the present disclosure.
[026] FIG. 8 is an exemplary user interface view of a patient queue management illustrating appointments availability for new patients in accordance with an embodiment of the present disclosure.
[027] FIG. 9 is an exemplary representation of a patient queue that depicts real time information pertaining to approximate wait time for appointments booked by users in accordance with an embodiment of the present disclosure.
[028] FIG. 10A-10B illustrates an exemplary method for optimizing healthcare services based on context and constraints in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS
[029] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
[030] Referring now to the drawings, and more particularly to FIGS. 1 through 10, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[031] FIG. 1 illustrates an exemplary block diagram of a system for optimizing healthcare services based on context and constraints that is in communication with one or more networked healthcare facilities 101A-N in accordance with an embodiment of the present disclosure. The expression ‘context’ herein may refer to information for example, one or more scenarios where users are at least one of (i) registered user(s) wherein information of the registered users is available and stored in a database of the system 100 and (ii) unregistered user(s) wherein information from such unregistered user(s) may be obtained from them to facilitate healthcare support services. The expression ‘constraint’ herein may refer to for example, but are not limited to, users (e.g., patients) not taking appointments, users coming from different ethnics, illiterate, disabled persons, and the like. The system 100 (also referred hereinafter as “healthcare services management system”) comprises one or more data storage devices or memory 102 operatively coupled to one or more hardware processor(s) 104, and communication interface device(s) or input/output (I/O) interface(s) 106. The memory 102 further includes one or more modules. The memory 102, the hardware processor 104, the input/output (I/O) interface 106, and/or the modules may be coupled by a system bus or a similar mechanism. The one or more processors 104 that are hardware processors can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) is configured to fetch and execute computer-readable instructions stored in the memory. In an embodiment, the system 100 can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud and the like.
[032] The I/O interface device(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface device(s) can include one or more ports for connecting a number of devices to one another or to another server.
[033] The memory 102 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, one or more modules (not shown) of the system 100 can be stored in the memory 102.
[034] The memory 102, may store instructions, any number of pieces of information, and data, used by a computer system, for example the system 100 may execute the modules stored in the memory 102 to perform one or more functionalities of the present disclosure. The memory 102 may include for example, volatile memory and/or non-volatile memory. Examples of volatile memory may include, but are not limited to volatile random access memory (RAM). The non-volatile memory may additionally or alternatively comprise an electrically erasable programmable read only memory (EEPROM), flash memory, hard drive, or the like. Some examples of the volatile memory includes, but are not limited to, random access memory, dynamic random access memory, static random access memory, and the like. Some example of the non-volatile memory includes, but are not limited to, hard disks, magnetic tapes, optical disks, programmable read only memory, erasable programmable read only memory, electrically erasable programmable read only memory, flash memory, and the like. The memory 102 may be configured to store information, data, applications, instructions or the like for enabling the system 100 to carry out various functions in accordance with various example embodiments.
[035] Additionally or alternatively, the memory 102 may be configured to store instructions which when executed by the hardware processor 104 causes the system 100 to behave in a manner as described in various embodiments (e.g., real time appointment scheduling, user identifier(s) based registration, patient queue management with business rule engine and algorithms to calculate patient waiting time based on real time analysis and Heuristics based learning system, doctor patient interface leveraging Machine learning technology, and the like).
[036] In an embodiment, the one or more networked healthcare facilities 101A-N are interconnected and are in communication with each other and the system 100 via one or more communication interfaces (not shown in FIG. 1) to enable information exchange and information availability thereof. In another embodiment, the system 100 may be integrated within the one or more networked healthcare facilities 101A-N (including server(s) or computer system(s) associated with the one or more networked healthcare facilities 101A-N). In an example embodiment, the one or more networked healthcare facilities 101A-N may comprise, but are not limited to, one or more healthcare clinics, individual healthcare practitioners, hospitals, medical emergency kiosk, and the like. In an embodiment, information exchange may comprise information pertaining to one or more engagements across one or more users for example, patients, medical professionals, healthcare facilities, and the like). The expression ‘engagement’ when used in context of interaction between patient(s) and medical practitioner(s) may also be referred as ‘episode’ hereinafter. Episode type may comprise, consultation on a health related query (or any information exchange on healthcare query – such as lab reports, and the like) for an example embodiment and is stored in the centralized healthcare database 214.
[037] FIG. 2, with reference to FIG. 1, is a block diagram that depicts various modules stored in the memory 102 of the system 100 for self-learning healthcare services management in accordance with an embodiment of the present disclosure. In an embodiment of the present disclosure, the memory 102 comprises a registration module 202, an appointment module 204, a queue management module 206, an interaction module 208, a consultation module 210, a communication module 212, a centralized healthcare database 214, and a consent module 216. The registration module 202 is configured to register one or more users (e.g., users who need medical assistance or consultation, patients, and the like). In an embodiment, the one or more users may register with the system 100 for healthcare services by enrolling (or submitting) one or more user identifiers. In an embodiment of the present disclosure, the user identifiers may be issued to users by a regulatory body, or a third party who is associated with a government entity. User identifiers may comprise, but are not limited to, Radio-Frequency Identification (RFID) based smart card(s), identity card(s) issued by government agencies, and the like. Examples of user identifiers may comprise a National Identification number such as Aadhaar or Social Security Number, Permanent Account Number (PAN), Voter Identifier, National Security identifier, and the like. The registration module 202 is further configured to enable users register payment details (e.g., electronic payment details) into the system 100 for enabling cashless payments towards the utilized healthcare services (or any add-on services). In an embodiment of the present disclosure, the system 100 enables registration of the RFID smart cards wherein the RFID smart cards can be topped up with some amount (or currency) that can be used for making payments towards utilized healthcare services (e.g., appointments, consultations, follow-ups, pharmacy, lab tests, and the like.).
[038] The appointment module 204 is configured to enable appointments for users with medical professionals. In an embodiment of the present disclosure, the appointment module 204 enables appointments through one or more communication channels (e.g., SMS, MMS, email, mobile application, Interactive Voice Response (IVR), call centre, and the like). In an embodiment, appointments may be enabled based on one or more vital signs obtained from the user. While users walk-in (or scan in and scan out), one or more sensors (e.g., physiological sensors) placed within the proximity of the entrance and exit of the hospital(s) and/or clinic(s), may capture vital signs of users and transmit them to the system 100. In an embodiment, the vital signs may be received by the communication module 212, and stored in a database 214 (also referred hereinafter “a centralized healthcare database”)residing in the memory 102. In an embodiment of the present disclosure, mobile communication devices associated with users may capture vital signs based on one or more sensors (e.g., physiological sensors) residing in the mobile communication device (or attached the user’s body). These vital signs may be captured and transmitted by the mobile communication devices (e.g., through a healthcare service management application executed on the mobile communication device) to the system 100. In an embodiment of the present disclosure, upon RFID of patients is scanned, the communication module 212 is further configured to display or provide (e.g., using web services whenever the RFID is scanned), information pertaining appointment prescription, symptoms/disease, captured vital signs of the patient, and the like, wherein doctor may have access to health records of patient and can prescribe medication, tests, and the like. The doctor may then view the records of the patient and accordingly perform one or more actions. For example, one or more actions may comprise, but are not limited to, initiating order requisition and prescription and lab test requests such as diagnosis / prognosis, and the like. During the current appointment(s) (or on-going appointments) or consultation(s) of patient with doctor, the patient can request (schedule or book) follow up appointments, in an example embodiment. In an embodiment of the present disclosure, there may be a scanning device (e.g., RFID scanner) connected to the system 100 (or doctor’s device, for instance computer system or mobile communication device) wherein when the RFID smart card of the patient is scanned, the healthcare service management executed on the doctor’s device (or the system 100) may automatically populate records pertaining to that patient, wherein doctor can access and view the records and perform the actions. In an embodiment, the RFID scanner may either be integrated within the doctor’s device (or the system 100) or externally connected to it via one or more communication interfaces.
[039] In an embodiment of the present disclosure, the memory 102 may comprise a rule engine (not shown in FIG. 2) that may be invoked by the appointment module 204 to segregate and intelligently guide the routing of patients using mobile based navigation maps. The rule engine may comprise one or more segregation logics that apply either Out-Patient Department (OPD) or Clinical process protocol(s) to identify an appropriate department for a patient based on one or more symptoms (or the captured vital signs). In an embodiment of the present disclosure, the appointment module 204 may receive the one or more symptoms (or the captured vital signs) corresponding to the one or more users (or patients) and maps them to one or more appropriate medical professionals (or departments) thereby routing them to the one or more appropriate medical professionals (or the departments) using navigation map(s). The queue management module 206 (may also be referred herein after as ‘patient queue management module 206’) uses the information pertaining to one or more appointment(s) corresponding to one or more users and generates real time information of appointments (e.g., wait time, expected appointment time, delay, preponed appointment details) on one or more dashboard being made available at one or more premises of the hospital(s) and/or clinic(s). In an embodiment of the present disclosure, the patient queue management module 206 may provide real time information of the appointments based on one or more criteria. In an example embodiment, the one or more criteria may comprise current appointments/number of patients going to meet a particular medical professional (e.g., a surgeon, an ENT (ear, nose, and throat) specialist, and the like), availability of medical professional, delay introduced by either medical professional(s) or patient(s), average time taken by a medical professional to meet a patient from a historical database, average patient scan in and scan out time and the like.
[040] The interaction module 208 (may also be referred herein after as ‘patient doctor interaction module 208’) provides an interface that facilitates capturing of problems, symptoms, causes, treatment plans, medication course, and the like, pertaining to one or more patients. The interface module 208 may further provide an interface (e.g., optimized data entry screens) for patients and/or medical professionals with pre-populated information pertaining to medical professional(s) (or medical experts), and/or patients based on one or more requests made by individuals. The patient and medical professional information may be made available to users based on RFID registration(s) or validations. The interface may provide real time information on number of pending patients, availability of resources (medical professionals such as physicians or doctors and laboratory equipment’s), and the like. The system 100 implements one or more machine learning technique(s) to learn pattern of registration of users, appointment(s) being made, wait time, delay, expected appointment time, patient and the medical professional history, information pertaining to illness, medical condition(s), and adopts computerized physician order entry (CPOE) user interface accordingly. In an embodiment of the present disclosure, when an appointment is being made by a user for a particular symptom/disease, based on the historical data (which acts as a continuous feedback to the system 100), the system 100 may generate one or more recommendations (e.g., using a recommendation module through the one or more machine learning technique(s) – not shown in FIG. 2) of a particular medical profession (e.g., using a current appointment description that may be indicative of symptom/disease, request for consultation). The recommendation may also comprise healthy and safety measures to be adopted by users (e.g., during monsoon season – to wear warm clothes, etc.). The recommendation may also be based on one or more feedback (e.g., positive of negative feedback pertaining to medical professionals/department, medical experts, caretakers in hospitals/clinics). Further, the recommendation module may also recommend (e.g., using the one or more machine learning technique(s)) an appointment date (indicating that the current appointment queue is less, and medical experts are available for the recommended date) and user can book an immediate appointment based on the recommendation accordingly.
[041] The system 100 may further rank, for instance using a ranking module – not shown in FIG. 2, tests, specimens, reports, and the like, using one or more ranking technique(s) (and/or the one or more machine learning technique(s)). The ranking module may further provide rank to medical professionals/department, medical experts, caretakers in hospitals/clinics based on continuous feedback, and the learning pattern. This helps or enables system 100 to provide real time information on health and safety programs (and/or epidemic outbreaks that can ensure proactive / preventive measures to counter an epidemic) to be conducted (or being conducted) during season(s), wherein there may be instances of users getting affected by diseases, and/or symptoms in a particular season. For example, during monsoon season, there is a high chance of dengue, chikungunya like diseases being spread across people, thus, the system 100 may provide real time information pertaining to safety measures and healthcare services for avoiding or treatment of such diseases may be provided to users (e.g., either on dashboards located in premises of hospital(s) (and/or clinic(s)) or directly to one or more registered mobiles devices associated with one or more medical professionals, users (or patients).
[042] The system 100 may further enable, for instance, using the one or more machine learning techniques or a learning module, appointment(s) and/or scheduling(s) based on the above intelligence (e.g., real time information, and current condition of patient(s) and appointments happening).
[043] The consultation module 210 (may also be referred herein after as ‘post consultation module 210’) provides a one stop process to facilitate post consultation activities, for example, but are not limited to, seeking follow up appointments with doctors, laboratories etc., billing, notifications/reminders, and the like. The system 100 is configured and integrated with billing, pharmacy, appointment system and laboratory system to perform billing for instance, using a billing module – not shown in FIG. 2, send request for medicines for instance, using a request module – not shown in FIG. 2, book (or schedule) follow up appointments for instance, using the appointment module 204 and request lab appointments for instance, using the request module respectively thus acting as ‘Single Window Exit Counter (SWEC).
[044] The communication module 212 is configured to store information related to multiple appointment channels, OPD process and policies, and provide content consumption interface that may generate real time (or static content) of frequently asked questions (FAQs), do’s and don’ts, processes, pricing, and policies of the hospital(s). This above information may be displayed in the one or more dashboard(s) located in the premises of the hospital(s), and/or may be transmitted to registered mobile communication devices associated with users.
[045] The centralized healthcare database 214 stores information pertaining to one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient.
[046] In an embodiment of the present disclosure, the registration module 202, the appointment module 204, the queue management module 206, the interaction module 208, the consultation module 210, and the communication module 212 are implemented as at least one of a logically self-contained part of a software program, a self-contained hardware component, and/or, a self-contained hardware component, with a logically self-contained part of a software program embedded into each of the hardware component that when executed perform the above method described herein, in one embodiment.
[047] FIG. 3, with reference to FIGS. 1-2, is an exemplary interaction diagram of the system 100 in accordance with an embodiment of the present disclosure. More particularly, FIG. 3 depicts an interaction diagram of the system 100 that communicates with one or more systems (or modules), for example, (i) registration interface(s) for registration of patients, (ii) appointment channels such as mobile communication devices, kiosk, desktops, IVRs, call centre, (iii) sensory systems for vital signs capturing, and/or screening machines for screening patients (or users), (iv) doctor-patient interface for doctor and patient history, (v) consultation interface (or post consultation interface) for requests of tests (laboratory system(s)), billing requests to billing system(s), medicine requests to pharmacy system(s), notifications (or communication to patients) by notification engine(s), (vi) dashboard application that is responsible for token or appointment display which is indicative of patient wait time, doctor availability, and content repository interface for FAQs, Policies, Pricing details, Brochure(s) and the like. In an embodiment, the one or more systems (or modules) depicted in FIG. 3 may either be integrated within the system 100 or connected to the system 100 via one or more communication interfaces.
[048] FIG. 4, with reference to FIGS. 1 through 3, is an exemplary user interface view illustrating a patient appointment system in accordance with an embodiment of the present disclosure. As depicted in FIG. 4, users can select appropriate options amongst (i) book follow up for previous visit, and/or (ii) select a department for a new appointment.
[049] FIG. 5, with reference to FIGS. 1 through 4, is an exemplary user interface view depicting information pertaining to patient(s) being made available to referral medical professional in accordance with an embodiment of the present disclosure. As can be seen in FIG. 5, the system 100 provides an interface to medical professional(s) to view one or more patients that are visiting for appointment(s) or consultation(s). The medical professional(s) may select appropriate options (being made available to them based on privileges), for example, department type, clinic (or specialty) type, shift or working hours, and the like. Based on the selected options by the medical professionals, information pertaining to patients may be displayed by the system 100 as depicted in FIG. 4.
[050] FIG. 6 is a graphical representation of a patient queue depicting real time patient volume in accordance with an embodiment of the present disclosure. More particularly, FIG. 6 depicts (i) appointment volumes with respect to time for morning OPD and Clinics, (ii) appointment volumes with respect to time for afternoon OPD and Clinics, age-wise breakup, gender-wise breakup, and building/location/premise-wise breakup.
[051] FIG. 7, with reference to FIGS. 1 through 6, is an exemplary user interface view of a patient queue management illustrating new appointments availability in accordance with an embodiment of the present disclosure. More particularly, the FIG. 7 depicts a patient queue management that is being made available at an end user’s system, for instance, a mobile communication device, wherein the healthcare service management system is executed (or installed) in user’s system. As depicted in FIG. 7, the patient queue management depicts availability of appointments for next 30 days for radiotherapy consultation, in an example embodiment. The patient queue management may be displayed to user via one or more reporting mediums, for instance, a dashboard. In FIG. 7, the availability status is displayed as ‘x’, wherein ‘x’ indicates number of availability appointments (e.g., for January 23, 2017, there are 23 appointments available), wherein ‘0’ represents non-availability of appointments.
[052] FIG. 8, with reference to FIGS. 1 through 7, is an exemplary user interface view of a patient queue management illustrating appointments availability for new patients in accordance with an embodiment of the present disclosure. In FIG. 8, the availability status is displayed as ‘x’, wherein ‘x’ indicates number of availability appointments (e.g., for Monday January 23, 2017, there are 29 appointments available for surgery, 5 appointments available for seeking consultation from or checkup by an ENT specialist), wherein ‘0’ represents non-availability of appointments.
[053] FIG. 9, with reference to FIGS. 1 through 8, is an exemplary representation of a patient queue that depicts real time information pertaining to approximate wait time for appointments booked by users in accordance with an embodiment of the present disclosure. More particularly, FIG. 9 depicts real time information on number of rooms (or department), with patient in queue for corresponding rooms, and approximate waiting time for each patient for seeking consultation (e.g., on medical condition) for pediatrics on Wednesday January 25th, 2017. As can be seen from FIG. 9, system 100 generates real time information (e.g., approximate wait time) comprising wait time for appointment/consultation with a medical professional. For example at room 9, the wait time is approximately 45 minutes for a patient (e.g., Chitra, age 4 years) in queue (e.g., having 32 patients ahead). If there is a quick movement of appointments, then the system 100 may reduce the wait time accordingly. Similarly, if there is a delay introduced based on unavailability of medical professional, or delay introduced due to current appointments with medical professional(s), the current wait time is expected to be increased accordingly. The wait time can be dynamic and may also be based upon historic data/report (e.g., average time taken by a doctor to attend a patient, or average time to conduct a test, etc.) wherein the system 100 may rely upon data/information pertaining to similar (or similar) appointments (or consultations).
[054] FIG. 10A-10B, with reference to, FIGS. 1 through 9, illustrates an exemplary method for optimizing healthcare services based on context and constraints in accordance with an embodiment of the present disclosure. In an embodiment of the present disclosure, at step 1002, the hardware processors 104 (or the system 100) register at the healthcare services management system 100 using the registration module 202, one or more patients using a corresponding unique identifier associated with each of the one or more patients. In an embodiment, upon successful registration of the one or more patients, each patient may be issued a unique and distinct identifier or also referred as patient identifier (PID), wherein the PID may be used by that particular patient to login to the system 100 or to access any of the one or more networked healthcare facilities. The PID may be activated and/or deactivated based on user activities performed. For example if the patient has not utilized any healthcare support services for a certain period, then the system 100 may determine the status and take appropriate action on the PID. Hence the PID when issued to a particular patient may be utilized by that patient to access information pertaining to the one or more medical professionals, the one or more networked healthcare facilities, and the one or more healthcare support services provided across the networked healthcare facilities. Likewise each medical professional may be provided with an identifier, for example, medical professional identifier (say MPID) to access information stored in the centralized healthcare database 214.
[055] In an embodiment of the present disclosure, at step 1004, the hardware processors 104 (or the system 100) obtaining a request from a computing device (e.g., a computer system, a mobile communication device, a laptop, and the like.) associated with at least one patient from the one or more patients. In an embodiment, the request may comprise at least one of a healthcare related query and/or one or more vital signs obtained pertaining to the at least one patient. The vital signs may be captured by one or more sensors and transmitted to the system 100 via one or more available communication channels (e.g., SMS, MMS, infrared, Bluetooth™, email, and the like) using one or more communication interfaces.
[056] In an embodiment of the present disclosure, at step 1006, the one or more hardware processors 104 query, based on the request, the centralized healthcare database associated with the healthcare services management system, to obtain an availability status of at least one of one or more healthcare support services and one or more medical professionals associated with one or more networked healthcare facilities integrated with the healthcare services management system 100. In an embodiment the one or more healthcare support services are catered (and/or provided) to the patients by either a virtual SWEC or a physical interaction. The virtual SWEC and physical interaction enable to facilitate the one or more healthcare support services, for example, but are not limited to, follow up appointments for consultation, prescription advice, treatment (e.g., surgery), laboratory assistance such as performing diagnostics, x-ray, scheduling laboratory tests, other services such as billing, payments, and the like.
[057] In an embodiment of the present disclosure, at step 1008, the one or more hardware processors 104 generate based on the availability status, a list comprising at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals associated with the one or more networked healthcare facilities. In an embodiment, the list further comprises (or may comprise) corresponding one or more available appointment times associated with the least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals and corresponding one or more appointment types. In case a particular medical professional is unavailable or not reachable for a given time period for an appointment, the patient may be referred to another medical professional. There may be scenarios where a particular medical profession is available and upon consultation by the patient would want to seek a second opinion. In such cases, patient may request for another list from the system 100 (e.g., by clicking on request for second opinion field on an interface of the system 100 – not shown in FIGS). In such cases, the system 100 may comprise a consent module 216 (see FIG. 2) that is configured to intelligently identify another medical professional (who is of the same background as the first medical professional). For example, if a patient visits an ENT specialist (say first medical professional), and later requests for a second opinion, the consent module 216 may identify another ENT specialist (a second medical professional or generate a list of ENT specialists) (from the healthcare centralized database 214) and communicate the same to the patient. The consent module 216 may direct the patient’s request to the first medical professional who in turn may suggest or recommend the second medical professional or provide the list of ENT specialists. The consent module 216 may identify the second medical professional or generate the list of ENT specialists from the healthcare centralized database 214 based on historical data, feedback, registration status of medical professionals, in an example embodiment. In case a second opinion is to be sought by the patient from the second medical professional, the system 100 may display a message, for example, “please confirm that you would like to share your medical history with other medical professionals/ healthcare facilities”. Upon user agreeing to share his/her medical history (e.g., submitting a Yes response to corresponding message as above), the information pertaining to current and prior episodes (or engagements) are then shared with the other medical professionals/ healthcare facilities by the system 100. Such information on availability and accessibility (e.g., who viewed and accessed when and at what time) is maintained by the system 100 in the centralized healthcare database 214. Such information on availability and accessibility (e.g., who viewed what information and accessed when and at what time) may also be referred hereinafter as ‘audit trail’, in an example embodiment.
[058] In an embodiment of the present disclosure, at step 1010, the one or more hardware processors 104 enable, using the single window exit counter (SWEC) interface, a selection of the at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals, the corresponding one or more available appointment times, and the corresponding one or more appointment types from the list. In an embodiment of the present disclosure, at step 1012, the one or more hardware processors 104 allocate at least one available appointment with an expected time to the at least one patient from the one or more available appointment times based on the selection made by the at least one patient (or an associated user).
[059] In an embodiment of the present disclosure, at step 1014, the one or more hardware processors 104 facilitate the allocated at least one available appointment between (i) at least one of the one or more medical professionals and the one or more healthcare support services and (ii) the at least one patient based on the selection of at least one appointment type. In one embodiment, the appointment types may comprise but are not limited to face-to-face appointments, non-face-to-face appointments. In another example embodiment, the appointment types may comprise a consultation over at least one of a call, a messaging service, an email service, and the like. Such appointments may occur either between (i) the patient and a select medical professional, (ii) a care taker associated with the patient and the select medical professional, (iii) an eligible person (e.g., also referred hereinafter as a certified medical professional) who is an assistant to the select medical professional, and (iv) combinations thereof. In an embodiment, the expected time associated with the allocated at least one available appointment pertaining to the least one patient is updated with an updated expected time which is dynamically computed based on one or more criteria. In an embodiment, the one or more criteria comprises for example, information pertaining to one or more prior appointments and one or more statuses associated with the one or more prior appointments. As discussed above, criteria may include current appointments/number of patients going to meet a particular medical professional (e.g., a surgeon, an ENT (ear, nose, and throat) specialist, and the like), availability of medical professional, delay introduced by either medical professional(s) or patient(s), average time taken by a medical professional to meet a patient from a historical database, average patient scan in and scan out time and the like.
[060] The system 100 is further configured by the instructions to facilitate, using the single window exit counter (SWEC) interface, the information pertaining to the one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient across the one or more networked healthcare facilities for subsequent requests obtained from the at least one patient for subsequent appointments. For example, a medical professional who is currently in engagement with a particular patient may refer to patient’s history (e.g., information pertaining to prior engagements (or prior episodes)). Such information may be made available subject to one or more privileges given to medical professionals who can access using their respective MPID. For example, executive and/or senior medical professionals may have higher privileges and access to information as compared to junior medical professional(s) in the one or more networked healthcare facilities. Another example may comprise, a general surgeon may not have the same privileges and access to information as compared to an orthopedic surgeon or specialist. Further, such privileges and access to information pertaining to prior engagements may also be dependent on feedback provided by users (e.g., registered users, anonymous users, and the like) and/or registration status associated with (i) medical professionals, (ii) the networked healthcare facilities and/or (iii) the healthcare support services. The registration status, for example, may comprise, active, inactive, pending, suspended, and the like. In an embodiment, feedback may comprise positive, negative and/or neutral opinion/view points on the one or more medical professionals, the one or more networked healthcare facilities, and the one or more healthcare support services being made available to users (including normal users, patients, and the like). Furthermore, privileges and access to such sensitive information may be subject to dynamically change as per the registration status, and is at the system (or patient’s) discretion. Therefore, the list that is generated at step 1008 may be intelligently generated based on historical data comprising at least one of feedback associated with at least one of the one or more medical professionals and the one or more healthcare support services across the one or more networked healthcare facilities, and/or the registration status thereof as described above. In an embodiment, the historical data is stored in the centralized healthcare database 214. This enables the system 100 to dynamically update the feedback collected over period of time and store the updated feedback in the database 214 (or centralized healthcare database 214).
[061] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[062] Embodiments of the present disclosure provide systems and methods for self-learning healthcare services management. The system enables is configured to handle large volumes of Out-Patients addressing the needs of diverse population across various demographics with consistent and enhanced patient experience with compassion and care in a public hospital(s) and/or clinics. Further the system comprises aggregated use of solutions related to real time, multi-channel appointment system, RFID based registration, automated vitals capturing system, patient queue management, monitoring and dashboard reporting. The system provides an optimized post consultation process with a Single Window Exit Counter (SWEC) which enables patients to effectively carry out activities for example, Billing, Pharmacy requests, Follow up appointments, procedures and raise lab (or laboratory) requests. The system further learns the pattern of registrations, appointments, wait time for appointments, nature of appointments/consultations, and receives feedback from medical professionals/patient which is adapted by the system to provide recommended and targeted solutions to users, thus making it an intelligent, self-learning, and scalable system.
[063] The embodiments of the present disclosure further enable the system 100 manage huge patient footfalls reduce delay(s) being occurring in OPD consultation (delays in seeking appointments, high patient wait times). The system further provides multiple channels for seeking appointments thus reducing wait times thereby reducing the complexity. Unlike conventional systems and methods, where there is overcrowding of patients across all departments with no clear segregation of new and follow up patients with or without appointments, the system is able to segregate new and follow up patients (with or without appointments) based on a streamlined process (e.g., by way of analyzing the requirements of users based on registrations and appointments indicative of appointment description, and the captured vital signs) and guides users with right amount of information thereby minimizing and/or preventing the overcrowding of patients across all departments and managing the expectations of medical professionals and/or patients. This enables the system to provide real time information around resources to patients and caregivers, leading to optimized patient doctor interaction time, thereby providing enhanced patient experience or reduced anxiety level with reduced wait time where there is a huge footfall of patients, particularly people with diverse needs, and who are illiterate.
[064] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[065] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[066] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[067] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[068] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.
,CLAIMS:1. A processor implemented method, comprising:
registering at a healthcare services management system, one or more patients using a corresponding unique identifier associated with each of the one or more patients (1002);
obtaining a request from a computing device associated with at least one patient from the one or more patients, wherein the request comprises at least one of a healthcare related query and one or more vital signs obtained pertaining to the at least one patient (1004);
querying, based on the request, a centralized healthcare database associated with the healthcare services management system, to obtain an availability status of at least one of one or more healthcare support services and one or more medical professionals associated with one or more networked healthcare facilities integrated with the healthcare services management system (1006);
generating based on the availability status, a list comprising at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals associated with the one or more networked healthcare facilities, wherein the list further comprises corresponding one or more available appointment times associated with the least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals and corresponding one or more appointment types (1008);
enabling, using a single window exit counter (SWEC) interface, a selection of the at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals, the corresponding one or more available appointment times, and the corresponding one or more appointment types from the list (1010);
upon the selection by the at least one patient, allocating at least one available appointment with an expected time to the at least one patient from the one or more available appointment times (1012); and
facilitating the allocated at least one available appointment between (i) at least one of the one or more medical professionals and the one or more healthcare support services and (ii) the at least one patient based on the selection of at least one appointment type (1014).
2. The processor implemented method of claim 1, further comprising dynamically computing, based on one or more criteria, an updated expected time of the allocated at least one available appointment, wherein the one or more criteria comprises information pertaining to one or more prior appointments and one or more statuses associated with the one or more prior appointments.
3. The processor implemented method of claim 1, further comprising storing in the centralized healthcare database, information pertaining to one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient.
4. The processor implemented method of claim 3, further comprising facilitating, using the single window exit counter (SWEC) interface, the information pertaining to the one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient across the one or more networked healthcare facilities for subsequent requests obtained from the at least one patient for subsequent appointments.
5. The processor implemented method of claim 1, wherein the list is generated based on historical data comprising at least one of a feedback associated with at least one of the one or more medical professionals and the one or more healthcare support services across the one or more networked healthcare facilities, wherein the historical data is stored in the centralized healthcare database.
6. The processor implemented method of claim 1, further comprising dynamically updating the centralized healthcare database based on one or more feedback submitted by one or more users.
7. A healthcare service management system (100), comprising
a memory (102) storing instructions and a centralized healthcare database (214);
one or more communication interfaces (106); and
one or more hardware processors (104) coupled to the memory (102) via the one or more communication interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to execute one or more modules comprising:
a registering module that is configured to register at the healthcare services management system, one or more patients using a corresponding unique identifier associated with each of the one or more patients; and
an appointment module that is configured to:
obtain a request from a computing device associated with at least one patient from the one or more patients, wherein the request comprises at least one of a healthcare related query and one or more vital signs obtained pertaining to the at least one patient;
query, based on the request, the centralized healthcare database associated with the healthcare services management system, to obtain an availability status of at least one of one or more healthcare support services and one or more medical professionals associated with one or more networked healthcare facilities integrated with the healthcare services management system;
generate based on the availability status, a list comprising at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals associated with the one or more networked healthcare facilities, wherein the list further comprises corresponding one or more available appointment times associated with the least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals and corresponding one or more appointment types;
enable, using a single window exit counter (SWEC) interface, a selection of the at least one of a subset of the one or more healthcare support services and a subset of the one or more medical professionals, the corresponding one or more available appointment times, and the corresponding one or more appointment types from the list;
upon the selection by the at least one patient, allocate at least one available appointment with an expected time to the at least one patient from the one or more available appointment times; and
facilitate the allocated at least one available appointment between (i) at least one of the one or more medical professionals and the one or more healthcare support services and (ii) the at least one patient based on the selection of at least one appointment type.
8. The healthcare service management system of claim 7, further comprising a queue management module that is configured to dynamically compute, based on one or more criteria, an updated expected time of the allocated at least one available appointment, wherein the one or more criteria comprises information pertaining to one or more prior appointments and one or more statuses associated with the one or more prior appointments.
9. The healthcare service management system of claim 7, wherein information pertaining to one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient is stored in the centralized healthcare database.
10. The healthcare service management system of claim 9, further comprising a communication module that is configured to facilitate, using the single window exit counter (SWEC) interface, the information pertaining to the one or more current and prior engagements between at least one of (i) the one or more healthcare support services and the one or more medical professionals and (ii) the at least one patient across the one or more networked healthcare facilities for subsequent requests obtained from the at least one patient for subsequent appointments.
11. The healthcare service management system of claim 7, wherein the appointment module is configured to generate the list based on historical data comprising at least one of a feedback associated with at least one of the one or more medical professionals and the one or more healthcare support services across the one or more networked healthcare facilities, wherein the historical data is stored in the centralized healthcare database.
12. The healthcare service management system of claim 7, wherein the centralized healthcare database is dynamically updated based on one or more feedback submitted by one or more users.
| Section | Controller | Decision Date |
|---|---|---|
| # | Name | Date |
|---|---|---|
| 1 | 201721002309-RELEVANT DOCUMENTS [05-02-2024(online)].pdf | 2024-02-05 |
| 1 | Form 3 [20-01-2017(online)].pdf | 2017-01-20 |
| 2 | 201721002309-US(14)-HearingNotice-(HearingDate-07-02-2024).pdf | 2024-01-12 |
| 2 | Drawing [20-01-2017(online)].pdf | 2017-01-20 |
| 3 | Description(Provisional) [20-01-2017(online)].pdf | 2017-01-20 |
| 3 | 201721002309-FER.pdf | 2021-10-18 |
| 4 | Other Patent Document [20-03-2017(online)].pdf | 2017-03-20 |
| 4 | 201721002309-ABSTRACT [01-04-2021(online)].pdf | 2021-04-01 |
| 5 | Form 26 [20-03-2017(online)].pdf | 2017-03-20 |
| 5 | 201721002309-CLAIMS [01-04-2021(online)].pdf | 2021-04-01 |
| 6 | 201721002309-ORIGINAL UNDER RULE 6 (1A)-27-03-2017.pdf | 2017-03-27 |
| 6 | 201721002309-COMPLETE SPECIFICATION [01-04-2021(online)].pdf | 2021-04-01 |
| 7 | 201721002309-FORM 3 [19-01-2018(online)].pdf | 2018-01-19 |
| 7 | 201721002309-FER_SER_REPLY [01-04-2021(online)].pdf | 2021-04-01 |
| 8 | 201721002309-OTHERS [01-04-2021(online)].pdf | 2021-04-01 |
| 8 | 201721002309-FORM 18 [19-01-2018(online)].pdf | 2018-01-19 |
| 9 | 201721002309-ENDORSEMENT BY INVENTORS [19-01-2018(online)].pdf | 2018-01-19 |
| 9 | Abstract1.jpg | 2019-02-07 |
| 10 | 201721002309-COMPLETE SPECIFICATION [19-01-2018(online)].pdf | 2018-01-19 |
| 10 | 201721002309-DRAWING [19-01-2018(online)].pdf | 2018-01-19 |
| 11 | 201721002309-COMPLETE SPECIFICATION [19-01-2018(online)].pdf | 2018-01-19 |
| 11 | 201721002309-DRAWING [19-01-2018(online)].pdf | 2018-01-19 |
| 12 | 201721002309-ENDORSEMENT BY INVENTORS [19-01-2018(online)].pdf | 2018-01-19 |
| 12 | Abstract1.jpg | 2019-02-07 |
| 13 | 201721002309-FORM 18 [19-01-2018(online)].pdf | 2018-01-19 |
| 13 | 201721002309-OTHERS [01-04-2021(online)].pdf | 2021-04-01 |
| 14 | 201721002309-FER_SER_REPLY [01-04-2021(online)].pdf | 2021-04-01 |
| 14 | 201721002309-FORM 3 [19-01-2018(online)].pdf | 2018-01-19 |
| 15 | 201721002309-COMPLETE SPECIFICATION [01-04-2021(online)].pdf | 2021-04-01 |
| 15 | 201721002309-ORIGINAL UNDER RULE 6 (1A)-27-03-2017.pdf | 2017-03-27 |
| 16 | 201721002309-CLAIMS [01-04-2021(online)].pdf | 2021-04-01 |
| 16 | Form 26 [20-03-2017(online)].pdf | 2017-03-20 |
| 17 | 201721002309-ABSTRACT [01-04-2021(online)].pdf | 2021-04-01 |
| 17 | Other Patent Document [20-03-2017(online)].pdf | 2017-03-20 |
| 18 | Description(Provisional) [20-01-2017(online)].pdf | 2017-01-20 |
| 18 | 201721002309-FER.pdf | 2021-10-18 |
| 19 | Drawing [20-01-2017(online)].pdf | 2017-01-20 |
| 19 | 201721002309-US(14)-HearingNotice-(HearingDate-07-02-2024).pdf | 2024-01-12 |
| 20 | Form 3 [20-01-2017(online)].pdf | 2017-01-20 |
| 20 | 201721002309-RELEVANT DOCUMENTS [05-02-2024(online)].pdf | 2024-02-05 |
| 1 | SearchStrategy_201721002309E_28-09-2020.pdf |