COMPUTING SYSTEM PROVIDING BLOCKCHAIN-FACILITATED SEMANTIC INTEROPERABILITY BETWEEN MULTIPLE DISPARATE SYSTEMS OF RECORD (SORs) AND RELATED METHODS

Abstract

A system for propagating a set of identity state changes for a shared identity may include a plurality of Systems of Record (SORs) and a management server configured to collaborate with the plurality of SORs, detect individual Create-Retrieve-Update-Delete (CRUD) operations on a specific SOR associated with at least one shared identity to generate a set of identity state changes corresponding to the current state of at least one shared identity; transact the set of identity changes, along with associated metadata, into a distributed immutable long-term storage as a current transaction; propagate the set of identity state changes and associated metadata to replicate the current state of the at least one shared identity based on the current transaction for at least one domain cache instance; and synchronize the current state of the at least one shared identity across the plurality of SORs from the at least one domain cache instance.

Description

Technology Field

[0001] The present invention relates to the field of Distributed Transactional Database Management Systems (DBMS) and Service-Oriented Architectures (SOA), and more specifically, to "semantic interoperability" between heterogeneous database systems in minimal relevant business domains. Background Technology

[0002] Enterprise Application Integration (EAI) technologies for ordinary data sharing within a specific IT topology of a business or organization typically include Message-Oriented Middleware (MOM) systems that provide network transparency regarding the explicit publication and subscription to message streams generated from known data sources, which typically require all subscribers to be informed in advance of Application Programming Interface (API) calls and enterprise data mappings. While such network transparency is advantageous in contexts where changes in physical topology are designed not to interrupt long-running client-server operations, it is completely impractical beyond the scope of any single IT network and, specifically, where strict requirements for "semantic interoperability" necessitate the sharing of protected information across legal boundaries, it is inevitably completely opaque to the IT topology of external stakeholder systems (related to a specific System of Record (SOR) running on a specific IT network of a single legal entity or organization).

[0003] Significantly, this is also true on specific IT networks of any mid-sized enterprise, where local entity domain data is distributed across heterogeneous internal SORs, and the data models of these SORs—and in some cases, their core semantic abstractions—are not strictly identical, even if aligned with the usual business domain in some business-critical functions. For example, insurance companies across various industries maintain information on the same pool of contracted service providers across numerous internal databases, including commercial contracts and even government-mandated programs supported by the insurer. These are typically used to maintain contract-specific provider registers, and in the case of government-supported insurance programs, are subject to government audits, but this is merely an example.

[0004] As another example, consider a financial services company that holds customer information across multiple systems. One database application may be strictly applied to customer agreements and billing matters, whereas another application may associate specific products with the customer and their associated financial status. Yet another system may record details about the customer from various meetings to determine their suitability for various investment and insurance recommendations, a requirement mandated by law in some regions. The point is that all three systems are "aware" of each customer, but they are designed for various aspects of the relationship between the customer and the financial services company. To review a specific customer comprehensively, it is necessary to aggregate data from these systems for reporting and Business Intelligence (BI) purposes. Certain changes, such as a change in a customer's address or surname, need to be propagated to each system, provided they involve the same data elements that are affected. This is typically done through manual data entry or ad-hoc batch processing; neither is a real-time operation, and both are prone to errors. For this reason, information from one system cannot be synchronized with another system, which may negatively impact the business logic of one or all of the systems.

[0005] Therefore, structural interoperability—and even the generally defined "semantic interoperability" (see below)—has been found to be difficult to grasp, even in enterprises where semantic misalignment of systems is not a major impediment to meaningful data sharing. In such enterprises, there is generally a lack of operational infrastructure that impacts real-time data synchronization. Advantageously, the current approach holds value even in the absence of external requests for entity information sharing across organizational boundaries.

[0006] While specific industries have undertaken numerous formal standard works to address the mapping and coding aspects of interoperability issues more restrictively (e.g., consider HL7 FHIR: https: / / www.hl7.org / fhir / ), the approach disclosed herein provides market-specific embodiments of a set of scalable software systems based on general methods and new architectures to reconcile conflicting information by leveraging these mappings for the identification of discrepancies across participating systems requiring the synchronization of known truths and automated or semi-manual workflows. In a world characterized by multiple "sources of truth" that are not synchronized with each other at any point and are guaranteed not to be substantially synchronized with reality, it is important to resolve data reconciliation problems without raw data exchange according to the concept of "interoperability," where "communicating" systems may potentially do more harm than good by violating the truthfulness of some participating SORs with information less accurate than the information prior to the data exchange. This is an interoperability issue, and the approach disclosed herein provides tools to address it directly.

[0007] For the purposes of this invention, the definition of “interoperability” is generally provided by the Association of Medical Information and Management Systems (or HIMSS) (see https: / / www.himss.org / library / interoperability-standards / what-is-interoperability), which divides the concept into three progressive categories: foundation, structure, and semantics. Semantic interoperability is built upon structure, which consequently builds upon the foundational interoperability layer, and presupposes two or more systems for “information exchange and use of exchanged information.” Furthermore: “Semantic interoperability enables a receiving information technology system to interpret data by utilizing both the structuring of data exchange and the coding of data including vocabulary.” This implies that the very nature of the received information, for the reasons disclosed herein, gives rise to feasible behavior—namely, requirements for which existing database information models are fundamentally unsuitable. means of solving the problem

[0008] A system for propagating a set of identity state changes for a shared identity may include a plurality of Systems of Record (SORs) and a management server configured to collaborate with the plurality of SORs, detect individual Create-Retrieve-Update-Delete (CRUD) operations on a specific SOR associated with at least one shared identity to generate a set of identity state changes corresponding to the current state of at least one shared identity; transact the set of identity changes, along with associated metadata, to a distributed immutable long-term storage as a current transaction; propagate the set of identity state changes and associated metadata to replicate the current state of the at least one shared identity based on the current transaction for at least one domain cache instance; and synchronize the current state of the at least one shared identity across the plurality of SORs from the at least one domain cache instance.

[0009] More specifically, the management server may be further configured to align branch data points in collaboration with the plurality of SORs to prevent the replication of the current state of the at least one shared identity. For example, the metadata may include a command to repeatedly regenerate the current state of the at least one shared identity based on the current transaction time. The identity state change set may correspond, for example, to graph-based information for the at least one shared identity.

[0010] In an exemplary embodiment, the management server may be configured to detect discrete CRUD operations based on a SOR adapter service process that collaborates with the specific SOR and performs operations independently of the specific SOR. More specifically, in an exemplary implementation, the SOR adapter service does not modify the operation semantics or core data requirements associated with the specific SOR.

[0011] Furthermore, the management server may be configured to collaborate with the plurality of SORs to transact the identity change state using a dedicated distributed transactor service process. Additionally, the distributed transactor service process may be further configured to generate a master identity index containing at least one shared identity to be copied across the plurality of SORs.

[0012] In one exemplary embodiment, the at least one domain cache instance may represent a single truth source comprising a subset of known identities associated with the plurality of SORs. Furthermore, the management server may be further configured to collaborate with the plurality of SORs to synchronize the state of the at least one shared identity through a synchronization service process. For example, the management server may be configured to collaborate with the specific SOR to store an immutability log in a long-term storage along with a transaction history for the at least one shared identity verified using a blockchain algorithm.

[0013] A related management server as briefly described above is also provided with a related method for propagating an identity state change set for a shared identity. The method may include the step of operating a management server that collaborates with multiple SORs: detecting individual CRUD operations on a specific SOR associated with at least one shared identity to generate an identity state change set corresponding to the current state of at least one shared identity; transacting the identity change set, along with associated metadata, to a distributed immutable long-term storage as a current transaction; propagating the identity state change set and associated metadata to replicate the current state of at least one shared identity based on the current transaction for at least one domain cache instance; and synchronizing the current state of at least one shared identity across the multiple SORs from the at least one domain cache instance. Brief explanation of the drawing

[0014] FIG. 1 is a schematic block diagram of a system for providing interoperability between heterogeneous recording systems (SORs) according to an exemplary embodiment. Figure 2 is a schematic diagram illustrating exemplary SORs that can be used with the system of Figure 1. FIG. 3 is a schematic block diagram of a detailed structure of an exemplary "whole stack" approach to the system of FIG. 1 according to an exemplary embodiment. Figure 4a is a schematic block diagram of an exemplary implementation of the big data layer of Figure 3. FIG. 4b is a schematic block diagram of an exemplary implementation of the big data layer of FIG. 3 in more detail, specifically illustrating the interaction of the blockchain storage. FIG. 4c is a schematic block diagram of an exemplary process in which a domain event according to an exemplary embodiment is recovered in real-time or on request after being transacted into a long-term storage to generate a time series of identity states managed in a distributed domain cache. FIG. 4d is a schematic block diagram providing a conceptual diagram of a method in which data can be linked across multiple domains without violating the meaning of data flow according to an exemplary embodiment. FIG. 5 is a schematic block diagram of a synchronizer interacting across the interaction service, enterprise data, and Service-Oriented Architectures (SOA) layers of FIG. 3 according to an exemplary embodiment. FIG. 6 is a schematic block diagram showing the business logic layer of FIG. 3 in more detail according to an exemplary embodiment. FIG. 7 is a schematic block diagram showing the application logic layer of FIG. 3 in more detail according to an exemplary embodiment. FIG. 8 is a Venn diagram showing a conceptual framework for a three-step workflow strategy related to the system and method described herein according to exemplary embodiments. FIG. 9 is a flowchart showing an exemplary propagation method mode according to an exemplary embodiment. FIG. 10 is a conceptual block diagram showing the User Experience (UX) layer of FIG. 3 in more detail according to an exemplary embodiment. FIG. 11 is a flowchart further illustrating the data flow illustrated in FIG. 10 according to an exemplary embodiment. Specific details for implementing the invention

[0015] As mentioned above, this relates to the fields of Distributed Transactional Database Management Systems (DBMS) and Service-Oriented Architectures (SOA). More specifically, it relates to the transparent, secure, and systematic exchange of semantically related domain entity events and domain entity state changes across heterogeneous IT (Information Technology) systems, networks, and organizational boundaries in near or "soft" real-time, sufficient to realize a practical and large-scale implementation of "semantic interoperability" between heterogeneous databases in minimally related business domains. The approach described herein provides a platform for distributed and coordinated data flow and represents an effective alternative to existing push-full API-based strategies for data exchange, which are impractical for large-scale use and cannot provide "semantic interoperability" according to the current definition.

[0016] In addition to the background mentioned above, therefore, in service-oriented domains such as healthcare and finance, there is a practical need for a generalized approach to the extensive sharing of semantically rich domain information about the general enterprise among heterogeneous Systems of Record (SORs), for example, within and across institutional boundaries. The approach described herein favorably addresses this operational need in a manner better suited to the ambitious goal of "semantic interoperability" compared to systems of the prior art.

[0017] The present invention comprises, but is not limited to: (1) an information model uniquely suitable for “soft” real-time synchronization of large-scale immutable fact-based data storage; (2) a practical architecture implementation strategy for a secure, low-trust, peer-to-peer (P2P) network federation of said data utilizing blockchain technology; (3) a software system for generalized domain event replication and entity state recovery and synchronization; (4) a robust and scalable hardware and middleware platform for “semantic interoperability” between two or more SORs across one or more heterogeneous IT networks in any business domain; and (5) a method for identifying and coordinating conflicting information across stakeholder systems and a three-step software-based workflow driving process.

[0018] In an exemplary embodiment, each IT network participating in the data federation strategy of the disclosed embodiment is a fully autonomous entity (part of a larger whole or completely independent) and internally has two or more heterogeneous computer database management SORs as needed for real-time and / or on-demand synchronization of domain-related information.

[0019] In addition to supporting data exchange in domains such as healthcare and finance, the architectural interoperability strategies described herein have significant implications for various consumer-centric industries, among other potential applications, including legacy data modernization and migration, IT asset integration following corporate mergers and acquisitions, and government regulation and auditing characterized by the need for legal entities (e.g., service providers) to exchange protected domain information regarding consumers or customers (e.g., service beneficiaries) in a secure and timely manner. For example, this approach can be applied to the exchange of medical information that must comply with strict federal privacy and data security requirements.

[0020] Furthermore, the approach described herein is also applicable to the general implementation of management, and one or more professional service providers working as professional practitioners for one or more service agencies in service-oriented industries must share sensitive information regarding common services for beneficiaries across heterogeneous IT networks between relevant entities in accordance with the law (or for the benefit of consumers).

[0021] Referring to FIG. 1, a system (30) and an associated method modality for the domain-agnostic, non-interference detection and systematic propagation of granular state changes of semantically rich, graph-based information regarding shared identities across IT SORs (31a-31n) in near or soft real-time are first described. In the illustrated example, one or more management servers (32) (e.g., may be implemented as part of a cloud computing cluster or distributed servers) collaborate with the SORs (31a-31n) to execute a five-branch strategy. The first branch includes the detection of individual Create-Retrieve-Update-Delete (CRUD) operations on SORs associated with one or more shared identities by a SOR adapter service process that independently computes exemplary SORs (31a-31n) under management. The second branch involves the transaction of identity state change sets from a long-term store to a distributed, immutable log by a dedicated distributed trader service process. The identity state change data set is annotated with sufficient metadata for each individual transaction change set to regenerate the current state of each associated identity at each transaction point in a repeatable and reliable manner.

[0022] A third branch replicates the “current state” of one or more domain cache instances based on the most recent or current transaction T, including the propagation of changes or updates to the shared identity affected based on transaction state T-1 (e.g., previous transaction state), by a change notification system. Each domain cache instance represents a single source of truth containing a useful subset of known identities associated with one or more SORs (31a-31n) under its scope. A fourth branch involves the synchronization of the new state across the stakeholder SORs (31a-31n) under a specific domain scope by a synchronization service process, including the SOR that was the source of the change. Additionally, the fifth branch includes the alignment of branch data points by the same SOR adapter process to prevent the SORs under management (31a-31n) from representing the “current state,” which must ultimately be consistent across all SORs that have an interest in the state of the related shared identity based on transaction T.

[0023] More specifically, the SOR adapter service advantageously provides non-interference change detection and propagation specific to the database technology of each SOR (31a-31n), that is, without modifying the operational semantics or core data requirements under management. That is, the SORs under management (31a-31b) not only do not “recognize” the specific data model or exchange format that can be used as part of the initiated change data propagation and data federation scheme, but also do not change how they are executed concurrently or how legacy “customer” systems interact with them as part of normal daily operations—that is, even the fact that they are participating in external data exchange is opaque by design to each managed SOR.

[0024] The SOR adapter service can also provide a queryable and time-correlated linked data view of the information contained in a specific SOR (31a-31n) and can be used independently regardless of whether the SOR under management was designed with linked data technology in mind. Furthermore, the trader process can be optionally distributed, in which case essentially different IT networks (effectively, of both different agencies) can participate in an initiated change propagation and data federation scheme as if the SORs of both agencies were on the same network. Additionally, this can be performed without leakage of agency-owned operations, and only universally relevant identity states are shared, which are the focus of semantic data interoperability.

[0025] Additionally, the trader process can provide a master identity index that is advantageously replicated across agency boundaries. This allows each participant in an initiated change propagation and data federation scheme to discover all identities of managed SORs determined to refer to the same real person, thing, location, or event over time, and to link them through business logic, reasoning, or other locally developed mechanisms, thereby enabling knowledge of the links—along with related new information and any factual conflicts that may arise from these links—to be shared in near real-time. In an exemplary configuration, distributed traders annotate and tag each replicated change set with comprehensive transaction metadata that includes, but is not limited to, the source, the change agency, and downstream data reconciliation and data cleanup workflows, as well as other important contextual information about the affected identities suitable for the ultimate goal of point-in-time recovery of each identity state.

[0026] Each institution participating in the initiated change propagation and data federation scheme maintains its own full copy of a long-term physical repository containing the transaction history for all shared identities, verified using blockchain technology or algorithms that encode each transaction and guarantee the integrity of the transaction order and content at each transaction point. Optionally, this may also be backed by other storage mechanisms depending on the preference of the IT department of each participant responsible for its management. In other words, this approach advantageously does not require participating institutions to adhere to the same long-term storage technology to ensure certainty regarding the accuracy and completeness of the data stored in these copies.

[0027] In an exemplary embodiment, a subset of data from each copy of the physical storage may be used to recover the state of one or more identities affected by transactions in the long-term storage of the in-memory domain cache at a specific point in time or over time, for the purpose of computing as a "single truth source" for downstream SOR alignment. Furthermore, a specific domain cache instance may be configured based on elastic time and identity parameters scoped to the requirements of one or more SORs (31a-31n) of a specific business line or subdomain. This advantageously allows configuration between or within various organizational environments. Additionally, a specific domain cache instance may be configured with user axioms, rules, and processing logic as well as standards, so that real-world constraints related to SOR (31a-31n) data integrity can be applied without loss of informational representation in the open-world model of the connected data.

[0028] The synchronization service may further propagate updates from a specific domain cache instance to one or more SORs adapters, or, when a new state violates business rules and indicates a serious discrepancy between one or more SORs (31a-31n) requiring human intervention, or otherwise fails to process for unknown reasons, it may instead generate a data reconciliation workflow. This helps prevent potentially inaccurate data from compromising otherwise accurate SORs (31a-31n). Workflows for handling data inconsistencies and violations of business logic may be handled in a semi-manual manner, and their precise rules may be defined, for example, by each organization participating in the propagation and data federation scheme initiated to address the urgency of local businesses and organizations.

[0029] The system (30) also provides an information model comprising linked data for one or more subjects representing one or more uniquely identifiable identities in a specific domain, based on non-exclusive concepts of who, when, where, and what. The model may further include one or more predicates forming mapped data elements and attributes of each shared identity, one or more predicate values ​​representing subject attributes at the time of distributed transactions, and metadata for each transaction. The metadata may include graphs representing the source, origin, and set of data changes, along with time details (taking into account time zones, location / culture, etc.), as well as other user-defined information that further captures the context in which the information change was detected. The information model may further include a trust flag based on factual claims, depending on whether a specific identity has been added to the knowledge base (i.e., claimed as true) or withdrawn (i.e., claimed as false). In an exemplary embodiment, a standard Subject-Predicate-Object (SPO) or EntityAttribute-Value (EAV) graph can be further enhanced with a strong concept of state change over time and can be transacted using blockchain technology that supports replicable long-term storage with strong guarantees for integrity against temporary tampering.

[0030] It should be noted that the aforementioned distributed computer system (30) may be implemented using one or more physical computers or virtual machines / containers having one or more physical processors allocated across one or more logical or physical network topologies. In some cases, they may be implemented with firewalls to prevent most forms of inter-process communication between them, except where explicitly permitted for the purpose of participating in a change propagation and data scheme facilitated by a management server (32). Software components of the initiated change propagation and data federation scheme implemented within the system (30) may be extended vertically and horizontally in response to real-time network traffic resulting from updates to SORs (311-31n) managed in a specific domain. These software components may be implemented as non-transitory computer-readable media containing computer-executable instructions that cause various computing devices to perform the operations discussed herein.

[0031] More specifically, at least some software components may be integrated into each participating IT network. Each network component may run separately, in some cases, in a redundant or "back-up" process (and each utilizes one or more CPU, GPU, or QPU processors to facilitate real-time change propagation and data integration across one or more heterogeneous networks).The software components may include one or more of the following: an authentication / authorization microservice; a message dispatch microservice used to recognize components of the live system and also to facilitate system-wide service discovery; one or more instances of SOR adapter microservices, each of which may be configured to participate in a domain; an optionally distributed domain transaction microservice that captures change events reported by the associated SOR adapter, annotates them as transaction metadata, and maintains one or more identical copies of all transactions locally; a master identity index microservice responsible for supporting identity verification; a long-term storage microservice responsible for maintaining local copies of transaction events; one or more domain cache microservices representing the hourly state of identities scoped to one or more local SORs in a specific subdomain; and a synchronization microservice that updates adapters for SORs in a specific domain to align them with the "single truth source" provided by the local domain cache instance. Coordination workflow services and related data for tracking semi-manual, human-led resolution of discrepancies according to a three-stage coordination process (prepare-contact-close); and scenario-specific documentation microservices that provide a modality-agnostic interface to human resources at the time of service in the form of one or more user experience microservices, each specializing in a specific method of data input preferred by individual users.

[0032] The foregoing will be further understood with reference to FIG. 2, which illustrates an exemplary embodiment at the upper level in the context of two participating IT networks. Reference numeral (100-1) represents IT organization (A), and (100-2) represents IT organization (B). Both are assumed to be exemplary execution management domains, first keeping internal SORs in a synchronized state in the 420 series, and then exchanging information regarding a common entity (i.e., consumer, supplier, or customer), regardless of which of them detects a change in the entity state first. The motive for this data exchange is assumed to be some combination of SOR alignment resulting from corporate interests, external regulatory requirements (e.g., in the medical field), and / or shared customer interests (as in broadly defined financial planning or various medical-related practices) and / or corporate acquisitions or mergers. The exact characteristics of the motive (or practice) are not important, but it is sufficient for the motive to be a simple entity that generates a requirement uniquely satisfied by the disclosed embodiment.

[0033] Items (400), (500), (600), and (800) represent an enterprise architecture "stack" for a large enterprise as defined in most media. Items (200) and (300) represent a new layer provided according to this example. Items (900-914) are used in all applicable drawings representing data flows over various standard network protocols in multi-domain data formats according to exemplary embodiments of the present invention.

[0034] Different software components can operate at different layers of the architecture stack as individual, independent, in-memory computer processes communicating with each other over various standard network protocols of specific domain formats. This, by design, minimizes coupling and allows for standalone use to promote high availability and upstream system maintenance while minimizing downstream disruptions, or otherwise allows each component to focus on a single architecture function or mission.

[0035] Therefore, advantageously, the entire stack can run on a single machine or scale across millions of machines. Accordingly, exemplary commercial implementations range from the consumer desktop database market to large, distributed enterprises. These embodiments share common characteristics as further discussed herein. Additionally, further commercial embodiments may be implemented using the architecture and methods described herein.

[0036] Referring to FIG. 2, the order of the layers from top to bottom is very important. The top layer (200) represents "big data," which was mostly an industrial phenomenon rather than a standardized architecture layer. Here, the concept is standardized into a separate architecture layer centered on a new information model using blockchain, and a vast amount of domain definition information is stored in (210) as referenced in FIG. 3.

[0037] Item (210-1) indicates a copy of the corresponding data of IT institution A, and 210-2 indicates a copy of the corresponding data of IT institution B. Both maintain full copies in case of downtime or disconnection for a certain period. Blockchain technology is utilized to enable both IT institutions to recover from any service interruption and to ensure that both parties are backing up each other's data. Although FIG. 2 illustrates only two IT institutions for conceptual clarity, the more IT institutions participating in the data sharing system, the less centralized and more robust the network becomes overall. "N" IT institutions may be shown in FIG. 2 and supported in a similar manner.

[0038] Exemplary components in layer (200) ("Big Data") include a blockchain storage and a distribution domain cache, exemplarily denoted as (210) and (240), respectively. These are discussed further below with reference to FIGS. 3 and FIGS. 4a-C.

[0039] The components of the layer (300) ("Interop Service") include, for example, a set of distributed database traders (310) and dedicated change monitoring services (320), one for each SOR under management (Fig. 2 has simplified this to a single logical change monitoring service component for clarity). In (320), the service monitors and reports new information introduced to each SOR to the distributed traders (310) for long-term storage processing and updates the distributed domain cache (210). This is discussed further below with reference to Figs. 3 and 5.

[0040] The hierarchy (400) ("Enterprise Data") includes, for example, an entity synchronization database (410) introduced to correct discrepancies in automated and semi-manual workflows. Components labeled as the 420 series in both organizations represent existing SORs to be managed. The system maintains these heterogeneous SORs in an accurate, up-to-date, and synchronized state with respect to common entity data through an advantageously shared source of truth (i.e., a distributed domain cache in (240)). This is discussed further below with reference to FIG. 3.

[0041] The layer (500) ("Enterprise Service Oriented Architecture (SOA)") includes, by example, a local synchronization service (510) and an associated web service (see the 520 series in FIG. 3) that manages the introduction of external novelty to managed SORs. This is discussed further below with reference to FIG. 3 and FIG. 7.

[0042] Layer (600) ("business logic") exemplarily includes a coordination workflow management service (610) that implements a three-stage mismatch coordination process. This is discussed further below with reference to FIGS. 3 and FIGS. 6. FIG. 8 details the conceptual basis for the three-stage workflow process implemented by (610).

[0043] Layer (700) ("Application Logic") exemplarily includes a coordination documentation service (710) that manages a three-step process for an instance of a specific workflow being actively worked on by an end user in Layer (800). This is discussed further below with reference to FIGS. 3 and FIGS. 7.

[0044] Layer (800) (also known as “User Experience” or “Presentation Layer”) includes, by example, a dedicated scenario-specific workflow UX interface (810). Additionally, further details regarding alternatives in this layer are provided with reference to FIG. 3. The method of providing a scenario-specific user experience with service support in these components and (710) and (610) is described in more detail in FIG. 10. The data flow illustrated in (900) is described in more detail in FIG. 11 as a flowchart centering on the concept of detecting and propagating novelty overall.

[0045] The structure of information stored in the blockchain, further described with reference to FIGS. 4b and 4c, enables the simultaneous maintenance of a large-scale, distributed read-only cache of domain-related entity information. This represents a "source of truth" for both IT organizations, or more precisely, a "single source of truth" for each organization. The definition of "related" is associated with a unique domain identity that exists in an external organization but engages in commercial interactions with one or both. FIG. 4b is a schematic block diagram of an exemplary implementation of the layer (200) ("big data") of FIG. 3 in more detail, specifically illustrating the interactions of the blockchain storage (220). FIG. 4c is a schematic block diagram of an exemplary process, also referred to as entity "description" in the distributed domain cache, in which domain events are transacted into the long-term storage and then recovered in real-time or upon request to generate a time series of identity states. This advantageously allows for insight into the current state of the managed identity and, potentially much more importantly, how it came to be in that state over time.

[0046] For example, let us consider patients at two separate hospitals or clinics. In this example, the domain cache (210-1) of IT institution (A) (100-1) includes all patients seeking medical services at institution (A), managed by the master identity index (or MII) of institution (A). The domain cache (210-1) of IT institution (B) (100-2) includes all patients seeking medical services at institution (B), managed by the MII of institution (B). Some patients receive medical services at both institutions, and IT institution (A) (100-1) and IT institution (B) (100-2) do not lack up-to-date information on the patients using the medical services of both institutions, which is advantageous to both institutions (A) and (B) and their patients. This will be discussed further in the detailed discussion of FIG. 8.

[0047] Advantageously, all records to the blockchain storage (225) (see FIG. 4b) and reads from the distributed domain cache (240) (see FIG. 3 and FIG. 4a) are kept strictly separated by design so that they can all be extended independently, ensuring the operational integrity of immutable data and fact occurrences in (220), which is important to the single writer meaning of the trader (310). This approach is known in the art as "Command-Query Responsibility Separation" (CORS), but the disclosed approach advantageously extends this concept by implementing a distributed single-writer trader in (310).

[0048] A single-writer system provides strong guarantees for atomicity, consistency, isolation, and durability (also known to those skilled in the art as the ACID (Atomicity, Consistency, Isolation, and Durability) properties that may be attributed to transaction database systems). A distributed single-writer system, such as in the embodiment of (320), also helps ensure redundancy, which is why it is commonly used in blockchain solutions where each node of the blockchain network obtains a completely immutable (append-only) copy of the data shared on the blockchain. This approach implements records so that all stakeholder systems that are part of the data sharing scheme of this embodiment receive new domain information in the order it comes in; however, reads are locally scoped to identities associated with a given stakeholder IT organization. This is not implemented merely to improve performance, but as a practical strategy for handling vast amounts of information on the shared blockchain, that is, strictly speaking, not related to the local systems of a specific IT organization.

[0049] Additionally, referring to FIG. 3, this is a schematic block diagram of a detailed structure of an exemplary “full stack” approach to the system of FIG. 1 according to an exemplary embodiment. In (250), both the storage (225) and the caching (240) are also designed to be elastic, meaning they expand (or contract) to meet requests. Many IT organizations already utilize elasticity as a feature of Infrastructure-as-a-Service (IaaS), also known as “Cloud,” but these usage characteristics typically involve the use of related data mining and business intelligence applications. Data mining itself is not the primary focus of “Big Data” for the purposes of the present invention, but rather the raw storage of a live domain cache and its reduction to downstream entities strictly related to the system of a specific organization. Nevertheless, as a discipline, much “data mining” attempts to reverse engineer the range of lost information that the storage facility of (210) will never lose, in contrast to the current relational information model, so the currently popular business intelligence and other “big data” computationally intensive uses can benefit from the detailed and realistic nature of the information model implemented in (210).

[0050] Considering the data flow as illustrated in the 900 series of Fig. 2 at a higher level, it is sufficient to point out that new information is introduced to each SOR through normal business processes in the 400 enterprise data layer, as will be explained in more detail below. This is processed in the long-term blockchain storage in (210) (i.e., for both institutions, after each trader references the master identity index, transactions are performed simultaneously in (210-1) and (210-2) through the transaction consensus phase (906), so the actual storage of both institutions in (907) is a side effect as illustrated in more detail in Fig. 4c). If the transaction affects an entity of interest for (100-1) or (100-2), the distributed domain cache of the affected institution is updated with the new information, and the synchronization process for non-disclosing SORs (i.e., SORs across all participating IT institutions that were not parties to the source of novelty but whose data is related thereto) occurs in (910-912). (911) may include manual adjustment of specific discrepancies found during the synchronization process below (510) as required by the business logic specific to the institution (and illustrated in FIG. 10). This may consequently allow for the acquisition of new information submitted to the trader through (905) initiated from (510). Eventually, in (914), for audit, diagnostic, and forensic / root cause purposes, the alignment of new information and non-SORs sources may be locally recorded in (210).

[0051] FIG. 3 provides a detail of FIG. 2 along with an exemplary commercial embodiment of the layered components described in more detail, focusing on a single IT organization across the architecture stack enhanced by the invention. In FIG. 3, the component (210) for any specific set of domain facts stored in (225) ("block journal") consists of the present embodiment of the following three sub-components ("Forever DB"): a raw elastic storage (220) containing a plurality of interrelated "block" journals (225) of all known domain facts and events stored in a blockchain; an identity coordination service, also known as a Master Identity Index ("MII"), which is a hypergraph of interrelated domain-defined identities and their various local and global identifiers used to find specific locally related SORs and generally related data in identity correlations; and an identity distributed domain cache (240) representing the state of all actively managed identities (i.e., locally scoped) associated with the IT organization at any specific transaction point in time, as shown in FIG. 3.

[0052] Referring to FIG. 3, since the recording of the content or raw data of each “block” of the elastic storage is isomorphic across all embodiments and is easily implemented on almost any physical storage as illustrated in the process described in FIG. 4c, potential embodiments of the raw elastic storage component (220) can utilize various existing standard commercial or open source SQL or NoSQL databases (such as graph, document, or hybrid graph-document databases) or other secure data or file storage systems acceptable to the domain regardless of the domain scheme. The embodiments treat the selection of physical storage for a specific domain as an orthogonal problem explicitly made by the configuration of the storage adapter rather than being hardcoded. Advantageously, this design decision allows the IT organization (100-X) to utilize existing investments in various storage facilities that have already been proven for security and other enterprise requirements. Despite embodiments having loaded or defaulted data storage options, different IT organizations participating in the data federation scheme of this embodiment can make various raw storage decisions without affecting operational semantics.

[0053] Although the amount of data considered for storage in "ForeverDB" and other potential embodiments of (210) is enormous, the concept of a distributed data domain cache (240) is to hold a much smaller subset of data related to identities that is actually used or actively stored in SORs at the (420) stage of a specific IT organization in (225). Thus, embodiments of (210) include a distributed architecture, which is illustrated in one of the several potential embodiments of FIG. 4a.

[0054] According to various embodiments, attention should be paid to the component (210) of the big data layer (200) of FIG. 3, in which, at every specific transaction point, a specific function in the data flow (980 and 909) transforms the world of all knowledge of the domain (220) into a manageable subset of all knowledge scoped by (30). This locally relevant snapshot of the domain represents an integrated "truth source" regarding the data alignment of each internal SOR (420-X) at any point in time being synchronized by the downstream component in the data flow (910-914).

[0055] Various embodiments of the master identity index (230) and distributed domain cache (240) are possible, but generally speaking, they can be implemented as a hypergraph of a fact-oriented graph representing a snapshot of the state describing in detail all identities that can be correlated according to their characteristics in the "real world": that is, who, what, when, and / or how.

[0056] The approach described herein advantageously formulates this concept into a core ontology. At any given point in time, some identities may be of more than one type, which makes it difficult to represent existing entity-related diagrams of a relational database management system (RDBMS) without reclassifying complex joins, which exponentially worsens the performance of large, rapidly growing datasets. Advantageously, the additional, clearly factual, and time-savvy nature of the information model used in the exemplary embodiment and the rotating unique snapshot of the identity state at a given point in time, derived from operationalization in various embodiments of (220), enable computerized inference about the method and reason for changes over time. Furthermore, at a given point in time, if a fundamental identity key or any correlated identifier is given to the master identity index (230), the system can return all knowledge (both factual and inferred) about the identities in the distributed domain cache (240) at that point in time in microseconds. Further details regarding the information model will be disclosed in the detailed discussion of Figures 4b and 4c.

[0057] From this perspective, it is important to note the advantageous operational implications of this interoperability strategy compared to current P2P or traditional message-oriented solutions regarding the problem of interoperability. That is, for any specific SOR (420-X), the issue of interoperability or data exchange is no longer a matter of "talking" to all other SORs (as in the conventional term for interoperability) or actively and directly communicating with other SORs. Instead, this approach allows for the operationalization of data exchange by mapping and aligning as much of the data stored in each SOR (420-X) individually as possible to a single shared source of local scope main truth (240). This is accomplished by using a web service (520) (in the case of introducing new information, i.e., "truth alignment") and a change monitoring service (320) (in the case of detecting new information). In this approach, data exchange with all other SORs has become a completely orthogonal problem performed in a systematic and carefully reasoned process by the black box architecture components, the interoperability service layer (300) and the big data layer (200). In other words, this makes data interoperability a proper orthogonal aspect of the enterprise architecture rather than an explicit problem for each and every deployed application.

[0058] Exemplary examples of change monitoring components (320a-d) can be seen in layer (300) ("Interoperability Service"). These are tasked with detecting new information in the managed SOR of each instance. That is, (320a) is dedicated to detecting changes in (420a), (320B), and (420b), etc. Additionally, there is an exemplary example of a distributed trader (310) in layer (300) of FIG. 3. As demonstrated by these detailed steps, the distributed trader component (310) must interact with the master identity index (230) and the sub-components of the raw storage (200) of (210) to transact new information into the long-term storage. This has the desirable side effect of updating one or more enterprise-scoped domain caches (240) after each transaction. Some embodiments may also provide a new method through user extension points to define and implement domain definition logic for identity verification when a new entity added to an enterprise of one SOR may be the same identity as one already existing in other SORs, in which case the identity is linked in (230) as part of step (906). In some embodiments, this may also be configured to interact in the data flow (905) during a transaction with another instance of itself deployed in an external IT organization, as illustrated in FIG. 2. This aspect of the exemplary embodiment of (310) effectively makes it a distributed single-recorder system.

[0059] Now turning our attention to the hierarchy (400) ("Enterprise Data"), we can see that the component at the upper level is the synchronization database (410). This does not necessarily have to be an n-tier database, but for the purposes of FIG. 3, this is the one most relevant to the meaning of the system as a whole and is discussed here. In an exemplary embodiment, the function of the synchronization database (410) is to list the propagation of changes in the 420 series or the "new truths" regarding the IT organization's SORs. This includes not only synchronization requiring manual workflows but also automated synchronization. (410) stores the history of both automated updates and long-lived workflow sessions, including data coordination of coordination workflow services ("team collaboration" in an exemplary embodiment) (610) that cannot be automatically propagated through the synchronization service (510) ("synchronization service" in a preferred embodiment) due to reasons related to the IT organization's business logic or policy.

[0060] In relation to the layer (500) ("Enterprise SOA"), when the data flow (910) indicates the need to propagate a new entity state from (240) to the 520 series SORs, the synchronization service (510) is responsible for ensuring that only the information coordinated in the data flow (911) is propagated to the SORs through the 520 series microservice components. The new entity state can be coordinated in (610) without violating business constraints, and the data flow (912-914) then updates all SORs that were not the source or origin of the change detected by the corresponding 320-stage component.

[0061] Advantageously, if the transaction includes entities associated with each IT organization that propagate new information transmitted by the most recent transaction, and only in such cases, this synchronization occurs simultaneously in all IT organizations participating in the data sharing scheme for a specific domain in (220) based on the most recent transaction context implied by FIG. 3. If the new state is not propagated until the three-step coordination workflow process realized in 911b-g is completed, the local flow (912-913) is suspended while waiting for such completion. If the coordination generates new knowledge that has not yet been propagated to (240), the new knowledge will be submitted directly to the BlockSync transaction (310) of the data flow (905) by (510) in the data flow (905) (indicated without a subscript indicating a specific management SOR because (510) is considered part of the final SOR (240). Whether to partially apply the original state change or to suspend it until new information creates a new propagation data flow (910) depends largely on the domain-specific logic of the workflow defined in (610) and stored in (410) for the synchronization event initiated in the data flow (910). In an exemplary embodiment, all new information is transmitted to the SOR in the 420 series that does not contradict the entity state recorded in (240). Additionally, if a transaction of new knowledge is completed in (907) and updated in (240) in the data flows (906-909), and only in such cases, any state representing the new information compared with (240) based on the most recent transaction context is transmitted to the distributed trader (310) to be processed as new knowledge via the data flow (905) to create a new "truth propagation cycle" initiated by the data flow (910).

[0062] With respect to the microservices in the 520a-d series of FIG. 3, the exemplary embodiments default to sending messages to existing web services (as illustrated in 420a-c). However, where such services do not exist (e.g., consider 420d), the present approach provides a framework for the rapid creation of such microservices, based on advice from a subject matter expert regarding the system, to facilitate the propagation of new information in a form and format suitable for the target SOR (such example, (520d)).

[0063] In the case of SOR (420d), a representation of a legacy system built according to a client-server model is identified, rather than being designed to fit a modern n-tier enterprise architecture stack. In this model, business, application, and connectivity logic are all contained within a hardcoded customer interface shown in FIG. 3 as a component (830) ("hardcoded customer"). Consequently, data flows (900d-903d) are all combined into a single existing data flow. This is a very common problem in modern architectures: while some systems implement the organization's desired architectural patterns, legacy systems do not. To introduce novelty outside the hardcoded customer interface, these microservices (520d) need to be created while implementing the embodiments of the invention.

[0064] Advantageously, this feature allows other systems, and even their replacements, to be executed until all data is aligned or until a function unique to (520d) and absent in its replacement is implemented in (610) as a user-defined workflow. In other words, rather than a “total replacement” strategy that would be highly disruptive to the organization, the exemplary embodiment allows for the gradual replacement of these legacy systems with minimal disruption to the organization’s usual and customary business processes.

[0065] Moving the subject to Layer (600) (“Business Logic”), the Coordination Workflow Service (610) (“Team Collaboration”) represents a workflow engine responsible for the systematic processing of domain-specific custom business processes as well as three-level Point-of-Service (POS) workflows employed for coordination. Data flows for workflow status “Read” operations (911b and 911c) and data flows for workflow status “Record” operations (911e and 911f) are described herein. All described SOR business logic components (620a–620c) may already exist on an IT organization’s n-layer architecture supporting the general and conventional functions of each SOR and do not need to be favorably affected by subsequent components added thereto (i.e., the non-intrusive nature of the implementation in relation to existing systems is an advantage of this approach).

[0066] Each coordination workflow session stored in the synchronization database (410) may include many reads and writes during a long-term operation session, which may eventually include multiple web sessions and multiple users collaborating for the conclusion of the coordination workflow. A simple example of this is illustrated in FIG. 10.

[0067] In an exemplary embodiment, data for each potential collaboration coordination session is stored in an invariant form and format (410) uniquely suitable for reproducing all UX interactions and state changes that generate a final confirmation document by the coordination session (and potentially from that new knowledge). Other applications of the new information model specific to this design and embodiment allow for analysis of business process quality in other dimensions, such as usability, efficiency, effectiveness, and offline evaluation, or data mining for continuous business process improvement. Although the variety and scope of analysis requirements vary significantly by domain, this approach is externally defined and can be changed without requiring alternatives to the user experience. Since requirements change based on continuous quality feedback, data mining can be performed multiple times. Advantageously, changes to these analysis requirements do not need to affect the user experience (UX) in step (800), except for improving the design of the workflow session over time. The UX does not require direct knowledge of the analysis requirements, and there is rarely a case where specific analysis capture logic must be hardcoded in the implementation. As in the case where it is consistent across the entire stack of the exemplary embodiment, these problems outside the direct region become strictly orthogonal.

[0068] In layer (700) ("Application Logic"), the coordination document service (710) (the "Documentor" of the exemplary embodiment) is described as a higher-level component that coordinates a three-step workflow for each user involved in the coordination process of a specific workflow instance. More details regarding the three-step process of resolving and documenting coordination sessions are disclosed in the detailed description of FIG. 10. The SOR application logic components (720a-720c) illustrated in FIG. 3 are existing components of an IT organization that support the routine and customary functions of each SOR implemented on the organization's n-tier enterprise architecture.

[0069] Layer (800) ("User Experience") (or simply "UX") has two embodiments of the actual user interface, one being web-based and therefore running within an existing web browser customer (820), and the other running in an exemplary embodiment (810) ("Odyssey"). The Odyssey application browser (810) provides additional features and services that support analytics capture, accessibility, and other orthogonal issues typically handled by enterprise web applications. However, there is no functional difference for the end user between the browser (810) and the (820) alternative UX implementation: the browser (810) offers better performance in maintaining many aspects of the implementation, such as accessibility and security modularity. Finally, SOR (420d), as previously mentioned, represents the legacy customer server system implemented in a hard-coded customer interface (830) for the functionality of the layer between (400) and (800).

[0070] Referring to FIG. 4a, this is a schematic block diagram of an exemplary implementation of the big data layer of FIG. 3, which is known as ForeverDB in at least one exemplary embodiment. "ForeverDB" comprises some components, in particular distributed traders (310), that are physically operated in layer (300) ("interoperability"), which are attributed to an internally distributed architecture. FIG. 4a shows that the "logical" layer of the entire stack architecture may have a multifaceted physical implementation and may be decomposed according to the same layering scheme illustrated by the entire system in FIG. 2 and FIG. 3. In this case, as with other things to come, the management functions of these components are also distributed across the desired enterprise architecture stack. FIG. 4a provides a diagram of the entire stack architecture of only step (200) ("big data") of the entire solution illustrated in FIG. 3, including its management aspects which are omitted for clarity. In an exemplary embodiment, this component is referred to as "ForeverDB"; However, this logical architecture diagram applies to other physical embodiments as well.

[0071] One point to note in Fig. 4a is that the subcomponents constituting ForeverDB itself also remain at specific layers of the architecture stack and, according to their respective purposes, align with the design of the system as a whole. Advantageously, this design allows various architecture components (of which ForeverDB is one) to be deployed as standalone, as part of an on-site implementation, or as a service in an internally managed data center (aka "cloud").

[0072] ForeverDB provides a management database (411). This database is distinct from (410) described in step (400) of FIG. 3, and its purpose is to maintain data related to workflows for specific instances of the domain cache (240) (and discussed more fully with reference to FIG. 10). In contrast, the database (411) stores data for the entire ForeverDB instance itself, such as all domains, and associated storage and domain cache facilities, user permissions, and other metadata. Advantageously, a single instance of ForeverDB provides long-term storage and domain cache services for multiple domains within an organization; each domain may have a multi-domain cache instance that serves a separate sub-organization.

[0073] ForeverDB provides a front-end web service (511) featuring a web-based API that has multiple network endpoints that allow the customer front-end to access data in (411). Endpoint types may include, but are not limited to, REST, SOAP, GraphQL, SQL, and SPARQL. The endpoints allowed for a specific instance and how they are configured are determined by the local network administrator, who is the first user of the management console.

[0074] ForeverDB management features are equipped with business logic defined in component (611), which serves as a workflow and verification layer for activities in the management console located further down the stack. Advantageously, this design allows the business logic of ForeverDB's management functions to be applied consistently regardless of customer characteristics.

[0075] Step (700) ("application logic") of FIG. 4a represents an advantageous feature of the present approach. As mentioned above, the management functions of ForeverDB can be consistently accessed by various customer front-end consoles. Since each of these has application logic specific to their operational semantics, they remain in different subcomponents; namely (711a and (711b).

[0076] In (711a), the application logic is primarily for a web-based customer (811a) in a web browser. Generally, since connections to the HTTP(s) protocol are stateless by definition, the web application manages server-side or customer-side state. Different embodiments may take one or a combination of the two approaches depending on the design of the customer frontend. Different embodiments support various strategies ranging from template-based generation of HTML per page to single-page applications, or a combination of both (where parts of HTML pages rendered via templates are loaded by the SPA). In (711b), the application logic is alternatively related to a desktop (811b) or mobile "Internet of Things" (IoT) (811c), which allows for network connection state tracking and generally communicates directly with the web server (511), and integrates the business logic module (611) into the code.

[0077] As an independent database service, ForeverDB supports all of these front-end types. Apex Domain Master, which incorporates ForeverDB as a module for consumer customers, supports only desktop and mobile IoT customers. As new forms of customer interaction and user experience emerge over time, other embodiments are possible. Advantageously, this approach is agnostic with respect to input forms and provides points of extension for adoption in new forms in all embodiments.

[0078] Referring again to Fig. 3, it will become clear that almost all major components intentionally repeat this logical design pattern up and down the architecture. Advantageously, this design consistency allows the system to be installed directly or hosted externally and deployed as bundles or separately. To avoid unnecessary repetition, and appropriately, a detailed description of the remaining components will refer to this discussion in Fig. 4a.

[0079] Now turning to FIG. 4b, this provides a diagram of another embodiment of the long-term storage aspect and component (220) of ForeverDB. The purpose of this component is to provide a durable distributed storage of the append-only history of the immutability of domain events. This is one of two components in a system using blockchain technology as part of the overall solution; the other is the "Synchronization DB" (410) of FIG. 3, which will be discussed in relation to FIG. 6 and, more specifically, FIG. 10.

[0080] Referring still to FIG. 4b, it can be seen that both the distributed trader (310) and the domain cache (240) interact with the storage agent (221), but do not interact with the master identity index (230) that has the associated identity verification service. This is an important observation, as all data stored in the long-term storage provided by (220) is guaranteed to be anonymized by design. The identity transaction map (222) is a strict internal component that associates only the alternate keys provided by the trader with the physical storage location managed by the storage agent in order to provide reliable data retrieval upon request from the transactionr (310) when constructing the next block on the blockchain of the flow (908b and 907a), or from the domain cache (240) when reconstructing the state of identity managed by the system after the next block is added to the flow (908a).

[0081] Advantageously, the built-in alternate key properties of (220) mean that the data stored in (225a-n) is completely anonymized and cannot be reconstructed without independent and authorized access to the master identity index and identity verification service (230) (of course, (310) and (240) are equipped with this). This means that as long as access to the master identity index (230) is strongly secured, it is completely safe to store the data files (225a-n) on a physical storage that is publicly accessible or otherwise could be compromised without the risk of exposure of protected information (regarding the domain where specific data needs to be protected).

[0082] As the data in (225a-n) theoretically grows "indefinitely," it is important to find a low-cost, potentially public, and resilient repository for this information in any case, and to protect everything properly stored in the domain. The clean separation between (220) and (230) ensures that the data in (225a-n) is completely meaningless to external observers and consists of a compressed set of closely interconnected keys citing unknown data. Furthermore, (230) is designed so that each instance of the ForeverDB domain generates a surrogate key using a unique cryptographic method for every identity stored in a copy of (225a-n); thus, each participating organization's copy of (225a-n) will reference a completely different alternate key at the storage layer, further frustrating potential hackers.

[0083] Another advantageous feature is a flexible journal file partitioning method that allows the domain designer to specify the range of one or more storage units (225), referred to as "domain journals" in exemplary embodiments. These are independent blockchains of data associated with one or more (or all) IDs in the domain, representing an immutable list of transaction events that update the state to IDs within the range of a given journal over time. ForeverDB and other embodiments provide the domain designer with significant flexibility to determine how to partition these chains by a single identity, a set of identities, or attributes determined by a custom ontology. Additionally, various archiving and file management policies and strategies may be facilitated by specifying a maximum size per journal file at the time of domain creation. In the case of specific journal file size limits, the system advantageously manages the seamless transition to "record" mode for a new journal file when the current file is "filled" and stored as "read-only." From the moment the journal file is archived, it is read-only; only records are added to the "current" journal file node (referred to as "225n" in FIG. 4b). One thing to note in Fig. 4a is that the subcomponents constituting ForeverDB itself also remain in specific layers of the architecture stack and, depending on their respective purposes, are consistent with the system design as a whole. Advantageously, this design allows various architecture components (of which ForeverDB is one) to be distributed independently as part of the on-site implementation or as services in an externally managed data center (also known as the "cloud").

[0084] The "blockchain" characteristics of the storage units (225a-n) are revealed in the drill-down to 225n. To be a valid blockchain, each "block" must contain the hash of the previous block data. This is done to ensure that the data in the entire sequence of transactional blocks has not been modified or tampered with in any way: this is the primary promise of the blockchain data structure. Recalculating the hash from the provided metadata is simple, and if it is not identical, something in the data has changed since it was originally calculated. Bitcoin adds a step of calculating complexity to the use of blockchain, which often fuses with the blockchain itself, and involves selecting a metaphor (i.e., "distributed ledger") to describe transaction data specific to that domain (cryptocurrency and finance). Thus, the applicant's system goal is to ensure that each participant in the data sharing scheme has an exactly identical copy of the domain change record over time, and the underlying metaphor of the disclosed embodiment using the blockchain is a distributed journal, not a distributed ledger.

[0085] This approach advantageously stores information in each data "block" of the blockchain in the "language of the domain." In an exemplary embodiment, this language is expressed in a fact-based format based on the WC3 standard resource description framework (Rodurce Description Framework (RDF)), which is referred to as a "triple" due to the three-part nature of an RDF "fact" (composed of a subject, predicate, and object). However, each triple expressed or withdrawn in a specific domain event transaction is materialized, and a cryptographically unique set of identifiers is stored in place. This achieves two objectives: a compressed representation of information that is inherently secure (by ambiguity), and the elimination of redundant information even if repetitive expressions exist.

[0086] Once an identifier is materialized and given, future materializations of the same triple can reuse the identifier, thereby significantly reducing information bloat associated with a large number of triple stores in the embodiments of the disclosed invention. A materialized factual statement or a statement in the language of an exemplary embodiment may be asserted or withdrawn multiple times over time, which is important metadata used downstream; however, redundant information set in each transaction context is not required, which is because the identity verification service of the master identity index (230) provides key mappings for the statements to the composite triple elements, each of which is also reused as much as possible for a specific identity of the system. Thus, as illustrated in FIG. 4c, to reconstruct the information stored in (225a-n), the interpreter must have access to the actual data referenced by the key, which is exactly what the domain cache (240) does when it receives a notification (908a) of new information added to the long-term storage managed by (220).

[0087] More specifically, the identity verification service (230) of the master identity index consults to reconstruct domain events using additional metadata calculated and new inferred knowledge calculated in sufficient transaction time to update the known good state of the relevant managed identity in the cache. This ultimately triggers any subscribed synchronous instance via (910), and upon receiving notification of these changes, further propagates the state changes to each SOR that maintains relevant information about the managed identity. Advantageously, the full capability of the inference functions of RDF, OWL, and related linked data technologies can be used to identify and resolve discrepancies requiring minor adjustments, and to generate new knowledge that must be matched and propagated to new transactions where they occur. (The discussion in FIG. 11 will explain this aspect more fully).

[0088] The disclosed approach enables the error probability for each source of information across the entire network to be evaluated in real-time and continuously over time, and each change can be tagged by this evaluation, which ultimately allows for non-sequential backtracking to improve inference and eradicate other erroneous derived information over time. This automated process of continuously re-evaluating the truth regarding the status of all administrative identities in light of everything previously verified as true (or false) is a significant and advantageous aspect of the current approach.

[0089] Advantageously, the disclosed approach uses this strategy to add the following three new pieces of information to every triple: source, the transaction context in which it occurred (importantly including the time associated with the information in the record system that generated the information and the time it became known to independent systems), and whether the triple is considered "true" or "false" in that context (depending on whether it is stated or withdrawn). The layering of dimensions of time and truth, along with other metadata regarding the origin of information, significantly extends the information model of RDF and is currently the only significant aspect suitable for solving the difficult problem of inferring truth in the presence of multiple sources of truth that are inaccurate or disagree on what is true.

[0090] Referring to FIG. 4c, as previously mentioned, this diagram further illustrates the high-level process in which new information is stored in the long-term storage (220) by a distributed transaction (310) in the process of receiving a change notification message N from one of the various sources via flow (905a). If a diff (or “difference”) actually needs to be applied to the view of the state of the associated identity affected by transaction N, this diagram also illustrates the process in which the information is retrieved from the long-term storage by the domain cache (240), correlated with the identity verification service of the master identity index (230), and reconstructed to generate a diff. If such a difference exists, it is further propagated to the synchronizer (510) via flow (910).

[0091] Flow (950a) represents a message transmitted to the transaction service (310) via one of the publicly available endpoints from some truth source attached to a specific SOR (i.e., (320a-d) of FIG. 3) or the synchronizer (510) itself (UDP, TCP, HTTPS, etc.). The content of the message is an RDF graph describing novelty introduced by some changes detected or observed during normal business operations according to a domain scheme (or "ontology" using technical terms specific to RDF).

[0092] Referring still to FIG. 4c, these messages enter a distributed queue service (310a) in the order they are received, with processing withheld. In some embodiments, this queue is coordinated with multiple (310a) instances to ensure that the novelty of entering the shared domain journal (i.e., blockchain) remains consistent across all replicas.

[0093] At some point, message N received via flow (905a) is pooled from the distributed column (310a) in flow (905b) for processing. This occurs when the local transaction processor (310b) is invoked by the network consensus algorithm determined at domain configuration time (different embodiments provide different default values ​​and options) to process the next message, and when all other messages preceding N have already been processed. At this time, the distributed transaction processor (310b) interacts with the identity verification service of the master identity index to augment transaction context information and materialize all triples (or reuse identifiers associated with previous materializations, which is the default policy). It associates with the next "block" of each blockchain affected by these transactions, or otherwise prepares the message for long-term storage according to the local policy. For example, the security policy may include encrypting specific identifiable information of the master identity index to further secure sensitive data.

[0094] The output of this process (906a) is transmitted to a storage processor (310c), and the responsibility of the storage processor (310c) is to store one or more blocks associated with one or more journals in order. This approach allows for the partitioning of domain information into one or more journals implemented as independent blockchains according to domain rules for identity management. Thus, a single change message N can actually add blocks to two or more blockchains managed by the storage agent (220). If this is true, the storage agent checks whether the previous hash associated with each individual journal entry matches the last block hash of each journal blockchain affected by the transaction, and the block mapping affected by the relevant journal is performed in the identity transaction map (222) of FIG. 4b. In this way, and still with brief reference to FIG. 4b, as illustrated in FIG. 4b, the overall schematic of the transaction state across multiple journals allows the storage agent (221) to automatically transmit relevant change information to the domain cache instance via flow (908a) at any degree and send it to the trader via flow (908b) upon request.

[0095] Referring again to FIG. 4c, in the process of sending the augmented block to the storage agent via 907a-b, the storage processor advantageously converts the information into an efficient, compressed, and fully anonymized representation suitable for long-term storage, even for public, commercial, or containerized infrastructure. In (907c), the role of the storage agent (220) is to add the new block to the relevant journal and maintain a careful accounting of the journal and identity (by the anonymized identity) affected by the logical transaction as mentioned above. Finally, in flow (908), the storage agent notifies all joined domain cache instances (240a-n) of the novelty.

[0096] Each domain cache instance (240) interacts with the identity verification service of the master identity index (230) upon an update notification for one or more domain journals of interest (other domain caches have their own mappings of the relevant identities as described with reference to FIG. 4) to determine whether the newly introduced information changes the current state of one or more identities of interest. The new information may have been introduced by an unaligned external system, and the "new" information does not affect the state change of the managed identity being considered by a particular domain cache instance. In this case, the update may be ignored. However, if the domain cache processor determines that there is a "diff," it immediately notifies all subscribed instances of the synchronizer as part of a differential propagation regime via flows (910a-b).

[0097] Referring now to FIG. 4d, this is a schematic block diagram providing a conceptual diagram of a method in which data can be linked across multiple domains without violating the semantics of the data flow according to the exemplary embodiment. The combinability of domain knowledge is used advantageously to allow for substantial inter-domain information sharing that supports various types of organizational structures. As previously mentioned, the augmentation of RDF having dimensions of time, truth, and source unique to the exemplary embodiment enables linking data across minimally related domains for the purpose of maintaining individual truth sources represented by the domain cache (240) for the purpose of local synchronization of changes. For this reason, RDF is referred to as "linked data" in the technical term preferred over "semantic web" (a prior art term that is still used today). The present approach makes advantageous use of the "linkable" nature of RDF data by enabling sophisticated planning for change propagation even beyond organizational boundaries. This includes internal organizational boundaries, such as wholly owned subsidiaries or sub-departments of a parent organization participating in the data sharing plan of the present approach. Thus, another advantageous use of the present approach is to align heterogeneous IT systems after mergers and acquisitions.

[0098] Despite specific domain use cases, an important point to note here is that the full deployment of the entire stack can facilitate numerous logical and physical configurations, allowing for arbitrarily complex SOR groupings based on one or more domains managed at the enterprise level. A single ForeverDB instance can manage one or more domains; each domain can typically have one or more domain cache instances scoped by sub-organizations; and each domain cache instance can provide one or more synchronization instances, each with one or more managed SORs. This is facilitated by the following three-tiered identity mapping scheme: a "master" identity index at the "domain" level; a "domain" identity index at the domain cache level (which, in practice, is scoped to one or more individual enterprises within a large distributed organization); and a "local" identity index at the individual SOR layer, scoped by participation in specific synchronization instances.

[0099] Considering the domain cache instance (A-1), it links data from domains (A) and (B) to the domain identity cache. This means that synchronous instances within that scope—namely, synchronous instances (A1, A2, and A3)—can each provide identity updates related to the corresponding SOR in domain (A) or domain (B). However, the following subtle difference should be noted: the identity index of the domain cache (A-1) tracks identity changes with data tracked in the journals (A1, A3, and B1), whereas the domain cache (A-2) tracks identity changes in the journals (A2 and B1). The point is that even when changes propagate across two logical domains, enterprises can fine-tune at a granular level which data to share and with which SORs.

[0100] Now, considering the domain cache (B-1), even though the domain (B) data is transparently shared with the upper domain (A) of the stack, it receives all data from domain (B) and receives no data from domain (A). Additionally, the domain cache (B-1) has only one synchronization client, and consequently, there is only one SOR under management. Coming down from this abstract level, we can materialize this example by imagining a medical use case, where domain (B) represents a status or medical code system and domain (A) represents an insurance provider. Specific provider information in domain (B) is not used: its sole purpose is to manage thousands of categories of status codes that are continuously updated, refined, and discarded. However, domain (A) is used for one or more status codes managed by domain (B), specifically billing status codes and special codes (two of the various types of codes managed by domain (B)).

[0101] Some systems in Domain (A) manage provider data specific to Line-of-Business (LOB) specific directories where specialized codes are important; others are interested only in insurance claim processing and are therefore interested only in claim status codes. When the code set of Domain (B) changes, the SORs related to the entire business unit within Domain (A) may be automatically updated to the new codes, or updated descriptions of existing codes may be updated when SORBla users update them. Similarly, when the system in Domain (A) related to claim processing updates provider addresses or other demographics, the system in Domain (A) processing directory information may be updated, and vice versa. Advantageously, the exemplary embodiment provides an accurate audit of which updates were propagated across the entire system, making it easier to perform root cause analysis when incorrect data is entered by users or incorrectly inferred by the system. This implies faster detection and resolution of errors and omissions, as well as inconsistencies, compared to the current state of technology.

[0102] FIG. 5 is a schematic block diagram of a synchronizer interacting across the layers (300–500) of FIG. 3 ("Interoperability Service," "Enterprise Data," and "Enterprise SOA," respectively). The management and management portal components are depicted on the same architecture as described in FIG. 4a. In some embodiments, the component is referred to as Apex Synchronicity; elsewhere, as Apex InterOp. Notwithstanding the reference to Apex Synchronicity or Apex InterOp or the names designated in other embodiments, the same scheme applies. FIG. 5 shows a schematic diagram of the entire synchronizer component (510), referred to as "Synchronicity" in an exemplary embodiment. Most of what is discussed in FIG. 4a applies here, insofar as the component shown down from the data layer performs the management functions for this component according to the same architecture pattern as "ForeverDB" in FIG. 4a.

[0103] One point worth clarifying is that, in order to simplify the deployment of the specific implementation of the entire stack, the synchronization service (510) may be logically distinct from the synchronization front-end or management service (512), even though they may be located on the same physical node. The synchronization service (510) handles the coordination of data flow between the domain cache instance and the SOR, whereas the synchronization front-end web service (512) is concerned with management and administrative issues related to a given instance of synchronization itself. Likewise, the databases (412, 410) are logically distinct but may be combined in a given implementation of one or more embodiments of the disclosed invention.

[0104] FIG. 6 is a schematic block diagram illustrating the layer (600) ("business logic") of FIG. 3 in more detail, with a particular focus on the management and management functions of the coordination workflow service (610) according to an exemplary embodiment. In some embodiments, these services and related management components are referred to as "TeamCollaborate." FIG. 6 shows a schematic diagram of the entire coordination workflow component (610) referred to as "TeamCollaborate" in an exemplary embodiment. Most of what is discussed in FIG. 4a and FIG. 5 applies here, provided that the components shown under the entire stack in the big data layer perform management functions for these components according to the same architectural pattern as "ForeverDB" and "Synchrony" in the related drawings.

[0105] The same description made in FIG. 5 above applies here, but with one nuance. The team collaboration service (610) is a business logic component in the context of the entire stack. Nevertheless, all interactions are managed by the business logic module for team collaboration (613).

[0106] FIG. 7 is a schematic block diagram illustrating the application logic layer of FIG. 3 in more detail, with particular focus on its management functions as well as its role in the workflow documentation component (710) and data flow (911) according to an exemplary embodiment. In some embodiments, this is referred to as the Documentor. Here, a schematic diagram of the entire Documentor (710) component of FIG. 1 is shown. Most of what was discussed in FIG. 4a and FIG. 5 applies here, insofar as the component shown under the entire stack in the big data layer performs management and administrative functions for this component according to the same architecture pattern as "ForeverDB," "Synchrony," and "Team Collaboration" in the related drawings.

[0107] It should be noted that as you descend down the stack, lower-level components have increasingly less visibility into the upper-level components' upper stack. The only actual interface of the documentation to the upper world is through the team collaboration service (610). This does not meaningfully interact with the management characteristics of team collaboration and also communicates with (610) through the business logic module (613). The synchronization service (510) and the synchronization DB (410) are displayed only for context. Nothing in the documentation interacts directly with these components.

[0108] Still referring to FIG. 7, the service (710) can access all UX options of the (800) ("User Experience") layer, but the main focus should be on handling the actual document sessions related to the ongoing coordination workflow managed by the team collaboration (610).

[0109] In addition, it should be noted that this is consistent with observations related to Fig. 11, and that an instance of Synchronous can service one or more instances of Team Collaboration, and an instance of Team Collaboration can service one or more instances of Documentation. However, unlike the upper components of the stack that maintain identity states in the strictly controlled new data flow, an instance of Team Collaboration can connect to multiple instances of Synchronous, and an instance of Documentation can connect to multiple instances of Team Collaboration. Although the associated workflow and documentation sessions "belong" to only one logical instance of Synchronous, there is no reason why a user with access rights to more than one instance for business reasons cannot connect to all instances using a single physical instance. This can be advantageous in large-scale implementations involving highly granular organizations where some users often need to work across multiple business lines.

[0110] Referring to FIG. 8, this is a Venn diagram illustrating a conceptual framework for a three-step workflow strategy related to the system and method described herein according to exemplary embodiments. This reveals the nature of the interoperability problem even in a perfect world where every IT organization possesses a complete copy of information regarding every entity in the domain, and how the three-step workflow session illustrated in FIG. 10 generates new knowledge independently of the existing (and often limited) interfaces of managed SORs. FIG. 8 is a highly conceptual representation of the interoperability problem in the form of two converging Venn diagrams to highlight the motivation for the approach described above and the workflow design, and provides a way to address how new information generates new information through the aforementioned three-step process. The top three circles (1000, 1003, and 1004) represent three distinct IT organizations ("A," "B," and "C," respectively) or, more precisely, three exact copies of all domain knowledge stored in a perfect copy of each organization of the raw elastic blockchain component (220) of FIGS. 2 and FIGS. 3 at a given point in time.

[0111] The nature of the interoperability problem, or rather the motivational challenge under the aspiration for interoperability expressed by the industry, is understood as the overlapping domains (1001, 1002, 1005, and 1006). (1001) represents a subset of all identities in the domain that are shared only between (1003)("B") and (1000)("A"); (1002) represents a subset of all identities in the domain that are shared only between (1000)("A") and (1004)("C"); (1005) represents a subset of all identities in the domain that are shared only between (1004)("C") and (1003)("B"). (1006) represents a subset of identities in the domain that are shared only among all three organizations.

[0112] However, in the case of the overlapping area of ​​Fig. 8, there will be no data sharing problem in finding a general interoperability solution. However, such overlap is generally guaranteed in all service-based industries that include identities that can freely use the services of multiple service providers, as in the best domain of "practical management."

[0113] Furthermore, it is a reality that in all service-oriented domains, changes to a human identity state cannot occur simultaneously in multiple locations or under the sponsorship of multiple institutions (as anyone can intuitively understand, people generally cannot be in two places at once), and it is a fact that this approach is advantageously used to allow simple proof of interest (source-based proof) for the purpose of obtaining consensus to transact domain events on a shared blockchain. This makes the consensus problem considerably simpler than other blockchain-based domains such as Bitcoin. However, as must be made clear, the exact type of proof required by a specific domain will vary, and for this reason, multiple embodiments of this aspect are allowed here by the configuration of the "consensus adapter" in (906) of FIG. 3, as elsewhere. On the other hand, while the "distributed ledger" deploys "smart contracts" for fund transfer logic required to execute across the entire blockchain, this approach provides facilities for consensus logic and domain constraints to be coded as a "distributed journal" concept, as implemented in exemplary embodiments.

[0114] Half of the Venn diagram in FIG. 8 contains circles (1000, 1200, and 1500). As previously mentioned, (1000) is a complete copy of Authority "A" regarding all domain knowledge about all identities in the domain. (1200) represents a subset of all domain identities associated with Authority "A" that is taken from (1000) and stored in the distributed domain cache (240) of (A). The size of the circle is not important, but it is of quality related to the Authority. (1500) represents all other data stored in the SOR that IT Authority "A" uses to transact all business related to the subset of identities in the domain (1200) associated with the Authority. Circles similar to (1200) and (1500) could also be drawn for the Authority represented by domain copies (1003 and 1004), but they are omitted for clarity.

[0115] The overlapping area between (1000), (1200), and (1500) is the area that drives the three-step process of data coordination provided by the embodiment. The focus of coordination is “confrontation” (1300), which leads to the resolution of conflicting information through direct interaction between one or more service providers representing an organization and service recipients whose data is found to be inconsistent between one or more systems or organizations.

[0116] The three-step process is implied in the data flow of the series (900) (which is unidirectional by design). The face-to-face data flow managed by the coordination workflow service (610) and the coordination documentation service (710) is indicated as 911a-911g in FIGS. 2 and 3. (1100) represents the first logical step of the process when data for the face-to-face is collected at (240) and the service provider prepares it. (1400) represents the data obtained during the interaction phase of the face-to-face (in this context, "service point" is broadly understood to mean a physical location or a telephone or Internet of Things). At the beginning of this meeting, the idea is to tell a "story" about the condition of the service recipient and how it happened, but at the end, through questions and observations, the situation is known, and the newly revealed facts obtained by the service provider await formulation. This formalization of the final documentation of the confrontation is indicated by (1600), and when new facts are submitted, including all decisions resulting from the meeting, the formal termination of the meeting is also recorded and shared across all participating networks of the blockchain. Thus, the three steps related to the coordination of the data and the basic confrontation workflow provided by the examples in the summary are: preparation, confrontation, and termination / decision.

[0117] Referring to FIG. 9, this is a flowchart illustrating an exemplary mode of propagation method according to an exemplary embodiment. Advantageously, the workflow algorithm can be customized according to the needs of the domain. Such customization is not solely defined by the domain; very often, they are further constrained by the urgency of the local enterprise, established corporate policies requiring implementation in all workflow processes, and policies that may not apply to other external participants in the data sharing scheme. In all cases, the goal is the same: to prevent "incorrect information" from overwriting "known good" information. Here, a process diagram is provided depicting the flow (911-912) of FIG. 3. More precisely, this diagram represents an advanced algorithm for the method, where the novelty propagated by the domain cache instance (240) to the synchronizer instance (510) in flow (910) is further propagated to the SOR under its management. The main task is to prevent bad data from overriding good data, and the components of FIG. 5, 6, and 7 participate in this process.

[0118] There are two main types of discrepancies that may require attention during this process: items that can be handled by clear business rules, and items that cannot be handled, provided there are no conditions or circumstances affecting other business rules applicable to in-flight information. Generally, discrepancies of the latter type involve internal misalignments caused by information from external sources different from local information or other factors (e.g., human error). In this context, another consideration is that as discrepancies are resolved manually, the reconciliation process may generate information that is significantly newer and more accurate than what is known in the managed SOR; in such cases, this new information must be transmitted to the trader to follow the same path described for all new items entering the system. Advantageously, embodiments disclosed in this manner can provide the consistency necessary for the state of any managed identity to be inferred at any point in a transaction.

[0119] With this in mind, we will now proceed with the process illustrated in FIG. 9, referencing previous figures as necessary. Step (8000) represents the moment when a new diff for a managed identity arrives at the synchronization service (510) via flow (910). At this point, in step (8001), the synchronization service (510) compares the previous state of the identity with the new state in the distributed domain cache (240) and determines whether there is a discrepancy between all externally known SORs (both internal and if configured to allow comparison). If there is no discrepancy, the diff is sent to all SORs under the scope of the synchronization service (510) that subscribes to the change for the identity in question, and the process terminates in step (8002) with flows (912a-n) as usual. At this point, each change monitor (320x) updates the managed SOR and checks alignment with the transaction (illustrated in FIG. 3).

[0120] If there is a discrepancy, in step (8003), the synchronization service (510) may use configured rules and logic (provided by subject matter experts via the management console (712a) of FIG. 5) to determine whether the discrepancy can be resolved automatically or if it needs to be resolved through a manual workflow involving some authorized users to determine the result. If it exists, further decisions must be made in step (8003): can the discrepancy be resolved automatically by an action handler provided by the subject matter experts? Or must a user of the field mediate? If so, in step (8004), these handlers or users of the field may make the necessary resolution for the discrepancy (e.g., ignoring information from a specific source determined to be outdated), and the change may be propagated and subsequently propagated to step (8002). Otherwise, the synchronization service (510) will initiate a reconciliation workflow that runs as long as possible in step (8005), which may require confrontation with the identity of the problem in step (8006).

[0121] Step (8006) represents a potentially long-running coordination workflow and the accompanying documentation sessions. Following Step (8006), there is another decision the system must make: whether new information has been acquired during the process. Let us frame a problem using a medication coordination use case and imagine determining, during a routine checkup (e.g., as part of a plan to address an opioid crisis), whether an OxyContin prescription from one hospital is the same prescription mentioned by another hospital or a completely separate prescription. The attending physician discovers that the patient (the subject of this new information) is taking a different medication of the same opioid class as prescribed by another hospital, and that the prescription is not recorded anywhere in the system. Of course, this new information must be added to the patient's medical history, but more importantly: it cannot yet be added directly to the SOR in the current "new information" path; rather, there is its own path through the same data flow described in Steps (8008-8009). The remainder of the "new information" may be passed to the relevant SOR unless it has not yet been discarded by the new information, and must arrive at an intermediate time after the manual workflow has started. This concept is described in step (8010). If it is determined that it is no longer in use, step (8011) generally handles the invalid condition by abandoning the update. Otherwise, once the final documentation regarding the encounter is understood, the new information (excluding newer information obtained from the process) may be passed to the SOR managed according to step (8002).

[0122] Now, turning our attention to FIG. 10, which is a schematic block diagram illustrating the hierarchy (800) ("User Experience (UX)") of FIG. 8. FIG. 10 is a conceptual block diagram illustrating the User Experience (UX) hierarchy of FIG. 3 in more detail, with a particular focus on the scenario-specific UX functions of FIG. 810, facilitated by the documentation service (710) in cooperation with the coordination workflow service (610) that stores session data in the synchronization database (410) according to an exemplary embodiment. For reference, the generalized three-step, multi-user, collaborative workflow presented in the (9000-9018) flow (described later) of this diagram occurs during the manual mismatch coordination steps (8005-8007) as illustrated in FIG. 9. Advantageously, it provides a general approach to associating multi-user operations with entity state changes during the lifetime of a coordination session for the purpose of general analysis, including but not limited to the usability, efficiency, and other quality-related dimensions of team-based workflow activities.

[0123] Figure 10 captures the interaction between the workflow and the document subsystem in a coordination session intentionally simplified to highlight key functions. Before proceeding with this step, let us examine a scenario borrowed from the medication coordination example above. The doctor has been alerted about discrepancies regarding the patient's medication list and has scheduled a meeting with the patient by phone, where the doctor will discuss the medication list in the file. Information has been obtained from an external source that the patient may "gamble on the system" to obtain opioids from multiple doctors due to chronic back pain resulting from an automobile injury. (This is merely an example, and another example could be devised in the financial services domain or other service-related domains.)

[0124] The confrontation will follow a three-stage coordination workflow protocol (more conceptually explained in relation to FIG. 8): preparation (identified by the flow indicated by the solid line); meeting (identified by the flow indicated by the dotted line); and closing document / decision (identified by the row indicated only by the dashed line). The coordination workflow begins at step (9000) when the synchronization service (510) initializes the session of the synchronization DB (410) with all data related to the identity of the problem, including previously known good information and proposed new information (including one or more discrepancies). This constitutes the "initial state" of the session.

[0125] It should be noted that the format of each coordination session utilizes blockchain technology for the same reason, but for a different purpose, in a manner similar to ForeverDB's long-term storage facility (220). While data sharing is important, in this case, the primary motivation is the ability to prove the immutability of the data and, in particular, that the information has not been tampered with. Every and every state change by every participant in the session is recorded in sequence so that the session data itself represents a kind of "black box flight recorder" of the session. In at least one embodiment including this exact use case, this approach was used to clearly and completely separate the analytics problem from the UX and general database problems. Otherwise, it would have been integrated with customer requirements. As a result, all interactions of all users across multiple user interfaces associated with the same session are neatly recorded, and in all cases, the desired analytics data points can be captured without weaving together the various related but independent problems included in the session from a software design perspective.

[0126] In a sense, this diagram can capture the essence of the entire system, except that it includes heterogeneous UX rather than heterogeneous SOR in scale. However, given that this is a difference in scale (i.e., detail) rather than a difference in type, the approach that operated in that context inspired many strategies in exemplary embodiments. Like SOR, UX has state and needs to be synchronized in real time despite the unique representation of that data.

[0127] The next step is for the team collaboration (610) to notify the doctor of a new session. This is described by the flow (9001). At this point, the task is assigned in (710), and (by the system or administrator according to the configured policy) the doctor can open the session through their Odyssey browser app (810) as shown in the flow (9002). For brevity, many interactions during the preparation phase of the confrontation, where the doctor explored data and attempted to shape the nature of the confrontation discussion interactively in Odyssey, have been omitted. At some point, the doctor prepares for the confrontation that takes place over the phone at the prescribed time in this hypothetical example. The doctor provides the patient with a secure URL and code to enter the session remotely using the browser, and the patient logs on through the flow (9003). At this point, the UX for the doctor and the UX for the patient are initialized with the same data, but fully render scenario-specific views adjusted to cognitive load tolerances and the user's overall role. For example, if the doctor views a list of medications with one selected, the patient can only see the currently selected medication.

[0128] At this point, the doctor updates the information regarding one of the drugs in the list of flow (9004). This causes the documenter (710) to send message (9005) to Team Collaboration, which maintains the new computed state of the session on the session blockchain via (9006). The new state is passed back to (9007) via the documenter, and the documenter notifies (810) and (820) of this in messages (9008a and 9008b). Both UXs are re-rendered, and now both users can view the same information according to their specific roles and cognitive requirements.

[0129] At this point, the patient adds a comment in accordance with the doctor's instructions, and as a result, a new state is transmitted to the documentation service via message (9009) in the web browser (820). This message is transmitted to the team collaboration service (610) via message (9010), and the team collaboration maintains the state change represented by (410) via (9011). Now, the new state is transmitted back to the documentation service via (9012), and both UXs are updated by the documentation service via (9013a) and (9013b), respectively. At this point, both UXs now uniquely render the current state including the patient's comment. At this point, the doctor is satisfied that the session has resolved the purpose of the confrontation, initiates termination via flow (9014), and the final state change for the session indicates the final termination of the documentation session.

[0130] Any conclusions or explanations that the physician could add to this stage of the session have been omitted for brevity. A message (9015) from the documentation to the team collaboration conveys this final state and persists to the session record 410 in message (9016). The final state of the session is now conveyed back from the team collaboration to the documentation via message (9017), which in turn is conveyed to the two UXs (810) and (820) via (9018a) and (9018b). It is important to note that the entire coordination session is stored in a blockchain representing all interactions between all entities of incremental state changes that occurred in the data during the session over time. While this is a highly simplified script to detail the core elements of this process, one can easily imagine more complex interaction scenarios in an actual coordination workflow involving multiple web sessions on this topic, two or more participants, and other variations. Various embodiments can favorably accommodate various user analysis requirements entirely perpendicular to the coordination process itself.

[0131] Referring to FIG. 11, this is a flowchart illustrating a data flow (900-914) further illustrating an exemplary “round-trip” method shared and synchronized across interested SORs according to an exemplary embodiment. Advantageously, this features a strictly unidirectional data flow designed to ensure the ability to infer the world state of the managed identity at every transaction point.

[0132] FIG. 11 provides a high-level "summary" of the entire process from start to finish. This diagram focuses on the 900 series data flow and represents a single individual change affected by a user of one of the multiple managed SORs regarding the identity managed by each SOR being considered in the example. Assuming the components based on FIG. 3, the process begins when a user of SOR1 updates some information about the managed identity via a web browser (820) (refer back to the discussion in FIG. 3 where this process is described). The SOR1 app (720a) sends a message (901a) to the SOR1 business logic module (620a), which in turn sends a message (902a) to the SOR1 WS (520a). (520a) receives the information into the SOR1 DB (420a) via a message (903a). Change Monitor SOR1 (320a) detects whether this change indicates actual novelty by the least conspicuous means available on the underlying database platform via 904a (these options vary from triggers to subscription / change views or long polling techniques depending on the available technology) (not propagation of known truth). Thus, Change Monitor sends the transaction to the distributed transaction (310) along with metadata defined by the implementation via (905a).

[0133] The trader (320) analyzes the identity data and metadata and prepares the transaction for submission after consulting with the master identity index and identity verification service (230) occurring in the flow (906a). The trader accepts the new transaction (which may consist of multiple journal updates as previously mentioned) via (907a). The long-term storage (220) updates the necessary journals and their internal identity transaction maps, and then updates all connected domain cache instances via (908), where the information is updated across the entire system. Then, the distributed cache consults with the identity verification service (230) in the flow (909) to reconfigure the new state changes and applies them to the new final state of the relevant identity at that transaction point. If necessary, the domain cache notifies each of the differential participating synchronizer service instances (510) via the flow (910), and each synchronizer determines the propagation suitability for each SOR under its scope in the flow (911a). Additionally, as needed, a manual workflow is initiated to record automatic and / or manual resolution of all conflicts via flow 911b-e, and if new information is additionally discovered during this process, it is transmitted to the trader via flow (905) as in other change agent monitoring.

[0134] At this point, if the new information is not discarded, it is transmitted to each non-source SOR (in this case, SOR2-SOR4) via each web service in flow (912b-n). Finally, each of these systems records the alignment facts regarding the known truth status of the identity being considered at the current transaction point via (914b-d) in flow (913b-d). At this point, all systems recording have aligned with the new information, and any additional new information found in the process is in the same pipeline.

[0135] It should be noted that this process will occur simultaneously in real time across all nodes of the data-sharing organizational network, and that at each stage, each participating organization has the autonomy to determine many basic policies regarding state propagation, such as what to automate and what to accept or reject as external information is merged with local information. While these policies may conflict or create new inconsistencies, the system will stabilize over time as universal data for each ID is uniformly propagated to the participating SORs and change management issues are simplified by actual urgency (for example, in one embodiment specific to the medical field, the fact that a patient can only be at one medical facility at a time is unimaginable, but this reduces the likelihood of two separate collaborating medical networks sending visit-related data to the system simultaneously).

[0136] Therefore, the foregoing provides, in an information technology (IT) term known as "semantic interoperability," an advantageous set of cohesive tools, technologies, methods, and computerized software components that offer both the necessary conceptual approach and a distributed physical infrastructure capable of meeting the demanding technical requirements for data sharing. The disclosed approach provides various semantically rich interoperability-related capabilities in a domain-neutral and unobtrusive manner through architectural innovations, primarily involving the use of blockchain technology. The method is compared and contrasted in several key ways with modern Enterprise Application Integration (EAI) technologies, which involve point-to-point data exchange via hard-coded APIs and MOM technologies. These are generally problematic because they must adhere to pre-negotiated protocols and message formats in short-term, ad-hoc integration efforts. In particular, it provides a general method for operating near real-time synchronization of relevant domain-specific data between stakeholder Records (SORs), as well as a new information model for the standard "enterprise architecture stack" and two new architectural layers. Importantly, this is achieved in a manner that makes data sharing explicit and unobtrusive, as well as implicit and transparent. Over time, this "behind-the-scenes" synchronization, driven by truth-savvy distributed data flow technology, occurs selectively across organizational boundaries according to the disclosed method, making managed SORs running on the participating IT networks completely passive beneficiaries of the data sharing scheme. In other words, they continue to operate normally without explicitly knowing that domain information is being exchanged between themselves and other SORs both inside and outside the IT network in which they are running.Advantageously, each management SOR participating in the disclosed interoperability system may continue to operate freely as if it were the definitive "source of truth" that must always be present, but in the real world, given the current state of technology, and without the very tools, techniques, methods, and software systems of the disclosed embodiments (until now), this cannot truly be the case.

[0137] Finally, the intentional and specially designed domain neutrality features of the open system enable the sharing of relevant information between systems in tangentially related or substantially unrelated domains, and allow data elements from different domains to overlap at least partially and be semantically connected with the help of subject expertise readily available in collaborative workflows, leveraging existing investments in so-called "connected data" (also known as the "semantic web") technologies.

[0138] Furthermore, the approach described herein can advantageously provide an architecture for the interoperability of heterogeneous SORs that can operate based on different database structures, allowing all shared data to be updated without modifying their respective operational semantics. In other words, the current approach can advantageously provide an infrastructure that does not interfere with the detection and propagation of changes specific to each SOR's database technology, without modifying the operational semantics or core data requirements of the managed SORs. Moreover, regarding common entity data through a shared source of truth—namely, a distributed domain cache—this approach can advantageously keep otherwise heterogeneous SORs accurate, up-to-date, and synchronized with each instance of the cache containing a useful subset of known IDs associated with each SOR(s) within that scope. Additionally, to avoid a database "total replacement" strategy that can be highly disruptive to an organization, using the current approach allows legacy systems to continue running alongside other systems and even enables final replacement until all data is aligned. In other words, using the technology described here allows for the gradual replacement of legacy database systems with minimal disruption to the adopting organization's common and customary business processes.

[0139] Many modifications and other embodiments will come to mind of those skilled in the art, taking advantage of the teachings set forth in the foregoing description and the associated drawings. Accordingly, the foregoing is not limited to exemplary embodiments, and modifications and other embodiments are intended to be included within the scope of the appended claims.

Claims

Claim 1 A plurality of record systems (SORs), each comprising a database that operates autonomously in a first layer based on different respective database characteristics; a plurality of change monitors operating in a second layer to communicate with each SOR using said database characteristics, said change monitors configured to detect individual CRUD (Create-Retrieve-Update-Delete) operations for each SOR associated with said at least one shared identity to generate an identity state change set corresponding to the current state of at least one shared identity; a transactor operating in the second layer and communicating with said change monitors in the language of the domain to transact said identity state change set, along with associated metadata, into a distributed immutable long-term storage as a current transaction; at least one domain cache instance operating in a third layer and using said domain language to regenerate the current state of at least one shared identity in a domain cache instance based on said current transaction time by cooperating with said distributed immutable long-term storage to propagate said identity state change set and said associated metadata, said domain cache instance, said domain cache instance, each of said transaction in the transaction history A system characterized by providing a transaction history including each state of at least one known shared identity in each of the above SORs over time; and a plurality of local state change sorting services operating in each of the above SORs and communicating with the domain cache instance in the language, each of the said local state change sorting services configured to communicate with the database of each of the above SORs using each of the said database characteristics, and configured to make the state of at least one known shared identity in other said SORs locally available in each of the above SORs at one or more points of the transaction history from at least one of the above domain cache instances. Claim 2 A system according to claim 1, wherein the local state change alignment service is additionally configured to align branch data points in cooperation with the plurality of SORs, otherwise the SORs would not be able to regenerate the current state of at least one of the shared identities. Claim 3 A system according to claim 1, characterized in that the metadata includes a command for repeatedly regenerating the current state of at least one shared identity based on the current transaction time. Claim 4 A system according to claim 1, characterized in that the set of identity state changes corresponds to graph-based information for at least one shared identity. Claim 5 A system according to claim 1, characterized in that the change monitor is configured to cooperate with each of the SORs to detect discrete CRUD operations based on a SOR adapter service process that operates independently of the given SOR. Claim 6 A system according to claim 5, characterized in that the SOR adapter service does not modify the operational semantics or core data requirements associated with the given SOR. Claim 7 A system according to claim 1, characterized in that the trader is further configured to generate a master identity index comprising at least one shared identity to be copied across a plurality of the SORs. Claim 8 A system according to claim 1, characterized in that the management server is configured to cooperate with the given SOR to store immutability logs in the long-term storage verified using a blockchain algorithm. Claim 9 A system for use with a plurality of record systems (SORs), each comprising a database that operates autonomously in a first layer based on different respective database characteristics; a plurality of change monitors operating in a second layer to communicate with each of the said SORs using said respective database characteristics, said change monitors configured to detect individual CRUD (Create-Retrieve-Update-Delete) operations for each of said SORs associated with said at least one shared identity to generate an identity state change set corresponding to the current state of at least one shared identity; a transactor operating in the second layer and communicating with said change monitors in the language of a domain to transact said identity state change set with associated metadata into a distributed immutable long-term store as a current transaction; at least one said domain cache instance operating in a third layer and using the language of said domain to regenerate the current state of at least one shared identity in a domain cache instance based on the current transaction time by cooperating with said distributed immutable long-term store to propagate said identity state change set and said associated metadata, said domain cache instance having transaction history For each of the above transaction times within, the transaction history including each state of at least one known shared identity in each of the above SORs is provided;A system characterized by a plurality of local state change sorting services operating in each of the above SORs and communicating with the domain cache instance in the language of the domain, each of the said local state change sorting services being configured to communicate with the database of each of the said SORs using each of the said database characteristics, and enabling the state of at least one known shared identity in another SOR to be locally available in each of the said SORs at one or more points in the transaction history from at least one of the said domain cache instances.; Claim 10 A system according to claim 9, wherein the local state change alignment service is further configured to align divergent data points in cooperation with the plurality of SORs, otherwise the SORs would not be able to regenerate the current state of the at least one shared identity. Claim 11 A system according to claim 9, wherein the metadata includes a command for repeatedly regenerating the current state of at least one shared identity based on the time of the current transaction. Claim 12 A system according to claim 9, wherein the set of identity state changes corresponds to graph-based information for at least one shared identity. Claim 13 A system according to claim 9, wherein the change monitor is further configured to cooperate with the given SOR to detect discrete CRUD operations based on a SOR adapter service process that operates independently of the given SOR. Claim 14 A step of operating a plurality of record systems (SORs), each comprising a database that operates autonomously at a first layer based on different respective database characteristics; a step of operating a plurality of change monitors to operate at a second layer to communicate with each of the said SORs using said database characteristics, and to detect individual CRUD (Create-Retrieve-Update-Delete) operations for each of the said SORs associated with said at least one shared identity in order to generate a set of identity state changes corresponding to the current state of at least one shared identity; A step of activating a transactor that transacts the identity state change set with associated metadata as a current transaction into a distributed immutable long-term store as a current transaction to communicate with the change monitor in the language of the domain in the second layer; a step of activating at least one domain cache instance using the language of the domain to regenerate the current state of at least one shared identity in the domain cache instance based on the current transaction time by propagating the identity state change set and the associated metadata to cooperate with the distributed immutable long-term store in the third layer, wherein the domain cache instance provides the transaction history containing each state of at least one known shared identity in each SOR for each transaction time in the transaction history; A method characterized by comprising the step of operating a plurality of local state change sorting services to enable local use in each of the SORs of the state of at least one known shared identity at one or more points of transaction history from at least one domain cache instance to communicate with the domain cache instance in the language of the domain in each of the SORs and to communicate with the database of each of the SORs using each of the database characteristics. Claim 15 A method according to claim 14, further comprising the step of operating such that the local state change alignment service cooperates with the plurality of SORs to align branch data points, otherwise the SORs cannot regenerate the current state of at least one of the shared identities. Claim 16 A method according to claim 14, wherein the metadata includes a command for repeatedly regenerating the current state of at least one shared identity based on the time of the current transaction. Claim 17 A method according to claim 14, wherein the set of identity state changes corresponds to graph-based information for at least one shared identity. Claim 18 A method according to claim 14, further comprising the step of the change monitor operating to cooperate with the given SOR to detect discrete CRUD operations based on a SOR adapter service process operating independently of the given SOR.

Images