Design Method for Index of Heterogeneous Data in Joint Replacement Surgery

By designing heterogeneous data index of joint replacement surgery, using a combination of partition key and sorting key structure, combining key/value pair pattern and global secondary index, the huge challenges of data isomerism and scale in orthopedic joint replacement surgery are solved, and efficient analysis of the causes of medical malpractice is achieved.

CN115237918BActive Publication Date: 2025-08-01HANGZHOU HUXIYUN BAISHENG TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202210887980.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-07-27
Publication Date
2025-08-01
Estimated Expiration
2042-07-27

AI Technical Summary

Technical Problem

In the prior art, there are adverse events in prosthesis implantation after orthopedic joint replacement surgery, and the lack of scientific and effective data management and analysis methods, which leads to difficulties in analyzing the causes of medical accidents. The data platform faces huge challenges in heterogeneity, timing and scale.

Method used

A heterogeneous data index method for joint replacement surgery is designed, using a combination of partition key and sorting key structure, combining key/value pair patterns and global secondary indexes, supporting accurate and flexible querying, and building a data model to analyze the causes of medical accidents.

Benefits of technology

It realizes high-performance indexing and search functions for massive multimodal orthopedic surgical data, supports backtracking and epidemiological analysis, and improves the scientificity and accuracy of medical accident causes analysis.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115237918B_ABST
    Figure CN115237918B_ABST
Patent Text Reader

Abstract

In an embodiment of the present disclosure, a design method for heterogeneous data indexing in joint replacement surgery is provided, belonging to the technical field of robot data processing. The method includes: all the data of the system consists of a partition key PK representing an entity, a sort key SK representing the attributes of the PK, and other data. Among them, a data table in the system database stores various different types of data during the surgery, and the various different types of data include: multiple types of data such as patients, doctors, prostheses, surgical plans, surgical operations, and postoperative effects. It realizes the support for massive multi-modal orthopedic surgery data, as well as high-performance indexing and searching functions. The processing solution of the present disclosure can scientifically, objectively, and accurately analyze the causes of medical accidents through big data technology, which has important significance in actual clinical applications.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to the technical field of robot data processing, and particularly to a method for designing an index for heterogeneous data in joint replacement surgery. Background Art

[0002] After orthopedic joint replacement surgery, the prosthesis can be used in the patient's body for up to ten years. However, currently, about 25% of prosthesis implantations have various adverse events and medical accidents, such as premature aging, prosthesis detachment, prosthesis abnormal sound, etc., resulting in the patient needing a second operation, which imposes a heavy burden on the patient's quality of life and medical insurance payment. Therefore, it is extremely urgent to analyze the causes of prosthesis implantation surgery accidents. However, due to the complex causes, it is very difficult to implement, and the main reasons include: unreasonable surgical plans, non-standard surgical operations, differences in patients' living habits, and quality problems of the prosthesis itself. With the emergence of computer-aided surgical systems such as surgical navigation and surgical robots, it has become possible to record high-quality data in detail and efficiently. However, in current clinical applications, there is still a lack of a scientific and effective data governance and analysis method for a large number of data from different sources and of different types, so that the causes of medical accidents can be analyzed scientifically, objectively, and accurately. In order to support the analysis of the causes of medical accidents, the data platform faces the following challenges in data governance:

[0003] 1) Due to the heterogeneity of data, the data platform needs to collect various different types of data.

[0004] Different from transaction data, which can be well tabulated, medical data includes a large amount of data that cannot be tabulated, such as medical images (preoperative and postoperative CT), prosthesis CAD models, prosthesis placement positions, patients' blood pressure and weight, etc. For a data platform with relatively complete data, there are roughly thousands of data types, and about tens of thousands of markers can be extracted. Due to the diversity of its data formats and types, different data governance methods need to be adopted.

[0005] 2) Due to the temporality of data, the data platform needs to analyze according to the order of event occurrence and implement interactions between multiple different modalities.

[0006] First, because the most important analysis method in current medical events is evidence-based analysis. For example, find patients who used the prosthesis of Company A for joint and had prosthesis detachment within three years after the operation. In this regard, in the recorded data of the data platform, the temporal relationship of medical events (within three years after the operation) is extremely important. Therefore, the database itself must be designed to support temporal tracking and searching.

[0007] Second, during the process of searching for medical data, cross-modal search is usually required. For example, through one type of data (the prosthesis of Company A for joint A), another type of data (patients with postoperative prosthesis detachment) is searched. Therefore, the database must also be designed to support cross-modal search.

[0008] 3) Due to the huge scale of medical data, a cluster of thousands of nodes is required for the data platform to complete.

[0009] For the complete data of orthopedic joint replacement surgery, each case is nearly at the TB level, and the number of surgeries planned annually is in the millions. For such a huge amount of data, the data platform faces huge challenges in data analysis and storage, and a cluster of thousands of nodes is required for it to complete. Summary of the Invention

[0010] In view of this, the embodiments of the present disclosure provide a method for designing heterogeneous data indexes for joint replacement surgery to at least partially solve the problems existing in the prior art.

[0011] The embodiments of the present disclosure provide a method for designing heterogeneous data indexes for joint replacement surgery, including:

[0012] All the data of the system consists of a partition key PK representing an entity, a sort key SK representing the attributes of the PK, and other data;

[0013] The PK is the partition key of the entire table, used to identify the entity itself; there are 5 types of entities in the database: patients, left femoral prostheses, right femoral prostheses, tibial prostheses, and surgical plans; the partition keys corresponding to the 5 types of entities are: PAT#PID, IMP#FL#ID, IMP#FR#ID, IMP#T#ID, and SUR#UUID; among them, PAT represents patients, PID represents patient ID, IMP#FL represents the left femoral prosthesis, ID represents the model, IMP#FR represents the right femoral prosthesis, IMP#T represents the tibial prosthesis, SUR represents the surgical plan, and UUID represents the unique surgical identifier; through this design form, the database has elasticity, and with the expansion requirements of the database structure, it supports incorporating extended entity fields into the PK column, and the extended fields include data required by doctors, nurses, etc.

[0014] The SK is the sorting key for the entire table and is used to identify attributes; the patient data includes the patient's basic information, associated surgeries, and associated doctors; among them, the patient's basic information includes attributes such as name, birthday, gender, and home address, and its SK is PAT#PID; the associated surgery records the surgery records the patient has undergone, and its SK is SUR#UUID; the associated doctor records the information of the patient's attending doctor, and its SK is DR#0001, representing the doctor numbered 0001 for this surgery; the surgical plan contains multiple attributes, including the affected limb of the surgery, the attending doctor, the patient undergoing the surgery, the preselected prosthesis model, the installed prosthesis model, preoperative data, intraoperative data, postoperative data, cutting plane, initial registration point, precise registration point, and gap balance curve. The SK starts with "SUR#", and SUR#PRE#LMK#HIPC represents the preoperative femoral center registration, where PRE represents preoperative data and LMK represents initial registration; SUR#IN#PLA#AP represents the intraoperative femoral front cutting plane origin point, where IN represents intraoperative data and PLA represents the cutting plane; the surgical operation data includes 6 types, namely the model of the replaced prosthesis, the installation position of the replaced prosthesis, each pick-up of the registration point, recording the surgical effects of various sensors and the results calculated by the surgical robot navigation system, the loading record of the surgical plan, and the information on whether the postoperative surgical plan is successfully stored. Its SK starts with "OP#", and OP#CII#0001 represents the surgical operation of replacing the prosthesis model, indicating its serial number is 0001; the SK is represented by a multi-layer structure and redundant items are added to enable fast query;

[0015] Other data has various different expressions and is used to expand the partition key PK according to specific requirements.

[0016] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0017] Use the key / value pair mode for storage and query. In the database, the primary key uniquely identifies data tuples. The database uses the partition key PK as the primary key, or forms the primary key by combining PK and the sorting key SK. When PK can uniquely identify each piece of data, PK will serve as the primary key to identify the tuple ID. When different data tuples have the same PK, SK is introduced as the identifier for auxiliary data. At this time, PK + SK as a whole serves as the primary key to uniquely identify the data. In the key / value pair design, the primary key is unique within the table, and the structure of the value is flexible and variable, thereby meeting the diversified expression of data and data relationships;

[0018] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0019] Data query includes two methods: precise query and flexible query.

[0020] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0021] Precise query is performed by inputting key values;

[0022] When it is necessary to set the limiting conditions for precise query, after setting the limiting conditions for the input key values, data query is performed through cross-modal secondary precise query;

[0023] When it is not necessary to set the limiting conditions for precise query, data query is directly performed through cross-modal secondary precise query.

[0024] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0025] When flexible query is performed, the database is repartitioned through a global secondary index GSI to facilitate query through different partition key values;

[0026] When it is necessary to set the limiting conditions for flexible query, after setting the limiting conditions for the input query values, data query is performed through cross-modal secondary precise query;

[0027] When it is not necessary to set the limiting conditions for flexible query, data query is directly performed through cross-modal secondary precise query

[0028] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0029] Data query is performed through precise query or flexible query. Precise query is a query method that directly inputs key values (PK, SK) to obtain patient information, surgical information, and prosthesis information. Flexible query is performed through a GSI index. Given a time range, information that meets the conditions is obtained;

[0030] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0031] A GSI table (PK: TYPE, SK: TIME) is designed for flexible query. During query, data will first be located according to the query inspection type, and then data that meets the time requirements and corresponding conditions will be screened out. The index structure is designed as follows:

[0032] GSI PK = TYPE (string)

[0033] GSI SK = TIME (string)

[0034] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0035] The query results are used to identify the causes of medical accidents and adverse events and conduct retrospective analysis, or to analyze the relationship between the frequency of various medical events and different biomarkers. Through secondary search and primary event aggregation, all eligible events are found. All found events are grouped and aggregated according to attributes, and the required information is found through secondary search.

[0036] Retrospective analysis is used to identify the causes of medical accidents and adverse events. When a patient experiences a medical event, it is used to:

[0037] Based on the preoperative plan and motion analysis, it can be analyzed whether the surgical plan is reasonable;

[0038] By comparing intraoperative data with preoperative data, the positioning error of the surgery can be analyzed, mainly analyzing whether there is positioning error in the computer-assisted navigation system;

[0039] The doctor's operating level can be analyzed based on the postoperative gap balance curve in the postoperative verification data, the actual measured prosthesis and installation effect, and the doctor's operation and planning errors;

[0040] According to the rehabilitation records, we can see whether the patient has returned to normal after surgery or whether there are any changes in living habits.

[0041] According to a specific implementation of the embodiment of the present disclosure, the method further includes:

[0042] Based on the results of flexible queries, epidemiological analysis is performed. Epidemiological analysis is used to analyze the association between the frequency of various medical events and different biomarkers, to prepare the definition of product and surgical indications, and to recruit suitable candidates for clinical trial enrollment, including the relationship between the frequency of adverse events in joint replacement surgery and body weight.

[0043] According to a specific implementation of the embodiment of the present disclosure, the method further includes:

[0044] Constructing a data model for heterogeneous data of joint replacement surgery, the data model includes: patient information data model, preoperative data model, intraoperative data model, postoperative data model, prosthesis data model and surgical operation record data model;

[0045] The patient information data model includes: medical history information, attending physician, selected prosthesis type, affected limb selection, and default flexion angle;

[0046] The preoperative data model includes: a preselected femoral prosthesis, femoral model data, femoral initial registration anatomical landmarks, a preselected tibial prosthesis, tibial model data, and tibial initial registration anatomical landmarks;

[0047] The intraoperative data model includes: femoral initial registration anatomical landmark points, femoral fine registration anatomical landmark points, femoral front cutting plane, femoral rear cutting plane, femoral distal cutting plane, femoral verification nail, tibial initial registration anatomical landmark points, tibial fine registration anatomical landmark points, tibial cutting plane, tibial verification nail, intraoperative gap balance curve;

[0048] The postoperative data model includes: femoral front cutting plane, femoral rear cutting plane, femoral distal cutting plane, femoral verification nail, tibial prosthesis cutting plane, tibial verification nail, postoperative gap balance curve;

[0049] The prosthesis data model includes: the normal vector of the front cutting plane, the normal vector of the femoral rear cutting plane, the origin coordinates of the front cutting plane, color, medial condyle registration point, three-dimensional prosthesis model, lateral condyle registration point, the origin coordinates of the rear cutting plane, prosthesis model in the left leg femoral prosthesis model; the normal vector of the front cutting plane, the normal vector of the femoral rear cutting plane, the origin coordinates of the front cutting plane, color, medial condyle registration point, three-dimensional prosthesis model, lateral condyle registration point, the origin coordinates of the rear cutting plane, prosthesis model in the right leg femoral prosthesis model; the normal vector of the tibial cutting plane, the origin coordinates of the tibial prosthesis cutting plane, tibial color, tibial three-dimensional prosthesis model, and tibial prosthesis model in the tibial prosthesis model;

[0050] The surgical operation record data model includes: a unique surgical identifier, the time when the data is generated, the types of surgical operations recorded, the data records before the operation, and the data records after the operation.

[0051] The method for designing an index for heterogeneous data in joint replacement surgery in the embodiments of the present disclosure includes constructing a data model for heterogeneous data in joint replacement surgery. The data model includes: patient information data model, preoperative data model, intraoperative data model, postoperative data model, prosthesis data model, and surgical operation record data model. Through the processing solution of the present disclosure, it is possible to support a large amount of multimodal orthopedic surgery data and achieve high-performance indexing and searching functions. Brief Description of the Drawings

[0052] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present disclosure. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0053] Figure 1 It is a flowchart of the method for designing an index for heterogeneous data in joint replacement surgery provided by the embodiments of the present disclosure;

[0054] Figure 2 It is a schematic diagram of data association provided by the embodiments of the present disclosure;

[0055] Figure 3 Schematic diagram of the data query method provided by the embodiments of the present disclosure;

[0056] Figure 4 Schematic diagram of distal femoral osteotomy provided by the embodiments of the present disclosure;

[0057] Figure 5 Schematic diagram of the data storage block diagram provided by the embodiments of the present disclosure;

[0058] Figure 6 Schematic diagram of the installation of the laser target of the surgical navigation system provided by the embodiments of the present disclosure. Detailed implementation manners

[0059] The embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0060] The embodiments of the present disclosure provide a method for designing heterogeneous data indexes for joint replacement surgeries. The method for designing heterogeneous data indexes for joint replacement surgeries provided by this embodiment can be executed by a computing device, which can be implemented as software, or as a combination of software and hardware, and the computing device can be integrally provided in a server, a client, etc.

[0061] The method for designing heterogeneous data indexes for joint replacement surgeries in the embodiments of the present disclosure includes the following:

[0062] For heterogeneous data of joint replacement surgeries, construct a data model, and the data model includes: a patient information data model, a preoperative data model, an intraoperative data model, a postoperative data model, a prosthesis data model, and a surgical operation record data model;

[0063] The patient information data model includes: medical record information, attending physician, selected prosthesis type, affected limb selection, and default flexion angle;

[0064] The preoperative data model includes: preselected femoral prosthesis, femoral model data, femoral initial registration anatomical landmark points, preselected tibial prosthesis, tibial model data, tibial initial registration anatomical landmark points;

[0065] The intraoperative data model includes: femoral initial registration anatomical landmark points, femoral fine registration anatomical landmark points, femoral front cutting plane, femoral rear cutting plane, femoral distal cutting plane, femoral verification nail, tibial initial registration anatomical landmark points, tibial fine registration anatomical landmark points, tibial cutting plane, tibial verification nail, intraoperative gap balance curve;

[0066] The postoperative data model includes: femoral front cutting plane, femoral rear cutting plane, femoral distal cutting plane, femoral verification nail, tibial prosthesis cutting plane, tibial verification nail, postoperative gap balance curve;

[0067] The prosthesis data model includes: the normal vector of the front cutting plane, the normal vector of the rear femoral cutting plane, the origin coordinates of the front cutting plane, color, the medial condyle registration point, the three-dimensional prosthesis model, the lateral condyle registration point, the origin coordinates of the rear cutting plane, and the prosthesis model number included in the left femoral prosthesis model; the normal vector of the front cutting plane, the normal vector of the rear femoral cutting plane, the origin coordinates of the front cutting plane, color, the medial condyle registration point, the three-dimensional prosthesis model, the lateral condyle registration point, the origin coordinates of the rear cutting plane, and the prosthesis model number included in the right femoral prosthesis model; the normal vector of the tibial cutting plane, the origin coordinates of the tibial prosthesis cutting plane, the tibial color, the three-dimensional tibial prosthesis model, and the tibial prosthesis model number included in the tibial prosthesis model;

[0068] The surgical operation record data model includes: a unique surgical identifier, the time when the data is generated, the type of surgical operation recorded, the data record before the operation, and the data record after the operation.

[0069] For the specific structures of the patient information data model, the preoperative data model, the intraoperative data model, the postoperative data model, the prosthesis data model, and the surgical operation record data model, please refer to Table 1-6 below.

[0070] Table 1 Patient Information Data Model

[0071]

[0072] Table 2 Preoperative Data Model

[0073]

[0074]

[0075] Table 3 Intraoperative Data Model

[0076]

[0077]

[0078] Table 4 Postoperative Data Model

[0079]

[0080]

[0081] Table 5 Prosthesis Data Model

[0082]

[0083]

[0084] Table 6 Surgical Operation Record Data Model

[0085]

[0086] In addition, referring to Figure 1 , the method for designing the heterogeneous data index of the joint replacement surgery in the disclosed embodiments may further include the following steps:

[0087] S101, all the data of the system consists of a partition key PK representing an entity, a sort key SK representing the PK attribute, and other data;

[0088] S102, the PK is the partition key of the entire table, used to identify the entity itself; there are 5 types of entities in the database: patients, left femoral prostheses, right femoral prostheses, tibial prostheses, and surgical plans; the partition keys corresponding to the 5 types of entities are: PAT#PID, IMP#FL#ID, IMP#FR#ID, IMP#T#ID, and SUR#UUID; where PAT represents patients, PID represents patient IDs, IMP#FL represents left femoral prostheses, ID represents models, IMP#FR represents right femoral prostheses, IMP#T represents tibial prostheses, SUR represents surgical plans, and UUID represents the unique surgical identifier; through this design form, the database has elasticity, and with the expansion requirements of the database structure, it supports incorporating extended entity fields into the PK column, and the extended fields include data such as doctors and nurses required;

[0089] S103. SK is the sorting key for the entire table, used to identify attributes. Patient data includes the patient's basic information, associated surgeries, and associated doctors. Among them, the patient's basic information includes attributes such as name, birthday, gender, and home address, and its SK is PAT#PID; the associated surgery records the surgeries the patient has undergone, and its SK is SUR#UUID; the associated doctor records the information of the patient's attending doctor, and its SK is DR#0001, representing doctor No. 0001 for this surgery; the surgical plan contains various attributes, including the affected limb for surgery, the attending doctor, the patient undergoing the surgery, the preselected prosthesis model, the installed prosthesis model, preoperative data, intraoperative data, postoperative data, cutting plane, initial registration point, precise registration point, and gap balance curve. The SK starts with "SUR#". SUR#PRE#LMK#HIPC represents the preoperative femoral center registration, where PRE represents preoperative data and LMK represents initial registration; SUR#IN#PLA#AP represents the intraoperative femoral front cutting plane origin point, where IN represents intraoperative data and PLA represents the cutting plane; the surgical operation data includes 6 types, namely the model of the replaced prosthesis, the installation position of the replaced prosthesis, each pick-up of the registration point, recording the surgical effects of various sensors and the results calculated by the surgical robot navigation system, the loading record of the surgical plan, and the information on whether the postoperative surgical plan is successfully stored. Its SK starts with "OP#". OP#CII#0001 represents the surgical operation of replacing the prosthesis model, indicating its serial number is 0001; the SK is represented by a multi-layer structure and redundant items are added to enable fast query;

[0090] S104. Other data has various different expressions, used to expand the partition key PK according to specific requirements.

[0091] The method for designing the heterogeneous data index of joint replacement surgery in the disclosed embodiments, the method further includes:

[0092] Data warehouse design and analysis system

[0093] 1. Data architecture and index format

[0094] 1) Design description

[0095] This system mainly uses a NoSQL unstructured database as the basic architecture, supports each tuple to be composed of different fields, thereby reducing the coupling relationship between data and enhancing the expandability of data attributes, so as to meet the diversified and flexible access of data and data relationships. When performing precise queries, it is searched through the primary key, and when performing flexible queries, it is queried through the global secondary index, that is, the GSI index. The descriptions of the primary key and the GSI index are as follows:

[0096] ① Primary key:

[0097] In terms of technical details, this system mainly uses the key / value pair pattern for storage and query. In a database, the primary key uniquely identifies data tuples. The database can directly use the partition key (Partition Key, i.e., PK) as a simple primary key, or form a composite primary key with PK and the sort key (Sort Key, i.e., SK). Specifically, when the PK can uniquely identify each piece of data, the PK will serve as a simple primary key to identify the tuple ID. When different data tuples have the same PK, the SK is introduced as an identifier for auxiliary data. At this time, the whole of PK + SK will be used as the primary key to uniquely identify the data. The system can efficiently locate and accurately query data based on the primary key of the data. Therefore, in the key / value pair design of this system, the primary key is unique within the table, while the structure of the value allows for flexibility, thus meeting the diverse expression of data and data relationships.

[0098] ②GSI Index:

[0099] When performing flexible queries, since the query time span is large and the query types and conditions are complex. Therefore, a GSI table (PK: TYPE, SK: TIME) is designed for such queries to speed up the query. During the query, the data will be located according to the query inspection type first, and then the data that meets the time requirements and corresponding conditions will be screened out. The index structure is designed as follows:

[0100] GSI PK = TYPE(string)

[0101] GSI SK = TIME(string)

[0102] 2) Data Index Format

[0103] All data in this system consists of a partition key (PK), a sort key (SK), and other data.

[0104] ①PK:

[0105] is the partition key of the entire table, used to identify the entity itself; there are 5 types of entities in the database: patients, left femoral prosthesis, right femoral prosthesis, tibial prosthesis, and surgical plan; the partition keys corresponding to the 5 types of entities are: PAT#PID, IMP#FL#ID, IMP#FR#ID, IMP#T#ID, and SUR#UUID; among them, PAT represents the patient, PID represents the patient ID, IMP#FL represents the left femoral prosthesis, ID represents the model, IMP#FR represents the right femoral prosthesis, IMP#T represents the tibial prosthesis, SUR represents the surgical plan, and UUID represents the unique surgical identifier; through this design form, the database has elasticity, and as the database structure expands, it supports incorporating extended entity fields into the PK column, and the extended fields include data such as doctors and nurses.

[0106] ②SK:

[0107] is the sort key of the entire table, used to identify attributes; patient data includes the basic information of the patient, associated surgeries, and associated doctors; among them, the basic patient information includes attributes such as name, birthday, gender, and home address, and its SK is PAT#PID; the associated surgery records the surgery records the patient has undergone, and its SK is SUR#UUID; the associated doctor records the information of the patient's attending doctor, and its SK is DR#0001, representing doctor No. 0001 for this surgery; the surgical plan contains multiple attributes, including the affected limb of the surgery, the attending doctor, the patient undergoing the surgery, the preselected prosthesis model, the installed prosthesis model, preoperative data, intraoperative data, postoperative data, cutting plane, initial registration point, precise registration point, and gap balance curve. The SK starts with "SUR#", and SUR#PRE#LMK#HIPC represents the preoperative femoral center registration, where PRE represents preoperative data and LMK represents the initial registration; SUR#IN#PLA#AP represents the intraoperative femoral front-end cutting plane origin point, where IN represents intraoperative data and PLA represents the cutting plane; the surgical operation data includes 6 types, namely the model of the replaced prosthesis, the installation position of the replaced prosthesis, each pick-up of the registration point, recording the surgical effects of various sensors and the results calculated by the surgical robot navigation system, the loading record of the surgical plan, and the information on whether the postoperative surgical plan is successfully stored. Its SK starts with "OP#", and OP#CII#0001 represents the surgical operation of replacing the prosthesis model, indicating its serial number is 0001; the SK is represented by a multi-layer structure and redundant items are added to enable fast query.

[0108] ③Other data:

[0109] has various different expressions and can be expanded according to specific requirements.

[0110] 3) Design advantages

[0111] Due to its simple and flexible structure design, NoSQL key / value databases are very easy to implement ultra-large-scale distributed systems. While supporting flexible data models, they also further meet the characteristics of large-capacity storage, high-performance access, and highly available operations.

[0112] 2. Data Index Format

[0113] 1) Design Description

[0114] Data is stored as data tuples, and the relationships between data will be simulated and stored using the adjacent list design pattern. The data of orthopedic surgeries is modeled in a single table. A convenient multi-level structure is used to arrange the data, extracting the differences in different types of data to achieve streamlined and efficient data modeling. In addition, it can also be quickly adjusted according to the needs of the hospital.

[0115] 2) Orthopedic Surgery Database Format

[0116] ① Patient

[0117]

[0118]

[0119] ② Surgical Data

[0120] a. Surgical Plan

[0121]

[0122]

[0123]

[0124]

[0125]

[0126] b. Surgical Operation

[0127]

[0128] c. Surgical Associated Data

[0129]

[0130]

[0131] ③ Prosthesis

[0132]

[0133]

[0134] 3. Data analysis and clinical application

[0135] This invention relates to a method and system for designing an index for heterogeneous data related to joint replacement surgery. This system utilizes big data technology to analyze and identify the causes of prosthetic implant surgery accidents. Due to the enormous scale of medical data and the difficulty of querying it, conventional relational databases are unable to achieve fast and efficient querying. Therefore, this system develops a distributed, heterogeneous data analysis platform for orthopedic joint replacement surgery based on NoSQL. This platform provides different query methods for data in different modalities, primarily supporting two query modes: precise query and flexible query. Precise query refers to a query method that directly inputs key values (PK, SK) to obtain patient information, surgical information, prosthesis information, and so on. Flexible query refers to a query using a GSI index, allowing for a given time range to retrieve information that meets the criteria. In addition to these query methods, cross-modal secondary precise querying is also available. This method involves querying PK values within other modal domains to obtain data from other modal domains. For example, if a patient's prosthesis falls off, the model number of the implanted prosthesis can be used to retrieve information about all patients who have installed that model within the past three years.

[0136] From a clinical perspective, there are two main applications of the data platform: the first is retrospective analysis, and the second is epidemiological analysis.

[0137] 1) Retrospective analysis

[0138] Retrospective analysis is mainly used to find the causes of medical accidents and adverse events. For example, when a patient has a medical event:

[0139] a. Based on the preoperative plan and motion analysis, it can be analyzed whether the surgical plan is reasonable;

[0140] b. By comparing intraoperative data with preoperative data, the positioning error of the surgery can be analyzed, mainly to analyze whether there is positioning error in the computer-assisted navigation system;

[0141] c. The doctor's operating level can be analyzed based on the postoperative gap balance curve in the postoperative verification data, the actual measured prosthesis and installation effect, and the doctor's operation and planning errors;

[0142] d. Check the patient's recovery record to see if they have recovered to normal or if their lifestyle has changed;

[0143] For this type of application, the analysis function mainly focuses on the same surgical event, searching for different modal data, which is defined as precise query in the system.

[0144] From the perspective of the database, the specific query applications are described as follows:

[0145] ① Patient-related data query

[0146] a. Obtain all information of the patient with PID = 0001:

[0147] When entering PK = PAT#0001, all patient-related information including the patient's basic information, surgical data, attending doctor, etc. can be obtained.

[0148] b. Obtain the basic information of the patient with PID = 0001:

[0149] When entering PK = PAT#0001 and SK = PAT#0001, the patient's basic information can be obtained.

[0150] c. Obtain all surgeries of the patient with PID = 0001:

[0151] · When entering PK = PAT#0001 and SK = SUR, all surgeries of the patient can be obtained, and the data part is the surgery id.

[0152] · If you need to obtain the data of a specific surgery, a cross-modal secondary precise query is required. Enter PK = PAT#0001 and SK = SUR#UUID again to obtain it.

[0153] d. Obtain the attending doctor of the patient:

[0154] When entering PK = PAT#0001 and SK = DR, the attending doctor of the patient can be obtained, and the name is the doctor's name.

[0155] ② Surgery-related data query

[0156] a. Obtain all information of a single surgery:

[0157] · When entering PK = SUR#UUID, all information of a single surgery including the patient ID, affected limb (left / right leg), attending doctor, selected prosthesis, surgical plan (pre-operative, intra-operative, post-operative), surgical operation, etc. can be obtained.

[0158] · If you enter TYPE = SUR#LMK again, all initial registration point information of the surgical plan (including pre-operative, intra-operative, post-operative) can be obtained;

[0159] · If you enter TYPE = SUR#PLA again, all cutting plane information of the surgical plan (including pre-operative, intra-operative, post-operative) can be obtained;

[0160] b. Obtain the patients associated with the surgery:

[0161] · Enter PK = SUR#UUID, SK = SUR#PAT, and the surgery-related patient can be obtained. The data part is the patient ID.

[0162] · If you need to obtain a specific piece of data, a cross-modal secondary precise query is required. Enter PK = PAT#PID again to obtain the patient data.

[0163] c. Obtain information about the affected limb:

[0164] Enter PK = SUR#UUID, SK = SUR#LEG, and information about the affected limb can be obtained. The data part is the right leg / left leg.

[0165] d. Obtain information about the attending doctor:

[0166] Enter PK = SUR#UUID, SK = SUR#DR, and information about the attending doctor can be obtained. The data part is the doctor's name.

[0167] e. Obtain information about the femoral and tibial prostheses before the surgery, as well as the information about the finally installed femoral and tibial prostheses:

[0168] · Enter PK = SUR#UUID, SK = SUR#IMP, and the femoral and tibial prostheses before the surgery, as well as the finally installed femoral and tibial prostheses, can be obtained. The data part is the prosthesis ID.

[0169] · If you need to obtain a specific piece of data, a cross-modal secondary precise query is required. Enter PK = IMP#FR0001 again to obtain the specific prosthesis data.

[0170] f. Obtain all the operation information of this surgery:

[0171] Enter PK = SUR#UUID, SK = OP, and all the operations of this surgery can be obtained.

[0172] g. Obtain all the operation information of a certain type in this surgery:

[0173] · Enter PK = SUR#UUID, SK = OP#CII, and all the operations of replacing the prosthesis model in this surgery can be obtained;

[0174] · Enter PK = SUR#UUID, SK = OP#CIP, and all the operations of replacing the installation position of the prosthesis in this surgery can be obtained;

[0175] · Enter PK = SUR#UUID, SK = OP#MV, and all the operations of the movement data in this surgery can be obtained;

[0176] · Enter PK = SUR#UUID, SK = OP#RES, and all the operations of the calculation results of the navigation system in this surgery can be obtained;

[0177] · Enter PK = SUR#UUID, SK = OP#LOAD, and all operations for loading the surgical plan for this surgery can be obtained.

[0178] · Enter PK = SUR#UUID, SK = OP#SAVE, and all operations for storing the calculated surgical effect for this surgery can be obtained.

[0179] h. Obtain the surgical plan data information before the surgery in this surgery:

[0180] Enter PK = SUR#UUID, SK = SUR#PRE, and the surgical plan data before the surgery in this surgery can be obtained.

[0181] i. Obtain the surgical plan data information during the surgery in this surgery:

[0182] Enter PK = SUR#UUID, SK = SUR#IN, and the surgical plan data during the surgery in this surgery can be obtained.

[0183] j. Obtain the surgical plan data information after the surgery in this surgery:

[0184] Enter PK = SUR#UUID, SK = SUR#AFT, and the surgical plan data after the surgery in this surgery can be obtained.

[0185] ③ Prosthesis-related data query

[0186] a. Obtain all information of the prosthesis of femoral (right) model 0001:

[0187] Enter PK = IMP#FR#0001 to obtain all information of the prosthesis of femoral (right) model 0001, including femoral prosthesis model, color, registration points of the medial and lateral condyles, coordinates and normal vectors of the cutting plane points, etc.

[0188] b. Obtain all information of the prosthesis of femoral (left) model 0001:

[0189] Enter PK = IMP#FL#0001 to obtain all information of the prosthesis of femoral (right) model 0001, including femoral prosthesis model, color, registration points of the medial and lateral condyles, coordinates and normal vectors of the cutting plane points, etc.

[0190] c. Obtain all information of the prosthesis of tibial model 0001:

[0191] When PK = IMP#T#0001, obtain all information of the prosthesis of tibial model 0001, including tibial prosthesis model, color, three-dimensional prosthesis model, etc.

[0192] 2) Epidemiological analysis

[0193] Epidemiological analysis is mainly used to analyze the association between the occurrence frequencies of various medical events and different biomarkers. In practical applications, it is mainly used to prepare for defining products and surgical indications, and to recruit suitable candidates for clinical trials, such as the relationship between the occurrence frequency of adverse events in joint replacement surgery and body weight. Such applications are implemented in the database through a pooling operation, which is defined as a flexible query in the system.

[0194] Usually through a secondary search, the first event pooling is mainly to find all eligible events, group and pool all the found events according to their attributes, and then find the required information through a secondary search.

[0195] From the perspective of the database, the specific query applications are described as follows:

[0196] ① Obtain surgical data through doctors

[0197] a. Input PK = SUR#DR;

[0198] b. Set the time range to obtain surgical data within the time period;

[0199] c. Obtain surgical data of a specified doctor;

[0200] d. If you need to obtain a specific piece of data, you need to perform a cross-modal secondary precise query. By inputting PK = SUR#UUID, you can obtain specific surgical data.

[0201] ② Obtain surgical data through prostheses

[0202] a. Input PK = SUR#IMP;

[0203] b. Set the time range to obtain surgical data within the time period;

[0204] c. Obtain surgical data of a specified use of femoral (left) / femoral (right) / tibial prosthesis model 1;

[0205] d. If you need to obtain a specific piece of data, you need to perform a cross-modal secondary precise query. By inputting PK = SUR#UUID, you can obtain specific surgical data; by inputting PK = SUR#UUID, SK = SUR#PAT, you can obtain the patient PID, and then obtain specific patient data through PAT#PID.

[0206] ③ Obtain patient data through doctors

[0207] a. Input PK = DR;

[0208] b. Set the time range to obtain patients within the time period;

[0209] c. Obtain the list of patients of a specified doctor;

[0210] d. If you need to obtain specific data of a certain patient, you need to perform a cross-modal secondary precise query. By inputting PK = PAT#PID, you can obtain the specific patient data.

[0211] ④ Check the prosthesis according to the color

[0212] a. Input PK = IMP#CLR;

[0213] b. Set the time range to obtain the prostheses within the time period;

[0214] c. Obtain the prostheses of the specified color;

[0215] d. Conduct a comparative analysis of prostheses of the same color but different models and manufacturers.

[0216] ⑤ Check the prosthesis according to the model and compare the prostheses between different companies of the same model

[0217] a. Input PK = IMP#ID;

[0218] b. Set the time range to obtain the prostheses within the time period;

[0219] c. Obtain the prostheses of the specified model;

[0220] d. Conduct a comparative analysis of prostheses between different companies of the same model.

[0221] ⑥ Screen patients by age

[0222] a. Input PK = PAT;

[0223] b. Set the time range to obtain the patients within the time period;

[0224] c. Set the age range: for example, 50 - 59 years old;

[0225] d. Obtain the data of all patients aged 50 - 59 years old.

[0226] 4. Data expansion

[0227] Since the database has strong scalability and there are various different expressions, users can flexibly add the required data according to specific needs. When expanding the data, it can be achieved by adding index data or adding PK items, as specifically described below:

[0228] 1) Add index data

[0229] For example, if you need to add prosthesis manufacturer information, you can add the following data under the corresponding prosthesis:

[0230]

[0231] For example, after the operation is completed and postoperative feedback needs to be added, the following data can be added under the corresponding operation data:

[0232]

[0233] For example, if patients need to be screened by femur length, the data of the patient's leg length can be added to achieve this. The specific data added is as follows:

[0234]

[0235] 2) Add PK items

[0236] If necessary, doctors, nurses, etc. can also be included in the PK items. After that, only the corresponding index needs to be added to query their data. The specific example is as follows:

[0237] ① First, add doctor data to the PK items:

[0238]

[0239] : ② Then add the index:

[0240]

[0241] The method for designing the heterogeneous data index of joint replacement surgery in the disclosed embodiment, the method further includes:

[0242] Data acquisition and storage

[0243] This system uses a surgical navigation robot for data collection, which is used to record orthopedic surgery data such as the incremental storage of surgery, the NoSQL heterogeneous data storage, the secondary storage of instrument data and patient imaging data. In actual application, various detailed data of the entire process (preoperative, intraoperative, and postoperative) of orthopedic joint replacement surgery, such as the joint prosthesis model used by the surgical robot during the operation, the prosthesis placement position, the surgical approach of the prosthesis, and the installation process, will be collected, and these data will be stored in the database according to the format defined by the database.

[0244] 1. Data collection

[0245] The data collection equipment of this system mainly includes a laser tracker, a laser target, a probe, etc., as Figure 6As shown. Laser tracker: used to read the relative positions of two laser targets in real time; two laser targets: one is placed on the femoral side of the knee joint, and the other is placed on the tibial side of the knee joint; knee plane tool: used to guide the doctor to confirm the osteotomy position and the prosthesis implantation position during osteotomy navigation; probe: used to collect anatomical landmark points. In actual use, the laser tracker marks the anatomical landmark points by capturing the coordinates of the probe relative to the laser target. The laser tracker captures the relative coordinates of the knee plane tool to determine the osteotomy plane position, as Figure 4 shown.

[0246] 2. Data storage

[0247] Most data can be directly stored in the database. However, surgical instrument data or patient image data related to the business is usually relatively large. If stored in the database, it will greatly affect the system data exchange speed. Therefore, the present invention uses a secondary storage middleware to store these large files, and uses a method of recording file index changes to replace frequent reading and writing of large files. Only all data is read and stored at the beginning and end of the surgery, and the changed parts are dynamically loaded through the file index during the surgery. The specific storage process is as Figure 5 shown.

[0248] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0249] Using the key / value pair mode for storage and query. In the database, the primary key uniquely identifies the data tuple. The database uses the partition key PK as the primary key, or forms the primary key by combining PK and the sort key SK. When PK can uniquely identify each piece of data, PK will serve as the primary key to identify the tuple ID. When different data tuples have the same PK, SK is introduced as the identifier of the auxiliary data. At this time, PK + SK as a whole serves as the primary key to uniquely identify the data. In the key / value pair design, the primary key is unique within the table, while the structure of the value is flexible and variable, thus meeting the diversified expression of data and data relationships; According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0250] Data query includes two methods: precise query and flexible query.

[0251] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0252] The precise query is performed by inputting the key value;

[0253] When it is necessary to set the limit conditions for the precise query, after setting the limit conditions for the input key value, the data query is performed through cross-modal secondary precise query;

[0254] When there is no need to set the limiting conditions for accurate query, directly perform data query through cross-modal secondary accurate query.

[0255] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0256] When performing flexible query, re-partition the database through the global secondary index GSI to facilitate query through different partition key values;

[0257] When it is necessary to set the limiting conditions for flexible query, after setting the limiting conditions for the input query value, perform data query through cross-modal secondary accurate query;

[0258] When there is no need to set the limiting conditions for flexible query, directly perform data query through cross-modal secondary accurate query

[0259] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0260] Perform data query through accurate query or flexible query. Accurate query is a query method to obtain patient information, surgical information, and prosthesis information by directly inputting key values (PK, SK). Flexible query is to perform query through the GSI index, and given a time range, obtain information that meets the conditions;

[0261] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0262] Designed a GSI table (PK: TYPE, SK: TIME) for flexible query. During query, the data will be located according to the query inspection type first, and then the data that meets the time requirements and corresponding conditions will be screened out. The index structure is designed as follows:

[0263] GSI PK = TYPE(string)

[0264] GSI SK = TIME(string)

[0265] According to a specific implementation manner of an embodiment of the present disclosure, the method further includes:

[0266] Based on the query results, when medical accidents and adverse events occur, find the causes of the accidents for retrospective analysis, or analyze the correlation between the occurrence frequencies of various medical events and different biomarkers. Through secondary search and the first event aggregation, find all events that meet the conditions, group and aggregate all the found events according to their attributes, and then find the required information through secondary search;

[0267] Retrospective analysis is used to find the causes of medical accidents and adverse events when they occur. After a medical event occurs to a patient, it is used for:

[0268] According to the preoperative plan and motion analysis, it can be analyzed whether the surgical plan is reasonable;

[0269] By comparing the intraoperative data with the preoperative data, the positioning error of the surgery can be analyzed, mainly analyzing whether there is a positioning error in the computer-assisted navigation system;

[0270] According to the postoperative gap balance curve in the postoperative verification data, the actual measurement of the prosthesis and the installation effect, and the error between the doctor's operation and the plan, the doctor's operation level can be analyzed;

[0271] According to the rehabilitation record, check whether the patient has returned to normal after the operation or whether there are changes in living habits.

[0272] According to a specific implementation manner of the embodiment of the present disclosure, the method further includes:

[0273] Based on the results of flexible queries, epidemiological analysis is performed. Epidemiological analysis is used to analyze the association between the occurrence frequencies of various medical events and different biomarkers, and is used to prepare for defining product and surgical indications and soliciting suitable candidates for clinical trial enrollment, including the relationship between the occurrence frequency of adverse events in joint replacement surgery and body weight.

[0274] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and this module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order from that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0275] The units involved in the embodiments of the present disclosure can be implemented in software or in hardware. Among them, the name of the unit does not constitute a limitation to the unit itself in some cases. For example, the first acquisition unit can also be described as "the unit for acquiring at least two Internet protocol addresses".

[0276] It should be understood that each part of the present disclosure can be implemented by hardware, software, firmware, or a combination thereof.

[0277] As described above, the foregoing are only specific embodiments of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed by the present disclosure should be covered by the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure shall be subject to the protection scope of the claims.

Claims

1. A design method for heterogeneous data indexing in joint replacement surgery, characterized in that Including: Construct a data model for heterogeneous data in joint replacement surgery. The data model includes: patient information data model, preoperative data model, intraoperative data model, postoperative data model, prosthesis data model, and surgical operation record data model; Use the key / value pair pattern for storage and query. In the database, the primary key uniquely identifies data tuples. The database uses the partition key PK as the primary key, or forms the primary key by combining PK and the sort key SK. When PK can uniquely identify each piece of data, PK will serve as the primary key to identify the tuple ID. When different data tuples have the same PK, SK is introduced as the identifier for auxiliary data. At this time, PK + SK as a whole serves as the primary key to uniquely identify the data. In the key / value pair design, the primary key is unique within the table, and the structure of the value is flexible and variable, thus meeting the diversified expression of data and data relationships; Data query includes two methods: precise query and flexible query. Precise query is performed by inputting key values; when it is necessary to set the limiting conditions for precise query, after setting the limiting conditions for the input key values, data query is performed through cross-modal secondary precise query; when it is not necessary to set the limiting conditions for precise query, data query is directly performed through cross-modal secondary precise query; When performing flexible query, the database is repartitioned through the global secondary index GSI to facilitate querying through different partition key values; when it is necessary to set the limiting conditions for flexible query, after setting the limiting conditions for the input query values, data query is performed through cross-modal secondary precise query; when it is not necessary to set the limiting conditions for flexible query, data query is directly performed through cross-modal secondary precise query; Data query is performed through precise query or flexible query methods. Precise query is a query method that directly inputs the key values (PK, SK) to obtain patient information, surgical information, and prosthesis information. Flexible query is performed through the GSI index. Given a time range, information that meets the conditions is obtained; A GSI table (PK: TYPE, SK: TIME) is designed for flexible query. During query, the data will first be located according to the query inspection type, and then the data that meets the time requirements and corresponding conditions will be screened out. The index structure is designed as follows: GSI PK = TYPE(string) GSI SK = TIME(string).

2. The method according to claim 1, wherein The method further includes: All data of the system consists of the partition key PK representing the entity, the sort key SK representing the attributes of PK, and other data; PK is the partition key for the entire table, used to identify the entity itself; there are 5 types of entities in the database: patients, left femoral prostheses, right femoral prostheses, tibial prostheses, and surgical plans; the partition keys corresponding to the 5 types of entities are: PAT#PID, IMP#FL#ID, IMP#FR#ID, IMP#T#ID, and SUR#UUID; among them, PAT represents patients, PID represents patient ID, IMP#FL represents the left femoral prosthesis, ID represents the model, IMP#FR represents the right femoral prosthesis, IMP#T represents the tibial prosthesis, SUR represents the surgical plan, and UUID represents the unique surgical identifier; through this design form, the database is made elastic, and with the expansion requirements of the database structure, it supports incorporating extended entity fields into the PK column, and the extended entity fields include data required by doctors and nurses; SK is the sort key for the entire table, used to identify attributes; patient data includes the basic information of the patient, associated surgeries, and associated doctors; among them, the basic patient information includes attributes such as name, birthday, gender, and home address, and its SK is PAT#PID; the associated surgery records the surgery records the patient has undergone, and its SK is SUR#UUID; the associated doctor records the information of the patient's attending doctor, and its SK is DR#0001, representing doctor No. 0001 for this surgery; the surgical plan contains multiple attributes, including the affected limb of the surgery, the attending doctor, the patient undergoing the surgery, the preselected prosthesis model, the installed prosthesis model, preoperative data, intraoperative data, postoperative data, cutting plane, initial registration point, fine registration point, and gap balance curve, and the SK starts with "SUR#", and SUR#PRE#LMK#HIPC represents the preoperative femoral center registration, where PRE represents preoperative data and LMK represents the initial registration; SUR#IN#PLA#AP represents the intraoperative femoral front-end cutting plane origin point, where IN represents intraoperative data and PLA represents the cutting plane; the surgical operation data includes 6 types, such as the model of the replaced prosthesis, the installation position of the replaced prosthesis, each pick-up of the registration point, recording the surgical effects of various sensors and the results calculated by the surgical robot navigation system, the loading record of the surgical plan, and the information on whether the postoperative surgical plan is successfully stored, and its SK starts with "OP#", and OP#CII#0001 represents the surgical operation of replacing the prosthesis model, indicating its serial number is 0001; the SK is represented by a multi-layer structure and redundant items are added to achieve fast query; Other data has various different expressions, used to expand the partition key PK according to specific requirements.

3. The method according to claim 1, wherein The patient information data model includes: medical record information, attending doctor, selected prosthesis type, affected limb selection, and default flexion angle.

4. The method according to claim 1, wherein The preoperative data model includes: preselected femoral prosthesis, femoral model data, femoral initial registration anatomical landmark points, preselected tibial prosthesis, tibial model data, and tibial initial registration anatomical landmark points.

5. The method according to claim 1, wherein The intraoperative data model includes: femoral initial registration anatomical landmark points, femoral fine registration anatomical landmark points, femoral front-end cutting plane, femoral rear-end cutting plane, femoral distal cutting plane, femoral verification nail, tibial initial registration anatomical landmark points, tibial fine registration anatomical landmark points, tibial cutting plane, tibial verification nail, and intraoperative gap balance curve.

6. The method according to claim 1, wherein The postoperative data model includes: femoral front-end cutting plane, femoral rear-end cutting plane, femoral distal cutting plane, femoral verification nail, tibial prosthesis cutting plane, tibial verification nail, and postoperative gap balance curve.

7. The method according to claim 1, characterized in that The prosthesis data model includes: the normal vector of the front-end cutting plane, the normal vector of the femoral rear-end cutting plane, the origin coordinates of the front-end cutting plane, color, medial condyle registration point, three-dimensional prosthesis model, lateral condyle registration point, the origin coordinates of the rear-end cutting plane, prosthesis model number included in the left-leg femoral prosthesis model; the normal vector of the front-end cutting plane, the normal vector of the femoral rear-end cutting plane, the origin coordinates of the front-end cutting plane, color, medial condyle registration point, three-dimensional prosthesis model, lateral condyle registration point, the origin coordinates of the rear-end cutting plane, prosthesis model number included in the right-leg femoral prosthesis model; the normal vector of the tibial cutting plane, the origin coordinates of the tibial prosthesis cutting plane, tibial color, tibial three-dimensional prosthesis model, and tibial prosthesis model number included in the tibial prosthesis model.

8. The method according to claim 1, wherein The surgical operation record data model includes: a unique surgical identifier, the time when the data is generated, the types of surgical operations recorded, the data records before the operation, and the data records after the operation.

9. The method according to claim 1, characterized in that, The method further includes: Based on the query results, when medical accidents and adverse events occur, it is used to find the causes of the accidents for retrospective analysis, or to analyze the associations between the occurrence frequencies of various medical events and different biomarkers. Through secondary search and the first event aggregation, all qualified events are found, and all the found events are grouped and aggregated according to their attributes, and then the required information is found through secondary search; The retrospective analysis is used to find the causes of accidents when medical accidents and adverse events occur. When a medical event occurs to a patient, it is used for: Analyzing whether the surgical plan is reasonable based on the preoperative plan and motion analysis; Comparing the intraoperative data with the preoperative data to analyze the positioning error of the surgery, mainly analyzing whether there is a positioning error in the computer-aided navigation system; Analyzing the doctor's operation level based on the postoperative gap balance curve in the postoperative verification data, the actual measurement of the prosthesis and the installation effect, and the error between the doctor's operation and the plan; Checking according to the rehabilitation record whether the patient has returned to normal after the operation or whether there are changes in living habits.

10. The method according to claim 1, characterized in that The method further includes: Based on the results of flexible query, epidemiological analysis is carried out. Epidemiological analysis is used to analyze the associations between the occurrence frequencies of various medical events and different biomarkers, and is used to prepare for defining product and surgical indications, soliciting suitable candidates for clinical trial enrollment, including the relationship between the occurrence frequency of adverse events in joint replacement surgery and body weight.

Citation Information

Patent Citations

  • Electricity big data querying method and system based on HBase secondary indexing

    CN106503243A

  • Spatio-temporal data indexing method in non-relational database

    CN107423368A