Outpatient service accompanying medical system and method

Abstract

The invention discloses an outpatient accompanying medical system and method, the system comprises a plurality of physical nodes, a central scheduling end, a plurality of mobile servers and a standardized data carrier, the standardized data carrier is used for recording patient information, and the standardized data carrier is generated when a service request is responded for the first time and is updated in a handover process; the state identification information comprises a service process state identification and a patient special demand identification; the special demand identifier of the patient comprises special disease and risk level information of the patient; and the central scheduling end combines the state of the mobile server, the service process state identifier and the patient special demand identifier to execute scheduling of the mobile server and action management of the patient. A standardized data carrier containing state identification information and node handover records is configured, scheduling of the mobile server and action management of patients are executed in combination with the state of the mobile server, service process state identification and patient special demand identification, and a safe closed loop of medical accompanying service is achieved.

Description

Technical Field

[0001] This invention relates to the field of medical service management and hospital operation optimization technology, and in particular to an outpatient companion system and method. Background Technology

[0002] Large, modern hospitals have complex functions, and special groups such as the elderly, pregnant women, and people with disabilities face various difficulties in accessing medical care. The traditional "one-on-one" full-process escort model has inherent drawbacks, such as ineffective waiting time, which consumes human resources.

[0003] Relay-style escort services can alleviate the problem of insufficient manpower for accompanying patients. Relay-style services divide the patient's visit into multiple stages, with escort personnel being released immediately after completing one stage (the waiting time for the patient to enter that stage), facilitating service to the next patient and reducing the waste of manpower caused by waiting. However, relay-style services also introduce new problems, including:

[0004] 1. After completing a phase of companion medical service, patients need to call the companion medical service again, which creates new problems for the reasonable scheduling of companion medical services;

[0005] 2. Relay-style service means that patients (especially "high-risk groups", such as elderly people with cognitive impairment) are in a "service gap" when they are waiting for their next service in the clinic area, examination department, etc. If a patient gets lost ("anti-lost warning"), falls or other accidents during this "service gap", the accompanying doctor or other medical staff may not be able to actively discover and warn. Summary of the Invention

[0006] The present invention aims to solve the problems existing in the prior art and provide an outpatient companion system and method.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] An outpatient companion system, the system comprising:

[0009] Multiple physical nodes, distributed across various locations within the hospital, are used to communicate with the mobile server and issue service requests.

[0010] A central dispatcher is used to receive service requests from patients or nodes and assign mobile servers to respond to the requests.

[0011] Multiple mobile servers are used to receive task instructions sent by the dispatcher and perform physical operations to escort the patient to the destination node; the mobile servers update the standardized data carrier at the destination node to complete the handover.

[0012] A standardized data carrier is used to record patient information, including basic patient information, status identification information, and node handover records. The standardized data carrier is generated when the service request is first responded to and is updated during the handover process. The status identification information includes service process status identification and patient special needs identification.

[0013] The patient special needs identifier includes the patient's specific disease and risk level information; the central dispatch terminal combines the mobile server status, service process status identifier and patient special needs identifier to perform mobile server scheduling and patient action management.

[0014] In some embodiments of the present invention, the standardized data carrier is generated upon initial response to a service request, records basic patient information, and initializes status identification information and node handover records.

[0015] The initialization includes initializing the node handover record after the first mobile server responds to the request, recording the current handover time and the mobile server ID information, recording the patient's special needs identifier, and updating the service process status identifier.

[0016] In some embodiments of the present invention, the central dispatcher schedules the mobile server to respond to the request based on the following method:

[0017] Obtain the current status of each mobile server, mobile server skill information, mobile server load information, and patient special needs identifier; the mobile server load information includes the cumulative working time of the mobile server on the current day calculated based on node handover records and the time from the end time of the previous working session of the mobile server to the current time.

[0018] Based on the current state of each mobile server, obtain the distance between the idle mobile server and the server that issued the service request, the distance between the mobile server in the occupied state and the destination node, and the total distance between the destination node and the server that issued the service request;

[0019] Based on the patient's specific needs identifier, match the mobile server's skill information, and assign priority values ​​to the mobile server based on the matching status;

[0020] By combining patient information, the distance or total distance between the mobile server and the server that issued the service request, the load of each mobile server, and the priority of the mobile server are weighted and allocated. The optimal schedulable mobile server is obtained through weighted evaluation.

[0021] In some embodiments of the present invention, the mobile server is configured with an RTLS tag;

[0022] When the standardized data carrier is generated, a temporary RTLS tag is configured for the patient based on the patient's special needs identifier;

[0023] The central dispatch terminal collects the location information of the RTLS tag and the temporary RTLS tag in real time.

[0024] In some embodiments of the present invention, the hospital is divided into multiple virtual boundaries to form multiple safe zones and dangerous zones;

[0025] The central dispatch terminal pre-configures different safety management schemes based on the patient's special needs identifier;

[0026] The central dispatch terminal monitors the service process status identifier update status in real time, and calls the corresponding security management scheme based on the current location of the temporary RTLS tag and the service process status identifier. When the patient leaves the security management, an alarm message is issued, and the location information of the temporary RTLS tag is synchronized in real time to one or more mobile servers within a preset range from the temporary RTLS tag, as well as the terminal registered by the patient's family.

[0027] The standardized data carrier includes the following fields:

[0028] Basic patient information, including patient name, outpatient number, and contact information for the patient and / or family members;

[0029] Status identification information includes service process status identifiers, patient special needs identifiers, and / or RTLS tag identifiers; the RTLS tag identifier records the unique identification information of the temporary RTLS bound to the patient;

[0030] The node handover record is used to record the handover time, the handover node ID, and the handover personnel information.

[0031] In some embodiments of the present invention, the mobile server enters an occupied state after receiving a task instruction and is released to an idle state after the handover is completed; mobile servers that do not participate in scheduling are marked as resting.

[0032] In some embodiments of the present invention, the standardized data carrier further includes a record of the service process completion status, and after the final handover is completed, the patient's standardized data carrier is sent to the central dispatch terminal for archiving.

[0033] In some embodiments of the present invention, the system further includes a central server acquiring archived standardized data carrier records, predicting the distribution of patient-specific needs identifiers for each time period based on a time series model, and performing pre-scheduling of the mobile server based on the prediction results.

[0034] This invention further provides an outpatient companionship method based on dynamic scheduling and standardized handover, the method comprising:

[0035] S1 receives a request for companion medical services from a patient;

[0036] S2 dispatches a first mobile server from the mobile server to respond to the request, generates a standardized data carrier bound to the current patient, and performs the physical operation of escorting the patient to a designated physical node. The standardized data carrier records patient information, including basic patient information, status identification information, and node handover records. The status identification information includes service process status identification and patient special needs identification. The patient special needs identification contains information about the patient's specific disease and risk level. The central dispatch terminal combines the mobile server status, service process status identification, and patient special needs identification to perform mobile server scheduling and patient action management.

[0037] The S3 first mobile server escorts the patient to the first destination node and updates the standardized data carrier at the current node to complete the handover;

[0038] When patient S4 completes the transaction at the first destination node and needs to enter the next destination node, he / she issues a medical companion service request through the current physical node.

[0039] The S5 second mobile server responds to the request, receives and updates the patient's current standardized data carrier, and completes the handover.

[0040] S6 repeats S2-S5 until the accompanying medical service is completed.

[0041] The present invention has the following beneficial effects:

[0042] This invention configures a standardized data carrier containing status identification information and node handover records, and combines the mobile server status, service process status identifiers, and patient special needs identifiers to perform mobile server scheduling and patient action management. It abandons the scheduling scheme based solely on the principle of availability and proximity, and provides medical companion services according to the patient's status. While ensuring scheduling efficiency, it ensures the service level for special risk groups, and configures corresponding action management schemes to solve security blind spots, realizing a safe closed loop for medical companion services. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of the outpatient companion system provided in an embodiment of the present invention.

[0044] Figure 2 A schematic diagram of a standardized data carrier structure provided for an embodiment of the present invention.

[0045] Figure 3 This is a schematic diagram of the central dispatch terminal functional modules provided in an embodiment of the present invention.

[0046] Figure 4 A detailed flowchart of the dynamic priority scheduling algorithm provided in the embodiments of the present invention.

[0047] Figure 5 This is a schematic diagram of a virtual fence and service process state binding state machine provided in an embodiment of the present invention.

[0048] Figure 6 This is a schematic diagram illustrating the deployment of RTLS hybrid positioning technology provided in an embodiment of the present invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0050] Example 1

[0051] This embodiment provides an outpatient companion system, the system structure of which is as follows: Figure 1 As shown, it includes a central dispatch terminal 100, multiple mobile servers 110, a standardized data carrier 120, and multiple physical nodes 130. Based on RTLS positioning requirements, base stations can be configured according to positioning method requirements, and corresponding RTLS tags can be configured for the mobile servers 110, as well as temporary RTLS tags can be configured for patients based on the identification information in the standardized data carrier 120.

[0052] like Figure 3 As shown, the central dispatch terminal 100 is a highly integrated software module that can be deployed on a hospital's local server or cloud platform. The central dispatch terminal 100 logically includes:

[0053] Request Receiving and Status Management Unit 101: Used to receive service requests from patients or physical nodes. It also maintains the real-time status of all mobile servers 110, such as "idle," "busy," and "resting." The "resting" status indicates that the server is not currently participating in scheduling and allocation, and is only used for personnel status recording.

[0054] RTLS positioning module 102: Used to process raw data from RTLS positioning base stations and calculate the precise location of all activated RTLS tags / RTLS temporary tags in real time.

[0055] Dynamic priority scheduling module 103: The core scheduling unit of the present invention, see embodiment 3 for details.

[0056] Active security management module 104: The core security unit of this invention, see Embodiment 2 for details.

[0057] AI predictive scheduling module 105: Optional advanced function module, see Example 4 for details.

[0058] System database 106: Used to store the core data structures of this invention.

[0059] The mobile server 110, also known as the medical companion, is typically configured with a terminal that records standardized data carrier 120 and an RTLS tag for location. The mobile server 110 usually achieves data sharing with the central dispatch terminal 100 through the terminal, including the standardized data carrier 120, and realizes node handover and updating of the standardized data carrier 120 through the terminal.

[0060] The structure of the standardized data carrier 120 is as follows: Figure 2 As shown, it includes basic patient information, status identification information, and node handover records; the standardized data carrier 120 is generated when responding to the service request for the first time and is updated during the handover process; the status identification information includes service process status identification and patient special needs identification.

[0061] Physical node 130 is a service station distributed in multiple locations within the hospital, used to communicate with mobile server 110 and send service requests to central dispatch terminal 100.

[0062] Example 2

[0063] The proactive safety management module 104 of the central dispatch terminal 100 is used to achieve adaptive safety management of patients by combining information recorded by the standardized data carrier 120. The specific structure of the standardized data carrier 120 provided in this embodiment is shown in Table 1:

[0064] Table 1. Data Structure of Standardized Data Carriers

[0065]

[0066] The workflow of the proactive safety management module 104 is as follows:

[0067] 1. Configure temporary RTLS labels:

[0068] When a patient first requests service, the request receiving and status management unit 101 of the central dispatch terminal 100 receives the patient's request, generates a standardized data carrier 120, and, in conjunction with the patient's special needs identifier (e.g., the patient's special needs identifier marks a high-risk patient), prompts staff to put a temporary RTLS tag on the patient. This tag can be a lightweight, secure wristband or badge ("wearable RTLS tag").

[0069] Staff associate the temporary RTLS tag with the patient's corresponding "standardized data carrier 120". For example, by scanning an NFC or barcode containing the temporary RTLS tag identification information, the tag ID is bound to the newly created "standardized data carrier 120", and the tag ID is written into the RTLS_Tag_ID field in Table 1.

[0070] To ensure positioning accuracy, this embodiment preferably uses UWB (Ultra-Wideband) technology as the indoor positioning solution, deploying UWB base stations in key areas (such as the clinic area, examination area, and entrance). In outdoor or non-core areas, hybrid positioning using Wi-Fi / Bluetooth can be used as an auxiliary method, such as... Figure 6 .

[0071] 2. Setting up and activating virtual fence policies:

[0072] System administrators (such as head nurses) can use the management software of the RTLS positioning module 102 to draw multiple virtual boundaries on the hospital's digital map ("plan view"), forming virtual fences. For example: "Outpatient Building 1 Exit (Hazardous Area)" and "Radiology Waiting Area (Safe Area)".

[0073] Administrators formulate corresponding virtual fence policies (“personal permitted activity range”) based on patients’ special physical conditions and risk levels, construct a mapping table between patients’ special needs identifiers and virtual fence policies, and pre-store it in the system database 106 for use by the proactive safety management module 104.

[0074] The proactive safety management module 104 reads the update status of the standardized data carrier 120 in real time, and activates or executes the corresponding virtual fence policy when Service_State or High_Risk_Vector (see Table 1) is updated.

[0075] Reference Figure 5 State machine diagram:

[0076] (State 1) When a patient's Service_State = Waiting_Node and High_Risk_Vector.Type = Cognitive Impairment, the system activates the "High Risk-Waiting Strategy" (Geofence_Profile_ID = 3). The rule of this strategy is: if the patient's temporary RTLS tag location information is not in the 'Radiology Waiting Area', an alarm message is issued.

[0077] (State 2) When the patient's Service_State=In_Transit (accompanied by a doctor), the system activates the "Low Risk - Escort Policy" (Geofence_Profile_ID=1). The rule of this policy is: movement in the "hospital corridor" is allowed, and if the patient's temporary RTLS tag location information is located at the 'Outpatient Building Exit 1', an alarm message is issued.

[0078] 3. Early warning mechanism and alarm records:

[0079] Warning: Once the RTLS location module 102 detects that the location of the RTLS_Tag_ID violates its currently active Geofence_Profile_ID rule, the proactive security management module 104 will immediately trigger an alarm.

[0080] Alarm push: Alarm information (including patient name, location, alarm type) is pushed to (1) the patient's family members and (2) all nearby (based on RTLS location) "idle" or "busy" mobile servers 110 via APP push, SMS or sound and light alarm.

[0081] Alarm Logs: All alarm events are recorded in the "Alarm Logs" and saved to the system database 106 for historical trajectory review, so as to facilitate post-event analysis and improve security management.

[0082] Example 3

[0083] This embodiment specifically illustrates the workflow of the dynamic priority scheduling module 103.

[0084] The dynamic priority scheduling module 103 employs a multi-factor cost function algorithm. (Refer to...) Figure 4 The detailed process of the algorithm is as follows:

[0085] S1: Receiving Requests and Preparing Data

[0086] When the dynamic priority scheduling module 103 receives a service request, it obtains the patient ID and queries the standardized data carrier of the corresponding patient based on the patient ID to obtain input parameters, including: the request location (e.g., physical node ID) and the patient's special needs identifier.

[0087] S2: Selecting the candidate pool

[0088] The dynamic priority scheduling module 103 queries the request receiving and status management unit 101 to obtain a set of candidate mobile servers, wherein the candidate mobile servers include at least:

[0089] (1) All mobile servers whose current status is "idle";

[0090] (2) A mobile server in a "busy" state that meets preset conditions, wherein the preset conditions may include: the estimated remaining time of the current task is less than a first threshold, and the path distance between the target physical node of the task and the physical node of the current service request does not exceed a second threshold. The estimated remaining time is predicted by the distance between the current location of the mobile server and the target physical node, and the speed of patients with similar special needs (same or similar risk level, physical condition) in historical data.

[0091] As a preferred implementation, during the candidate server screening process, terminals with "low battery" or "poor network connectivity" health statuses are excluded, even if their service status is "idle". Device health is fundamental to the reliable operation of the RTLS system; a terminal about to shut down is not a valid "idle" resource.

[0092] S3: Iterate through and calculate the overall cost score

[0093] The dynamic priority scheduling module 103 iterates through each candidate server i in the candidate pool and calculates its comprehensive cost score Score_i for each candidate server:

[0094]

[0095] , , This is a weighting factor, which can be determined by the administrator based on the hospital's actual situation (e.g., safety priority). Distance priority Configure it.

[0096] For candidate servers in an "idle" state, the distance cost is the distance (non-linear distance) they travel from their current location (obtained via an RTLS tag) to the patient's location (obtained via a temporary RTLS tag or via the location of a physical node).

[0097] For candidate servers in a "busy" state, the distance cost is the sum of the distance traveled from its current location to its current target physical node location and the distance traveled from the target physical node location to the patient's location. The distance cost is normalized before being used to calculate the overall cost score.

[0098] The priority cost is calculated as follows:

[0099] =Match_Priority(Patient.High_Risk_Vector, Server_i.Skills).

[0100] This is a "mismatch" cost function. Server_i.Skills ("professional skills") are stored in the personnel profile of the mobile server 110 (e.g., ["good at calming people down", "can use a wheelchair", "knows first aid"]).

[0101] Assign values ​​based on skill matching, for example:

[0102] If a patient's special needs identifier indicates a specific physical condition (Patient.High_Risk_Vector.Type) requiring a particular professional skill, and the Server_i.Skills stored on the mobile server 110 can cover this specific need, then it is a perfect match. Assign a value of 0; otherwise (Server_i.Skills does not contain any skills that match the requirements of Patient.High_Risk_Vector.Type). The value is greater than 0 (for example, it could be 10, representing high cost).

[0103] This ensures that high-risk patients are prioritized for assignment to skilled medical companions.

[0104] The cost of load balancing is calculated as follows:

[0105]

[0106] In the formula, The current workload of candidate server i. The duration from the end of the previous working time of candidate server i to the current time. The current workload is the cumulative working time of server i from the first order received on the day to the current time, calculated by recording the time from the time server i received the schedule to the handover time in the node handover record.

[0107] This is used in Among medical companions with similar matching scores, choose one who is relatively free to avoid the situation where "the busy one is always busy".

[0108] S4: Assign the best candidate

[0109] The dynamic priority scheduling module 103 selects candidate server i. lowest( The server sends task instructions to the mobile terminal.

[0110] Assigned The status has been updated to "Busy".

[0111] Example 4

[0112] This embodiment provides an optional AI predictive scheduling module 105 to realize the transformation from "passive response" to "proactive deployment".

[0113] 1. Data Input and Preprocessing:

[0114] The AI ​​predictive scheduling module 105 extracts massive amounts of historical data from the system database 106. The data source may include:

[0115] The archived "standardized data carrier 120" includes, in particular, the timestamps and target node ID1 in the handover records.

[0116] Patient visit records (diagnosis, examination items) in the hospital's HIS system.

[0117] "Alarm Records" database.

[0118] 2. AI Model Training:

[0119] Utilize time series models such as LSTM (Long Short-Term Memory Network) or ARIMA (Autoregressive Moving Average Model).

[0120] Prediction objective: To predict the number of medical companion service requests that will be generated at each physical node within the next N hours (e.g., 1 hour), and the types of these requests (i.e., the distribution of patient special needs identifiers).

[0121] 3. Optimize deployment:

[0122] Active scheduling and dynamic allocation: The prediction results of the AI ​​predictive scheduling module 105 are output to the central scheduling terminal 100.

[0123] Example: The model predicts that "between 10:00 and 11:00, the radiology department will receive 15 service requests, 5 of which are 'high-risk - cognitive impairment'."

[0124] Response: At 9:50, the central dispatch terminal 100 automatically pushes a "pre-schedule" instruction to the mobile server terminal 110 with status = "idle" and skills = "good at soothing", guiding them to move to physical nodes near the radiology department in advance to optimize deployment and reduce the mentioned "average service response time".

[0125] Example 5

[0126] This embodiment demonstrates the complete workflow of the method of the present invention through a specific scenario:

[0127] Scenario: Patient Zhang, 78 years old, diagnosed with "early stage of Alzheimer's disease" ("elderly person with cognitive impairment"), needs to go from the "outpatient hall" to the "radiology department" for a CT scan.

[0128] S1: Request received: Zhang's family members applied for medical companionship service at the medical companionship service desk ("Central Dispatch Terminal 100").

[0129] S2: Carrier Creation and Risk Identification:

[0130] Staff created a "Standardized Data Carrier 120" and entered patient information.

[0131] The system (or staff) marks the patient’s special needs identifier (Table 1) as {Type: “CognitiveImpairment”, Level: “High”}.

[0132] The service process status (Table 1) is initialized to Waiting_Pickup.

[0133] S3: Bind RTLS temporary tag:

[0134] Staff put an RTLS temporary tag wristband on Zhang, and after scanning, RTLS_Tag_ID=UWB-Tag-007 was written into the standardized data carrier 120.

[0135] S4: Activate virtual fence:

[0136] The proactive safety management module 104 detected High_Risk_Vector and Service_State.

[0137] The system activates the Geofence_Profile_ID=4 ("High Risk - Lobby Waiting" policy), with the rule: IFNOTIN 'Outpatient Lobby Waiting Area' THENALARM (refer to...) Figure 5 ).

[0138] S5: Perform dynamic priority scheduling (see reference) Figure 4 ):

[0139] Dynamic priority scheduling module 103 is started.

[0140] Candidate A: Accompanying Doctor Wang Wu, Status = "Idle", Skills = ["Regular"]. RTLS Location = "Outpatient Hall" (10 meters away).

[0141] Candidate B: Accompanying doctor Li Si, Status = "Idle", Skills = ["Skilled at soothing", "First Aid"]. RTLS Location = "Second Floor Laboratory" (50 meters away).

[0142] Algorithm calculation (refer to Example 3):

[0143]

[0144]

[0145] in, ,but (Because Li Si possesses "skilled in comforting," which perfectly matches the patient's high-risk condition of "cognitive impairment"), due to When the (priority weight) value is high, the overall result satisfies Therefore, the system assigned Li Si (B), who was farther away but had a higher matching degree, to perform the task, thus achieving the scheduling goal of "safety first, resource optimization".

[0146] S6: Parallel Monitoring and Escort:

[0147] Li Si (B) accepted the assignment and went to the "outpatient hall".

[0148] (S6-Parallel): While Li Si (B) was arriving, Zhang (the patient)'s Service_State remained Waiting_Pickup. The proactive safety management module 104 was continuously monitoring UWB-Tag-007.

[0149] (S6-Parallel-Exception): Zhang attempted to leave the lobby. The location of UWB-Tag-007 triggered the rule Geofence_Profile_ID=4.

[0150] (S6-Parallel-Alarm): The proactive safety management module 104 immediately triggers an alarm. The central dispatch terminal 100 and the nearest terminal, Wang Wu (A), simultaneously sound an alarm: "High-risk patient Zhang is leaving the lobby!"

[0151] (S6-Parallel-Handling): Wang Wu (A) responded immediately and reassured Zhang.

[0152] This step demonstrates how the present invention compensates for the "safety blind spot" in the "relay" mode.

[0153] S7: Standardized handover and status update:

[0154] Li Si (B) arrived and handed over the goods to Wang Wu (A) and his family.

[0155] Li Si (B) escorted Zhang to the "Radiology Department". At this time, Li Si (B) clicked "Start Escort" on his terminal, and the service process status (Table 1) was updated to In_Transit.

[0156] The proactive safety management module 104 detected a status change and automatically switched Geofence_Profile_ID (Table 1) to Profile=2 (“Escorting” policy), allowing movement in the corridor (see reference). Figure 5 ).

[0157] Upon arriving at the "Radiology Department" physical node, Li Si (B) and the radiology nurse conducted a standardized handover, and both parties signed on the standardized data carrier 120.

[0158] Li Si (B) clicks "Complete Handover", the service process status (Table 1) is updated to Waiting_Node (node ​​waiting), and the time of the node handover record is updated. Li Si (B)'s status is released to "Idle".

[0159] The proactive safety management module 104 detected a status change again and automatically switched Geofence_Profile_ID to Profile=3 ("Radiology Department - Waiting" strategy) (see reference). Figure 5 ).

[0160] S8: Loop and End:

[0161] While Zhang is "waiting at a node", his safety is taken care of by the active safety management module 104 and the fence with Profile=3.

[0162] After Zhang completed the CT scan, the radiology nurse initiated a "service re-application" through a physical node.

[0163] The system repeats S5-S7, assigning a new medical companion to take the patient home.

[0164] Service ends, RTLS tag is reclaimed, and standardized data carrier 120 is archived.

[0165] This specific implementation (Example 5) fully demonstrates how the present invention uses a standardized data carrier (Table 1) as the core to deeply integrate proactive safety management and priority scheduling with a relay-style medical companion process, thereby perfectly solving the problems of "safety blind spots" and "resource mismatch" in terms of technology.

[0166] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An outpatient chaperoning system, comprising: The system comprises: a plurality of physical nodes distributed in multiple locations of the hospital for interfacing with mobile service ends and issuing service requests; a central dispatching end for receiving service requests from patients or nodes and assigning mobile service ends to respond to the requests; a plurality of mobile service ends for receiving task instructions sent by the dispatching end and performing physical operations of escorting patients to destination nodes; the mobile service ends update standardized data carriers at the destination nodes to complete the interfacing; standardized data carriers for recording patient information, including patient basic information, state identification information, and node interfacing records; the standardized data carriers are generated when initially responding to service requests and are updated during the interfacing; the state identification information includes service process state identification and patient special demand identification; the patient special demand identification contains special disease and risk level information of the patient; the central dispatching end combines the state of the mobile service end, the service process state identification, and the patient special demand identification to perform dispatching of the mobile service end and action management of the patient.

2. The system of claim 1, wherein, the standardized data carriers are generated when initially responding to service requests, record patient basic information, and initialize state identification information and node interfacing records; the initialization includes initializing the node interfacing records after the first mobile service end responds to the request, recording the current interfacing time and mobile service end ID information of the interfacing, recording the patient special demand identification, and updating the service process state identification.

3. The system of claim 1, wherein, the central dispatching end dispatches the mobile service end to respond to the request based on the following manners: obtaining the current state of each mobile service end, mobile service end skill information, mobile service end load information, and patient special demand identification; the mobile service end load information contains the daily cumulative working time length of the mobile service end calculated based on the node interfacing records and the time length from the previous working end time of the mobile service end to the current time; based on the current state of each mobile service end, obtaining the distance between the idle state mobile service end and the service request end and the total distance between the occupied state mobile service end, the destination node, and the service request end; based on the patient special demand identification, matching the mobile service end skill information, and based on the matching state, assigning priority to the mobile service end; combining the patient information to assign weights to the distance or total distance between the mobile service end and the service request end, the load of each mobile service end, and the priority of the mobile service end, and obtaining the optimal mobile service end that can be dispatched through weighted evaluation.

4. The system of claim 1, wherein, the mobile service end is configured with an RTLS tag; when the standardized data carrier is generated, a temporary RTLS tag is configured for the patient based on the patient special demand identification; the central dispatching end collects the positioning information of the RTLS tag and the temporary RTLS tag in real time.

5. The system of claim 4, wherein, a plurality of virtual boundaries are divided in the hospital to form a plurality of safe areas and dangerous areas; the central dispatching end pre-configures different safety management schemes based on the patient special demand identification; The central scheduling end monitors the service process state identifier update state in real time, calls the corresponding safety management scheme based on the temporary RTLS tag current position and service process state identifier, issues an alarm information when the patient is out of safety management, and synchronizes the positioning information of the temporary RTLS tag to one or more mobile service ends within a preset range from the temporary RTLS tag and a terminal registered by the patient's family member in real time.

6. The system of claim 1, wherein, The fields contained in the standardized data carrier include: Patient basic information, including patient name, outpatient number, patient and / or family contact information; State identifier information, including service process state identifier, patient special demand identifier and / or RTLS tag identifier; the RTLS tag identifier records the unique identification information of the temporary RTLS bound to the patient; Node handover record, used to record the handover time, handover node ID and handover personnel information.

7. The system of claim 1, wherein, The mobile service end enters the occupied state after receiving the task instruction, and releases to the idle state after completing the handover; the mobile service end not participating in scheduling is marked as resting state.

8. The system of claim 1, wherein, The standardized data carrier also contains the record of the service process end state, and after completing the last handover, the patient's standardized data carrier is sent to the central scheduling end for archiving.

9. The system of any one of claims 1-8, wherein, Further comprising: The central service end obtains the archived standardized data carrier record, predicts the distribution of patient special demand identifier in each time period based on the time series model, and performs pre-scheduling of the mobile service end based on the prediction result.

10. A method for outpatient accompanying based on dynamic scheduling and standardized handover, characterized in that, The method comprises: S1 receiving a medical service request from a patient; S2 assigning a first mobile service end from the mobile service end to respond to the request, generating a standardized data carrier bound to the current patient, and performing physical operation of escorting the patient to the designated physical node; the standardized data carrier records patient information, including patient basic information, state identifier information and node handover record; the state identifier information includes service process state identifier and patient special demand identifier; the patient special demand identifier contains patient's special disease and risk level information; the central scheduling end combines the mobile service end state, service process state identifier and patient special demand identifier to perform scheduling of the mobile service end and action management of the patient; S3 the first mobile service end escorts the patient to the first destination node, and updates the standardized data carrier at the current node to complete the handover; S4 the patient completes the transaction of the first destination node, and when it is necessary to enter the next destination node, issues a medical service request through the current physical node; S5 the second mobile service end responds to the request, receives and updates the current standardized data carrier of the patient, and completes the handover; S6 repeating S2-S5 until the medical service is completed.

Images