Patient whole-process medical information association method based on dynamic service coding

Abstract

The invention provides a patient full-process medical information association method based on a dynamic service code, which comprises the following steps of: generating a unique dynamic service code when a patient performs a first doctor seeing service, and generating initial service track data; when the patient carries out subsequent doctor seeing service, the dynamic service code is identified, records of the subsequent doctor seeing service are sequentially associated to the initial service track data according to the time sequence, and a full-process doctor seeing service track chain of the patient is generated; according to the method, a unique dynamic service code is generated for each patient and serves as a unified identity label and an information transmission voucher of the patient in a cross-service scene in a medical institution, and dynamic information series connection and closed-loop management of multi-process services such as screening, follow-up visit and re-visit are supported; meanwhile, a field-level authority control mechanism is also arranged, so that on-demand authorization and scene-based access of data are ensured, and the data security and compliance management capability are enhanced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical information management, and more particularly to a patient whole-process medical information association method based on dynamic service coding. BACKGROUND

[0002] In the current medical system, patients frequently flow among primary medical points (such as village health clinics), community service centers, and county-level hospitals, and especially in the field of chronic disease management, patients often need to receive screening, follow-up, reexamination, intervention, and other services multiple times. This process faces the following main problems: 1) Identity recognition is broken: Different service nodes do not have unified patient identity recognition methods, and information is frequently registered repeatedly.

[0003] 2) Service data is fragmented: The data generated in the process cannot be automatically associated, and a complete health management chain cannot be constructed.

[0004] 3) Lack of closed-loop mechanism: Service nodes cannot cooperatively share patient service status, resulting in interrupted management.

[0005] 4) Supervision and analysis are difficult: Lack of unified records and visualized tracks of service processes restricts quality control and performance evaluation.

[0006] Currently, an existing technology proposes a scheme for realizing patient medical information interconnection through a patient master index (EMPI). The main purpose of EMPI is to effectively associate multiple medical information systems together through a unique patient identifier in a complex medical system, to realize interconnection and intercommunication between systems, and to ensure the completeness and accuracy of personal information collection for the same patient distributed in different systems. However, the current popularity of this scheme is low, and it is mostly applied among some large medical institutions, and cannot adapt to primary medical points with insufficient medical resources; in addition, EMPI is a static identifier that basically does not change once established, and the EMPI architecture needs to establish a unified database and index service within the medical community, which has a high cost.

[0007] Therefore, a low-cost dynamic coding mechanism is urgently needed to realize unified identification, data sharing, and service process tracking of patient medical information in the whole process of medical services, and to improve service efficiency and information continuity. SUMMARY

[0008] The present application provides a patient whole-process medical information association method based on dynamic service coding to overcome the problem that the prior art cannot dynamically track the patient's medical service information at low cost, by generating a unique dynamic service coding (Patient Dynamic Service Coding, PDSC) for each patient as its unified identity identifier and information transfer voucher in the medical institution across service scenarios, supporting dynamic information connection and closed-loop management of multi-process services such as screening, follow-up, re-examination, etc.

[0009] To solve the above technical problems, the technical solutions of the present application are as follows: A patient whole-process medical information association method based on dynamic service coding, comprising the following steps: Generating a unique dynamic service coding when the patient performs initial medical service, and generating initial service trajectory data; When the patient performs subsequent medical service, identifying the dynamic service coding, and sequentially associating the records of the subsequent medical service to the initial service trajectory data in chronological order to generate the whole-process medical service trajectory chain of the patient.

[0010] Preferably, the dynamic service coding at least includes: medical institution code of initial medical service, patient hash, generation date, validity period label and check digit.

[0011] Preferably, the medical institution code is structured and spliced by provincial code, county code and medical institution serial number, and Base36 coding rules are adopted.

[0012] Preferably, the patient hash is generated according to the following steps: Splicing the patient's ID number and the private salt value randomly generated by the medical institution to calculate the SHA-256 hash value, obtaining a 256-bit hash value; Using a slidable window, starting from the first bit of the hash value, a 35-bit hash value fragment is intercepted and Base32 encoded to generate an irreversible 7-byte de-identification string; Performing uniqueness verification on the de-identification string, if the verification is passed, the de-identification string is taken as the patient hash; otherwise, the window is slid to the next bit of the hash value, a 35-bit hash value fragment is re-intercepted, and a de-identification string is re-generated.

[0013] Preferably, after generating the dynamic service coding, it further comprises: Binding the dynamic service coding with the ID of the patient in different medical institutions.

[0014] Preferably, the medical service trajectory chain includes several service trajectory data, and the service trajectory data includes at least: the patient's dynamic service code, medical service timestamp, medical service type label, medical institution code, responsible doctor identifier for the medical service, and SHA 256 digest of the medical service record.

[0015] Preferably, the method further includes: After identifying the dynamic service code, different medical institutions access the patient's medical service trajectory chain with different permissions according to their respective preset access permissions.

[0016] Preferably, the medical service trajectory chain is stored in a server; After identifying the dynamic service code, the medical institution sends an access request to the server, and the server returns an access token with corresponding permissions to the medical institution. The medical institution then accesses the patient's medical service trajectory chain with the corresponding permissions based on the permissions of the access token.

[0017] Preferably, the access token is a JWT format token, represented as follows: JWT = Header + Payload (Fset, TTL, nonce) + Medical Institution Signature Here, Header represents the token header information; Payload represents the token payload data; Fset represents the whitelist of fields generated by the server; TTL represents the token validity period field; and nonce represents a random number.

[0018] Preferably, the method further includes: A visual map is generated based on the service trajectory chain, which is used for out-of-hospital analysis, disease course review, and quality control assessment.

[0019] Compared with the prior art, the beneficial effects of the technical solution of the present invention are: This invention provides a method for associating patient medical information throughout the entire process based on dynamic service codes. When a patient receives initial medical services, a unique dynamic service code is generated, and initial service trajectory data is generated. When the patient receives subsequent medical services, the dynamic service code is identified, and the records of subsequent medical services are sequentially associated with the initial service trajectory data in chronological order to generate the patient's entire medical service trajectory chain. The present invention can achieve the following effects: 1) Streamline patient service processes and promote closed-loop management: The same service code runs through multiple stages such as screening, follow-up, and re-examination, avoiding duplicate record-keeping and service interruptions, and supporting continuous health management of patients throughout the entire process.

[0020] 2) Improve the efficiency and experience of basic services: basic medical points can identify patient identity and follow-up status by scanning the code, simplify paper records, reduce manual burden, and improve service convenience and accuracy.

[0021] 3) Break down data barriers and reduce the "information island" phenomenon: all service nodes use the same PDSC code, which can quickly access patient historical records and current health status without the need to pre-build a unified database, improving data flow efficiency and interconnection level, while effectively reducing data interconnection costs.

[0022] 4) Strengthen data security and compliance management capabilities: the invention also sets up a field-level permission control mechanism to ensure that data is authorized on demand, accessed by scene, and traced and audited after the fact through access logs.

[0023] 5) Form a full-process data asset to support intelligent governance: the service trajectory chain can record every patient visit service behavior, so based on the invention, a patient full-process service data resource pool can be built to support public health management, performance evaluation and intelligent decision analysis. BRIEF DESCRIPTION OF DRAWINGS

[0024] Figure 1 A flowchart of a patient full-process medical information association method based on dynamic service coding provided in embodiment 1.

[0025] Figure 2 A flowchart of a patient full-process medical information association method based on dynamic service coding provided in embodiment 2.

[0026] Figure 3 A complete flowchart from patient identity identification to service invocation and trajectory recording provided in embodiment 2.

[0027] Figure 4 A PDSC code generation diagram provided in embodiment 2.

[0028] Figure 5 A visit service trajectory diagram provided in embodiment 2.

[0029] Figure 6 A visual service path diagram provided in embodiment 2.

[0030] Figure 7 A role-based permission control mechanism diagram provided in embodiment 2. DETAILED DESCRIPTION

[0031] The accompanying drawings are only for illustrative purposes and cannot be understood as limiting the application; To better illustrate this embodiment, some parts in the accompanying drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions; It will be understood by those skilled in the art that certain well-known structures and their descriptions may be omitted in the accompanying drawings.

[0032] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0033] Example 1 like Figure 1 As shown, this embodiment provides a method for associating patient medical information throughout the entire process based on dynamic service coding, including the following steps: S1: Generate a unique dynamic service code and initial service trajectory data when the patient receives the first medical service. S2: When the patient receives subsequent medical services, the dynamic service code is identified, and the records of subsequent medical services are sequentially associated with the initial service trajectory data in chronological order to generate the patient's full-process medical service trajectory chain.

[0034] In the specific implementation process, a unique dynamic service code is first generated when the patient receives the initial medical service, and initial service trajectory data is also generated. When a patient receives subsequent medical services, the dynamic service code is identified, and the records of subsequent medical services are sequentially linked to the initial service trajectory data in chronological order to generate the patient's full-process medical service trajectory chain. In this embodiment, each patient has a unique service code within the medical institution, which serves as a full-process identity index. The same code connects multiple service processes without the need for repeated registration or identification. At the same time, each time a patient receives a medical service, the data of that service can be automatically linked to the patient's historical medical service data, ultimately forming a service trajectory chain uniquely indexed by the service code. This provides data support for other medical institutions to quickly review the patient's historical medical information.

[0035] Example 2 like Figure 2 As shown, this embodiment provides a method for associating patient medical information throughout the entire process based on dynamic service coding, including the following steps: S1: When a patient receives initial medical services, a unique dynamic service code is generated, and initial service trajectory data is generated; the dynamic service code is bound to the patient's ID in different medical institutions; S2: When the patient receives subsequent medical services, the dynamic service code is identified, and the records of subsequent medical services are sequentially associated with the initial service trajectory data in chronological order to generate the patient's full-process medical service trajectory chain. S3: Different medical institutions access the patient's medical service trajectory chain with different permissions according to their respective preset access permissions; The dynamic service code includes at least: the medical institution code of the initial visit, the patient hash, the generation date, the validity period label, and the check digit; The medical institution code is constructed by structurally concatenating the provincial code, district / county code, and medical institution serial number, and adopts the Base36 encoding rule; The patient hash is generated according to the following steps: The patient's ID number is concatenated with a privately generated salt value randomly generated by the medical institution, and then the SHA-256 hash value is calculated to obtain a 256-bit hash value. Using a sliding window, starting from the first bit of the hash value, a 35-bit hash value fragment is extracted and Base32 encoded to generate an irreversible 7-byte de-identified string; The de-identified string is uniquely verified. If the verification passes, the de-identified string is used as the patient's hash. Otherwise, the window is slid to the next position of the hash value, a 35-bit hash value segment is extracted again, and the de-identified string is regenerated. The medical service trajectory chain includes several service trajectory data, which at least include: the patient's dynamic service code, medical service timestamp, medical service type label, medical institution code, responsible doctor identifier for the medical service, and SHA 256 digest of the medical service record; The medical service trajectory chain is stored on the server; After identifying the dynamic service code, the medical institution sends an access request to the server, and the server returns an access token with corresponding permissions to the medical institution. The medical institution then accesses the patient's medical service trajectory chain with the corresponding permissions based on the permissions of the access token. The access token is specifically a JWT format token, represented as follows: JWT = Header + Payload (Fset, TTL, nonce) + Medical Institution Signature Here, Header represents the token header information; Payload represents the token payload data; Fset represents the server-generated whitelist of fields; TTL represents the token validity period field; and nonce represents a random number. The method further includes: A visual map is generated based on the service trajectory chain, which is used for out-of-hospital analysis, disease course review, and quality control assessment.

[0036] In the specific implementation process, such as Figure 3 As shown, Figure 3The complete process from patient identification to service calling and track recording is demonstrated, which embodies the technical closed loop of code generation, unified calling, permission verification and data deposition encapsulation. A unique dynamic service code is generated when the patient visits the service for the first time, and initial service track data is generated; at the same time, the dynamic service code is bound with the ID of the patient in different medical institutions; As shown in Figure 4 , the generation logic of the PDSC service code is shown in Figure 4 The generation logic of the PDSC service code is shown in

[0037] Specifically, the PDSC service code in the embodiment is generated according to the rule of "institution code + patient hash + generation date + validity period label + check digit", and after calculation by the check digit generator (mod32), a unique and checkable code is output. Table 1 Field meaning of PDSC service code

[0038] Among them, the medical institution code is structured by the provincial code, the county code and the medical community serial number, which consists of 6 characters. It is compressed by using Base36 character set instead of integer encoding to ensure fixed length, clear structure, support two-dimensional code scanning analysis and platform registration allocation, as shown in Table 2: Table 2 Encoding rule of medical institution code

[0039] To ensure that the patient's identity is not associated, not reversible in different institutions, the embodiment adopts SHA256 hash + Base32 encoding to generate a fixed-length de-identification main index segment as the patient hash in the PDS C; Specifically, a 128-bit random salt is generated for each institution to enhance the de-identification security of the patient hash and ensure that the patient hash generated by the same patient in different institutions is not the same. The patient's identity card number is spliced with the institution's private salt value (inst_salt), and the spliced result is subjected to SHA-256 operation to obtain a 256-bit hash value (such as 101010001010...); Then in a sliding window manner, a 35-bit (5-byte) hash segment is taken out each time, and Base32 encoding is performed on it to obtain a 7-character length result (Base32 is a 5-bit grouping based encoding method); The first 7 bits of this result (the result after Base32 is 7 bits) are intercepted as the candidate patient hash, and it is checked whether the candidate patient hash has been used by a patient of the current institution. If not used, return this code; If the candidate patient hash has been used, continue to take 35-bit from the 2-bit to perform the second round of Base32 encoding and uniqueness verification until a unique patient hash is determined; If all windows are traversed and conflict occurs, throw a conflict exception. In actual application, the conflict probability is less than one trillionth due to Base32 7 ≈10 10 , the conflict probability is less than one trillionth; The method generates a short string form (supports two-dimensional code display) through Hash algorithm encoding, has irreversibility, and the same patient has a unique code in the same institution life cycle, which is suitable for full-process reuse.

[0040] In the initial service node (such as a screening site), a dynamic service code (PDSC) of the patient is generated and bound, and the code information is written to the unified registration platform of the institution or medical community, and only the patient's unique ID of the current institution (such as the main index in the HIS system, the patient's main index EMPI) is bound; It's worth noting that EMPI is a unified patient identity management system within a medical consortium, addressing the issue of "one person, multiple IDs." It primarily serves to uniformly identify patients throughout their entire lifecycle, with each person having a unique master index, enabling identity integration, information sharing, and master data management. Once established, it remains largely unchanged. Furthermore, the EMPI architecture requires a unified database and indexing service within the medical consortium. In contrast, the PDSC service code provided by this method is suitable for multi-process service scenarios within the medical consortium, such as chronic disease screening, follow-up, and re-visit, enabling closed-loop management and penetrating tracking of service processes. It is particularly suitable for dynamic process scenarios based on "services." Primarily used for process coding within the same service cycle, it supports service calls and process tracking. A single code is generated dynamically for each service cycle, expiring or being updated as needed, enabling service penetration, trajectory analysis, access control, and secure access. The code itself is irreversibly anonymized, naturally possessing a certain level of privacy protection. Moreover, PDSCs can be locally self-generated, making them more suitable for edge system applications (such as mobile devices / tablets / handheld terminals).

[0041] In this embodiment, the PDSC allows subsequent service nodes to gradually complete the binding relationship between their institution's patient ID and the PDSC after scanning and identification, achieving cross-process data fusion. For example, village doctors or primary care institutions enter basic patient information (such as name, ID number, contact number, etc.) and generate a 24-digit dynamic PDSC service code for the patient. During registration, the patient ID of the institution is bound to the PDSC. After successful binding, the system will mark the validity period according to the scenario, such as "D7" for 7 days and "L0" for long-term validity, supporting automatic expiration and update logic. After subsequent scanning and identification by other institutions, if they find that there is already such a patient in the system, they can bind their institution ID to the same PDSC to achieve gradual completion and avoid the initial overhead of full-domain matching.

[0042] During subsequent patient visits, each service node can identify the patient's PDSC (Patient Pathway Signature) via QR code scanning or manual entry. After PDSC identification, the system automatically loads the patient's master index-linked file information and historical service history. New service records generated by the current service node are appended to the same PDSC, forming a time-continuous trajectory chain. Figure 5 As shown, Figure 5 It demonstrates the logic of multiple service trajectory nodes connected in sequence under the same PDSC code, with each node indicating the service time and type, realizing a visual chain record of the patient's entire service behavior; After each service action is completed, the system will automatically record the track node, including service time, service type, institution identification, responsible doctor, and other core information, and write it into the track dataset as part of the patient service chain, and store the service track data in a structured standard, facilitating cross-system aggregation, regulatory audit, and chain evidence. In addition, a visual display graph can be generated based on the track chain for patient disease course review, missed visit analysis, process quality control, and other scenarios. As shown in Table 3, the core structure of the service track data is defined:

[0043] Specifically, after completing a visit, re-examination, screening, or other services, the service node generates a JSON format track data package according to the unified structure, and attaches fields such as PDSC and timestamp; after standardizing the JSON content (field sorting, removing null values, etc.), SHA 256 hashing is performed to generate a 256 bit digest for data integrity verification and tamper-proofing; the track JSON and corresponding digest are written into the track database or service index table, supporting query of historical service chain by patient, and can also be used as a chain anchor for synchronous evidence; finally, the historical track nodes are aggregated by PDSC to generate a service path graph, which assists doctors in reviewing patient disease courses and supports downstream function calls such as missed visit analysis, as shown in Figure 6 Figure 6 The patient service track node is displayed in the form of icons and line breaks, which intuitively indicates the time and type of each service, enhancing the visual effect and user experience.

[0044] The embodiment also sets up a permission control and information hierarchical access mechanism, and different medical institutions access the patient's medical service track chain with different permissions according to their respective preset access permissions; Specifically, the minimum set control is performed on the visible information according to the access institution, post permission, and service scenario, to ensure the zero trust strategy of "authorization on demand, processing nearby, and minimizing storage"; for example: the village doctor can only see basic information and follow-up tasks; the county hospital can view all screening records and prescription history; as shown in Figure 7 Figure 7 The role-based permission control structure is shown, and different posts perform field-level filtering through the access control engine to achieve precise visibility management of village doctors, community doctors, county doctors, and administrators.

[0045] After identifying the dynamic service code, the medical institution sends an access request to the authorization server through the OAuth2.0 process, and the authorization server returns an access token (Token) with corresponding permissions to the medical institution, which accesses the patient's medical service track chain with corresponding permissions according to the access token's permissions; in this embodiment, the access token is a JWT format token, represented as: ​​JWT = Header + Payload (Fset, TTL, nonce) + medical institution signature Wherein, the Header indicates token header information;The Payload indicates token load data;Fset indicates the field whitelist generated by the server;TTL indicates the token validity period field, controls the token use time length, avoids expired access;Nonce indicates random number, used for preventing replay attacks, ensuring that each token is unique;The medical institution signature is used to ensure that the above information has not been tampered with, and the identity of the requester can be verified; After the medical institution obtains the access token, first, the legality of Token structure and signature is verified, and then the CK (check bit) of patient PDSC and Token is verified, if matched, the data returned by the server is filtered according to Fset whitelist in Token, only the authorized field is displayed; The revoked TokenID is stored by authorization server (support Redis or distributed CRL) Hash storage;All service gateways query the revocation list before receiving the request, judge whether the Token is still valid;Token has a time limit field TTL (Time to Live) by default, indicating the validity period, default 30 minutes, not more than 24 hours;For short-term interaction scenarios (such as scanning code to view follow-up records), short-term Token can be issued, combined with field whitelist restriction, to avoid long-term out-of-control authorization;After TTL expires, Token is automatically invalid, and access token needs to be applied again.

[0046] In general, the core point of the application is: 1) Patient dynamic service code (PDSC) mechanism: the application designs a dynamic unique coding method based on patient identity identification and service time window, which realizes the one-identity identification of patient identity in medical institutions. The code has irreversibility, inaccessibility, security and reusability, and builds a service index basis for patients in medical community, cross-institution, cross-process and cross-node.

[0047] 2) One code multi-process through mechanism: support using the same PDSC code to run through multiple service nodes such as screening, follow-up and diagnosis in the patient service cycle, avoid repeated filing and repeated code scanning, reduce human error and process interruption. The system registers services through the main index, binds the code to the unique identity of the patient in different institutions, and guarantees cross-system access and information fusion.

[0048] 3) Service track chain structure construction mechanism: the application automatically generates standardized track JSON data for each service behavior and writes it into a database or a chain storage structure with a SHA 256 digest. Each track node contains fields such as service time, type, agency identification, and person in charge, forming a chain structure to support process backtracking, disease review, and quality control analysis.

[0049] 4) Scene-based fine-grained permission control mechanism: generate access tokens (JWT Token) based on user roles, access scenarios, and patient relationships. The Token contains a field whitelist (Fset) as the basis for data visibility filtering, supporting field-level authorized access, and supporting Token life cycle management and dynamic revocation mechanisms.

[0050] The same or similar reference signs correspond to the same or similar components; The positional relationship described in the drawings is only used for illustrative description, and should not be understood as a limitation on the application; Obviously, the above embodiments of the application are only examples for clearly illustrating the application, and are not intended to limit the embodiments of the application. Based on the above description, those skilled in the art can make other different forms of changes or modifications. Here, it is not necessary and impossible to exhaust all the embodiments. Any modification, equivalent replacement and improvement made within the spirit and principle of the application should be included in the protection scope of the claims of the application.

Claims

1. A patient whole-process medical information association method based on dynamic service coding, characterized in that, The method comprises the following steps: generating a unique dynamic service code when a patient receives a first service, and generating initial service trajectory data; when the patient receives a subsequent service, identifying the dynamic service code, and sequentially associating records of the subsequent service to the initial service trajectory data in chronological order to generate a whole-process service trajectory chain of the patient.

2. The method for associating patient information in a whole process of medical treatment based on dynamic service coding according to claim 1, characterized in that, The dynamic service code at least comprises a medical institution code of the first service, a patient hash, a generation date, a validity period label, and a check digit.

3. The method of claim 2, wherein, The medical institution code is structured and spliced by a provincial code, a county code, and a medical institution serial number, and Base36 encoding rules are adopted.

4. The method of claim 2, wherein, The patient hash is generated according to the following steps: splicing the patient's ID number and the private salt value randomly generated by the medical institution to calculate the SHA-256 hash value, obtaining a 256-bit hash value; using a slidable window, starting from the first bit of the hash value, a 35-bit hash value segment is intercepted and Base32 encoded to generate an irreversible 7-byte de-identification string; performing uniqueness verification on the de-identification string, if the verification is passed, the de-identification string is taken as the patient hash; otherwise, the window is slid to the next bit of the hash value, a 35-bit hash value segment is re-intercepted, and a de-identification string is re-generated.

5. The method of claim 1, wherein, After generating the dynamic service code, the method further comprises: binding the dynamic service code with the patient's ID in different medical institutions.

6. The method of claim 1, wherein, The service trajectory chain comprises a plurality of service trajectory data, and the service trajectory data at least comprises a dynamic service code of the patient, a service time stamp, a service type label, a medical institution code, a responsible doctor identifier of the service, and a SHA 256 digest of the service record.

7. The method of claim 1, wherein, The method further comprises: After identifying the dynamic service code, different medical institutions respectively access the service trajectory chain of the patient with different permissions according to their respective preset access permissions.

8. The method of claim 7, wherein, The service trajectory chain is stored in a server; After identifying the dynamic service code, the medical institution sends an access request to the server, the server returns an access token with corresponding permissions to the medical institution, and the medical institution accesses the service trajectory chain of the patient with corresponding permissions according to the permissions of the access token.

9. The method of claim 8, wherein, The access token is specifically a JWT format token, which is expressed as: JWT = Header + Payload (Fset, TTL, nonce) + medical institution signature Wherein, Header represents token header information; Payload represents token payload data; Fset represents a field whitelist generated by the server; TTL represents a token validity period field; nonce represents a random number.

10. The method of claim 1, wherein, The method further comprises: generating a visual map based on the service trajectory chain for visit analysis, disease course review, and quality control evaluation.

Images