Hospital fine management method and system based on digital portal unified platform

Abstract

The application discloses a hospital fine management method and system based on a digital portal unified platform, and comprises the following steps: receiving a task processing request for local medical data in a target medical institution initiated from a client, in response to the task processing request, acquiring the local medical data corresponding to the task processing request from one or more first data devices located in a local area network of the target medical institution, executing the task processing request based on the acquired local medical data, generating a task processing result, and sending the task processing result to the client. The application can improve the technical problems of the island phenomenon in hospital information management and the inconvenience caused by different information system operation permissions and geographical restrictions in the related art.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and system for refined hospital management based on a unified digital portal platform. Background Technology

[0002] With the development of modern healthcare, the functional departments of target medical institutions are becoming increasingly specialized, business scenarios are gradually increasing, and business processes are becoming more complex. Encapsulating these various business scenarios into information systems has become one of the main means of addressing the surge in concurrent business operations. Through information technology, target medical institutions can achieve functions such as process optimization, information sharing, and data analysis, playing a crucial role in improving the efficiency and quality of medical services, optimizing patient experience, enhancing medical safety, and improving the utilization rate of medical resources.

[0003] Currently, to achieve comprehensive information management, different functional departments and sections within the target medical institution use their own independent information management systems. For example, clinical departments use patient information systems, medical technology departments use ultrasound and imaging information systems, and human resources departments use personnel information systems. While these information systems have improved the efficiency of the target medical institution, significant differences in design standards, level of digitization, and operating habits have led to information silos in actual use. This results in problems such as difficulty in data exchange, isolated business scenarios, and difficulties in business workflow, ultimately preventing the hospital's information management efficiency from reaching the expected level. Summary of the Invention

[0004] This application provides a method for refined hospital management based on a unified digital portal platform, aiming to improve the technical problems in related technologies such as the silo phenomenon in hospital information management and the inconvenience caused by different information system operation permissions and geographical restrictions.

[0005] In a first aspect, embodiments of this application provide a method for refined hospital management based on a unified digital portal platform, comprising: receiving a task processing request initiated by a client for local medical data in a target medical institution, wherein the client includes a first client located inside the target medical institution and a second client located outside the target medical institution, the first client communicating with the target medical institution via a local area network and the second client connecting and communicating with the target medical institution via a remote communication network; responding to the task processing request, obtaining local medical data corresponding to the task processing request from one or more first data devices located within the local area network of the target medical institution; executing the task processing request based on the obtained local medical data, generating a task processing result, and sending the task processing result to the client.

[0006] Preferably, the step of obtaining the local medical data corresponding to the task processing request includes: obtaining a configuration file from the local area network of the target medical institution; querying the configuration information matching the task processing request in the configuration file, wherein the configuration information indicates the first data device to be accessed to execute the task request and the acquisition method corresponding to the local medical data to be obtained; and obtaining the local medical data corresponding to the task processing request based on the first data device and acquisition method indicated by the configuration information.

[0007] Preferably, the task processing request includes a data display request. After receiving the data display request, the first device corresponding to the data display request is determined from the configuration information, and the corresponding content is obtained from the first device and sent to the client as the task processing result.

[0008] Preferably, the task processing request includes a data comparison request. Upon receiving the data comparison request, the system retrieves the real-time data corresponding to the data comparison request from the local medical dataset and retrieves the preset range corresponding to the data comparison request from the specified data record container. If the real-time data exceeds the preset range, the system generates a task processing result and sends the task processing result to the client.

[0009] Preferably, the task processing request includes a scheduled task request; upon receiving the scheduled task request, the trigger time information corresponding to the scheduled task request is obtained from the configuration information, the trigger time information including a preset start time for executing the task processing, and / or a preset sending time for sending the task processing result; when the trigger time is reached, the task processing request is executed.

[0010] Preferably, the task processing request includes a local area network (LAN) data access request; after receiving the LAN data access request, the system queries local medical data in the first data device within the target medical institution's LAN, and if the local medical data is found, it forwards the found local medical data to the client.

[0011] Preferably, the task processing request includes an automation processing request, which contains input parameters. After receiving the automation processing request, a process template corresponding to the automation processing request is called from a pre-stored process template library; the input parameters are filled into the corresponding parameter positions in the process template to generate a parameterized process instance; the parameterized process instance is executed to generate a task processing result, and the task processing result is sent to the client.

[0012] Preferably, the process template is a preset follow-up process template, and the input parameters include patient identification information and follow-up time information. Based on the patient identification information and follow-up time information, relevant patient information is extracted from the patient database and populated into the corresponding form fields in the follow-up process template to generate a follow-up form to be sent. The trigger time information in the configuration information is updated based on the received follow-up time information, and the follow-up form is sent to the client when the trigger time information is reached. After sending the follow-up form to the client, new input parameters are obtained based on preset trigger conditions. The new input parameters include patient follow-up feedback information. The new input parameters are updated in the follow-up process template, and an updated follow-up result is generated based on the updated template content. The task processing result is updated based on the updated follow-up result and sent back to the client.

[0013] Preferably, before retrieving the local medical dataset corresponding to the task processing request in response to a task processing request for local medical data within the local area network of the current target medical institution, the method further includes the following steps: pre-setting at least two types of permission identifiers, including at least two of the following: patient identifier, doctor identifier, nurse identifier, caregiver identifier, hospital administrative staff identifier, competent department identifier, basic health physician identifier, and association member identifier; pre-creating a set of usable query requests corresponding to each permission identifier; receiving a query request containing a user identifier, and determining whether the query request belongs to the set of usable query requests corresponding to the permission identifier based on the user identifier and the corresponding set of usable query requests; if the query request belongs to the set of usable query requests corresponding to the permission identifier, executing the query request to retrieve the local medical dataset corresponding to the configuration information in the local medical data resource; if the query request does not belong to the set of usable query requests corresponding to the permission identifier, generating and returning an error message.

[0014] Preferably, upon receiving the task processing request, the client's identity is authenticated, and the client's permission to access the requested data is verified according to a preset access control policy.

[0015] Secondly, embodiments of this application provide a hospital refined management system based on a unified digital portal platform, comprising: The client communication module receives task processing requests for local medical data in a target medical institution initiated by a client. The client includes a first client located inside the target medical institution and a second client located outside the target medical institution. The first client communicates with the target medical institution through a local area network, and the second client connects and communicates with the target medical institution through a remote communication network. The data acquisition module, in response to the task processing request, acquires local medical data corresponding to the task processing request from one or more first data devices located in the local area network of the target medical institution; The task processing module executes task processing requests based on the acquired local medical data, generates task processing results, and sends the results to the client.

[0016] This application presents a hospital refined management method and system based on a unified digital portal platform, which enables data interoperability within the target medical structure, breaks down the silos in hospital information management, and provides data that may be more in line with the usage habits and high usability of external second clients. It also eliminates the inconvenience caused by different information system operation permissions and geographical restrictions, and improves the efficiency of medical collaboration and the level of information sharing. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a hospital refined management method based on a unified digital portal platform, provided in one embodiment of this application. Figure 2 This is a functional diagram of a hospital refined management system based on a unified digital portal platform provided in one embodiment of this application; Detailed Implementation

[0019] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0020] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0021] To address at least one of the aforementioned technical problems, embodiments of this application provide a method, apparatus, device, storage medium, and product for obtaining time-series correlated nodes. The method for obtaining time-series correlated nodes provided in this application embodiment will be described first below.

[0022] Figure 1 This illustration shows a flowchart of a hospital refined management method based on a unified digital portal platform, according to an embodiment of this application. The method may include the following steps: S100, receive a task processing request from a client for local medical data in a target medical institution. The client includes a first client located inside the target medical institution and a second client located outside the target medical institution. The first client communicates with the target medical institution through a local area network, and the second client connects and communicates with the target medical institution through a remote communication network. S200, in response to the task processing request, obtain local medical data corresponding to the task processing request from one or more first data devices located in the local area network of the target medical institution; The S300 executes task processing requests based on the acquired local medical data, generates task processing results, and sends the results to the client.

[0023] In this embodiment, a task processing request for local medical data in a target medical institution is received from a client. The client includes a first client located inside the target medical institution and a second client located outside the target medical institution. The first client communicates with the target medical institution via a local area network, and the second client connects and communicates with the target medical institution via a remote communication network. In response to the task processing request, local medical data corresponding to the task processing request is obtained from one or more first data devices located within the target medical institution's local area network. Based on the obtained local medical data, the task processing request is executed, a task processing result is generated, and the task processing result is sent to the client. This solves the problems of data barriers, information conversion and loss, and data compatibility caused by differences in standards and digitization levels during the design phase between different information systems, ensuring data integrity and consistency. At the same time, it solves the inconvenience of medical staff switching and learning between different systems, as well as the inconvenience of different information system operation permissions and geographical restrictions.

[0024] In S100, a task processing request for local medical data in a target medical institution is received from a client. The first client includes doctor workstations, nurse stations, PACS imaging workstations, etc., and communicates with the first data device via TCP / IP protocol. The second client includes mobile terminal apps, remote consultation platforms, third-party research institution systems, etc.; the second client communicates with the first data device via secure communication protocols such as HTTPS or VPN tunnels. When the client is the first client, it is located on the target medical institution's internal local area network; when the client is the second client, it is located outside the target medical institution and connected via a remote network such as the Internet. The task processing request originates from the client (first client or second client) and includes the task type and related parameters, such as a timed task request with a specified trigger time parameter.

[0025] Furthermore, the second client includes steps developed and maintained by a third-party developer. The third-party developer can access the local medical data and initiate the task processing request through the following methods: First, the third-party developer submits an access application to the relevant internal department of the target medical institution. The access application includes at least the application name, the required interface information, and developer-related information. The relevant internal department of the target medical institution reviews the access application, including but not limited to the developer's qualifications, application purpose, and data access requirements. If the access application is approved, the open platform assigns a calling key to the third-party developer. The third-party developer uses the calling key and, according to the interface specifications provided by the open platform, calls the corresponding interface of the open platform to obtain the authorized local medical data and initiates the task processing request based on the local medical data. By having the target medical institution develop and maintain a second client through a third-party developer, data interoperability of application services can be achieved, breaking down silos in hospital information management. Furthermore, providing a second client that may better suit user habits improves usability and eliminates the inconvenience caused by different information system operation permissions and geographical restrictions, thereby improving medical collaboration efficiency and information sharing levels.

[0026] In step S200, in response to the task processing request, local medical data corresponding to the task processing request is obtained from one or more first data devices located within the local area network of the target medical institution. The first data devices are data devices located within the local area network of the current target medical institution, and the local medical data is stored in data storage units within the first data devices. The first data devices include, but are not limited to, medical device server hardware, operating systems of medical staff's personal computers, or file-sharing service software. Each first data device has a corresponding data storage unit, from which local medical data can be read. The data storage unit can be in the form of a folder, database, or SQL database. The aforementioned local medical data includes the target medical institution's information management data, specifically including patient information, medical staff information, medical service information, and hospital management information. The information includes: patient information such as basic personal information, records of medical visits, follow-up data, real-time physiological monitoring indicators, and prescriptions issued by doctors; medical staff information such as identification information, personal contact information, work schedule information, system operation permissions, electronic signatures, and personal schedules; medical service information such as online diagnosis and treatment information, follow-up plans, and inter-hospital collaboration information; and hospital management information such as information on internal affairs that need to be made public, detailed records of assets and materials, meeting organization and recording information, administrative duty arrangements, and configuration and execution records of other business processes.

[0027] In one implementation, when the first data device is a computer in the radiology department, its data storage unit is a DICOM directory for storing medical image data, with each patient's image data stored in a subdirectory within this DICOM directory. The corresponding medical image data can be read from the appropriate subdirectory based on the patient identification information included in the task processing request. It should be noted that when there is only one first data device, the data storage unit corresponding to that first data device is the same as the storage unit for storing local medical data. When there are multiple first data devices, the corresponding data storage unit can be determined for each first data device, and subsequent steps can be performed to obtain the local medical data corresponding to the task processing request. Therefore, when multiple first data devices exist, all local medical data related to the task processing request can be obtained.

[0028] In S300, after acquiring the local medical data corresponding to the task processing request, the system processes the data according to the task type, including but not limited to data analysis, information comparison, and information push. For example, if the task processing request is about patient follow-up, the system will extract the relevant data from the database based on the patient identifier, process it, calculate the follow-up results, and generate a follow-up report. The results of task processing can be various types of data output, such as data analysis results, reports, alarm information, or other forms of output. For example, if it is a data comparison task, the system will compare the differences between real-time data and preset intervals and generate a difference report; if it is a task for scheduled display, the system will generate relevant display content results according to the preset time. The types of task processing results include data files, notification messages, or data update records.

[0029] In some embodiments, the above-described S200 may include: Obtain the configuration file from the local area network of the target medical institution; The configuration information matching the task processing request is queried in the configuration file, wherein the configuration information indicates the first data device to be accessed to execute the task request and the acquisition method corresponding to the local medical data to be acquired; Based on the first data device and acquisition method indicated by the configuration information, local medical data corresponding to the task processing request is acquired.

[0030] In this embodiment, the configuration file can be stored on a Local Area Network (LAN) server and accessed via a communication protocol. For example, using a File Transfer Protocol (FTP), designated users or third-party software developers can connect to the server and access and download configuration information. Furthermore, the configuration information can be preset information, customized by the target medical institution according to specific needs, and can be further modified after the initial setup. Configuration file management can be implemented using centralized configuration management tools (such as ZooKeeper, Consul) or a database. The configuration file can use formats such as JSON and YAML. The configuration information indicates the data devices to be accessed (e.g., database servers, file servers), the method of obtaining data from the data devices (e.g., database query statements, API interfaces, file paths), and format conversion requirements.

[0031] This embodiment uses configuration files to determine the business requirements corresponding to task processing requests and specifies the acquisition methods for local medical data obtained from various first devices in different local medical institutions, ensuring effective access and querying, and improving configurability and maintainability.

[0032] In some embodiments, the task processing request includes a data display request. After receiving the data display request, the first device corresponding to the data display request is determined from the configuration information, and the corresponding content is obtained from the first device and sent to the client as a task processing result.

[0033] Furthermore, the first device may include a content management module and a duty roster management module. The content corresponding to the data display request includes the content to be publicized stored in the content management module and the duty schedule information stored in the duty roster management module.

[0034] When the first device is a content management module, the content corresponding to the data display request includes the content to be publicized stored in the content management module. Specifically, the content management module (CMS) is used to store and manage hospital affairs information, which includes content to be publicized. This publicized content includes, for example, notices, announcements, operating procedures, workflows, and hospital news. This information is typically intended for internal hospital staff and is used for information dissemination and sharing. As an example, publicized content includes notices and announcements. The notice and announcement submodule is responsible for publishing and managing various hospital notices, announcements, and messages. After user permission verification, users with publishing permissions can initiate announcements and edit the announcement content using a rich text editor (e.g., supporting HTML, Markdown, etc.). The content can include multimedia elements such as images, tables, and links. The publisher can also specify the recipients or organizations of the announcement for targeted delivery. After the announcement is published, the system automatically generates a unique URL, which can be shared via a link or QR code. The system backend records metadata such as the announcement's publication time, publisher, and number of views, and provides a read / unread status tracking function to help publishers understand the dissemination of announcements.

[0035] In addition, the information to be disclosed includes: the circulation of official documents, including internal document issuance applications, incoming document processing, and internal reports, supporting customizable processing workflows to achieve paperless office operations and permanent document storage; asset inventory information, including the status of assets to be disclosed and records of changes in the status of each asset; materials management information, including records of asset procurement, storage, and usage; employee meal ordering information, including information related to meal ordering services provided by hospital staff, such as menus, ordering times, and pick-up locations; administrative duty information, including duty schedules and management information for administrative staff; and personnel attendance information, including employee attendance records and working hours.

[0036] When the first device is a duty sequence management module used to manage and generate duty schedule information, the content corresponding to the data display request includes the duty schedule information stored in the duty sequence management module. Specifically, it receives duty sequence configuration information from a configuration file, which defines the rotation order of the scheduled personnel; based on the received duty sequence configuration information, the duty sequence management module generates a detailed duty schedule plan, each schedule plan containing at least one duty schedule information, wherein each duty schedule information includes the duty personnel identifier (such as employee number or name) and the duty date; when the specified duty date arrives, the duty sequence management module automatically generates a duty reminder message and sends this message to a second client (such as a mobile device or desktop notification system) associated with the duty personnel identifier to inform relevant personnel to be aware of their duty arrangements in a timely manner; the duty sequence management module can respond to duty record query requests and provide corresponding duty records, which include at least one duty schedule, to facilitate managers to view historical duty schedules or perform statistical analysis.

[0037] When the second client receives the duty reminder information, it generates personalized itinerary information for the corresponding user. The itinerary information displays the user-related arrangements obtained from all the first devices in the local medical institution, as well as the corresponding locations and times of the arrangements. The arrangements include duty schedules, outpatient schedules, surgery schedules, ward rounds schedules, meeting schedules, and outings. Furthermore, when there are multiple arrangements within the same time period in the itinerary, or when the time required to reach the location of the next arrangement is less than the interval, the relevant arrangements are marked, and the user is reminded through the second client.

[0038] Each event is labeled with the user's role, which varies depending on the event. For example, in a surgery event, roles include surgeon, first assistant, anesthesiologist, circulating nurse, etc.; in a meeting event, roles include host, speaker, guest, attendee, etc. Contact information for the event's responsible person and / or the responsible department and / or the user's responsible person is provided based on the user's role. When a user has multiple events scheduled within the same time period, they are prioritized based on urgency and / or role importance. These priorities are pre-set; for example, in a meeting event, the speaker's role importance is higher than that of the attendee. Users adjust their event schedules by selecting the corresponding contact information based on the role content of each event, ensuring that at most one event exists within any given time period in the user's schedule. The system updates users' travel information in real time. Firstly, it confirms the user's location via a second client, updates the travel time to the event location, and reminds the user before the event time. Secondly, it uses data devices within the event location area, including attendance machines and surveillance cameras, to identify all users involved in the event and automatically completes the corresponding tasks. Simultaneously, it compiles a list of users who have not arrived at the event location by the preset time before the event time and adjusts the list according to each user's role. Thirdly, when temporary emergency events occur, such as emergency surgery or a patient's sudden critical symptoms, it automatically notifies the person in charge of subsequent events, allowing for adjustments, including replacing users or postponing the event. This effectively saves users time spent adjusting subsequent events when dealing with emergencies and avoids delays caused by users not having time to adjust subsequent events. Furthermore, before the person in charge of the event chooses to postpone the event, it obtains the travel information of all participants for subsequent time periods and sorts them according to the importance of their roles, facilitating the person in charge's selection of a specific postponement time.

[0039] This embodiment addresses data display requests by acquiring and displaying specified local medical data, effectively improving the efficiency of information dissemination, sharing, and management within the hospital, as well as the automation and convenience of duty scheduling management.

[0040] In some embodiments, the task processing request includes a data comparison request. Upon receiving the data comparison request, the real-time data corresponding to the data comparison request is obtained from local medical data, and a preset range corresponding to the data comparison request is obtained from a specified data recording container. If the real-time data exceeds the preset range, a task processing result is generated and sent to the client.

[0041] As an example, the data comparison request is a patient physiological information monitoring and early warning request. Upon receiving the data comparison request (i.e., the patient physiological information monitoring and early warning request), the system performs the following steps: acquiring real-time data, wherein the real-time data includes the patient's physiological information and drug-related information, and the patient's physiological information is acquired from the synchronous records of the medical management system; monitoring information parameter values ​​according to preset rules and outputting judgment results, including expired, insufficient remaining quantity, and critical value warnings, etc. Specifically, the real-time data includes real-time physiological information data obtained from real-time monitoring of the patient's physiological parameters (such as heart rate, blood pressure, blood oxygen saturation, etc.), and the real-time data also includes drug attribute and status information recorded and maintained by the drug administration department, including drug-related information such as name, remaining quantity, production date, and shelf life.

[0042] The steps of monitoring information parameter values ​​according to preset rules and outputting judgment results include: obtaining the preset range corresponding to the data comparison request from the data recording container specified in this report. In this embodiment, the range is the normal range of the patient's physiological information, such as the normal range of heart rate and blood pressure. For medicines, the preset range can be a shelf-life remaining days threshold or a remaining quantity threshold. It should be noted that the data recording container can be a configuration file or a separate dataset stored on the local area network server of the target medical institution. Then, after obtaining the real-time data and the preset range, data comparison is performed. The data comparison includes physiological parameter comparison and medicine bottle status comparison. The physiological status comparison includes comparing the real-time monitored patient physiological parameters with the preset normal range. For example, if the heart rate exceeds or falls below the preset threshold, it is determined to be abnormal. The medicine status comparison includes comparing the remaining quantity of the medicine with the preset remaining quantity threshold and comparing the shelf life with the current date to determine whether the medicine has expired or is about to expire. Based on the results of the above data comparison, the system determines whether the real-time data exceeds the preset range. If a patient's physiological parameters exceed the preset range, or if medication is expired or insufficient, a critical situation or potential risk is identified, triggering a corresponding warning and generating a task processing result. For example, when the heart rate exceeds a preset upper limit, the system generates a high heart rate warning; when the medication's expiration date is approaching or the remaining quantity is below a threshold, the system generates an expired or insufficient stock warning. After generating these task processing results, they are sent to a client, such as a healthcare worker's workstation or mobile terminal, so that appropriate medical measures can be taken promptly.

[0043] This embodiment achieves effective monitoring and early warning of patient physiological information and drug status by responding to data comparison requests and comparing real-time data with a preset range.

[0044] Furthermore, the system presets physiological indicators that require emergency surgery for patients. When a patient's physiological information reaches the preset physiological indicators for emergency surgery, for example, when the amount of internal bleeding exceeds a preset threshold, it is determined that the criteria for emergency surgery have been met. The system generates the temporary emergency task and sends the task processing result to the client, such as the workstation or mobile terminal of medical staff, so that appropriate emergency surgical measures can be taken in a timely manner. At the same time, the system automatically notifies the person in charge of subsequent arrangements for the medical staff involved in the emergency surgery.

[0045] In some embodiments, the task processing request includes a local area network (LAN) data access request; after receiving the LAN data access request, the system queries local medical data in a first data device within the target medical institution's LAN, and if the local medical data is found, it forwards the found local medical data to the client.

[0046] As an example, upon receiving a local area network (LAN) data access request, the system first queries local medical data on a first data device within the target medical institution's LAN. This first data device is a server within the target medical institution, such as a server storing administrative scheduling information and personal affairs information. The local medical data includes administrative scheduling information and personal affairs information, such as duty rosters, schedules, personal files, payslips, contact information, memos, learning resources, and personal information.

[0047] Specifically, personal affairs information can be queried through the Personal Affairs Management module, which includes the following sub-modules: Schedule Management, Personal Resource Management, Payslip Inquiry, Office Assistant, Address Book, Memo, Internal Components, Learning Hub, Signature Maintenance, and Personal Information Maintenance. The Schedule Management sub-module manages users' schedules, such as doctors' on-call schedules, surgery schedules, and other medical affairs; patients' appointment and examination schedules; and hospital administrators' pending tasks. The Personal Resource Management sub-module manages personal work, teaching, and research files and resources, including personal cloud storage. The Payslip Inquiry module connects to the hospital's internal personnel system, allowing internal staff to query monthly salaries and details. The Address Book module allows users to view and / or manage contacts within the hospital based on their permissions, and communicate with contacts within their authorized scope, such as transferring data, sending instant messages, and making voice and video calls. The Memo module assists users in recording, storing, and retrieving information. The Learning Corner module provides users with learning resources and tools, such as video lectures, reading materials, departmental regulations, and knowledge assessments. The Signature Maintenance module manages and maintains users' personal signature information. The Personal Information Maintenance module manages users' personal information, such as collecting user identity information.

[0048] After locating the corresponding local medical data, the system accesses and forwards the retrieved data to the client via a preset local area network file sharing protocol. For example, on-duty personnel can view the shift schedule through the mobile client, and the system will provide reminders before their shift. Employees can view their payslip information through the client. Users can access files in their personal cloud storage through the client. Users can view their address book information and communicate with contacts through the client. Users can view memo information through the client. Users can access learning resources in the learning area through the client.

[0049] This embodiment integrates personal affairs management as local medical data and presents it in a unified manner with heterogeneous systems within the hospital, which can then be displayed on mobile devices, thereby enhancing the hospital's mobile information-based office capabilities.

[0050] In some implementations, the task processing request includes a scheduled task request; upon receiving the scheduled task request, the trigger time information corresponding to the scheduled task request is obtained from the configuration information, the trigger time information including a preset start time for executing the task processing, and / or a preset sending time for sending the task processing result; when the trigger time is reached, the task processing request is executed.

[0051] In some embodiments, the task processing request includes an automation processing request, which contains input parameters. Upon receiving the automation processing request, a process template corresponding to the automation processing request is retrieved from a pre-stored process template library; the input parameters are filled into the corresponding parameter positions in the process template to generate a parameterized process instance; the parameterized process instance is executed to generate a task processing result, and the task processing result is sent to the client.

[0052] Specifically, the process template is a preset follow-up process template, and the input parameters include patient identification information and follow-up time information. Based on the patient identification information and follow-up time information, relevant patient information is extracted from the patient database and filled into the corresponding form fields in the follow-up process template to generate a follow-up form to be sent. The trigger time information in the configuration information is updated according to the received follow-up time information, and the follow-up form is sent to the client when the trigger time information is reached. After sending the follow-up form to the client, new input parameters are obtained according to preset trigger conditions. The new input parameters include patient follow-up feedback information. The new input parameters are updated in the follow-up process template, and an updated follow-up result is generated based on the updated template content. The task processing result is updated based on the updated follow-up result and sent to the client again.

[0053] As an example, in response to a received automated processing request containing at least one input parameter, such as a follow-up request in this embodiment, a follow-up process template corresponding to the follow-up request is retrieved from a pre-stored process template library. This process template library can be stored in a first data device within a local area network. The input parameters for the automated processing request include patient identification information (e.g., patient ID, name, medical record number, etc.) and follow-up time information (e.g., follow-up date, follow-up cycle, etc.). Then, the input parameters are filled into the corresponding parameter positions in the follow-up process template to generate a parameterized process instance. For example, the follow-up process template includes parameter positions such as "patient name," "last visit date," and "suggested follow-up visit time." The follow-up engine fills in the specific patient information and follow-up time into these positions. Finally, the parameterized process instance is executed to generate a task processing result, including extracting relevant patient information (e.g., past medical history, medication history, examination results, etc.) from the patient database based on the patient identification information and follow-up time information, and filling this information into the corresponding form fields in the follow-up process template to generate a follow-up form to be sent.

[0054] This embodiment pre-stores multiple follow-up process templates on the target medical institution's local area network server and automatically calls the corresponding template based on the received follow-up request. This avoids repetitive manual operations, improves the efficiency and standardization of the follow-up process, and reduces the incidence of human error. The generation of parameterized process instances ensures the relevance and personalization of each follow-up visit, improving the effectiveness of the follow-up.

[0055] As an example, the trigger time information in the configuration information is updated according to the received follow-up time information, the follow-up request is configured as a scheduled task request, and the follow-up time information in the follow-up form is configured as the trigger time information, which serves as the preset start time for executing the task. When the trigger time is reached, the follow-up form to be sent is sent to the client.

[0056] In some implementations, the method further includes: receiving updated follow-up data from the client and generating an analysis report based on the received follow-up data. The analysis report includes data labeling of high-risk or abnormal patients using preset rules, so that medical staff can focus on them.

[0057] In some implementations, the process further includes acquiring new input parameters and updating follow-up results based on preset trigger conditions. These preset trigger conditions include patient follow-up feedback information submitted by the patient in a follow-up form. This feedback information includes the patient's self-reported condition or examination results. Upon receiving this feedback, the follow-up workflow template is updated based on the feedback, and updated follow-up results are generated according to the updated template content. For example, this might involve updating the patient's follow-up status or adjusting the follow-up plan. By updating the follow-up workflow template based on patient feedback, dynamic updates to follow-up data are achieved, ensuring the timeliness and accuracy of the data. Analysis reports are generated based on the updated data, and high-risk or abnormal patients are marked, enabling timely detection of patient health risks and providing timely warnings and intervention information for medical staff, thereby improving medical quality and patient safety.

[0058] This embodiment obtains new input parameters (such as patient follow-up feedback information) based on preset trigger conditions, updates the template, generates updated follow-up results, and sends them back to the client. This method avoids repetitive manual operations, improves follow-up efficiency and standardization, reduces human error, and ensures the relevance and effectiveness of each follow-up through parameterization.

[0059] In some implementations, S200 further includes: pre-setting at least two types of permission identifiers, including at least two of the following: patient identifier, doctor identifier, nurse identifier, caregiver identifier, hospital administrative staff identifier, competent authority identifier, basic health physician identifier, and association member identifier; pre-creating a set of usable query requests corresponding to each permission identifier; receiving a query request containing a user identifier, and determining whether the query request belongs to the set of usable query requests corresponding to the permission identifier based on the user identifier and the corresponding set of usable query requests; if the query request belongs to the set of usable query requests corresponding to the permission identifier, executing the query request to obtain the local medical data corresponding to the configuration information in the local medical data resource; if the query request does not belong to the set of usable query requests corresponding to the permission identifier, generating and returning an error message.

[0060] In some implementations, S100 further includes: after receiving the task processing request, authenticating the client's identity and verifying whether the client has permission to access the requested data according to a preset access control policy.

[0061] Specifically, upon receiving a task processing request from a first or second client, the system retrieves the client identification information from the request. This information includes user ID, username, and other identifying data. It then queries the local medical institution's LAN server using an authentication module to verify the extracted identity information. This verification process involves comparing the user credentials stored on the local medical institution's LAN server with the user role's permission configuration to determine if the user has the necessary access permissions to execute the task, ensuring the authenticity and legitimacy of the identity. If authentication fails or permissions are insufficient, a corresponding error message (such as "authentication failed" or "no access permission") is generated and returned, terminating the subsequent data processing flow. If authentication is successful and permission verification passes, the system continues with step S200 to retrieve local medical data and complete the task processing request.

[0062] Figure 2 This illustration shows a schematic diagram of a hospital refined management system based on a unified digital portal platform, according to an embodiment of this application. The system may include the following modules: The client communication module receives task processing requests for local medical data in a target medical institution initiated by a client. The client includes a first client located inside the target medical institution and a second client located outside the target medical institution. The first client communicates with the target medical institution through a local area network, and the second client connects and communicates with the target medical institution through a remote communication network. The data acquisition module, in response to the task processing request, acquires local medical data corresponding to the task processing request from one or more first data devices located in the local area network of the target medical institution; The task processing module executes task processing requests based on the acquired local medical data, generates task processing results, and sends the results to the client.

[0063] It should be noted that the specific implementation of the hospital refined management system based on the unified digital portal platform in this application embodiment refers to the specific implementation of the hospital refined management method based on the unified digital portal platform proposed in the first aspect of the aforementioned application embodiment, and will not be repeated here.

[0064] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for refined hospital management based on a unified digital portal platform, characterized in that: include: The system receives a task processing request from a client for local medical data in a target medical institution. The client includes a first client located inside the target medical institution and a second client located outside the target medical institution. The first client communicates with the target medical institution via a local area network, and the second client connects and communicates with the target medical institution via a remote communication network. In response to the task processing request, local medical data corresponding to the task processing request is obtained from one or more first data devices located in the local area network of the target medical institution. The system executes task processing requests based on the acquired local medical data, generates task processing results, and sends the results to the client.

2. The hospital refined management method based on a unified digital portal platform according to claim 1, characterized in that, The acquisition of local medical data corresponding to the task processing request includes: Obtain the configuration file from the local area network of the target medical institution; The configuration information matching the task processing request is queried in the configuration file, wherein the configuration information indicates the first data device to be accessed to execute the task request and the acquisition method corresponding to the local medical data to be acquired; Based on the first data device and acquisition method indicated by the configuration information, local medical data corresponding to the task processing request is acquired.

3. The hospital refined management method based on a unified digital portal platform according to claim 1, characterized in that: The task processing request includes a data display request. After receiving the data display request, the first device corresponding to the data display request is determined from the configuration information, and the corresponding content is obtained from the first device as the task processing result and sent to the client.

4. The hospital refined management method based on a unified digital portal platform according to claim 1 or 3, characterized in that: The task processing request includes a data comparison request. Upon receiving the data comparison request, the real-time data corresponding to the data comparison request is obtained from the local medical dataset, and the preset interval range corresponding to the data comparison request is obtained from the specified data recording container. If the real-time data exceeds the preset range, a task processing result is generated and sent to the client.

5. The hospital refined management method based on a unified digital portal platform according to claim 1, characterized in that: The task processing request includes a scheduled task request; upon receiving the scheduled task request, the trigger time information corresponding to the scheduled task request is obtained from the configuration information, the trigger time information including the preset start time for executing the task processing, and / or the preset sending time for sending the task processing result; when the trigger time is reached, the task processing request is executed.

6. The hospital refined management method based on a unified digital portal platform according to claim 1, characterized in that: The task processing request includes a local area network (LAN) data access request; after receiving the LAN data access request, the system queries local medical data in the first data device within the target medical institution's LAN, and if the local medical data is found, it forwards the found local medical data to the client.

7. The hospital refined management method based on a unified digital portal platform according to claim 1, characterized in that: The task processing request includes an automation processing request, which contains input parameters. Upon receiving the automation processing request, a process template corresponding to the automation processing request is called from a pre-stored process template library. Fill the input parameters into the corresponding parameter positions in the process template to generate a parameterized process instance; The parameterized process instance is executed to generate a task processing result, which is then sent to the client.

8. The hospital refined management method based on a unified digital portal platform according to claim 7, characterized in that: The process template is a preset follow-up process template. The input parameters include patient identification information and follow-up time information. Based on the patient identification information and follow-up time information, relevant patient information is extracted from the patient database and filled into the corresponding form items in the follow-up process template to generate a follow-up form to be sent. The trigger time information in the configuration information is updated according to the received follow-up time information. When the trigger time information is reached, the follow-up form is sent to the client. After sending the follow-up form to the client, new input parameters are obtained according to preset trigger conditions. The new input parameters include patient follow-up feedback information. The new input parameters are updated in the follow-up process template, and an updated follow-up result is generated based on the updated template content. The task processing result is updated based on the updated follow-up result and sent to the client again.

9. The hospital refined management method based on a unified digital portal platform according to claim 1, characterized in that: Before obtaining the local medical dataset corresponding to the task processing request in response to a task processing request for local medical data within the local area network of the current target medical institution, the following steps are also included: At least two types of access identifiers are preset, including at least two of the following: patient identifier, doctor identifier, nurse identifier, caregiver identifier, hospital administrative staff identifier, competent authority identifier, primary healthcare physician identifier, and association member identifier; Pre-create the set of available query requests corresponding to each permission identifier; Receive a query request containing a user identifier, and determine whether the query request belongs to the available query requests corresponding to the permission identifier based on the user identifier and the corresponding set of available query requests; If the query request belongs to the set of available query requests corresponding to the permission identifier, the query request is executed to obtain the local medical dataset corresponding to the configuration information in the local medical data resource; if the query request does not belong to the set of available query requests corresponding to the permission identifier, an error message is generated and returned. Upon receiving the task processing request, the client's identity is authenticated, and the client's permission to access the requested data is verified according to a preset access control policy.

10. A hospital refined management system based on a unified digital portal platform, characterized in that: include: The client communication module receives task processing requests for local medical data in a target medical institution initiated by a client. The client includes a first client located inside the target medical institution and a second client located outside the target medical institution. The first client communicates with the target medical institution through a local area network, and the second client connects and communicates with the target medical institution through a remote communication network. The data acquisition module, in response to the task processing request, acquires local medical data corresponding to the task processing request from one or more first data devices located in the local area network of the target medical institution; The task processing module executes task processing requests based on the acquired local medical data, generates task processing results, and sends the results to the client.

Images