Elderly medical intercommunication scheme operation reliability evaluation and optimization method and system

Abstract

The application discloses an old-age medical intercommunication scheme operation reliability evaluation and optimization method and system, the method comprises the following steps: receiving a state event forwarded by a community gateway and associated with an old person identifier, a service matter identifier and a participant subject identifier, writing the state event into a service state ledger after identification matching, message checking, deduplication and time sequence arrangement, updating device online state, data integrity state, referral response state and authorization state; determining a current breakpoint according to the current service stage and the pre-requisite dependency relationship of each state, and generating a configuration adjustment instruction according to the current breakpoint and the state version; the target node executes the instruction and generates a new state event, updates the state and the state version after writing the new state event into the service state ledger, re-determines the current breakpoint, and forms an optimized state when the corresponding state remains to meet the condition in the verification period after the original interruption condition is eliminated. The application can improve the reliability of old-age medical intercommunication service interruption positioning and operation recovery.

Description

Technical Field

[0001] This application relates to the field of smart elderly care and medical information technology, specifically to a method and system for evaluating and optimizing the operational reliability of an elderly care and medical interoperability solution. Background Technology

[0002] With the development of community-based elderly care, home-based elderly care, and telemedicine collaborative services, elderly care service platforms typically need to connect to wearable devices, smart pillboxes, community gateways, medical institution interfaces, and door-to-door service terminals to complete tasks such as vital sign collection, medication confirmation, medical referral, and service handling. These tasks involve multiple stakeholders, including equipment, platforms, medical institutions, and service personnel. The sources of status data are dispersed, and there are differences in message formats, reporting cycles, and communication conditions, which can easily lead to issues such as duplicate events, out-of-order events, missing data, conflicts, and terminal offline issues.

[0003] Existing systems often focus on monitoring individual devices or judging single business results, lacking unified correlation analysis of authorization, equipment, data, and referral response status. When multiple anomalies occur simultaneously, it is difficult to determine the actual interruption point based on the sequence of business processing, easily leading to duplicate alarms, incorrect handling, or invalid retries. Furthermore, some systems typically perform fixed reconnection, resending, or retransmission operations after detecting anomalies, without fully verifying changes in business status and the applicability of handling instructions, and lacking verification of the continuity of recovery results. This may result in the repeated execution of expired instructions or re-interruption after a short period of recovery. Therefore, how to continuously and accurately evaluate the operational status of elderly care and medical interoperability services, locate key interruption points affecting business progress, and optimize subsequent processing parameters based on handling results remains a problem that related technologies need to solve. Summary of the Invention

[0004] This application provides a method and system for evaluating and optimizing the operational reliability of an elderly care and medical interoperability scheme, in order to at least solve some of the technical problems existing in the related technologies described above.

[0005] According to a first aspect of the embodiments of this application, a method for evaluating and optimizing the operational reliability of an elderly care and medical interoperability scheme is provided, including: Receive status events forwarded by the community gateway and associated with three identifiers: the three identifiers include the elderly identifier, the service item identifier, and the participating entity identifier; perform identifier matching, message verification, deduplication, and time sequence organization on the status events, write them into the service status ledger according to the ledger index composed of the three identifiers, and update four types of statuses including device online status, data integrity status, referral response status, and authorization status; Based on the current service stage and the prerequisite dependencies of the four types of states, generate authorization interruption candidates, device interruption candidates, data interruption candidates, and referral interruption candidates, and determine the candidate corresponding to the earliest unmet prerequisite as the current interruption point; Based on the current interruption point and the current state version, a configuration adjustment instruction is generated for the corresponding target node. After the target node executes the configuration adjustment instruction, a new state event is generated. Write the new status event into the service status ledger, update the corresponding status and status version, and redetermine the current interruption point; when the original interruption conditions are eliminated and the status that triggered the original interruption point remains satisfied during the verification period, update the corresponding status, status version, and verification result as the optimized status.

[0006] As an optional approach, when creating the service status ledger, the device online status is set to pending determination, the data integrity status is set to pending receipt, the referral response status is set to untriggered, and the authorization status is set to pending verification, and the status version is generated; when any status changes, the value before the change, the value after the change, the trigger event identifier, and the change time of the status are saved in the same write transaction, and the status version is incremented.

[0007] As an optional approach, messages from different sources are converted into a unified status event. This status event includes the elderly person's identifier, the service item identifier, the participating entity identifier, the source node identifier, the event type, the event generation time, the event reception time, the event sequence number, and the message digest. A deduplication identifier is formed using the source node identifier, the event sequence number, and the event type. Status events with the same deduplication identifier and the same message digest are retained. Status events with the same deduplication identifier but different message digests are marked as conflicting events and their writing to the status field is stopped. Non-conflicting events are organized according to the event generation time. When the time difference between the event generation time and the platform server time exceeds the allowed time synchronization deviation, the timing position of the corresponding status event is determined according to the event reception time. The allowed time synchronization deviation is calibrated based on the terminal clock accuracy and the communication environment.

[0008] As an optional solution, when the current service phase requires access to data within the intended data range and the authorization status is expired or revoked, an authorization interruption candidate is generated; when the authorization status is valid, the current service phase requires the target terminal to perform an operation and the device's online status is offline, a device interruption candidate is generated; when the authorization status is valid, the device's online status is online, the data reception time limit has expired and the data integrity status is incomplete, a data interruption candidate is generated; when the authorization status is valid, the data integrity status is complete, the referral request has been successfully sent and the referral response status is response timeout, a referral interruption candidate is generated; and the earliest existing candidate in the order of the authorization interruption candidate, the device interruption candidate, the data interruption candidate, and the referral interruption candidate is determined as the current interruption point.

[0009] As an optional approach, an interruption location result is generated based on the current interruption point. The interruption location result corresponding to the authorized interruption candidate includes the permission management module and authorization credentials; the interruption location result corresponding to the device interruption candidate includes the target terminal and the communication channel between the target terminal and the community gateway; the interruption location result corresponding to the data interruption candidate includes missing data items, the range of missing sequences, and the target terminal that generated the missing data items; the interruption location result corresponding to the referral interruption candidate includes the remote medical interface, the request identifier, and the target medical entity identifier; the current interruption point, the interruption location result, and the current status version are used as the inputs for generating the configuration adjustment instruction.

[0010] As an optional approach, the configuration adjustment instruction includes an instruction identifier, the ledger index, the target node identifier, an action type, action parameters, execution preconditions, a valid time period, and an associated status version. The target node identifier, action type, and action parameters are determined based on the current interruption point and the interruption location result. Specifically, the authorization interruption candidate corresponds to re-verifying authorization or requesting an update of authorization credentials; the device interruption candidate corresponds to re-establishing the communication connection between the target terminal and the community gateway; the data interruption candidate corresponds to resending data according to the missing data items and missing sequence range; and the referral interruption candidate corresponds to resending the referral request using the request identifier and retransmission identifier. The target node deduplicates data according to the instruction identifier, associates the service status ledger according to the ledger index, and executes the configuration adjustment instruction according to the action type and action parameters when the associated status version is consistent with the current status version, the execution preconditions are met, and the valid time period has not expired.

[0011] As an optional solution, after receiving the configuration adjustment instruction, the target node returns a received receipt, and after completing the corresponding action, returns an execution result receipt and generates the new status event; the received receipt and the execution result receipt are written into the processing field of the service status ledger, and the new status event is written into the service status ledger after performing identifier matching, message verification, deduplication, and timing organization, and the corresponding status and status version are updated; when the original interruption point corresponds to the authorized interruption candidate and the authorization status becomes valid and the authorization scope covers the range of data to be accessed, or the original interruption point corresponds to the device When the interruption candidate is selected and the device's online status changes to online and a valid heartbeat event or valid business message associated with the service item identifier is received, or when the original interruption point corresponds to the data interruption candidate and the data integrity status changes to complete, or when the original interruption point corresponds to the referral interruption candidate and the referral response status changes to responded, the original interruption condition is determined to be eliminated and a verification period is started; when the verification period expires, if the state of the original interruption point remains satisfied and no interruption candidate preceding it appears, then the original interruption point is marked as recovered and forms the optimized state; otherwise, the original interruption point is retained.

[0012] As an optional approach, after each verification period ends, a configuration policy record is generated, including interruption type, node category, stable recovery flag, recovery time, and policy version. From the configuration policy records with the same interruption type, the same node category, and the stable recovery flag indicating stable recovery, the most recent record is selected according to a preset sample window. The median recovery time of the most recent record is calculated, and the median recovery time is limited to between a preset minimum allowable time period and the remaining processing time limit of the service item. The resulting time period is used as the waiting period for the next similar configuration adjustment instruction. The next similar configuration adjustment instruction adopts the updated policy version, and the configuration adjustment instruction being executed retains the policy version it was generated from.

[0013] As an optional approach, a data list is generated when a service item is created. The data list includes the data types, required fields, expected data segments, and allowed formats required for the current service stage. The received data is compared item by item with the data list. If all required data items are present, the format verification passes, and there are no gaps in the continuous sequence, the data integrity status is updated to complete. If any required data item is still missing or there are unfilled gaps in the continuous sequence after the data reception deadline, the data integrity status is updated to incomplete. Before the data reception deadline expires, the data integrity status is kept as pending reception.

[0014] According to a second aspect of the embodiments of this application, a system for evaluating and optimizing the operational reliability of an elderly care and medical interoperability scheme is also provided, comprising: The status event processing module is used to receive status events forwarded by the community gateway and associate them with three identifiers: the elderly identifier, the service item identifier, and the participating entity identifier; the module performs identifier matching, message verification, deduplication, and time sequence organization on the status events, writes them into the service status ledger according to the ledger index composed of the three identifiers, and updates four types of statuses, including device online status, data integrity status, referral response status, and authorization status. The interruption identification module is used to generate authorized interruption candidates, device interruption candidates, data interruption candidates, and referral interruption candidates based on the current service stage and the prerequisite dependencies of the four types of states, and to determine the candidate corresponding to the earliest unmet prerequisite as the current interruption point; The configuration adjustment module is used to generate a configuration adjustment instruction for the corresponding target node based on the current interruption point and the current state version. After the target node executes the configuration adjustment instruction, it generates a new state event. The optimization verification module is used to write the new status event into the service status ledger, update the corresponding status and status version, and redetermine the current interruption point; when the original interruption conditions are eliminated and the status that triggered the original interruption point is satisfied during the verification period, the updated corresponding status, status version and verification result are recorded as the optimized status.

[0015] Compared to existing technologies, this application uses elderly identifiers, service item identifiers, and participating entity identifiers to construct a ledger index. It verifies, deduplicates, and organizes the time sequence of multi-source status events, and records changes in device online status, data integrity, referral response, and authorization status through status version records, enabling traceability of service item operations. By determining the earliest point of failure based on the pre-dependencies of each status, it reduces redundant judgments and incorrect localization when related anomalies occur simultaneously. Configuration adjustment instructions are generated based on the current interruption point, interruption localization results, and status version, ensuring that adjustments are only implemented on target nodes when the status is valid and execution conditions are met, reducing the impact of expired instructions on business operations. New status events generated by adjustments are rewritten into the ledger, and the continuity of the restored status is confirmed through a verification period, avoiding misjudging short-term recovery as stable recovery. Utilizing verified configuration strategies to record the waiting period for updating similar instructions improves the adaptability of processing parameters to actual operating conditions, enhancing the reliability of the evaluation and anomaly recovery of the elderly care and medical interoperability service.

[0016] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Furthermore, no embodiment in this disclosure is required to achieve all the effects described above. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0018] Figure 1 A flowchart illustrating a method for evaluating and optimizing the operational reliability of an elderly care and medical interoperability scheme, provided in this embodiment of the disclosure; Figure 2 A schematic block diagram of a reliability evaluation and optimization system for an elderly care and medical care interoperability scheme provided in this embodiment of the disclosure; Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0020] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, collected data, used data, generated data, processed data, etc.) and the data (including but not limited to data used for analysis, stored data, displayed data, collected information, used information, generated information, processed information, etc.) are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0021] This embodiment is applicable to the scenario of integrated medical and elderly care, which combines community-based elderly care, home-based elderly care, and telemedicine. The system includes a community gateway, wearable devices, medicine box terminals, telemedicine interfaces, property management work order terminals, a platform server, an optimization server, and a permission management module. The community gateway receives status events generated by each terminal and forwards them to the platform server. The platform server maintains a service status ledger. The optimization server reads the status version and status fields in the service status ledger and performs interruption identification, configuration adjustment, and recovery verification. Each terminal, interface, and server has a distinguishable node identifier and maintains the ability to record time to support event sorting. Events in the same service item are associated with the elderly person's identifier, the service item identifier, and the participating entity identifier.

[0022] The implementation process of the method described in this application will be described in detail below with reference to specific embodiments. It should be noted that this embodiment is only used to explain this application and is not intended to limit the scope of protection of this application. Conventional adjustments or substitutions of each step by those skilled in the art without departing from the concept of this application should be included in the scope of protection of this application.

[0023] Please see Figure 1 , Figure 1 This is a flowchart of the reliability evaluation and optimization method for the elderly care and medical care interoperability scheme according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps: S1, receive status events forwarded by the community gateway and associated with three identifiers; the three identifiers include elderly identifier, service item identifier, and participating entity identifier; perform identifier matching, message verification, deduplication, and time sequence organization on the status events, write them into the service status ledger according to the ledger index composed of the three identifiers, and update four types of statuses including device online status, data integrity status, referral response status, and authorization status; S2, based on the current service stage and the prerequisite dependencies of the four types of states, generates authorization interruption candidates, device interruption candidates, data interruption candidates, and referral interruption candidates, and determines the candidate corresponding to the earliest unmet prerequisite as the current interruption point; S3, Generate a configuration adjustment instruction for the corresponding target node based on the current interruption point and the current state version, and generate a new state event after the target node executes the configuration adjustment instruction; S4, write the new status event into the service status ledger, update the corresponding status and status version, and redetermine the current interruption point; when the original interruption conditions are eliminated and the status that triggered the original interruption point remains satisfied during the verification period, update the corresponding status, status version and verification result as the optimized status.

[0024] In some embodiments, for step S1, the platform server creates a service item at the start of an independently traceable vital sign collection, medication confirmation, medical referral, or home visit service. The platform server obtains the elderly person's identifier, generates a service item identifier for this service, and obtains the participant identifier corresponding to the device, institution interface, or execution terminal involved in this service. The ledger index is composed of the elderly person's identifier, the service item identifier, and the participant identifier. Node identifiers are used to distinguish the device or interface that actually sends the event and are written as event attributes into the service status ledger.

[0025] Specifically, the platform server creates a service status ledger record based on the ledger index, and sets the device online status, data integrity status, referral response status, authorization status, current service stage, and status version in this record. The initial values ​​for device online status, data integrity status, referral response status, and authorization status are pending judgment, pending receipt, not triggered, and pending verification, respectively. The current service stage is initially the authorization preparation stage, and the status version increments in the order of changes in valid statuses.

[0026] When the same elderly person has multiple service items, the platform server uses different service item identifiers to create separate accounts; when the participating entity changes its specific terminal, the participating entity identifier remains unchanged, and a new node identifier is written.

[0027] Wearable devices, medicine box terminals, remote medical interfaces, property management work order terminals, and access control modules generate messages related to vital sign sampling, medication confirmation, referral receipts, service confirmation, and authorization changes, respectively. When the community gateway forwards terminal messages, it appends the gateway reception time and the source node identifier. The platform server converts all source messages into unified status events.

[0028] Each status event includes at least the elderly person's identifier, service item identifier, participating entity identifier, source node identifier, event type, event generation time, event reception time, event sequence number, and message digest. The event sequence number is incremented by the source node within the same service item; if consecutive event sequence numbers cannot be provided, the community gateway supplements them according to the reception order and retains the original event generation time. The message digest is used to identify duplicate events and content conflicts, and the event type is uniformly converted according to a preset type mapping table.

[0029] The platform server first performs identifier matching to determine whether the elderly person's identifier, service item identifier, and participating entity identifier correspond to the created ledger index. Status events that match all three identifiers are entered into message verification; status events that do not match are written to the pending association area and their status is not updated.

[0030] Message validation includes event type validity validation, required field integrity validation, message digest validation, and consistency validation between event content and source node type. Status events that fail validation are recorded with the reason for failure but not written to the status field. After successful validation, the platform server uses the source node identifier, event sequence number, and event type to create a deduplication identifier. For status events written to the pending association area, the platform server periodically attempts to match the event in the pending association area with the newly added ledger index when creating a new ledger index. If a match is successful, the event is removed from the pending association area and processed according to the normal procedure.

[0031] In one embodiment, when the deduplication identifier and message digest of two status events are the same, the platform server retains the one that passes the verification first, and the later event is marked as a duplicate event; when the deduplication identifier is the same but the message digest is different, the later event is marked as a conflict event and is not written into the status field. The platform server returns a conflict indication to the source node and requests it to resend the original message; when the source node resends, it uses a new event sequence number, so that the message is re-verified as an independent new status event, avoiding being marked as a conflict event again due to duplicate deduplication identifiers.

[0032] After deduplication, the platform server organizes the events according to their generation time. For status events with the same generation time or whose time granularity is insufficient to distinguish their sequence, the order is determined by the event sequence number from the same source node. Status events from different source nodes with the same generation time are arranged according to their event reception time. The platform server calculates the time difference between the event generation time and the platform server time. When this time difference does not exceed the allowable time synchronization deviation, the event generation time is used as the basis for business sequence. When the time difference exceeds the allowable time synchronization deviation, the status event is marked as pending time verification, and its sequence position is determined according to the event reception time. The allowable time synchronization deviation is calibrated based on the terminal clock accuracy, community gateway forwarding latency, and communication environment, and is less than the shortest time period among the online detection period, data reception time limit, and response time limit.

[0033] In one embodiment, the platform server updates the device online status, data integrity status, referral response status, and authorization status based on the processed status events. When a single status event involves multiple statuses, the platform server completes the update within the same status version and retains the triggering event identifier. For example, after a vital sign sampling frame passes authorization verification, the device online status is updated first, and then the data integrity status is determined based on the data list.

[0034] Regarding the online status of devices, when the platform server requires a corresponding terminal to perform data collection, confirmation, or feedback operations during the current service phase, it identifies that terminal as the target terminal and initiates an online detection period. The online detection period is determined based on the target terminal's normal reporting cycle, which is derived from the terminal's configuration or continuous operation records. The online detection period must cover at least one normal reporting cycle and allow for communication forwarding time. When the platform server receives a valid heartbeat event or valid business message from the target terminal that passes verification within the online detection period, it updates the device's online status to online; if no such event is received by the end of the online detection period, the device's online status is updated to offline.

[0035] Regarding data integrity, the platform server generates a data list when creating a service item or entering a new current service phase. The data list includes the data types, required fields, expected data segments, and allowed formats needed for the current service phase, and is associated with the corresponding service item identifier. The platform server compares the received data item by item with the data list, checking the existence of required data items, whether the field formats conform to allowed formats, and whether there are sequence gaps in data segments with continuous relationships. If all required data items exist, format validation passes, and there are no gaps in the continuous sequence, the data integrity status is updated to complete. If any required data item is still missing after the data reception deadline, or if there are unfilled gaps in the continuous sequence, the data integrity status is updated to incomplete. Before the data reception deadline expires, the data integrity status remains pending reception. The data reception deadline is determined based on the data volume, normal reporting cycle, and service item processing time limit, and is earlier than the time when the data is subsequently used.

[0036] The platform server updates the referral response status after a referral request is generated. Before a referral request is generated, the referral response status remains untriggered. After the platform server successfully sends the referral request through the telemedicine interface, it updates the referral response status to "Waiting for Response" and records the request sending time, request identifier, and target medical entity identifier in the service status ledger. When the telemedicine interface returns a valid receipt or processing receipt matching the request identifier, the platform server updates the referral response status to "Responded." If no valid receipt or processing receipt is received by the response time limit, the referral response status is updated to "Response Timeout." The response time limit is determined based on the service level of the telemedicine interface and the processing time limit of the service item, and is no later than the latest processing time for that service item.

[0037] Regarding the authorization status, the platform server submits the elderly user identifier, service item identifier, participating entity identifier, intended data access range, and operation type to the permission management module. The permission management module returns authorization credentials, authorization range, effective start time, effective end time, and authorization result based on existing authorization records. The platform server then associates this information with the corresponding ledger index. If the current operation is within the authorized range and the operation time falls within the valid time period defined by the effective start and end times, the authorization status is updated to valid. If the current time is later than the effective end time, the authorization status is updated to expired. When the platform server receives a revocation event corresponding to the current authorization credentials, the authorization status is updated to revoked. If a verifiable authorization result has not yet been obtained, the authorization status remains pending verification. When the authorization status is pending verification, expired, or revoked, the platform server suspends access to data within the intended data range but continues to receive device heartbeat events and interface status events.

[0038] Before each write operation, the platform server reads the current state version corresponding to the ledger index. If the state to be written is the same as the existing state, the platform server appends a state event record but does not increment the state version. If the state to be written is different from the existing state, the platform server saves the value before the state change, the value after the state change, the trigger event identifier, and the change time within the same write transaction, and increments the state version. After the update is complete, the platform server sends the ledger index, state version, and changed state fields to the optimization server. If a higher state version appears during the optimization server's read operation, it stops using the old state version for further judgment and re-executes the interruption identification based on the latest state version.

[0039] In some embodiments, for step S2, the four states have a prerequisite dependency relationship in the order of authorization verification, terminal communication, data formation, and referral response. The optimization server generates interruption candidates based on this relationship and determines the earliest unmet condition as the current interruption point.

[0040] Specifically, the platform server maintains the current service phase based on confirmed status events. After creating a service item, it enters the authorization preparation phase; once the authorization status is updated to valid and the authorization scope required for the current operation has been confirmed, it enters the terminal interaction phase; after the target terminal is online and sends the business messages required for the current service, it enters the data aggregation phase; when the data integrity status is updated to complete and the referral trigger conditions are met, the platform server generates and sends a referral request, and after successful sending, it enters the referral waiting phase; after receiving a valid processing receipt or service completion confirmation, it enters the service completion phase. Configuration adjustment commands themselves do not change the current service phase; only new status events generated and verified after the target node executes the configuration adjustment command can potentially drive changes to the current service phase.

[0041] The optimized server performs checks when a status version is added, an online detection period expires, a data reception period expires, a response period expires, an authorization expires, an authorization is revoked, or a verification period expires. When a period expires, the platform server generates a time-limited event containing a ledger index, time-limit type, and trigger time, and writes it to the service status ledger.

[0042] In one embodiment, when the current service phase needs to access data within the intended data range, and the authorization status is expired or revoked, the optimization server generates an authorization interruption candidate. If the authorization status is pending verification and the authorization verification period has not yet expired, the current service remains in a waiting state; if no verifiable authorization result is obtained by the expiration of the authorization verification period, an authorization interruption candidate is also generated, and the missing authorization result is recorded in the candidate. The authorization verification period is determined based on the average response time and service item processing time of the permission management module, and is calculated from the time the platform server submits the authorization request to the permission management module.

[0043] Device interruption candidates are generated only if the authorization status is valid. When the current service phase requires the target terminal to perform an operation, the authorization status is valid, and the device is offline, the optimized server generates device interruption candidates. If the authorization status is invalid, device interruption candidates are not generated simultaneously.

[0044] Data interruption candidates are contingent upon the authorization status being valid and the device being online. If the data reception time limit expires, the authorization status is valid, the device is online, and the data integrity status is incomplete, the optimization server generates data interruption candidates and extracts missing data items and missing sequence ranges from the data list. If the device is offline, no data interruption candidates are generated; missing data is only written to the interruption record as an affected status.

[0045] Referral interruption candidates are contingent upon valid authorization status, complete data integrity status, and successful referral request transmission. When all these conditions are met, and the referral response status is "response timeout," the optimization server generates a referral interruption candidate. A response timeout is not determined if the referral request was not successfully transmitted; a referral interruption candidate is only considered after the request identifier, target medical entity identifier, and request transmission time have been written into the service status ledger and the response time limit has expired.

[0046] Multiple surface anomalies may occur within the same state version. The optimization server sequentially checks authorization interruption candidates, device interruption candidates, data interruption candidates, and referral interruption candidates, identifying the first candidate that appears as the current interruption point and excluding subsequent candidates. Subsequent candidates are not treated as independent interruptions; their related states are retained in the service state ledger. After the current interruption point is eliminated, the optimization server re-examines all candidates based on the new state version. If the subsequent conditions are still not met, the corresponding candidate is then identified as the new current interruption point.

[0047] In one embodiment, the optimization server generates an interruption location result based on the current interruption point. When the current interruption point is from an authorization interruption candidate, the interruption location result includes the permission management module and the current authorization credentials, and records the corresponding situations of missing authorization results, authorization expiration, or authorization revocation; when the current interruption point is from a device interruption candidate, the interruption location result includes the target terminal and the communication channel between the target terminal and the community gateway; when the current interruption point is from a data interruption candidate, the interruption location result includes missing data items, the range of missing sequences, and the target terminal that generated the missing data items; when the current interruption point is from a referral interruption candidate, the interruption location result includes the telemedicine interface, the request identifier, and the target medical entity identifier.

[0048] The optimized server writes the current breakpoint, breakpoint location result, first exception time, and current state version to the active breakpoint record. When the same current breakpoint persists, only the duration and most recent state version are updated; once the current breakpoint is eliminated, the record is closed, and subsequent exceptions are only written as affected states before that.

[0049] In some embodiments, for step S3, after the optimization server obtains the current interruption point, interruption location result, and current state version, it generates a configuration adjustment instruction for the corresponding target node. The configuration adjustment instruction does not directly modify the four types of states; after the target node executes it, a new state event is generated, and the platform server rewrites it into the service state ledger according to the processing flow in the aforementioned steps.

[0050] Specifically, each configuration adjustment instruction includes an instruction identifier, ledger index, target node identifier, action type, action parameters, execution preconditions, effective time period, and associated status version. The instruction identifier is generated by the optimization server and remains unique within the same ledger index. The associated status version is taken from the current status version at the time the instruction was generated. Execution preconditions include the original current interruption point still existing, the target node matching the interruption location result, and no adverse changes in the authorized status required for the action. The effective time period is determined based on the remaining processing time of the service item and the normal execution time of the action; it will not be executed after its expiration.

[0051] When the current interruption point originates from an authorization interruption candidate, the target node is the access control module, and the action type is either re-verify authorization or request an update of authorization credentials. Action parameters include the elderly user identifier, service item identifier, participating entity identifier, intended data access scope, operation type, and original authorization credential identifier. After obtaining new authorization covering the intended data access scope, the access control module generates a new authorization result and authorization credentials; otherwise, it returns a rejection result or a pending confirmation result.

[0052] When the current interruption point originates from a device interruption candidate, the target node is either the target terminal or the community gateway, and the action type is to re-establish the communication connection between the target terminal and the community gateway. Action parameters include the target node identifier, the current communication channel, the allowed backup channel, the reconnection waiting period, and the maximum number of reconnections. The reconnection waiting period is determined based on the target terminal's normal handshake time and communication transmission delay. The maximum number of reconnections is determined based on the remaining processing time of the service item and the time required for a single reconnection, ensuring that all reconnection operations do not exceed the remaining processing time of the service item. After the connection is established, the target terminal sends a valid heartbeat event or a valid service message with the original service item identifier.

[0053] When the current interruption point originates from a data interruption candidate, the target node is the target terminal that generated the missing data item, and the action type is data resending. Action parameters include the data list identifier, the missing data item, the missing sequence range, the allowed data resending time range, and the resending deadline. The target terminal reads the original data corresponding to the missing data item and missing sequence range from its local cache, retains the original event generation time, uses a new event sequence number to form a resending data event, and attaches the original data association identifier. The platform server, based on the original data association identifier, adds the resending data to the original data list, without replacing the original acquisition time with the resending sending time.

[0054] When the current interruption point originates from a referral interruption candidate, the target node is the telemedicine interface, and the action type is resend the referral request. Action parameters include the original request identifier, request content summary, target medical entity identifier, retransmission identifier, waiting period, and allowed retransmission count. The telemedicine interface sends the request using the original request identifier and retransmission identifier, causing the target medical entity to recognize the retransmission request as a duplicate transmission under the same service item. The waiting period and allowed retransmission count are determined based on the remaining processing time limit of the service item, and all retransmissions and waiting processes must not exceed this remaining processing time limit.

[0055] For the same activity interruption record, only one valid configuration adjustment command is retained under the same current state version. If the optimization server does not receive a receipt from the target node, it can resend a copy of the command with the same command identifier within the valid time period; the target node will deduplicate the command according to the command identifier and will not repeat the configuration adjustment command that has already been received or completed.

[0056] In one embodiment, after receiving a configuration adjustment instruction, the target node sequentially verifies the instruction identifier, target node identifier, ledger index, associated state version, execution preconditions, and valid time period. If the associated state version is inconsistent with the current state version, and the original current breakpoint has been eliminated, the target node refuses to execute the configuration adjustment instruction and returns a result indicating that the state has changed. If the associated state versions are inconsistent, but the original current breakpoint still exists, the target node requests the optimization server to regenerate the configuration adjustment instruction based on the latest state version. If the execution preconditions are not met or the valid time period has expired, the target node returns the corresponding rejection reason and does not perform any action.

[0057] After successful verification, the target node first returns a received receipt, which includes the instruction identifier, ledger index, and reception time. After the action is executed, the target node returns an execution result receipt, which includes the instruction identifier, action start time, action end time, execution success flag, failure reason, and new status event identifier generated by the action. The platform server writes the received receipt and execution result receipt into the processing field of the service status ledger. Neither the received receipt nor the execution result receipt directly changes the current breakpoint.

[0058] New status events generated by the execution of actions are still processed in the order of identifier matching, message verification, deduplication, and timing. After the platform server confirms that a new status event matches the original ledger index, it writes it into the service status ledger and updates the corresponding status and status version according to the rules of the aforementioned steps. The new status event triggers corresponding updates to the authorization status, device online status, data integrity status, or referral response status.

[0059] If a candidate for an interruption occurs before the original current interruption point during the execution of a configuration adjustment command, the optimization server stops processing actions that depend on subsequent conditions. For example, if the authorization status changes to "revoked" during data retransmission, the platform server stops receiving retransmission data within the intended data range. The optimization server identifies the authorization interruption candidate as the new current interruption point and marks the original configuration adjustment command for retransmission data as having failed as a precondition. Only after the new authorization status is updated to be valid will the optimization server re-evaluate whether the data interruption candidate still exists based on the latest status version and decide whether to generate a new configuration adjustment command accordingly.

[0060] In some embodiments, for step S4, after the optimization server reads the new status version, it determines whether the original interruption condition has been eliminated according to the type of the original current interruption point. If the original current interruption point is from an authorization interruption candidate, the authorization status becomes valid, and the authorization scope covers the range of data to be accessed, thus eliminating the original interruption condition. If the original current interruption point is from a device interruption candidate, the device's online status becomes online, and a valid heartbeat event or valid business message associated with the service item identifier is received, thus eliminating the original interruption condition. If the original current interruption point is from a data interruption candidate, missing data items and the range of missing sequences have been filled, and the data integrity status becomes complete, thus eliminating the original interruption condition. If the original current interruption point is from a referral interruption candidate, the platform server receives a valid receipt or processing receipt matching the original request identifier, and the referral response status becomes responded, thus eliminating the original interruption condition.

[0061] After the original interruption conditions are eliminated, the optimization server starts the verification period and marks the active interruption record as being in recovery verification. The verification period is determined based on the normal reporting cycle of the corresponding node or the normal response cycle of the corresponding interface, covering at least one cycle in which the triggered status can be observed again, while not exceeding the remaining processing time limit of the service item. During the verification period, the platform server continues to receive status events and update the service status ledger; if the status of the original interruption point changes to unmet again, the optimization server maintains the original active interruption record and marks this configuration adjustment instruction as unstable recovery.

[0062] When the verification period expires, if the conditions triggering the original current interruption point are still met, and no interruption candidates preceding the original current interruption point appear, the optimization server marks the original current interruption point as recovered, closes the corresponding active interruption record, and generates an optimized state. The optimized state includes the updated device online status, data integrity status, referral response status, authorization status, the status version at the time of recovery, the recovery time, the corresponding instruction identifier, and the verification result. If new subsequent interruption candidates appear during the verification period, the original current interruption point is marked as recovered, and the optimization server then determines the new current interruption point based on the latest state version.

[0063] In one embodiment, after each verification period ends, the optimization server generates a configuration policy record. The configuration policy record includes the interruption type, node category, stable recovery flag, recovery time, and policy version; wherein, the interruption type is taken from the current interruption point, the node category is taken from the target node in the interruption location result, the stable recovery flag is generated based on the judgment result when the verification period expires, and the recovery time is calculated from the time when the configuration adjustment instruction is first executed to the time when the original interruption condition is first eliminated.

[0064] The optimization server selects the most recent records from configuration policy records with the same interruption type, node category, and stable recovery flag, according to a preset sample window, and calculates the median recovery time of these most recent records. The preset sample window represents the number of the most recent valid records participating in this statistical analysis, and its value is preset by the deployment personnel based on the event frequency of similar nodes; if the number of valid records is insufficient, the initial waiting period marked during deployment is used. The optimization server limits the median recovery time to between the minimum allowed time period and the remaining processing time limit of the service item, and the resulting time period is used as the waiting period for the next similar configuration adjustment instruction. The minimum allowed time period is marked based on the shortest processing time required for the target node to complete a valid action, and the remaining processing time limit of the service item is obtained based on the difference between the latest processing time of the service item and the current time.

[0065] When the waiting period changes, a new policy version is generated. Subsequent configuration adjustment commands of the same type will use the updated policy version, while currently executing configuration adjustment commands will retain the original policy version. The maximum number of reconnections, the resend deadline, and the allowed number of resends are re-determined by the optimization server based on the updated waiting period and the remaining processing time for the service item, ensuring that the total expected execution time does not exceed the remaining processing time for the service item. Configuration policy records only participate in the parameter selection for subsequent configuration adjustment commands.

[0066] In one embodiment, for example, after detecting abnormal vital signs, the wearable device sends a vital sign sampling frame to the platform server via the community gateway. The platform server creates a ledger index and sets four initial states, then submits the elderly person's identifier, service item identifier, participating entity identifier, intended data access range, and operation type to the permission management module. After the permission management module returns valid authorization, the platform server updates the authorization status to valid and increments the status version. During the online detection period, the wearable device sends valid heartbeat events and vital sign sampling frames. The platform server completes identifier matching, message verification, deduplication, and timing organization, updating the device's online status to online.

[0067] The platform server, based on the data list, detects gaps in the continuous sampling sequence. After the data reception time limit expires, it updates the data integrity status to incomplete. The optimization server, under the conditions of valid authorization and online device status, generates data interruption candidates, identifies them as the current interruption point, and forms an interruption location result based on the missing data item, the range of the missing sequence, and the wearable device. After receiving the configuration adjustment command for resending data, the wearable device reads the missing data from its local cache and generates a new status event. The platform server adds the resent data to the original data list, and after the data integrity status changes to complete, it initiates a verification period. Upon successful verification, the optimized status is generated.

[0068] The platform server then sends a referral request and updates the referral response status to "awaiting response." If no valid response is received by the deadline, the optimization server generates a referral interruption candidate, establishes an interruption location result based on the telemedicine interface, request identifier, and target medical entity identifier, and generates a configuration adjustment instruction to resend the referral request. The telemedicine interface resends the request using the original request identifier and resend identifier. After receiving a matching response, the platform server updates the referral response status to "responded." If this status remains satisfied during the verification period and no earlier interruption candidate appears, the optimization server closes the referral interruption record and establishes the optimized status. After the service is completed, the platform server saves the status events, status changes, configuration adjustment instructions, execution result responses, and verification results.

[0069] Through the above processing, multi-source state events are continuously recorded according to the ledger index and state version. The pre-dependencies of the four types of states determine the current interruption point, and the interruption location result generates a configuration adjustment instruction. After the target node executes the instruction, a new state event is generated. After writing and verification, the optimized state is obtained, and the subsequent waiting period is updated according to the verified configuration strategy.

[0070] Please see Figure 2 , Figure 2 This is a structural block diagram of a reliability evaluation and optimization system for an elderly care and medical interoperability scheme provided in an embodiment of this application. Figure 2 As shown, the system includes: The status event processing module 201 is used to receive status events forwarded by the community gateway and associate them with three identifiers: the three identifiers include the elderly identifier, the service item identifier, and the participating entity identifier; the status events are matched with identifiers, verified with messages, deduplicated and sorted in time sequence, written into the service status ledger according to the ledger index composed of the three identifiers, and updated four types of statuses including device online status, data integrity status, referral response status, and authorization status. The interruption identification module 202 is used to generate authorized interruption candidates, device interruption candidates, data interruption candidates and referral interruption candidates based on the current service stage and the prerequisite dependencies of the four types of states, and to determine the candidate corresponding to the earliest unmet prerequisite as the current interruption point; The configuration adjustment module 203 is used to generate a configuration adjustment instruction for the corresponding target node based on the current interruption point and the current state version. After the target node executes the configuration adjustment instruction, it generates a new state event. The optimization verification module 204 is used to write the new status event into the service status ledger, update the corresponding status and status version, and redetermine the current interruption point; when the original interruption conditions are eliminated and the status that triggered the original interruption point is maintained during the verification period, the updated corresponding status, status version and verification result are recorded as the optimized status.

[0071] Each processing unit and / or module in the embodiments of this application can be implemented by an analog circuit that implements the functions described in the embodiments of this application, or by software that executes the functions described in the embodiments of this application.

[0072] Based on the same inventive concept, this application also provides an electronic device, the method corresponding to which can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. For example... Figure 3 As shown, Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of the present disclosure. The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods and / or technical solutions of the foregoing embodiments of the present application.

[0073] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by a processor, it performs the functions defined in the methods of this application.

[0074] Another embodiment of this application provides a storage medium storing computer program instructions thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application.

[0075] In the above embodiments, the descriptions of each embodiment have different focuses. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. The above descriptions are merely preferred embodiments of this application and explanations of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solutions formed by specific combinations of the above technical features, but should also cover other technical solutions formed by arbitrary combinations of the above technical features or their equivalent features without departing from the inventive concept.

Claims

1. A method for evaluating and optimizing the operational reliability of an integrated elderly care and medical care scheme, characterized in that, include: Receive status events forwarded by the community gateway and associated with three identifiers; The three identifiers include an identifier for seniors, an identifier for service items, and an identifier for participating entities; The status events are identified, matched, verified, deduplicated, and time-series organized. They are written into the service status ledger according to the ledger index composed of the three identifiers, and the four types of status are updated, including device online status, data integrity status, referral response status, and authorization status. Based on the current service stage and the prerequisite dependencies of the four types of states, generate authorization interruption candidates, device interruption candidates, data interruption candidates, and referral interruption candidates, and determine the candidate corresponding to the earliest unmet prerequisite as the current interruption point; Based on the current interruption point and the current state version, a configuration adjustment instruction is generated for the corresponding target node. After the target node executes the configuration adjustment instruction, a new state event is generated. Write the new status event into the service status ledger, update the corresponding status and status version, and redetermine the current breakpoint; When the original interruption condition is eliminated and the state of the original interruption point remains satisfied during the verification period, the corresponding state, state version, and verification result will be updated and recorded as the optimized state.

2. The method for evaluating and optimizing the operational reliability of an integrated elderly care and medical care scheme according to claim 1, characterized in that, When creating the service status ledger, the device online status is set to pending determination, the data integrity status is set to pending receipt, the referral response status is set to untriggered, and the authorization status is set to pending verification, and the status version is generated; when any status changes, the value before the change, the value after the change, the trigger event identifier, and the change time of the status are saved in the same write transaction, and the status version is incremented.

3. The method for evaluating and optimizing the operational reliability of an elderly care and medical care interoperability scheme according to claim 2, characterized in that: Messages from different sources are converted into a unified status event. The status event includes the elderly person's identifier, the service item identifier, the participating entity identifier, the source node identifier, the event type, the event generation time, the event reception time, the event sequence number, and the message digest. A deduplication identifier is formed using the source node identifier, the event sequence number, and the event type. Status events with the same deduplication identifier and the same message digest are retained. Status events with the same deduplication identifier but different message digests are marked as conflict events and writing to the status field is stopped. Non-conflicting events are organized according to the event generation time. When the time difference between the event generation time and the platform server time exceeds the allowable time synchronization deviation, the time sequence position of the corresponding status event is determined according to the event reception time. The allowable time calibration deviation is determined based on the terminal clock accuracy and communication environment.

4. The method for evaluating and optimizing the operational reliability of an integrated elderly care and medical care scheme according to claim 3, characterized in that, When the current service phase requires access to data within the intended data range and the authorization status is expired or revoked, an authorization interruption candidate is generated; when the authorization status is valid, the current service phase requires the target terminal to perform an operation and the device's online status is offline, a device interruption candidate is generated; when the authorization status is valid, the device's online status is online, the data reception time limit has expired and the data integrity status is incomplete, a data interruption candidate is generated; when the authorization status is valid, the data integrity status is complete, the referral request has been successfully sent and the referral response status is response timeout, a referral interruption candidate is generated; the earliest existing candidate in the order of the authorization interruption candidate, the device interruption candidate, the data interruption candidate, and the referral interruption candidate is determined as the current interruption point.

5. The method for evaluating and optimizing the operational reliability of an integrated elderly care and medical care scheme according to claim 4, characterized in that, An interruption location result is generated based on the current interruption point; the interruption location result corresponding to the authorized interruption candidate includes the permission management module and authorization credentials; the interruption location result corresponding to the device interruption candidate includes the target terminal and the communication channel between the target terminal and the community gateway; the interruption location result corresponding to the data interruption candidate includes missing data items, missing sequence range, and the target terminal that generated the missing data items; the interruption location result corresponding to the referral interruption candidate includes the remote medical interface, request identifier, and target medical entity identifier. The current interruption point, the interruption location result, and the current state version are used as the inputs for generating the configuration adjustment instruction.

6. The method for evaluating and optimizing the operational reliability of an integrated elderly care and medical care scheme according to claim 5, characterized in that, The configuration adjustment instruction includes an instruction identifier, the ledger index, the target node identifier, an action type, action parameters, execution preconditions, a valid time period, and an associated status version. The target node identifier, action type, and action parameters are determined based on the current interruption point and the interruption location result. Specifically, the authorization interruption candidate corresponds to re-verifying authorization or requesting an update of authorization credentials; the device interruption candidate corresponds to re-establishing the communication connection between the target terminal and the community gateway; the data interruption candidate corresponds to resending data according to missing data items and the range of missing sequences; and the referral interruption candidate corresponds to resending the referral request using the request identifier and the retransmission identifier. The target node deduplicates data according to the instruction identifier, associates the service status ledger according to the ledger index, and executes the configuration adjustment instruction according to the action type and action parameters when the associated status version is consistent with the current status version, the execution preconditions are met, and the valid time period has not expired.

7. The method for evaluating and optimizing the operational reliability of an integrated elderly care and medical care scheme according to claim 6, characterized in that, After receiving the configuration adjustment instruction, the target node returns a received receipt, completes the corresponding action, returns an execution result receipt, and generates the new status event. The received receipt and the execution result receipt are written into the processing field of the service status ledger. The new status event is then processed by identifier matching, message verification, deduplication, and timing organization before being written into the service status ledger, and the corresponding status and status version are updated. When the original interruption point corresponds to the authorized interruption candidate and the authorized status becomes valid and the authorized scope covers the intended data range, or the original interruption point corresponds to the device interruption candidate and the device online status becomes online and receives a valid heartbeat event or valid business message associated with the service item identifier, or the original interruption point corresponds to the data interruption candidate and the data integrity status becomes complete, or the original interruption point corresponds to the referral interruption candidate and the referral response status becomes responded, the original interruption condition is determined to be eliminated and the verification period is started. When the verification period expires, if the original interrupt point remains in a state that satisfies the condition and no interrupt candidate appears before it, then the original interrupt point is marked as recovered and forms the optimized state; otherwise, the original interrupt point is retained.

8. The method for evaluating and optimizing the operational reliability of an elderly care and medical care interoperability scheme according to claim 7, characterized in that, After each verification period ends, a configuration policy record is generated, including interruption type, node category, stable recovery flag, recovery time, and policy version. From the configuration policy records with the same interruption type, the same node category, and the stable recovery flag indicating stable recovery, the most recent record is selected according to a preset sample window. The median recovery time of the most recent record is calculated, and the median recovery time is limited to between a preset minimum allowable time period and the remaining processing time limit of the service item. The resulting time period is used as the waiting period for the next similar configuration adjustment instruction. The next similar configuration adjustment instruction adopts the updated policy version, and the configuration adjustment instruction being executed retains the policy version it was generated from.

9. The method for evaluating and optimizing the operational reliability of an integrated elderly care and medical care scheme according to claim 8, characterized in that, When creating a service item, a data list is generated, which includes the data types, required fields, expected data segments, and allowed formats required for the current service stage. The received data is compared item by item with the data list. If all required data items are present, the format validation passes, and there are no gaps in the continuous sequence, the data integrity status is updated to complete. If any required data item is still missing or there are unfilled gaps in the continuous sequence after the data reception deadline, the data integrity status is updated to incomplete. Before the data reception deadline expires, the data integrity status remains "pending reception".

10. A reliability evaluation and optimization system for an integrated elderly care and medical care scheme, characterized in that, include: The status event handling module is used to receive status events forwarded by the community gateway and associate them with three identifiers; The three identifiers include an identifier for seniors, an identifier for service items, and an identifier for participating entities; The status events are identified, matched, verified, deduplicated, and time-series organized. They are written into the service status ledger according to the ledger index composed of the three identifiers, and the four types of status are updated, including device online status, data integrity status, referral response status, and authorization status. The interruption identification module is used to generate authorized interruption candidates, device interruption candidates, data interruption candidates, and referral interruption candidates based on the current service stage and the prerequisite dependencies of the four types of states, and to determine the candidate corresponding to the earliest unmet prerequisite as the current interruption point; The configuration adjustment module is used to generate a configuration adjustment instruction for the corresponding target node based on the current interruption point and the current state version. After the target node executes the configuration adjustment instruction, it generates a new state event. The optimized verification module is used to write the new status event into the service status ledger, update the corresponding status and status version, and redetermine the current breakpoint; When the original interruption condition is eliminated and the state of the original interruption point remains satisfied during the verification period, the corresponding state, state version, and verification result will be updated and recorded as the optimized state.

Images