A cross-hospital, cross-temporal patient panoramic health report generation and sharing method

Abstract

The application discloses a cross-hospital and cross-time sequence patient panoramic health report generation and sharing method, receives a report generation request sent by a patient, and obtains all index records of the patient from a database; groups all the index records and generates a time sequence after internal sorting of each group; performs trend analysis on the time sequence to obtain a trend analysis result; inputs the original records in the time sequence and the trend analysis result into a structured report template, and performs content filling to generate a panoramic report; responds to a generation and sharing two-dimensional code instruction input by the patient, creates a token, encodes the token into a URL to generate a two-dimensional code image and returns the two-dimensional code image to a client; responds to an access request initiated by a viewer by scanning the two-dimensional code, extracts a token and performs verification, and returns corresponding data from the panoramic report to the viewer after verification. The application not only improves the clinical information acquisition efficiency, but also guarantees the privacy and security of personal health data.

Description

Technical Field

[0001] This application relates to the field of medical and health information processing and access control technology, specifically to a method for generating and sharing a comprehensive patient health report across hospitals and time periods. Background Technology

[0002] In my country, patients with chronic diseases often need to visit multiple hospitals, resulting in their personal health data (including lab reports, imaging reports, prescriptions, and medical records) being highly fragmented across heterogeneous information systems (such as HIS, LIS, and PACS) across different medical institutions, creating "data silos." Statistics show that chronic disease patients visit an average of 3-5 medical institutions annually, highlighting the problem of data fragmentation. In the consultation room, doctors have limited time (usually only a few minutes) but need to quickly grasp the overall picture of a patient's key indicator changes over several years. Currently, patients generally convey information through verbal descriptions or by reviewing scattered screenshots on their phones, making it difficult for doctors to form a comprehensive assessment of the condition in a short time. This has become a real bottleneck affecting the efficiency and quality of diagnosis and treatment.

[0003] The root cause of these problems lies in the lack of mechanisms for cross-institutional data interoperability and the inadequacies in security and usability of existing methods for sharing personal health information. On the one hand, the lack of interoperability between hospital systems forces patients to act as "physical transporters" of their own data; on the other hand, my country's Personal Information Protection Law sets forth principles such as informed consent, purpose limitation, and minimum necessity for the sharing of sensitive personal information like medical and health information, and medical industry standards also emphasize that cross-institutional data exchanges must have audit traceability capabilities.

[0004] Currently, there are three main solutions for cross-institutional sharing of personal health data:

[0005] Static export solution: Some health management apps offer an "Export Health Record PDF" function. After the user clicks, the system generates a fixed PDF file that sorts all historical records by time, but does not differentiate between indicator types, nor does it perform any trend calculations or visualizations. Patients can print this PDF file as a paper report or send it to their doctor via social media.

[0006] Link-sharing solutions: Some online consultation platforms offer a "generate shareable link" function. Users can send the generated URL link to doctors via WeChat or other methods, and doctors can then click to view it online. This method supports electronic viewing and avoids the physical delivery of paper documents.

[0007] Regional data sharing solutions: Some regions, under the guidance of the government, have built regional health information platforms, enabling the sharing and access of some data among medical institutions within their jurisdiction. Doctors can directly access patients' historical medical records within the region within their authorized scope.

[0008] However, the above solutions have the following significant drawbacks in practical applications:

[0009] Data loss of control risk (static export type): Once PDF files or paper reports are handed over to the recipient, they are completely out of the sender's control. The recipient can view, copy, and forward them an unlimited number of times, making it impossible to achieve a closed access loop of "patient authorization, doctor viewing, and automatic closure upon expiration," which seriously violates the principles of minimum data necessity and audit traceability.

[0010] Privacy and permission concerns (link sharing): The generated shareable links are usually valid for a long time, and cancellation depends on the user's manual operation within the app. This is easily forgotten in a clinic setting, leading to long-term leakage of the links. Furthermore, the solution lacks a permission hierarchy mechanism, with doctors seeing all data by default, making it impossible to differentiate the display based on different roles such as "attending physician / consulting expert / nurse". In addition, link sharing often requires the two parties to have a friendship or known contact information, which is not suitable for temporary or unfamiliar medical scenarios.

[0011] Limited coverage and flexibility (regional interoperability): Regional platforms rely on administrative coordination, resulting in limited coverage. Furthermore, patients cannot independently manage or integrate data from across regions or systems, making it difficult to meet the actual needs of mobile medical treatment nationwide.

[0012] Furthermore, none of the above solutions offer cross-time point trend quantification and visualization capabilities. For example, a patient's fasting blood glucose levels may have changed three times consecutively: 7.2 → 6.8 → 6.1 mmol / L. While the most recent value might appear "high but close to normal" on its own, the overall trend shows a continuous decline and improvement over three months. Current solutions only display a list of raw values, requiring doctors to perform mental calculations and comparisons, making it impossible to intuitively grasp key information about the disease's progression and severely impacting the efficiency and accuracy of initial diagnosis. Summary of the Invention

[0013] To address these issues, this application provides a method for generating and sharing a comprehensive patient health report across hospitals and time periods, thereby resolving the problems of data loss of control, privacy and access risks, limited coverage, and inability to provide trend quantification and visualization functions across time points when sharing personal health data across institutions, as well as the problems of existing technologies.

[0014] To achieve the above objectives, this application provides the following technical solution:

[0015] Firstly, a method for generating and sharing a comprehensive patient health report across hospitals and time periods, the method being applied on a server-side, including:

[0016] Step 1: Receive a report generation request sent by the patient through the client, and retrieve all the patient's indicator records from the database according to the report generation request. Each indicator record includes at least: indicator code, value, collection timestamp and source institution identifier;

[0017] Step 2: Group all the indicator records according to the indicator code, group records with the same indicator code into the same group, and sort them according to the collection timestamp within each group to generate a time series for each indicator record;

[0018] Step 3: Perform trend analysis on the time series recorded for each indicator; the trend analysis includes at least: calculating the change amount and overall rate of change of adjacent time points, determining the direction of change, marking consecutive abnormal time points, and comparing the values ​​of the same indicator from different source institutions to obtain the trend analysis results;

[0019] Step 4: Input the original records in the time series and the trend analysis results into the predefined structured report template, and fill in the content according to the preset different clinical information partitions to generate a panoramic report;

[0020] Step 5: In response to the patient's input command to generate a shareable QR code, create a token carrying a report identifier, data visibility range, validity period, and access limit, encode the token into a URL, generate a QR code image, and return it to the client;

[0021] Step 6: Respond to the access request initiated by the viewer by scanning the QR code, extract the token from the access request and verify it. The verification includes at least token validity verification, timeliness verification and number of times verification. If the verification is successful, select the corresponding data from the panoramic report according to the data visibility range and return it to the viewer, and update the access record. If any verification fails, refuse to return the data.

[0022] Optionally, in step 3, calculating the change at adjacent time points and the overall rate of change specifically includes: calculating the difference between the values ​​of two adjacent time points in the time series recorded for each indicator, and using this difference as the adjacent change; when the time series contains three or more time points, using a linear fitting method to calculate the linear fitting slope of the time series, and using the slope as the overall rate of change.

[0023] Optionally, in step 3, determining the direction of change specifically includes: determining the direction of change of the indicator based on the comparison result of the sign and absolute value of the slope with a preset threshold; the direction of change is rising, falling, or remaining flat; the preset threshold is set according to the range of biological variation in clinical tests.

[0024] Optionally, in step 3, marking the time points of continuous abnormality specifically includes: comparing the value of each time point with the preset reference interval corresponding to the indicator, and marking the values ​​that exceed the upper limit of the preset reference interval and the values ​​that are lower than the lower limit of the preset reference interval; if the same indicator is marked at two or more consecutive time points in the time series, then the indicator is marked as having a continuous abnormal state.

[0025] Optionally, in step 3, the step of comparing the values ​​of the same indicator from different source institutions specifically includes: for cases where different institutions have records of the same indicator within a set time window, displaying the values ​​side by side and labeling the names of the source institutions.

[0026] Optionally, in step 4, the structured report template includes six fixed sections: patient basic information area, key indicator summary area, abnormal indicator warning area, trend chart area, cross-institutional comparison area, and medical record timeline area.

[0027] Optionally, in step 4, the filling rules for filling content according to different preset clinical information partitions are as follows: traverse all indicators, fill the key indicator summary area with the indicator code that matches the key indicator list; fill the abnormal indicator warning area and pin the indicator with an abnormal or persistently abnormal status; fill the trend chart area with indicators containing two or more record points.

[0028] Optionally, in step 6, the token validity verification includes: determining whether the token identifier exists and whether the corresponding token status is not invalid; the expiration verification includes: determining whether the current time of the server is earlier than the expiration time; the count verification includes: determining whether the cumulative number of accesses is less than the maximum number of accesses.

[0029] Optionally, it also includes: maintaining a lifecycle state for the token, the lifecycle state including: creation time, expiration time, cumulative access count, and current state; the patient can manually set the token state to: invalidated on the client, the invalidation operation takes effect immediately, and the issued QR code image becomes invalid after taking effect.

[0030] Secondly, a device for generating and sharing comprehensive patient health reports across hospitals and time periods includes:

[0031] The data acquisition module is used to receive a report generation request sent by the patient through the client, and to retrieve all the patient's indicator records from the database according to the report generation request. Each indicator record includes at least: indicator code, value, collection timestamp and source institution identifier.

[0032] The time-series aggregation module is used to group all the indicator records according to the indicator code, group records with the same indicator code into the same group, and sort them according to the collection timestamp within each group to generate a time series for each indicator record.

[0033] The trend analysis module is used to perform trend analysis on the time series recorded for each indicator; the trend analysis includes at least: calculating the change amount and overall rate of change of adjacent time points, determining the direction of change, marking consecutive abnormal time points, and correlating and comparing the values ​​of the same indicator from different sources to obtain the trend analysis results;

[0034] The report generation module is used to input the original records in the time series and the trend analysis results into a predefined structured report template, and fill in the content according to different preset clinical information partitions to generate a panoramic report;

[0035] The token creation module is used to respond to the patient's input instruction to generate a shareable QR code, create a token carrying a report identifier, data visibility range, validity period and access limit, encode the token into a URL and generate a QR code image to return to the client;

[0036] The verification and return module is used to respond to the access request initiated by the viewer by scanning the QR code, extract the token from the access request and verify it. The verification includes at least token validity verification, time validity verification and number of times verification. After the verification is successful, the corresponding data is selected from the panoramic report according to the data visibility range and returned to the viewer, and the access record is updated. If any verification fails, the returned data is rejected.

[0037] Compared with the prior art, this application has at least the following beneficial effects:

[0038] This application provides a method for generating and sharing a comprehensive patient health report across hospitals and time periods. It receives a report generation request from a patient via a client and retrieves all patient indicator records from a database. All indicator records are grouped and sorted within each group to generate a time series for each indicator record. Trend analysis is performed on the time series of each indicator record to obtain the trend analysis results. The original records and trend analysis results from the time series are input into a predefined structured report template, and content is populated according to preset different clinical information partitions to generate a comprehensive report. In response to the patient's input command to generate a sharing QR code, a token is created, the token is encoded into a URL, and a QR code image is generated and returned to the client. In response to an access request initiated by a viewer by scanning the QR code, the token is extracted and verified. After successful verification, the corresponding data is selected from the comprehensive report and returned to the viewer. This application eliminates the risk of data loss of control, ensures privacy and access security, breaks through the limitations of coverage, and achieves cross-time point trend quantification and visualization. It not only improves the efficiency of clinical information acquisition but also ensures the privacy and security of personal health data. Attached Figure Description

[0039] To more intuitively illustrate the prior art and this application, exemplary drawings are provided below. It should be understood that the specific shapes and structures shown in the drawings should not generally be regarded as limiting conditions for implementing this application; for example, based on the technical concept disclosed in this application and the exemplary drawings, those skilled in the art are able to easily make conventional adjustments or further optimizations to the addition / reduction / classification, specific shapes, positional relationships, connection methods, size ratios, etc. of certain units (components).

[0040] Figure 1 A flowchart illustrating a method for generating and sharing a comprehensive patient health report across hospitals and time periods, as provided in Embodiment 1 of this application;

[0041] Figure 2 This is a schematic diagram of the structure of a method for generating and sharing a panoramic health report of patients across hospitals and time periods, provided in Embodiment 1 of this application. Detailed Implementation

[0042] The present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0043] In the description of this application: unless otherwise stated, "a plurality of" means two or more. The terms "first," "second," "third," etc., in this application are intended to distinguish the objects referred to and do not have any special meaning in terms of technical connotation (e.g., they should not be construed as an emphasis on importance or order). Expressions such as "including," "comprising," and "having" also mean "not limited to" (certain units, components, materials, steps, etc.).

[0044] The terms used in this application, such as "upper," "lower," "left," "right," and "middle," are generally used to indicate the general relative positional relationship for the purpose of intuitive understanding by referring to the accompanying drawings, and are not absolute limitations on the positional relationship in the actual product.

[0045] Example 1

[0046] This embodiment provides a method for generating and sharing a comprehensive patient health report across hospitals and time periods. The method automatically aggregates structured health data scattered across multiple hospitals and time points into a time series according to indicators, calculates the rate of change and direction of change, and fills it into a preset report template, thereby generating a structured comprehensive report that doctors can read in a short time. At the same time, by using a QR code token with access permissions and validity period, a controllable sharing process of "patient authorization, doctor scanning, time-limited viewing, expiration and invalidation, and full record keeping" is realized.

[0047] This embodiment provides a method for generating and sharing a comprehensive patient health report across hospitals and time periods, with the operating environment being a WeChat mini-program client and a server (cloud function). Patients manage their personal health records through the mini-program (the method for creating the records is not within the scope of this embodiment; this embodiment assumes that the database already contains structured records stored in a four-dimensional format of "patient-time-institution-indicator"); doctors view the report by scanning a QR code on the patient's mobile phone.

[0048] Please see Figure 1 and Figure 2 This embodiment provides a method for generating and sharing a comprehensive patient health report across hospitals and time periods, applied to the server side, including:

[0049] S1: Receives a report generation request sent by the patient through the client, and retrieves all the patient's indicator records from the database according to the report generation request. Each indicator record contains at least: indicator code, value, collection timestamp and source institution identifier;

[0050] Specifically, after receiving a patient's report generation request, the server retrieves all indicator records for that patient from the structured record table in the database, using the patient's unique identifier as the query key. Each indicator record contains the following fields: indicator code (normalized unified internal code), indicator name, value, standard unit, lower limit of reference interval, upper limit of reference interval, source institution identifier, collection timestamp, and original document hash value.

[0051] S2: Group all indicator records by indicator code, group records with the same indicator code into the same group, and sort them by collection timestamp within each group to generate a time series for each indicator record.

[0052] Specifically, this step involves two levels of grouping for all indicator records: The first level groups records by indicator code, meaning records with the same indicator code are grouped together, while different indicator codes (e.g., fasting blood glucose and systolic blood pressure) are grouped separately and not mixed. The second level arranges records within each group in ascending order of collection timestamps, forming a time-series sequence for that indicator. For example, a patient's "fasting blood glucose" record has three entries from Hospital A in March 2024, Hospital B in September 2024, and Hospital A in February 2025. These are aggregated to form a time-series sequence with three time points, each time point labeled with its source institution.

[0053] When grouping data into two levels, if there are multiple records at the same point in time (e.g., a patient had the same test at two hospitals on the same day), all records are retained and the source institution is marked. They are neither merged nor discarded to ensure the data integrity of cross-institutional comparisons. If there are inconsistencies in units in the historical records (e.g., early records use mg / dL, while recent records use mmol / L), a pre-set unit conversion table is used to perform a unified conversion. The converted values ​​are then marked with a conversion label for explanation when displayed on the front end.

[0054] It should be noted that during data aggregation in this step, heterogeneous data exported from different hospitals (Electronic Medical Records (EMR), Picture Archiving Systems (PACS), Laboratory Information Systems (LIS)) can be mapped and semantically aligned using the HL7 FHIR standard protocol. Entity resolution algorithms are then used to associate the identity of the same patient across different institutions under a unified ID. For long-term dynamic monitoring data (such as continuous data from continuous glucose meters and wearable devices), the data can be stored in a time-series database. A sliding window algorithm is used to detect timestamp drift caused by cross-institutional data collection, and outliers deviating from the normal range are automatically marked for manual review. The aforementioned FHIR mapping and sliding window detection are both publicly available data processing techniques in the field; this invention combines them for application in cross-institutional health record aggregation scenarios.

[0055] S3: Perform trend analysis on the time series of each indicator record; the trend analysis includes at least: calculating the change amount and overall rate of change of adjacent time points, determining the direction of change, marking the time points of continuous anomalies, and comparing the values ​​of the same indicator from different sources to obtain the trend analysis results;

[0056] Specifically, the calculation of changes at adjacent time points and the overall rate of change includes: for each indicator, the calculation of changes at two adjacent time points in the time series. and Numerical calculation of the difference: As adjacent changes, the slope is used as the rate of change. When the time series contains three or more time points, a linear fitting method (e.g., least squares method) is used to calculate the slope of the linear fit of the time series, and the slope is used as the overall rate of change. The specific meaning of the slope S depends on the indicator. For example, a negative slope for fasting blood glucose indicates a continuous decline and improvement, while a slope for glycated hemoglobin close to zero indicates stable control. It should be noted that when the time series contains fewer than three data points, adjacent differences can be used instead of least squares fitting to determine the direction. When there are enough data points, piecewise linear fitting can be used instead of global linear fitting. The segmented intervals are automatically divided according to key clinical event nodes (such as medication adjustment dates, surgery dates), so that the trend within each time period is more in line with clinical reality.

[0057] Determining the direction of change includes: comparing the sign and absolute value of the slope S with a preset threshold. The comparison results determine the direction of change of the indicator: when When, the direction is determined to be "upward"; when When, the direction is determined to be "descending"; when At that time, the direction is determined as "equal". Among them, a preset threshold... The preset minimum threshold is used to filter measurement errors and physiological fluctuations. The δ value is different for different indicators (e.g., δ for blood glucose is 0.1 mmol / L / month, and δ for blood lipids is 0.05 mmol / L / month). These thresholds can be set according to the range of biological variation in clinical tests.

[0058] Marking consecutive abnormal time points includes: comparing the value of each time point with the preset reference range corresponding to the indicator, and marking "high" values ​​that exceed the upper limit of the preset reference range and "low" values ​​that are lower than the lower limit of the preset reference range; if the same indicator is marked as "high" or "low" at two or more consecutive time points in the time series, the indicator is marked as having a "continuous abnormal" state.

[0059] This method compares and correlates the values ​​of the same indicator from different sources. Specifically, it displays the values ​​side-by-side and labels the source institutions for cases where different institutions have records of the same indicator within a set time window (defaulting to the same calendar month). This allows doctors to directly compare the differences in test results from different hospital laboratories and determine whether changes in the values ​​are due to changes in the patient's condition or differences in the testing systems.

[0060] It should be noted that, in scenarios where a large number of patients simultaneously request reports, this embodiment can use a message queue to receive data change events from various institutions, and use a streaming computing framework to update the time series and trend calculation results of affected indicators in real time. When a key indicator exceeds the warning threshold, an immediate report is automatically generated to notify the patient. Computing resources are elastically scalable using container orchestration.

[0061] S4: Input the raw records and trend analysis results from the time series into the predefined structured report template, and fill in the content according to the preset different clinical information partitions to generate a panoramic report;

[0062] Specifically, the structured report template is a predefined JSON document containing six fixed sections: ① Patient Basic Information Section (name, age, allergy history, etc., retrieved from the patient record system); ② Key Indicator Summary Section (displaying the latest values ​​and change arrows for preset key indicators such as blood glucose, blood pressure, four blood lipids, uric acid, creatinine, and liver function); ③ Abnormal Indicator Warning Section (displaying all indicators marked "abnormal" or "persistently abnormal," sorted by degree of deviation, with red cards at the top to distinguish between "occasional one-time deviation" and "persistent abnormality," the latter indicating the need for clinical attention); ④ Trend Chart Section (displaying line graph data for indicators with two or more record points, with the horizontal axis representing time and the vertical axis representing values, and reference intervals marked with light-colored shading); ⑤ Cross-Institutional Comparison Section (displaying parallel values ​​of the same indicator from different institutions); ⑥ Medical Record Timeline Section (arranging all medical records in reverse chronological order, labeling the institution name and main examination items).

[0063] The filling rules for content according to the preset clinical information partitions are as follows: Traverse all indicators and determine their position according to the following rules: Indicator codes that match the "Key Indicator List" are filled into the Key Indicator Summary Area; indicators with a status of "Abnormal" or "Persistent Abnormal" are filled into the Abnormal Indicator Warning Area and placed at the top; indicators containing two or more record points are filled into the Trend Chart Area. An indicator can appear in multiple partitions simultaneously (e.g., blood glucose appears in the Summary Area, Warning Area, and Trend Chart Area simultaneously), and the data is not stored repeatedly.

[0064] This step automatically generates a text description for each abnormal or significantly changing indicator by selecting a matching structured report template from a pre-set template library and filling in the calculation results from step S3. The template library pre-sets standard sentence structures (approximately 150 template statements in total) covering common indicators, arranged in a three-dimensional combination of "indicator type × direction of change × current status". For example, the template for "decreasing blood sugar + currently high" is "{indicator name} has shown a decreasing trend in the last {number} times, from {initial value}{unit} to {last number value}{unit}, and is currently still higher than the upper limit of the reference range {upper limit value}{unit}". All text descriptions are generated by template filling and data concatenation, without using generative AI models, to ensure the stability and interpretability of the output.

[0065] The final generated panoramic report is a structured JSON document containing complete data for the six sections mentioned above (text summary, data cards, chart coordinate data, anomaly markers, and sorting information). It is sent to the client for rendering in a preset mobile style. The rendering style is a card-style vertical scrolling layout, with anomaly indicators highlighted at the top with red borders, and trend charts drawn using a lightweight canvas component.

[0066] It should be noted that in the terminal display stage of this embodiment, the panoramic report page can be overlaid with a digital watermark containing visitor identification and timestamp, and screenshot detection and blurring processing are added to reduce the risk of privacy leakage when the viewer forwards the screenshot.

[0067] S5: Respond to the patient's input command to generate a shareable QR code, create a token carrying a report identifier, data visibility range, validity period and access limit, encode the token into a URL and generate a QR code image to return to the client;

[0068] Specifically, after the patient clicks the "Generate Share QR Code" button on the client, the server performs the following operations:

[0069] S501, Create Token Record: Generate a globally unique token identifier (UUID) and associate it with the following control parameters: Report Identifier (points to the storage location of the structured JSON document output in step S4); Data Range Whitelist (specifies which indicator codes are visible for this sharing, defaults to all); Validity Expiration Time (defaults to creation time + 24 hours, patients can modify as needed); Maximum Access Limit (defaults to no limit, patients can set a specific number of times).

[0070] S502, Token Encoding: Encode the token identifier into a short URL in the format "https: / / server domain / r / {token identifier}", and generate a QR code image from this URL and return it to the client. The QR code image uses the QR code standard encoding, with a fault tolerance level set to M (approximately 15% fault tolerance) to ensure that it can be recognized by common scanning tools under normal screen brightness on a mobile phone.

[0071] It should be noted that the sharing carrier QR code can be replaced with any of the following: ① One-time short link (sent via SMS, expires upon first opening); ② Digital password (6 to 8 digits, manually entered by the doctor on the verification page); ③ Mini-program sharing card (sent via WeChat conversation, carrying token parameters). All three replacements achieve the purpose of carrying a token, being valid for a limited time, and being able to be actively invalidated.

[0072] S6: Respond to the access request initiated by the viewer by scanning the QR code, extract the token from the access request and verify it. The verification includes at least token validity verification, time validity verification and number of times verification. If the verification is successful, the corresponding data is selected from the panoramic report according to the data visibility range and returned to the viewer, and the access record is updated. If any verification fails, the data is refused to be returned.

[0073] Specifically, the person viewing the information (e.g., a doctor) opens WeChat and scans the QR code on the patient's phone. The process is as follows:

[0074] S601, URL parsing: After scanning the code, obtain the URL encoded in the QR code and extract the token identifier from it;

[0075] S602, Triple Verification: The client calls the server's verification interface carrying a token identifier. The server executes the following checks sequentially: ① Validity check (whether the token identifier exists in the token table and its status is not "invalid"), returning "Token invalid or invalid" if it fails; ② Expiration check (whether the current server time is earlier than the expiration date), returning "Token expired" if it fails; ③ Count check (whether the cumulative number of accesses is less than the set maximum number of accesses), returning "Maximum number of accesses reached" if it fails. The process terminates if any check fails, and no report data is returned.

[0076] S603, upon successful completion: After all three verifications pass, the server filters fields from the JSON document in step S4 according to the token's whitelist and returns them to the client for rendering and display. The client renders the content according to the mobile card layout, with the abnormal indicator highlighted in red. The server increments the cumulative access count by 1 and records the timestamp and client IP of this access (for auditing and traceability).

[0077] It should be noted that the token verification logic is executed on the server side by default. However, the verification rules can also be deployed to CDN edge nodes to leverage their geographical advantages and reduce QR code scanning response latency. The edge nodes only perform preliminary verification of token existence and validity; data range filtering and the return of a complete report are still handled by the origin server.

[0078] In this embodiment, each verification request, regardless of success or failure, is recorded in the server log, including the token identifier, request time, verification result (reason for success / rejection), and client IP. This log is used by patients to subsequently view "who scanned my QR code," "when it was scanned," and "what they saw." For example, the access log JSON structure is:

[0079] {

[0080] "log_id": "audit-20250101-001",

[0081] "token_id": "550e8400-e29b-41d4-a716-446655440000",

[0082] "req_time": "2025-01-01T10:30:00+08:00",

[0083] "result": "accept",

[0084] "failure_reason": null,

[0085] "client_ip": "192.0.2.1",

[0086] "report_id": "RPT-20250101-001",

[0087] "data_scope": ["GLU","SBP","TC"]

[0088] }

[0089] It should be noted that in this embodiment, attribute-based encryption (ABE) and zero-knowledge proof (ZKP) mechanisms can be superimposed during the token verification process to further enhance privacy protection. Patients can define an access policy composed of attributes (attribute dimensions such as role, affiliated institution, patient relationship, time window, etc.) when generating the token. Sensitive fields in the report are encrypted according to the policy, and can only be decrypted when the accessor's attribute set satisfies the policy expression. During token verification, the accessor constructs a zero-knowledge proof to prove to the server that the attributes satisfy the policy without exposing specific attribute values, thus preventing the server from learning details of the accessor's identity. The token can be signed using the national cryptographic algorithm SM2, digested using SM3, and symmetric encrypted using SM4, and carried as a QR code. After verifying the zero-knowledge proof, validity period, and number of uses, the server only issues a short-term data access ticket, not a decryption key. After the token expires or becomes invalid, the corresponding key is added to the revocation list. The above-mentioned cryptographic components (ABE, ZKP, and the national cryptographic SM series algorithms) are all publicly available technical tools in this field; this embodiment uses them as optional security superposition methods in the health report sharing scenario.

[0090] This embodiment provides a method for generating and sharing a comprehensive patient health report across hospitals and time periods. It also includes maintaining the lifecycle status of a token, which includes: creation time, expiration time, cumulative access count, and current status (valid / expired / invalid / access limit reached). Patients can manually set the token status to "invalid" on the client side. The invalidation operation takes effect immediately, and the issued QR code image becomes invalid after the operation takes effect.

[0091] This embodiment provides a method for generating and sharing a comprehensive patient health report across hospitals and time periods. It also includes writing the report generation metadata, token creation and verification logs into a tamper-proof log storage structure (such as a log chain based on hash pointers), so that each report generation and each scan-to-view behavior corresponds to a timestamp record that cannot be modified afterward, thus meeting the traceability requirements of medical data compliance audits for who viewed what data when.

[0092] The method for generating and sharing a comprehensive patient health report across hospitals and time periods provided in this embodiment has the following advantages compared to existing technologies:

[0093] Compared to statically exported PDFs: This embodiment generates a dynamic, structured report that is validated in real-time by the server, rather than a static PDF file. The report content is organized according to clinical reading habits: abnormal indicators are highlighted with red cards, trend line graphs visually show the direction of change, and cross-institutional values ​​are compared side-by-side. Doctors obtain key information much more efficiently than flipping through dozens of pages of records. More importantly, viewing permissions are entirely controlled by the patient: which indicators can be viewed and for how long are determined by a token parameter, which can be revoked at any time; whereas once a PDF is issued, all control is lost.

[0094] Compared to link sharing: QR codes are better suited for face-to-face scenarios in clinics: doctors can directly scan the QR code on the patient's phone to view the information, without the patient needing to send it manually or the two parties needing to exchange contact information. The token carries a whitelist of data ranges, allowing for differentiated display based on the viewer's role (e.g., a nurse's token only includes vital signs, while a physician's token includes all indicators), whereas existing link solutions typically do not provide content grading. The token's validity and usage control take effect directly: the QR code immediately becomes invalid after the patient clicks "cancel," without requiring the recipient's cooperation in deleting it.

[0095] Compared to regional interoperability: This implementation does not rely on administrative coordination or government promotion. Any individual patient using this method can complete cross-institutional data aggregation, without being limited by geographical location or hospital coverage. It also adds trend analysis and report template generation steps, going beyond simply transferring and exchanging data; it processes, calculates, and presents the data in a structured manner.

[0096] This embodiment can automatically aggregate and calculate trends from years of patient data across multiple hospitals, generating a structured, comprehensive report. Doctors can quickly grasp the full picture and trajectory of a patient's core indicators by scanning a QR code during consultation, reducing duplicate examinations and diagnostic errors caused by incomplete information. The QR code token mechanism strikes a balance between one-click sharing and privacy control, preventing health data from spiraling out of control after sharing.

[0097] In summary, this embodiment eliminates the risk of data loss of control, protects privacy and access security, breaks through the limitations of coverage, and realizes cross-time point trend quantification and visualization; it not only improves the efficiency of clinical information acquisition, but also protects the privacy and security of personal health data.

[0098] Example 2

[0099] This embodiment provides a device for generating and sharing comprehensive patient health reports across hospitals and time periods, including:

[0100] The data acquisition module is used to receive a report generation request sent by the patient through the client, and to retrieve all the patient's indicator records from the database according to the report generation request. Each indicator record includes at least: indicator code, value, collection timestamp and source institution identifier.

[0101] The time-series aggregation module is used to group all the indicator records according to the indicator code, group records with the same indicator code into the same group, and sort them according to the collection timestamp within each group to generate a time series for each indicator record.

[0102] The trend analysis module is used to perform trend analysis on the time series recorded for each indicator; the trend analysis includes at least: calculating the change amount and overall rate of change of adjacent time points, determining the direction of change, marking consecutive abnormal time points, and correlating and comparing the values ​​of the same indicator from different sources to obtain the trend analysis results;

[0103] The report generation module is used to input the original records in the time series and the trend analysis results into a predefined structured report template, and fill in the content according to different preset clinical information partitions to generate a panoramic report;

[0104] The token creation module is used to respond to the patient's input instruction to generate a shareable QR code, create a token carrying a report identifier, data visibility range, validity period and access limit, encode the token into a URL and generate a QR code image to return to the client;

[0105] The verification and return module is used to respond to the access request initiated by the viewer by scanning the QR code, extract the token from the access request and verify it. The verification includes at least token validity verification, time validity verification and number of times verification. After the verification is successful, the corresponding data is selected from the panoramic report according to the data visibility range and returned to the viewer, and the access record is updated. If any verification fails, the returned data is rejected.

[0106] For details on the specific implementation of each module in a cross-hospital, cross-time-series patient panoramic health report generation and sharing device, please refer to the above description of the limitations of a cross-hospital, cross-time-series patient panoramic health report generation and sharing method, which will not be repeated here.

[0107] The technical features of the above embodiments can be combined in any way (as long as there is no contradiction in the combination of these technical features). For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described; these embodiments not explicitly written should also be considered to be within the scope of this specification.

Claims

1. A method for generating and sharing a comprehensive patient health report across hospitals and time periods, characterized in that, The method is applied to the server side and includes: Step 1: Receive a report generation request sent by the patient through the client, and retrieve all the patient's indicator records from the database according to the report generation request. Each indicator record includes at least: indicator code, value, collection timestamp and source institution identifier; Step 2: Group all the indicator records according to the indicator code, group records with the same indicator code into the same group, and sort them according to the collection timestamp within each group to generate a time series for each indicator record; Step 3: Perform trend analysis on the time series recorded for each indicator; the trend analysis includes at least: calculating the change amount and overall rate of change of adjacent time points, determining the direction of change, marking time points of continuous anomalies, and comparing the values ​​of the same indicator from different sources to obtain the trend analysis results; Step 4: Input the original records in the time series and the trend analysis results into the predefined structured report template, and fill in the content according to the preset different clinical information partitions to generate a panoramic report; Step 5: In response to the patient's input command to generate a shareable QR code, create a token carrying a report identifier, data visibility range, validity period, and access limit, encode the token into a URL, generate a QR code image, and return it to the client; Step 6: Respond to the access request initiated by the viewer by scanning the QR code, extract the token from the access request and verify it. The verification includes at least token validity verification, timeliness verification and number of times verification. If the verification is successful, select the corresponding data from the panoramic report according to the data visibility range and return it to the viewer, and update the access record. If any verification fails, refuse to return the data.

2. The method for generating and sharing a comprehensive patient health report across hospitals and time periods according to claim 1, characterized in that, In step 3, the calculation of the change at adjacent time points and the overall rate of change specifically includes: calculating the difference between the values ​​of two adjacent time points in the time series recorded for each indicator, and using this difference as the adjacent change; when the time series contains three or more time points, using a linear fitting method to calculate the linear fitting slope of the time series, and using the slope as the overall rate of change.

3. The method for generating and sharing a comprehensive patient health report across hospitals and time periods according to claim 2, characterized in that, In step 3, determining the direction of change specifically includes: determining the direction of change of the indicator based on the comparison result of the sign and absolute value of the slope with a preset threshold; the direction of change is rising, falling, or remaining flat; the preset threshold is set according to the range of biological variation in clinical tests.

4. The method for generating and sharing a comprehensive patient health report across hospitals and time periods according to claim 1, characterized in that, In step 3, marking the time points of continuous abnormality specifically includes: comparing the value of each time point with the preset reference interval corresponding to the indicator, and marking the values ​​that exceed the upper limit of the preset reference interval and the values ​​that are lower than the lower limit of the preset reference interval; if the same indicator is marked at two or more consecutive time points in the time series, then the indicator is marked as having a continuous abnormal state.

5. The method for generating and sharing a comprehensive patient health report across hospitals and time periods according to claim 1, characterized in that, In step 3, the step of comparing the values ​​of the same indicator from different source institutions specifically includes: for cases where different institutions have records of the same indicator within a set time window, displaying the values ​​side by side and labeling the names of the source institutions.

6. The method for generating and sharing a comprehensive patient health report across hospitals and time periods according to claim 1, characterized in that, In step 4, the structured report template includes six fixed sections: patient basic information area, key indicator summary area, abnormal indicator warning area, trend chart area, cross-institutional comparison area, and medical record timeline area.

7. The method for generating and sharing a comprehensive patient health report across hospitals and time periods according to claim 6, characterized in that, In step 4, the filling rules for filling content according to different preset clinical information partitions are as follows: traverse all indicators, fill the key indicator summary area with the indicator code that matches the key indicator list; fill the abnormal indicator warning area and pin the indicator with an abnormal or persistently abnormal status; fill the trend chart area with indicators containing two or more record points.

8. The method for generating and sharing a comprehensive patient health report across hospitals and time periods according to claim 1, characterized in that, In step 6, the token validity verification includes: determining whether the token identifier exists and whether the corresponding token status is not invalid; the validity period verification includes: determining whether the current time of the server is earlier than the expiration time; the number of accesses verification includes: determining whether the cumulative number of accesses is less than the maximum number of accesses.

9. The method for generating and sharing a comprehensive patient health report across hospitals and time periods according to claim 1, characterized in that, Also includes: The token maintains a lifecycle state, which includes: creation time, expiration time, cumulative access count, and current state. Patients can manually set the token status to "invalid" on the client side. The invalidation operation takes effect immediately, and the issued QR code image will become invalid after it takes effect.

10. A device for generating and sharing panoramic patient health reports across hospitals and time periods, characterized in that, include: The data acquisition module is used to receive a report generation request sent by the patient through the client, and to retrieve all the patient's indicator records from the database according to the report generation request. Each indicator record includes at least: indicator code, value, collection timestamp and source institution identifier. The time-series aggregation module is used to group all the indicator records according to the indicator code, group records with the same indicator code into the same group, and sort them according to the collection timestamp within each group to generate a time series for each indicator record. The trend analysis module is used to perform trend analysis on the time series recorded for each indicator; The trend analysis includes at least: calculating the change amount and overall rate of change at adjacent time points, determining the direction of change, marking consecutive abnormal time points, and comparing the values ​​of the same indicator from different sources to obtain the trend analysis results; The report generation module is used to input the original records in the time series and the trend analysis results into a predefined structured report template, and fill in the content according to different preset clinical information partitions to generate a panoramic report; The token creation module is used to respond to the patient's input instruction to generate a shareable QR code, create a token carrying a report identifier, data visibility range, validity period and access limit, encode the token into a URL and generate a QR code image to return to the client; The verification and return module is used to respond to the access request initiated by the viewer by scanning the QR code, extract the token from the access request and verify it. The verification includes at least token validity verification, time validity verification and number of times verification. After the verification is successful, the corresponding data is selected from the panoramic report according to the data visibility range and returned to the viewer, and the access record is updated. If any verification fails, the returned data is rejected.

Images