JP5475231B2 - System and method for exchanging patient data with a decision support system for feasible guidelines - Google Patents

Description

  The present invention relates generally to decision support systems and, more particularly, to decision support systems used to assist in providing health care to patients using viable clinical guidelines.

  Existing demonstrations can improve the effectiveness of patient treatment by utilizing a computer-based implementation of evidence-based clinical feasibility guidelines integrated with the clinical workflow. This improvement may include allowing patient-specific recommendations to be provided at each point of treatment. Feasible guidelines make the knowledge readily available to the doctor without the doctor having to find the specific knowledge. Many professional societies (ACP-ASIM, ACR, ACC, etc.) provide feasible guidelines for patient treatment. Decision support systems (DSS) have been developed to integrate feasible guideline execution and patient-related data stored in the information system and the patient's treatment.

  However, decision support systems are not widely deployed at each treatment point. This is mainly due to a mismatch between the information system for storing patient data and the decision support system. One approach to solving the mismatch problem is to provide a tight integration between the DSS and the local clinical information storage system, which makes it extremely difficult to share the DSS with other facilities To.

  Another approach has been to design a medical logic module (MLM) for DSS to provide compatibility between the DSS and the local information storage system for information sharing. The MLM has a special section in which the terms used by the DSS are surrounded by additional terms to provide a mapping with the terms used by the local information storage system. These additional terms are known as curly braces. The mapping between MLM terminology and local information storage systems is specific to the facility and requires a lot of customization processing. Therefore, the burden of preparing and using the mapping is usually referred to as the “braces problem”. The cost and effort of building a DSS is very large, and its customization process for use by a local information storage system is time consuming and hinders the purpose of sharing the DSS with many facilities.

  The present invention thus relates to the problem of developing systems and methods in which DSS is connected to multiple information systems and deployed in multiple facilities.

  A feature of the present invention is to provide a data exchange system and method. The system includes a local information storage system that stores a plurality of first data elements for each piece of data relating to a plurality of patients, and an executable guideline decision support system that is executable on at least one processor. The decision support system includes an executable guideline storage system for storing a plurality of executable guidelines, and an execution engine for executing the guidelines including processing of data related to at least the second data element.

  The decision support system is executable on at least one processor for generating a request to exchange data relating to the second data element between the local information system, the decision support system and the patient knowledge base. Has a search module. The patient knowledge base includes a first data element of a plurality of first data elements corresponding to the second data element, and at least one compatibility parameter that defines how the first and second data elements correspond. It can be executed on at least one processor to determine. Further, the patient knowledge base is executable to process data exchanged according to at least one compatibility parameter determined to establish semantic compatibility between the first data element and the second data element. . A connection is provided for transmitting data exchanged between the first data element and the second data element.

  The method provides for generating a request to exchange data between a local information system and a decision support system, and a first data element of a plurality of first data elements corresponding to the second data element And providing to determine at least one compatibility parameter that defines how the first and second data elements correspond. The method further provides for processing data exchanged according to the determined at least one compatibility parameter to establish semantic compatibility between the first data element and the second data element; Providing for transmitting data exchanged between the first data element and the second data element.

  The above and other features, aspects and advantages of the present invention will become better understood with reference to the drawings enumerated below and the detailed description of the invention.

  The present invention describes a system having a decision support system for executing feasible clinical guidelines that provides users with clinical guidelines in patient treatment. The decision support system is connected to a local information storage system that stores data regarding a plurality of patients and / or treatments of the patients. Data stored in the patient information storage system may be required by the decision support system to implement the guidelines, and the decision support system may need to update the data stored by the local information storage system. Absent. The decision support system provides queries or updates generated by the decision support system and information stored by the local information storage system to provide semantic compatibility between the decision support system and the local information storage system. And a patient knowledge base that semantically matches This semantic compatibility means that the decision support system and the local information storage system share a common meaning of the requested and exchanged data and / or actions to avoid misinterpretation and ultimately false medical judgment. Guarantee that you have an understanding of.

  FIG. 1 illustrates a preferred embodiment of an example system 10 having a decision support system connected to a local information storage system that is used to provide decision support in patient health care. The system 10 includes an executable guideline storage system 14, a DSS execution engine 16, a user interface (UI) 18, a domain knowledge base (DKB) 22, a patient knowledge base (PKB) 24, and a request module 30. It has an executable guideline decision support system (DSS) 12. The system 10 further includes a local information storage system (LISS) 26 and an interface module 28 that store data relating to at least one patient and / or treatment of the patient. The execution engine 16 detects the semantically correct data needed for the execution of the guideline, or utilizes the data processed by the execution engine 16 such as for updating the LISS 26. The request module 30 for generating a query or request for searching the PKB 24 is provided.

  The term storage system refers to a system for storing and accessing information such as one or more databases or repositories that may and may not be configured. The DSS 12 is realized using at least one processor and at least one storage medium accessible by the processor. The components of system 10 include (e.g., local information storage system 26, interface module 28, DSS 12 and its components (evidence guideline storage system 14, DSS execution engine 16, user interface 18, domain knowledge base 22, patient knowledge base 24, request Connected via a wired or wireless connection 31, which may be provided by one or more networks such as a LAN, WAN, intranet, the Internet, or combinations thereof.

  Each component of system 10 may share at least one processor and at least one storage medium resource, or may exclusively utilize one or more of these resources. The at least one processor may include, for example, a personal computer, a microprocessor, a portable computing device, a server, and the like. The at least one storage medium may include, for example, a hard drive, CD-ROM, RAM, flash memory, volatile memory, non-volatile memory, and the like.

  The LISS 26 is preferably selectable from various types of LISSs that allow the DSS to exchange information with various types of LISSs of various types of LISSs. The LISS 26 preferably includes a plurality of patients that may include patient information, examination results, imaging results, etc. stored as a plurality of first data elements configured in accordance with at least one of the standard electronic medical record types. And data relating to the patient's treatment.

  The DSS 12 or a portion thereof may be located on a server or storage accessible by the server, where the server is accessible by multiple computers. For example, the user may operate a workstation such as a personal computer in order to use the DSS 12 in which the execution of the DSS 12 is executed in the server or the workstation. Alternatively, the DSS may be located in one or more workstations or storage accessible by the workstations. Further, the DSS 12 may be embedded within or linked to other systems such as a management information storage system (eg, for hospitals, nursing homes, laboratories, etc.). An exemplary application of the DSS 12 includes resource management, planning and / or quality assurance support.

  The guideline storage system 14 stores a plurality of executable guidelines. The guidelines stored in the executable guideline storage system 14 are preferably evidence-based and are developed according to the experience and research of experts in the field. The guideline is encoded by an appropriate encoding such as ASBRU, GLIF, EON, GUIDE, PRODIGY, or PROforma. The guideline storage system 14 is preferably a guideline that best meets the criteria, typically a clinical guideline for treatment within a context that best matches at least one combination of patient status, user status, treatment status, etc. Searchable to find guidelines that provide

  The DSS 12 accesses the guideline selected from the guideline information system 14. The guidelines may be selected by the user by maintaining access to the selected guidelines in the DSS 12, and / or the guidelines may include the patient's current status, medical history, status of treatment provided so far, etc. , May be selected by the DSS 12 according to clinical situation related data available to the DSS 12. The clinical application may be utilized to submit clinical status data to the DSS 12, or the user interface 18 may be utilized to allow the user to enter clinical status data. A copy of the selected guideline or link to it may be stored temporarily or permanently with patient data in the local information storage system 26, such as on a user's workstation, and / or the executable guideline system 14 Or it may be stored in a workspace accessible and / or provided by the DSS 12. The stored copy may be individually customized, for example, by using a guideline editing tool or by deleting or omitting a specific step of the guideline.

  Each guideline includes at least one step sequence where each sequence includes at least one step. Each step of the guideline includes various types of steps. One type of step is an action step that directs a user (doctor, nurse, hospital administrator, technician, etc.) or a component of system 10 to perform an action. Examples of actions include gathering information, running a test, providing treatment, and jumping to other steps or other guidelines in the guidelines. Another type of step is a selection step to prompt the user to make a selection, such as determining the next step to be performed from the selection of at least two steps. Another type of step is a state step or execution process that represents the patient's current state, the patient-related entity or the patient's treatment. Yet another type of step is performed to make decisions such as at least one algorithm determining which step should be performed next. Information collection from LISS 26, etc. may be performed during the execution of various types of steps.

  Interaction between the DSS 12 and the user is provided via the guideline user interface 18. The guidelines to be executed are presented to the user via the guideline user interface 18. The guideline user interface 18 may generate a display, such as for display on a screen of a mobile or desktop computing device, and process input from an input device such as a pointing device and / or a keyboard. The guideline user interface 18 is not limited to this, but may generate a graphical user interface (GUI). For example, the guideline user interface 18 may provide an interface that includes a voice activated system that provides menu selection and / or prompts via voice messages, such as for use via a telephone. User responses may be provided by key presses and / or voice responses, and voice recognition techniques may be utilized to process the responses.

  The execution engine 16 of the DSS 12 executes at least one executable guideline stored in the guideline storage system 14. Execution of the at least one executable guideline typically includes access to and processing of data stored in the domain knowledge base 22 and / or the local information storage system 26. However, different uses or interpretations of the data and terms used by DSS 12 and LISS 26 will lead to misinterpretation of the data and subsequent erroneous medical decisions. The patient knowledge base provides semantic compatibility to ensure that the requester of information (such as the executable engine 16) and the provider have a common understanding of the meaning of the requested data and services. Semantic compatibility refers to a context-dependent semantic matching process and may include the compensation required to ensure compatibility between the information requester and the provider. Semantic matching is applied to the definition of the concept along with its instantiation.

  Specific examples of semantic differences include differences in numerical representation, measurement units, differences in technology and status, differences in measurement accuracy, differences in the degree of error, differences in information sources (such as professional physician vs. computer algorithm), numerical values or Differences in diagnostic confidence, differences in demographic conditions (gender, weight, height, skin color, ethnicity, etc.), differences in clinical status, differences in environmental status, differences in reference points, use of terms and scope Differences are included.

  Both PKB 24 and DKB 22 are preferably occupied information storage systems configured as an ontology. In each ontology, knowledge about the domain of patient data is expressed in a declarative language. A set of objects that can be expressed in a declarative language is called a universe of disciplines. Ontologies define a set of expressive terms and provide formal axioms that limit the interpretation and clearly defined use of these terms, as described below. The interface module 28 that interfaces between the PKB 24 and the LISS 26 may be implemented using available specifications, such as the HL7 Templates or Australian Archtypes specifications.

  The PKB 24 stores data nodes that maintain patient-related data, relationships between data nodes, and attributes related to each data node. The data may be configured according to standard medical data models (HL7, DICOM, etc.). The above relationships such as semantic links indicate how they are related via causal relationships, temporal relationships and / or group membership relationships. The attributes include information describing the status and semantic meaning of the data to limit the interpretation and use of the data, such as how the data was acquired and how it is represented. For example, attributes can be numerical representations, units of measure, technology and status, measurement accuracy, degree of error, information sources (such as specialized physician vs. computer algorithms), numerical or diagnostic confidence, demographic conditions, relevant clinical It may describe data-related characteristics such as state, environmental state, reference point, use of terms and use of scope. Further, the attribute may include a LISS indicator that indicates when the data node corresponds to a local information storage system and / or a data element of any local information storage system.

  The DKB 22 stores information that is not related to a specific patient, such as data related to illnesses, drugs, and treatments. The information establishes semantic compatibility, for example, to compensate for differences in units, reference points, environmental conditions, etc., and to define and / or compensate for relationships between incompatible uses of information. May include algorithms and / or equations useful for: The DKB 22 provides a semantic link between stored information. For example, the DKB 22 may include an obstetric area that includes elements of fetal waist circumference (AC) and estimated fetal weight (EFW). A semantic link may be provided between both AC and EFW elements to establish that the AC can be used to determine the EFW. In other examples, the femoral length (FL) and menstrual age (MA) elements may be included within the same region or other regions such as orthopedics. Other semantic links may be provided between both the MA and FL elements that establish that FL is a function of MA.

  Referring to FIG. 2, a flowchart 200 is provided that illustrates the steps that are performed during the processing of the system 10 in which the DSS 12 requests data from the LISS 26. In step 202, the request module 30 extracts the data stored by the LISS 26 corresponding to the second data element processed by the execution engine 16 while maintaining semantic compatibility with a second data element. Generate a PKB query that includes a request for. The desired data to be extracted according to the request is data to be exchanged between the LISS 26 and the DSS 12. More specifically, the PKB query detects information about how the PKB 24 detects desired data in one of the first data elements stored in the LISS 26, and the detected data is transmitted to the execution engine 16. To determine how it can be used while maintaining its semantic compatibility. Preferably, the attribute of the second data element that maintains semantic compatibility with the second data element processed by the execution engine 16 is known by the PKB 24. Otherwise, the PKB query can provide attributes by querying the DKB 22 because the attributes are already specified when defining the data elements of the guideline. The PKB query may request extraction of data corresponding to the plurality of first data elements and / or the plurality of second data elements. The following description relates to a case of extracting data corresponding to one first data element and one second data element.

  The PKB 24 processes the PKB query. In step 204, the PKB 24 accesses the first data node corresponding to the second data element. In step 206, the PKB 24 determines a second data node associated with the first data node and associated with the first data element stored by the LISS 26. The second data node is arranged by processing at least one relationship related to the first data element and checking the correlation with the first data element stored by the LISS 26. The correlation with the first data element stored by the LISS 26 may be determined by checking the LISS indicator when included with the data node of the PKB 24. Otherwise, the LISS 26 itself or a provided list of multiple first data elements may be queried. For example, in the example where multiple potential data nodes are associated with the first data node and associated with the first data element stored by the LISS 26, the best data node is the user's choice, most likely to be the first node. The second data node is selected according to a predetermined condition, such as the simplest relationship having a common attribute.

  In step 208, the PKB 24 determines at least one compatibility parameter that defines how the first data element and the second data element correspond, as indicated by the relationship between the first node and the second node. The compatibility parameter is a method of compensation between at least one of at least one relationship that defines how the first data element and the second data element are related, and the first data element and the second data element. And at least one set of at least one compensation rule.

  The at least one relationship may be determined according to a relationship configured between the first node and the second node and may include an identifier used by the LISS 26 to identify the data element of interest. The compensation rule is determined by comparing the attributes of the first data node (corresponding to the second data element) and the second data node (corresponding to the first data element). The compensation rule determines the difference in the attribute of the first node relative to the attribute of the second node, and provides semantic compatibility between the first data element and the second data element, thus compensating for the determined difference. It is determined by generating a rule so that information can be obtained from data available in the LISS 26. Preferably, the PKB query is configured as a descriptive logic based query. Request module 30 preferably includes at least one artificial intelligence module for formulating a PKB query. The PKB 24 may query the DKB 22 or intelligent agent to determine the compatibility attributes and the second data node.

  The compatibility parameters may be stored temporarily or permanently in association with at least the second data element or the first node for subsequent use. Storage of the determined relationship and the determined compensation rule or access to it may be provided by PKB 24 and DKB 22 according to design choices. If compatibility parameters are stored and available, they are extracted from storage instead of determining them.

  In step 210, the PKB generates a LISS query according to the determined at least one relational compatibility parameter for querying the LISS 26 to extract data relating to the first data element. This at least one relational compatibility parameter is utilized to identify the first data element in the LISS. In step 212, the LISS 26 responds to the LISS query by providing the interface module 28 with a result having data relating to the first data element. In step 214, the interface module 28 further converts the results of the LISS query, if necessary, into a format that can be understood by the PKB 24. The interface module 28 provides the converted result to the PKB 24.

  Upon receipt of the result in step 216, PKB 24 compensates the data to ensure that the result data is semantically compatible with the second data element to ensure correct processing by the DSS 12 execution engine 16. Therefore, the determined compensation rule is applied to the result data. In step 218, the PKB 24 provides semantically compatible data to the executable engine 16 that can be used by the execution engine 16 to process and / or update the rationale guideline storage system 14.

  Referring to FIG. 3, a flowchart is provided showing the steps performed during the processing of the system 10 in which the DSS 12 updates the data stored in the LISS 26. In step 302, the PKB 24 receives an update request from the execution engine 16 to update the data element of the LISS 26 with the data of the second data element that is to be exchanged. The update request may request an update corresponding to the plurality of first data elements and / or the plurality of second data elements. However, for simplicity, the following description relates to the case of extracting data corresponding to one first data element and one second data element.

  In step 304, the PKB 24 accesses the first data node corresponding to the second data element. In step 306, PKB 24 determines a second data node associated with the first data node and correlated to the first data element stored by LISS 26. In step 308, the PKB 24 determines at least one compatibility parameter that defines how the first data element and the second data element correspond, as indicated by the relationship between the first node and the second node. If compatibility parameters are stored and available, they are extracted from storage instead of determining them.

  In step 310, the PKB 24 applies the determined compensation rules to the data associated with the second data element to compensate the data so that the data is semantically compatible with the first data element. In step 312, the PKB generates a LISS update request according to the determined at least one relational compatibility parameter to instruct to update the first data element with the data compensated in the storage 26 by the LISS 26. This at least one relationship compatibility parameter is utilized to identify the first data elements and their corresponding elements in LISS 26. The interface module 28 converts the LISS update request into a format understood by the LISS 26 in accordance with the conventions utilized by the LISS 26 in order to properly update the first data element. In step 314, the LISS 26 updates the first data element with the appropriate compensated data.

  In developing the DSS 12, it is preferable to prepare the DSS 12 by utilizing the semantic conventions utilized by the most available LISS 26. When developing PKB 24, it is not necessary to completely replicate LISS 26 to be utilized together. Preferably, the PKB 24 is occupied by knowledge that complies with the anticipated incompatibilities between the DSS 12 and the extensive LISS 26. The discussion area of the PKB 24 needs to be large enough to accommodate the data it processes, such as data from DSS 12 or data stored in LISS 26 corresponding to data transmitted in DSS 12. There is.

  It is conceivable that a PKB may be developed as it is used. For example, detecting a compatibility issue that did not change well may require user intervention. If the user input is successfully determined, the execution module 16, PKB 24, and / or interface module 28 of the system 10 may be updated with suggested solutions for subsequent use, as needed. (Permanently or temporarily). Alternatively, upon detecting a similar problem, the intelligent agent may be queried to provide a solution. If the intelligent agent recommended solution is determined to be successful, it may be used to update the system 10 as needed.

  Furthermore, it is conceivable that updates to the system 10 as described above may be uploaded to servers connected to multiple systems 10. This update may be downloaded to system 10 of systems 10 that are prone to encounter similar compatibility issues. Update uploads and downloads may be monitored or automated by the system administrator of each system.

  The described embodiments of the present invention are illustrative rather than limiting and do not represent every embodiment of the present invention. Various changes and modifications can be made without departing from the spirit or scope of the present invention as given in the following claims, both literally and legally recognized.

FIG. 1 shows a block diagram of an exemplary system having a decision support system connected to a local information storage system according to the present invention. FIG. 2 shows a flow chart of the steps performed during the processing of the system shown in FIG. 1 where the decision support system requests data extraction from the local information support system. FIG. 3 shows a flowchart of the steps performed during the processing of the system shown in FIG. 1 in which the decision support system updates the data stored by the local information storage system.

Claims (12)

A local information storage system for storing a plurality of first data elements relating to respective data of each of a plurality of patients;
Executable guideline decision support having an executable guideline storage system for storing a plurality of executable guidelines and an execution engine having at least one processor for executing the guidelines including at least processing data relating to the second data element System,
A data exchange system comprising:
The decision support system includes:
A search module for generating a request to exchange data related to the second data element between the local information system and the decision support system;
At least one compatibility parameter defining a first data element of the plurality of first data elements corresponding to the second data element and how the first data element and the second data element correspond to each other; A patient knowledge base for processing the data exchanged according to the determined at least one compatibility parameter to establish a semantic relationship between the first data element and the second data element When,
A connection for transmitting the data exchanged between the first data element and the second data element;
I have a,
The at least one compatibility parameter is:
At least one of at least one relationship defining how the first data element and the second data element are related;
At least one set of at least one compensation rule defining a compensation method for compensating for a difference between the first data element and the corresponding second data element;
Have
The patient knowledge base is:
A plurality of data nodes and at least one relationship for each data node of the plurality of data nodes defining how each data node is associated with other data nodes of the plurality of data nodes; Store or access at least one attribute associated with the node;
Accessing a first data node of the plurality of data nodes corresponding to the second data element;
Determining a first data element by determining a second data node that can be correlated to a data element of the plurality of first data elements by at least processing at least one relationship related to the first data node;
Determining at least one relationship of the at least one compatibility parameter according to at least one stored or accessed relationship defining a relationship between the first node and the second node;
The system for determining the at least one compensation rule for the at least one compatibility parameter according to the at least one attribute stored or accessed for the first data node and the second data node . The system of claim 1, comprising:
The patient knowledge base is configured as an ontology. The system of claim 1, comprising:
The system is characterized in that the search module is configured by artificial intelligence to generate the request. The system of claim 1, comprising:
The system, wherein the request is a patient knowledge base query configured as a descriptive logic based query. The system of claim 1, further comprising:
A system comprising an interface module that interfaces between the patient knowledge base and the local information storage system. The system of claim 1, further comprising:
A domain knowledge base storing information related to at least one compatibility parameter associated with each data node of the plurality of data nodes not related to the plurality of patients;
The patient knowledge base accesses the domain knowledge base to determine the at least one compatibility parameter;
A system characterized by that. The system of claim 1 , comprising:
The request is for extracting from the local information storage system data to be used for processing the second data element;
The patient knowledge base further includes:
Wherein according to at least one relationship between at least one compatibility parameter, the raw form with respect to the first said query requesting the extraction of data said switching from the data of the data element local information storage system,
Accepts the requested exchanged data,
Processing the accepted data to be exchanged according to the at least one compensation rule;
For processing that due to the execution engine, and updates the data related to the second data element by said compensated data,
A system characterized by that. The system of claim 1, comprising:
The request is for updating data stored by the local information storage system with the exchanged data;
The patient knowledge base further includes:
Processing the exchanged data in accordance with the at least one compensation rule to compensate the exchanged data;
Generating an update request according to at least one relationship of the at least one compatibility parameter to update the first data element with the compensated exchanged data;
Sending the update request to the local information storage system;
A system characterized by that. The system of claim 1, comprising:
Before Symbol decision support system for the exchange of data by the local information storage system multiple, it is possible to establish the semantic compatibility,
A system characterized by that. A method for exchanging data between a feasible guideline decision support system and a local information storage system,
A step wherein the local information storage system, for storing a plurality of first data elements according to the data,
Said executable guideline decision support system, comprising the steps of storing a plurality of executable guidelines,
The executable guideline decision support system executing at least one guideline of a plurality of guidelines including at least processing data relating to a second data element;
The executable guideline decision support system generating a request for exchanging data contained in data related to the second data element between the local information system and the decision support system;
How the executable guideline decision support system corresponds to a first data element of the plurality of first data elements corresponding to the second data element, and the first data element and the second data element Determining at least one compatibility parameter defining;
The exchanged data according to the determined at least one compatibility parameter for the executable guideline decision support system to establish semantic compatibility between the first data element and the second data element. A step of processing
The executable guideline decision support system transmitting the data exchanged between the first data element and the second data element to the local information storage system ;
I have a,
The at least one compatibility parameter includes at least one of at least one relationship defining how the first data element and the second data element are related, and the second data element corresponding to the first data element. At least one set of at least one compensation rule defining a compensation method for compensating for differences between data elements;
Determining the first data element further comprises:
A plurality of data nodes and at least one relationship for each data node of the plurality of data nodes defining how each data node is associated with other data nodes of the plurality of data nodes; Storing and accessing at least one attribute associated with the node;
Accessing a first data node of the plurality of data nodes corresponding to the second data element;
Determining a second data node correlating to a data element of the plurality of first data elements by at least processing at least one relationship related to the first data node to determine the first data element; Steps,
Determining at least one relationship of the at least one compatibility parameter according to the at least one stored or accessed relationship defining a relationship between the first node and the second node;
Determining at least one set of the at least one compensation rule for the at least one compatibility parameter according to the at least one attribute stored or accessed according to the first data node and the second data node; When,
A method characterized by comprising: The method of claim 10 , comprising:
The method further data to be used for processing of the second data element, comprising the step of extracting from the local information storage system,
The step of processing the data further comprises:
Generating a query for the local information storage system generated in accordance with at least one relationship of the at least one compatibility parameter to extract the exchanged data from data associated with the first data element; ,
Processing the exchanged data received in response to the query according to the at least one compensation rule to compensate the exchanged data;
For processing that by the execution engine of the executable guideline decision support system, the sub-steps of updating the data relating to the second data element by said compensated data,
Having
A method characterized by that. The method of claim 10 , comprising:
The method further comprises the step of updating the data stored by the local information storage system by the data the exchange,
The step of processing the data further comprises:
Processing the exchanged data according to the at least one compensation rule to compensate the exchanged data;
Generating an update request in accordance with at least one relationship of the at least one compatibility parameter to update the first data element with the compensated exchanged data;
Sending the update request to the local information storage system;
Having
A method characterized by that.

Images