Clinical data-oriented stepped asynchronous acquisition system and method, medium, program product and terminal

Abstract

The invention provides a clinical data-oriented stepped asynchronous acquisition system and method, a medium, a program product and a terminal. The system comprises a task acquisition module, a multi-stage analysis module and a data acquisition module, the method comprises the following steps: acquiring main index information of a current patient, and generating a doctor seeing acquisition task based on the main index information; obtaining corresponding doctor-seeing information based on the doctor-seeing collection task, generating a doctor's advice collection task based on the doctor-seeing information and the main index information, obtaining corresponding doctor's advice information based on the doctor's advice collection task, and generating a data collection task based on the doctor's advice information; and generating a corresponding time window parameter for the data acquisition task based on a preset time window rule, and executing the data acquisition task based on the time window parameter to obtain clinical result data of the current patient. And a set of stepped asynchronous incremental acquisition mechanism taking a time window and state driving as a core is constructed, so that the continuous pressure on a source system is reduced.

Description

Technical Field

[0001] This application relates to the field of medical data acquisition technology, and in particular to a tiered asynchronous acquisition system, method, medium, program product and terminal for clinical data. Background Technology

[0002] As hospitals become increasingly information-based, various business systems coexist, including Electronic Medical Records (EMR), Hospital Information Systems (HIS), Laboratory Information Systems (LIS), and Picture Archiving and Communication Systems (PACS). Clinical data exhibits characteristics such as diverse sources, heterogeneous structures, and inconsistent output timelines. Upper-level applications (such as clinical research, data governance, quality control analysis, and intelligent decision support) typically need to continuously acquire patient-related data from these business systems through interfaces.

[0003] In existing technologies, the main methods for acquiring clinical data via interfaces are as follows: timed full or incremental polling: data is acquired by calling the interface at fixed time intervals; event-triggered push: the source system actively pushes the data after it is generated; and single object-level query: data is acquired at the granularity of a single business object such as a patient, medical order, or report.

[0004] Existing technologies focus on obtaining medical order data from patient medical records and presenting it in a structured manner. Their technical focus is on data display and treatment plan organization logic, but they do not involve dynamic scheduling strategies for the delayed output characteristics of clinical data, nor do they involve asynchronous retry, state coordination and acquisition process control mechanisms across time windows.

[0005] In real-world clinical scenarios, existing technologies still have the following problems:

[0006] (1) There is a significant delay in data output: such as test results, pathology reports, and imaging reports, which are often generated hours, days or even weeks after the prescription is issued, making it difficult to obtain complete data from one-time or low-frequency collection.

[0007] (2) It is difficult to balance system pressure and efficiency: high-frequency polling will put a lot of pressure on the source system interface, while low-frequency polling will cause data update delay;

[0008] (3) Lack of collaborative management of business hierarchy: There is a natural hierarchy and dependency relationship between objects such as patients, visits, medical orders, and reports. Traditional technical solutions often collect data independently for each object, which can easily lead to problems such as invalid queries, duplicate calls and inconsistent data logic.

[0009] (4) Lack of a unified governance mechanism for exceptions and failures: There is a lack of sustainable state management and recovery mechanisms for situations such as interface call failure and data delay exceptions. Summary of the Invention

[0010] In view of the shortcomings of the prior art described above, the purpose of this application is to provide a tiered asynchronous acquisition system, method, medium, program product and terminal for clinical data, which aims to solve the deficiencies of existing systems such as data omission, excessive interface pressure and uncontrollable acquisition process.

[0011] To achieve the above and other related objectives, a first aspect of this application provides a tiered asynchronous data acquisition system for clinical data. The system includes: a task acquisition module for acquiring the current patient's master index information and generating a patient visit acquisition task based on the master index information; a multi-level parsing module for acquiring corresponding patient visit information based on the patient visit acquisition task, generating a medical order acquisition task based on the patient visit information and the master index information, acquiring corresponding medical order information based on the medical order acquisition task, and generating a data acquisition task based on the medical order information; and a data acquisition module for generating corresponding time window parameters for the data acquisition task based on preset time window rules, and executing the data acquisition task based on the time window parameters to acquire the current patient's clinical outcome data.

[0012] In some embodiments of the first aspect of this application, the system further includes: a status management module; the status management module is used to trigger the execution or terminate the execution of each task according to the lifecycle status of the medical visit collection task, the medical order collection task, and the data collection task.

[0013] In some embodiments of the first aspect of this application, the time window parameters include: start time, detection time period, detection interval strategy, detection count threshold, and end time.

[0014] In some embodiments of the first aspect of this application, the process of executing the data acquisition task based on the time window parameter to obtain the current patient's clinical outcome data includes: starting from the start time, asynchronously calling an external data interface using a probe interval strategy to query and obtain the corresponding clinical outcome data in the data acquisition task through the external data interface; terminating the current data acquisition task when the number of asynchronous calls to the external data interface exceeds the probe count threshold, or when the deadline is exceeded during the query process.

[0015] In some embodiments of the first aspect of this application, the system further includes: an interface adaptation module; the interface adaptation module is connected to the data acquisition module and the multi-level parsing, and is used for adapting and communicating with external data interfaces of different clinical information systems.

[0016] In some embodiments of the first aspect of this application, the system further includes: a data processing module; the data processing module is connected to the data acquisition module and is used to perform deduplication, integration and standardization processing on the acquired clinical outcome data.

[0017] To achieve the above and other related objectives, a second aspect of this application provides a step-by-step asynchronous data acquisition method for clinical data. The method includes: acquiring the current patient's master index information; generating a patient visit data acquisition task based on the master index information; acquiring corresponding patient visit information based on the patient visit data acquisition task; generating a medical order data acquisition task based on the patient visit information and the master index information; acquiring corresponding medical order information based on the medical order data acquisition task; generating a corresponding time window parameter for the data acquisition task based on a preset time window rule; and executing the data acquisition task based on the time window parameter to acquire the current patient's clinical outcome data.

[0018] To achieve the above and other related objectives, a third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned step-by-step asynchronous acquisition method for clinical data.

[0019] To achieve the above and other related objectives, a fourth aspect of this application provides a computer program product comprising computer program code that, when executed on a computer, enables the computer to implement the step-by-step asynchronous acquisition method for clinical data.

[0020] To achieve the above and other related objectives, a fifth aspect of this application provides an electronic terminal, including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the step-by-step asynchronous acquisition method for clinical data.

[0021] As described above, the tiered asynchronous data acquisition system, method, medium, program product, and terminal of this application for clinical data have the following beneficial effects:

[0022] (1) Significantly improved data integrity: This application uses a tiered dependency-driven architecture to ensure that the data collection process strictly follows the natural laws of clinical business. It achieves intelligent convergence of target data from the source. For example, the system only collects medical information when it confirms that the patient has a valid medical visit; or, it only starts collecting results when it confirms that there is a valid medical order for the medical visit.

[0023] (2) The system call efficiency has been significantly improved: the system presets differentiated and configurable time windows and detection strategies for data with different output rhythms (such as fast testing and slow pathology), realizing fine scheduling of "fast acquisition of high-frequency data and patient waiting for low-frequency data".

[0024] (3) Enhanced stability and controllability: The unified process management mechanism with the state management module at its core provides a scheduling hub for the entire asynchronous and distributed data acquisition process. The lifecycle status of each data acquisition task is tracked and managed in real time, and the execution and termination of tasks are driven by the lifecycle status, so that abnormal situations (such as temporary interface failure) can be automatically captured and retried according to the strategy, avoiding the infinite occupation of resources by zombie tasks. Attached Figure Description

[0025] Figure 1 The diagram shown is a schematic representation of a stepped asynchronous acquisition system for clinical data according to an embodiment of this application.

[0026] Figure 2 The diagram shown is a schematic representation of a stepped data acquisition process in one embodiment of this application.

[0027] Figure 3 The diagram shown is a flowchart illustrating a step-by-step asynchronous acquisition method for clinical data in one embodiment of this application.

[0028] Figure 4 The diagram shown is a structural schematic of an electronic terminal according to an embodiment of this application. Detailed Implementation

[0029] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0030] To facilitate understanding of the embodiments of this application, firstly, in conjunction with Figure 1 Detailed explanation. Figure 1 A schematic diagram of a stepped asynchronous data acquisition system 100 for clinical data according to an embodiment of the present invention is shown. The system 100 includes: a task acquisition module 101, a multi-level parsing module 102, and a data acquisition module 103.

[0031] The task acquisition module 101 is used to acquire the current patient's master index information and generate a medical visit collection task based on the master index information.

[0032] It should be noted that the system described in this application connects with a clinical information system in a medical setting to obtain clinical outcome data for subsequent clinical research, data governance, quality control analysis, intelligent decision support, and other higher-level applications. However, the clinical information system is characterized by strong confidentiality and large data scale. Obtaining information of interest through global traversal not only fails to meet the hospital's confidentiality requirements for patient information but also results in a significant waste of system resources. Therefore, based on the data storage characteristics of the clinical information system, it is divided into four hierarchical data layers: patient's master index information, corresponding consultation information, corresponding medical order information, and corresponding clinical outcome data. These layers have a natural hierarchy and dependency relationship. The system described in this application first obtains the patient's master index information and then retrieves the corresponding clinical outcome data through a hierarchical, step-by-step search, as described in the following embodiments.

[0033] The clinical information system includes, but is not limited to, one or more combinations of various business systems such as electronic medical record system (EMR), hospital information system (HIS), laboratory information system (LIS), and picture archiving and communication system (PACS).

[0034] Specifically, the patient's master index information includes one or more unique identifiers for the patient, such as an ID card number, medical appointment number, or bank card number. Any index information that can uniquely represent the patient's identity can be used as the patient's master index information; no specific limitation is made here.

[0035] Furthermore, based on the acquired master index information, a patient data collection task corresponding to the patient is generated. By using the patient's master index information as the starting point for the task, invalid scanning of irrelevant patient data can be avoided, thus improving overall data collection efficiency.

[0036] The multi-level parsing module 102 is used to obtain the corresponding medical information based on the medical collection task, generate a medical order collection task based on the medical information and the main index information, obtain the corresponding medical order information based on the medical order collection task, and generate a data collection task based on the medical order information.

[0037] In one embodiment of this application, the system further includes: an interface adaptation module; the interface adaptation module is connected to the data acquisition module and the multi-level parsing module respectively, and is used to adapt and communicate with external data interfaces of different clinical information systems.

[0038] Furthermore, such as Figure 2As shown, the medical visit data collection task includes the master index information and corresponding medical visit retrieval conditions. The retrieval conditions can be the medical visit information of the corresponding patient within the last 24 hours or the corresponding patient currently hospitalized. The multi-level parsing module matches the corresponding external data interface for the medical visit data collection task based on the master index information. Based on the external data interface, it queries the corresponding clinical information system for medical visit records of the patient corresponding to the master index information that meet the medical visit retrieval conditions. If a corresponding medical visit record is found in the clinical information system, the corresponding medical visit information is generated; if no corresponding medical visit record is found in the clinical information system, the execution of the current task is stopped. The medical visit information includes, but is not limited to, medical visit record identifier, visit time, and department information.

[0039] Furthermore, after obtaining the master index information and the corresponding medical visit information, the filtering conditions are further refined. Based on the master index information and the corresponding medical visit information, a medical order collection task is generated. This task inherits the medical visit information and corresponding medical order retrieval conditions. The retrieval conditions can be medical orders that have been issued and are not yet terminated, corresponding to the current medical visit information. The multi-level parsing module matches the medical order collection task with a corresponding external data interface based on the medical order retrieval conditions. Using this external data interface, it queries the corresponding clinical information system for medical order records corresponding to the patient in the master index information that meet the retrieval conditions. If a corresponding medical order record is found in the clinical information system, the corresponding medical order information is generated; otherwise, the execution of the current task is stopped. The medical order information includes, but is not limited to, test results, examinations, pathology reports, etc.

[0040] It should be noted that a three-tiered, hierarchical structure consisting of the main index information, corresponding visit information, and corresponding medical order information is used for step-by-step retrieval and collection. Compared to directly polling massive amounts of historical data, this embodiment first converges the data scope from all of the patient's historical information to a single medical service event through visit information, and then further focuses the target on the actual medical order behavior through medical order information. This convergence mechanism eliminates invalid queries for non-existent medical orders or non-current visit data from the source, which can reduce most of the redundant interface calls to the clinical information system and significantly reduce the load pressure on the source system.

[0041] In another embodiment of this application, multiple medical order collection tasks can be generated based on the medical visit information. Each independent medical order collection task will obtain corresponding medical order information, such as test orders, examination orders, and pathology orders. The data for each independent medical order collection task comes from the corresponding medical visit information, and additional fields such as medical order ID are added to distinguish different medical order collection tasks.

[0042] Furthermore, based on the specific medical order information in the medical order collection task, the multi-level parsing module 102 will generate the final data collection task. For example, for a "complete blood count" test order, a data collection task is generated with the goal of collecting its "test report".

[0043] It is important to emphasize that the query logic is not directly shared between tasks at each level, but is decoupled and associated only through dependency conditions, thereby avoiding the interface redundancy caused by traditional hierarchical traversal queries.

[0044] The data acquisition module 103 is used to generate corresponding time window parameters for the data acquisition task based on preset time window rules, and to execute the data acquisition task based on the time window parameters to obtain the current patient's clinical outcome data.

[0045] In one embodiment of this application, the time window parameters include: start time, detection period, detection interval strategy, detection count threshold, and end time. The start time refers to the earliest time at which the data acquisition task can begin; the detection period is the duration for which the data acquisition task can be executed; the detection interval strategy is the frequency strategy for queries within the detection period; the detection count threshold is the maximum number of queries that can be performed during the data acquisition task; and the end time is the latest time at which the data acquisition task can be executed.

[0046] The preset time window rule sets different time window parameters according to different data acquisition tasks. Specifically, it can be represented as a configurable mapping table that associates different types of medical order information with a set of time window parameters. When the system executes a data acquisition task, it queries this mapping table based on the type code in the medical order information associated with the task to obtain the corresponding start time, end time, and other parameters.

[0047] Furthermore, in practice, different types of medical order information are produced according to different patterns, and different medical scenarios also have different actual situations. For example, different hospitals have a fixed pattern for the delay time between the examination and the output of the electrocardiogram. Due to the limitations of hospital internal processes, regulations, and the number of patients, the delay time is usually within a fixed range, such as 24 hours to 72 hours after the examination.

[0048] For example, the clinical results of a routine blood test in Hospital A are generally available from one day to seven days after the test. Therefore, the time window parameters for the routine blood test in Hospital A are as follows: start time: 1 day later; end time: within 7 days; detection period: 6 days; detection interval strategy: exponential backoff strategy; detection number threshold: 50 times.

[0049] Furthermore, the detection interval strategy refers to the detection frequency setting adopted within the detection time period. Based on the actual situation of clinical result data output, this application preferably adopts a detection strategy of high frequency first and then low frequency. Specifically, an exponential backoff strategy or a step-back strategy can be adopted, without specific limitations here.

[0050] In one embodiment of this application, the process of executing the data acquisition task based on the time window parameter to obtain the current patient's clinical outcome data includes: starting from the start time, asynchronously calling an external data interface using a probe interval strategy to query and obtain the corresponding clinical outcome data in the data acquisition task through the external data interface; terminating the current data acquisition task when the number of asynchronous calls to the external data interface exceeds the probe count threshold, or when the deadline is exceeded during the query process.

[0051] It should be noted that after initiating a data request to the external data interface of an external clinical information system, the current system's subsequent processing flow is not blocked. Instead, other tasks continue to be executed asynchronously. When the external data interface returns a response, the returned data is then received and processed.

[0052] In this invention, asynchronous calls to external data interfaces are used to periodically initiate data query requests to external systems according to preset time window parameters during the execution of data acquisition tasks. Through asynchronous calls, the system described in this application does not need to wait for the external interface to return results after each request before continuing operation, thereby avoiding resource consumption and task blocking caused by external system response delays, and improving overall data acquisition efficiency and system concurrency processing capabilities.

[0053] Specifically, starting from the start time, external data interfaces are asynchronously invoked according to the aforementioned detection interval strategy; clinical outcome data corresponding to the data acquisition task is queried and obtained through the external data interfaces; when the number of asynchronous calls to the external data interfaces exceeds the detection count threshold, the current data acquisition task is terminated; or, when the query process exceeds the deadline, the current data acquisition task is terminated. By introducing a time window parameter, the clinical outcome data acquisition process becomes controllable, avoiding prolonged blocking or invalid polling.

[0054] In one embodiment of this application, the system 100 further includes a status management module; the status management module is used to trigger the execution or terminate the execution of each task according to the life cycle status of the medical visit collection task, medical order collection task, and data collection task.

[0055] Specifically, the status management module is associated with the patient visit data collection task, medical order data collection task, and data acquisition task, respectively, and is used to record and manage the lifecycle status of each task. The status management module records the current status of each task. Before each execution, the multi-level parsing module 102 or the data acquisition module 103 obtains the current status of the current task from the status management module, and only executes if the task status is "pending execution". When a task is completed or fails, the status management module updates the status of the corresponding task.

[0056] The lifecycle states include, but are not limited to: pending execution state, in execution state, completed state, failed and pending restart state, and terminated state.

[0057] In another embodiment of this application, the status management module is also used to trigger the execution or termination of the corresponding task according to the life cycle status of each task, thereby realizing unified scheduling and control of the entire tiered acquisition process.

[0058] In one embodiment of this application, the system further includes: a data processing module; the data processing module is connected to the data acquisition module and is used to perform deduplication, integration and standardization processing on the acquired clinical outcome data.

[0059] Specifically, the data processing module is connected to the data acquisition module and is used to preprocess the acquired clinical outcome data. The preprocessing includes data deduplication, data integration, and data standardization. Through this data processing module, the consistency and usability of the final clinical outcome data can be improved, facilitating subsequent data analysis or business applications.

[0060] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0061] It should be noted that, in the embodiments of this application, the words "exemplary" or "for example" indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0062] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0063] Figure 3 This is a schematic block diagram illustrating a method-based approach provided in an embodiment of this application. The method is applied to a system as described above, and includes:

[0064] Step S31: Obtain the current patient's master index information and generate a medical visit collection task based on the master index information.

[0065] Step S32: Obtain the corresponding medical information based on the medical visit collection task, generate a medical order collection task based on the medical visit information and the master index information, obtain the corresponding medical order information based on the medical order collection task, and generate a data collection task based on the medical order information.

[0066] Step S33: Generate corresponding time window parameters for the data acquisition task based on preset time window rules, and execute the data acquisition task based on the time window parameters to obtain the current patient's clinical outcome data.

[0067] It should be understood that the specific process of performing the above-mentioned steps has been described in detail in the above system embodiments, and will not be repeated here for the sake of brevity.

[0068] It should also be understood that the module division in the embodiments of this application is illustrative and only represents a logical functional division; in actual implementation, there may be other division methods. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0069] Figure 4 This is a schematic block diagram of the electronic terminal provided in an embodiment of this application. Figure 4As shown, the computer device includes at least one processor 401, a memory 402, at least one network interface 403, and a user interface 405. The various components in the device are coupled together via a bus system 404. It is understood that the bus system 404 is used to implement communication between these components. In addition to a data bus, the bus system 404 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 4 The general will label all buses as bus systems.

[0070] The user interface 405 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0071] It is understood that memory 402 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.

[0072] In this embodiment of the invention, the memory 402 is used to store various types of data to support the operation of the electronic terminal 400. Examples of this data include any executable program for operation on the electronic terminal 400, such as the operating system 4021 and application program 4022; the operating system 4021 contains various system programs, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks. The application program 4022 may contain various applications, such as media players, browsers, etc., for implementing various application services. The tiered asynchronous acquisition method for clinical data provided in this embodiment of the invention can be included in the application program 4022.

[0073] The methods disclosed in the above embodiments of the present invention can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 401 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 401 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in a memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0074] In an exemplary embodiment, the electronic terminal 400 may be used to execute the aforementioned method by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs).

[0075] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to perform the method of any of the embodiments.

[0076] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to execute a step-by-step asynchronous acquisition method for clinical data according to any of the embodiments shown.

[0077] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0078] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0079] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0080] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0081] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0082] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0083] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. A computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs, DVDs), or semiconductor media (e.g., solid-state disks, SSDs, etc.).

[0084] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0085] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included 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.

[0086] In summary, this application provides a tiered asynchronous data acquisition system, method, medium, program product, and terminal for clinical data. The system includes: a task acquisition module for acquiring the current patient's master index information and generating a patient visit acquisition task based on the master index information; a multi-level parsing module for acquiring corresponding patient visit information based on the patient visit acquisition task, generating a medical order acquisition task based on the patient visit information and the master index information, acquiring corresponding medical order information based on the medical order acquisition task, and generating a data acquisition task based on the medical order information; and a data acquisition module for generating corresponding time window parameters for the data acquisition task based on preset time window rules, and executing the data acquisition task based on the time window parameters to acquire the current patient's clinical outcome data. This application reduces the continuous pressure on the source system by constructing a tiered asynchronous incremental acquisition mechanism centered on time windows and state-driven mechanisms.

[0087] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A tiered asynchronous data acquisition system for clinical data, characterized in that, include: The task acquisition module is used to acquire the current patient's master index information and generate a medical visit collection task based on the master index information. A multi-level parsing module is used to obtain corresponding medical information based on the medical visit collection task, generate a medical order collection task based on the medical visit information and the main index information, obtain corresponding medical order information based on the medical order collection task, and generate a data collection task based on the medical order information. The data acquisition module is used to generate corresponding time window parameters for the data acquisition task based on preset time window rules, and to execute the data acquisition task based on the time window parameters to obtain the current patient's clinical outcome data.

2. The tiered asynchronous acquisition system for clinical data according to claim 1, characterized in that, The system also includes a status management module; the status management module is used to trigger the execution or terminate the execution of each task according to the life cycle status of the medical visit collection task, medical order collection task, and data collection task.

3. The tiered asynchronous acquisition system for clinical data according to claim 1, characterized in that, The time window parameters include: start time, detection time period, detection interval strategy, detection number threshold, and end time.

4. The tiered asynchronous acquisition system for clinical data according to claim 3, characterized in that, The process of performing the data acquisition task based on the time window parameter to obtain the current patient's clinical outcome data includes: Starting from the start time, an external data interface is asynchronously invoked using a detection interval strategy to query and obtain the corresponding clinical outcome data in the data acquisition task through the external data interface; The current data collection task is terminated when the number of asynchronous calls to the external data interface exceeds the detection threshold, or when the deadline is exceeded during the query process.

5. The tiered asynchronous acquisition system for clinical data according to claim 1, characterized in that, The system further includes an interface adaptation module; the interface adaptation module is connected to the data acquisition module and the multi-level parsing module respectively, and is used to adapt and communicate with external data interfaces of different clinical information systems.

6. The tiered asynchronous acquisition system for clinical data according to claim 1, characterized in that, The system further includes a data processing module; the data processing module is connected to the data acquisition module and is used to perform deduplication, integration and standardization processing on the acquired clinical outcome data.

7. A stepped asynchronous acquisition method for clinical data, characterized in that, include: Obtain the current patient's master index information, and generate a medical visit collection task based on the master index information; Based on the medical visit collection task, obtain the corresponding medical visit information, and generate a medical order collection task based on the medical visit information and the main index information. Based on the medical order collection task, obtain the corresponding medical order information, and generate a data collection task based on the medical order information. Based on preset time window rules, corresponding time window parameters are generated for the data acquisition task, and the data acquisition task is executed based on the time window parameters to obtain the current patient's clinical outcome data.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the stepwise asynchronous acquisition method for clinical data as described in claim 7.

9. A computer program product, characterized in that, The computer program product includes computer program code, which, when run on a computer, enables the computer to implement the step-by-step asynchronous acquisition method for clinical data as described in claim 7.

10. An electronic terminal, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the stepwise asynchronous acquisition method for clinical data as described in claim 7.

Images