TECHNICAL FIELD

This disclosure relates to the fields of distributed transactional database management systems (DBMS) and enterprise Service-Oriented Architectures (SOA), and more particularly to “semantic interoperability” between disparate database systems in minimally-related business domains.

BACKGROUND

Conventional Enterprise Application Integration (EAI) techniques for data sharing within a given Information Technology (IT) topology in a business or organization commonly involve Message-Oriented Middleware (MOM) systems that provide network transparency for calls to Application Programming Interfaces (APIs) and explicit publishing of and subscription to message streams produced by well-known sources of data whose enterprise data mappings must be known in advance to all subscribers. This network transparency is beneficial in its intended context to ensure physical topology changes do not break long-running client-server operations, but it is wholly impractical beyond the scope of any one IT network, particularly when the hard requirements for “semantic interoperability” demand sharing of protected information across legal entity boundaries, for whom the IT topologies of external stake-holding systems (relative to a given SOR running on a specific IT network of a single legal entity or organization) are necessarily completely opaque.

Significantly, it is moreover the case even on a given IT network of any moderately-sized enterprise that local entity domain data is distributed across disparate internal SORs whose data models and in some cases core semantic abstractions are not strictly identical, even if they are conceptually aligned by a common business domain in some business-critical function. For example, insurance companies in diverse industries have information about the same pool of contracted service providers across many internal databases involving commercial contracts and even government-mandated programs supported by the insurer. These are typically used to maintain contract-specific provider registries, and are subject to government audit in the case of government-supported insurance programs, but this is just one example.

As another example, consider a financial services company who keeps client information in multiple systems. One database application might pertain strictly to client engagement and billing concerns, whereas another might relate clients to specific products and financial positions relative to those products. Yet another system might record details about the client at various meetings, for the purpose of determining client suitability for various investment and insurance recommendations, proof of which is mandated by law in some jurisdictions. The point is, all three systems “know about” each client, but are designed for different aspects of the financial service company's relationship with each client. To have a full view of any given client it is necessary to aggregate the data from these systems for reporting and business intelligence purposes. Some changes, such as change of client address or surname, would need to be propagated to each system, as much as they contain the same affected data elements. This is usually a manual data entry or ad-hoc batch processing job, neither of which are real-time, and all of which are error-prone. For this reason, information in one of the systems can frequently be out of sync with the others, adversely impacting the business logic of one or all of the systems.

Structural interoperability, much less “semantic interoperability” as it is commonly defined (see below), has therefore proven elusive even in enterprises in which the semantic misalignment of systems is not the primary inhibitor of meaningful data sharing. In these enterprises, the operational infrastructure to affect real-time data synchronization is typically lacking. Advantageously, the present approach has value even in the absence of external requirements to share entity information across organizational boundaries.

While certain industries have worked on numerous formal standards to address the mapping and coding aspects of the interoperability problem more narrowly (e.g., consider HL7 FHIR: https://www.hl7.org/fhir/), the approach disclosed herein provides a general method and example market-specific embodiments of a set of extensible software systems on a new architectural foundation to leverage such mappings for the synchronization of known truth and identification of discrepancies across participating systems requiring automated or semi-manual workflow to reconcile conflicting information.

In a world characterized by multiple “sources of truth” that are all guaranteed, at any point in time, to be out-of-sync both with each other and indeed current reality, it is important to address the problem of data reconciliation, as without it raw data exchange per the conventional concept of “interoperability” in which systems “talk to each other” could potentially do more harm than good by violating the integrity of some participating SORs with information that is less accurate than what it had before the data exchange. This is a challenge of interoperability, and the approach disclosed herein provides tools to address it directly.

For the purposes of this disclosure the definition of “interoperability” generally will be that provided by the Healthcare Information and Management Systems Society (or HIMSS) (see https://www.himss.org/library/interoperability-standards/what-is-interoperability), which breaks the concept into three progressive categories: foundational, structural and semantic. Semantic interoperability is built on top of structural, which in turn is built on top of foundational interoperability, and supposes two or more systems intended “to exchange information and use the information that has been exchanged.” Further: “semantic interoperability takes advantage of both the structuring of the data exchange and the codification of the data including vocabulary so that the receiving information technology systems can interpret the data.” This implies that the very nature of the information received triggers actionable behavior, a requirement for which traditional database information models are fundamentally inadequate, for reasons disclosed herein.

SUMMARY

A system for propagating an identity state change set about shared identities may include a plurality of systems of record (SORs), and a management server cooperating with the plurality of SORs and configured to: detect discrete Create-Retrieve-Update-Delete (CRUD) operations on a given SOR related to at least one shared identity to generate an identity state change set corresponding to a current state of the at least one shared identity; transact the identity state change set, with associated metadata, to a distributed immutable long-term storage as a current transaction; propagate the identity state change set and associated metadata to replicate a current state of the at least one shared identity as of the current transaction to 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.

More particularly, the management server may be further configured to cooperate with the plurality of SORs to align divergent data points preventing the SORs from replicating the current state of the at least one shared identity. By way of example, the metadata may include instructions for repeatably recreating the current state of the at least one shared identity as of the time of the current transaction. The identity state change set may correspond to graph-based information about the at least one shared identity, for example.

In an example embodiment, the management server may be configured to cooperate with the given SOR to detect the discrete CRUD operations based upon an SOR adapter service process operating independently of the given SOR. More particularly, in an example implementation the SOR adapter service does not modify operational semantics or core data requirements associated with the given SOR.

Furthermore, the management server may be configured to cooperate with the plurality of SORs to transact the identity change state using a dedicated, distributed transactor service process. Moreover, the distributed transactor service process may be further configured to generate a master identity index including the at least one shared identity to be replicated across the plurality of SORs.

In an example implementation, the at least one domain cache instance may represent a single source of truth comprising a subset of known identities relevant the plurality of SORs. Furthermore, the management server may be further configured to cooperate with the plurality of SORs to synchronize the state of the at least one shared identity via a synchronization service process. By way of example, the management server may be configured to cooperate with the given SOR to store the immutable log in the long-term storage with a transaction history for the at least one shared identity verified using a blockchain algorithm.

A related management server, such as the one described briefly above, is also provided along with a related method for propagating an identity state change set about shared identities. The method may include operating a management server in cooperation with a plurality of systems of record (SORs) to: detect discrete Create-Retrieve-Update-Delete (CRUD) operations on a given SOR related to at least one shared identity to generate an identity state change set corresponding to a current state of the at least one shared identity; transact the identity state change set, with associated metadata, to a distributed immutable long-term storage as a current transaction; propagate the identity state change set and associated metadata to replicate a current state of the at least one shared identity as of the current transaction to 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.

