Individual Entity Life Record Engine and System

Abstract

A system, apparatus, and associated method for collecting, standardizing, evaluating, and processing entity life and care information from diverse information systems and sources. After collection, the life and / or care data and information contained within a particular message is transformed, including normalizing, processing, evaluating, and converting, into a Curated Manifest (CM), a persisted and immutable document compatible with the specific configuration and design of the ILR platform / system in a specific context. The CM is stored in one or more databases, in addition to numerous other CMs. A contextual best-of-record view, which may be a standard pre-established view or multiple views built "on the fly" or "on demand," is used to find, locate, identify, and report responsive data from the stored CM.

Description

[Technical Field]

[0001] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 408,501, filed September 21, 2022, and U.S. Provisional Application No. 63 / 539,574, filed September 20, 2023, both of which are specifically incorporated herein by reference in their entirety for all purposes.

[0002] FIELD OF THE INVENTION The present invention relates to an apparatus and system for collecting, standardizing, evaluating, and processing information about entities, including creating multiple curated entity life record components, which are then accessible to various contextual best-record views. Summary of the Invention [Means for solving the problem]

[0003] (Summary of the Invention) In various exemplary embodiments, the present invention includes systems, apparatus, and associated methods for collecting, standardizing, evaluating, and processing entity life and care information from diverse information systems and sources. An "entity" is an object, item, person, or anything that is being cared for, collected, maintained, or the like. An entity may be animate or inanimate. In some embodiments, an entity has high value (such as, but not limited to, financial, sentimental, historical, or other forms of value) and therefore survives or is maintained or retained for a substantial or long period of time and therefore needs to be monitored or documented during its life cycle or maintenance or retention cycle. Examples of an "entity" include, but are not limited to, animals (e.g., dogs, cats, horses, giraffes, and the like), individuals / people (e.g., household members, service personnel, members, consumers, patients, clinicians, service providers, subscribers, users, and the like), vehicles (e.g., automobiles, motor vehicles, buses, trucks, vans, scooters, airplanes, trains, bulldozers, excavators, construction vehicles, and the like), items or objects (e.g., books, works of art, relics, manuscripts, furniture, crystal, coins, jewelry, guns, and the like), equipment / machinery. (e.g., robots, manufacturing equipment, field analyzers, computers, mobile computing devices, laptops, computer network servers and components, and the like), property (e.g., real estate parcels, buildings, homes, bridges, roadways, and the like), organizations (e.g., employers, government entities or agencies, business entities, payers, service providers, hospitals, laboratories, reference laboratories, imaging centers, nursing homes, and the like), and other forms of vital or useful business or personal items or entities.

[0004] In some exemplary embodiments, the present invention comprises an individual entity life record (ILR) platform or system that uses its "connectivity" functionality to receive or actively mine multiple entity information streams and other data sources for messages containing information about an entity or entities, including, but not limited to, care data. The entity or entities may be known in advance, or the data may be analyzed to identify the entity or entities. Data may also be obtained by direct entry of data by an entity care professional, in some cases in addition to specific entity information elements, if the entity has been previously identified, as discussed in more detail below.

[0005] After collection, the life and / or care data and information contained within a particular message is transformed, including normalized, processed, evaluated, and translated into a Curated Manifest (CM), a persisted and immutable document that is compatible with the specific configuration and design of the ILR platform / system in a specific context. The CM is stored in one or more databases, in addition to numerous other CMs. The CM is not limited to the history of an entity, but may include all types of activities and events that the entity has experienced or is experiencing.

[0006] Contextual Best Record (CBR) views, which can be standard pre-established views or multiple views built "on-the-fly" or "on demand," are used to find, locate, identify, and report responsive data from stored CMs. A rules engine may apply rules to modify and / or enhance the data and CBR views. The application of rules may in turn create data and information, which is then stored as a separate or new CM. A data externalization function manages interactions with external users and queries, including providing API responses. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 shows a schematic diagram of the general relationships between the major functions of the present invention.

[0008] [Figure 2] FIG. 2 shows a schematic diagram of the ILR system architecture with various application services.

[0009] [Figure 3] Figure 3 shows the system architecture of Figure 2, but with three cooperating monoliths.

[0010] [Figure 4] FIG. 4 illustrates an embodiment of a scaling service involving multiple process threads.

[0011] [Figure 5] Figure 5 shows a schematic diagram of the conversion of a payload into an ILR-structured, curated manifest.

[0012] [Figure 6] Figure 6 shows the basic structure of a curated manifesto.

[0013] [Figure 7]FIG. 7 shows a diagram detailing the data curation process.

[0014] [Figure 8] Figure 8 illustrates the use of observables and observables in creating a curated manifesto and representing data within a CBR view.

[0015] [Figure 9] FIG. 9 shows an example of a CBR view index.

[0016] [Figure 10] FIG. 10 illustrates the relationship between multiple CBR views based on selection data from a curated manifest.

[0017] [Figure 11] FIG. 11 shows a schematic diagram of the two-way API services associated with external applications and associated ILR data processes.

[0018] [Figure 12] FIG. 12 illustrates the use of credentials by the two-way API service of FIG. DETAILED DESCRIPTION OF THE INVENTION

[0019] DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS In various exemplary embodiments, the present invention includes systems, apparatus, and associated methods for collecting, standardizing, evaluating, and processing entity life and care information from diverse information systems and sources. An "entity" is an object, item, person, or anything that is being cared for, collected, maintained, or the like. An entity may be animate or inanimate. In some embodiments, an entity has high value (such as, but not limited to, financial, sentimental, historical, or other forms of value) and therefore survives or is maintained or retained for a substantial or long period of time and therefore needs to be monitored or documented during its life cycle or maintenance or retention cycle. Examples of an "entity" include, but are not limited to, animals (e.g., dogs, cats, horses, giraffes, and the like), individuals / people (e.g., household members, service personnel, members, consumers, patients, clinicians, service providers, subscribers, users, and the like), vehicles (e.g., automobiles, motor vehicles, buses, trucks, vans, scooters, airplanes, trains, bulldozers, excavators, construction vehicles, and the like), items or objects (e.g., books, works of art, relics, manuscripts, furniture, crystal, coins, jewelry, guns, and the like), equipment / machinery. (e.g., robots, manufacturing equipment, field analyzers, computers, mobile computing devices, laptops, computer network servers and components, and the like), property (e.g., real estate parcels, buildings, homes, bridges, roadways, and the like), organizations (e.g., employers, government entities or agencies, business entities, payers, service providers, hospitals, laboratories, reference laboratories, imaging centers, nursing homes, and the like), and other forms of vital or useful business or personal items or entities,

[0020] Figure 1 illustrates the general relationships among the major functions of the present invention. In general, the present invention comprises an individual entity life record (ILR) platform or system that uses its "connectivity" functionality 10 to receive or actively mine multiple entity information streams and other data sources 8 for messages containing information about an entity or entities, including, but not limited to, care data. The system may receive this data via one or more telecommunications or similar networks, wired or wireless, including, but not limited to, the Internet, the World Wide Web, or the "Cloud." The entity or entities may be known in advance, or the data may be analyzed to identify the entity or entities. Data may also be obtained by direct entry of data by an entity care professional, in some cases in addition to specific entity information elements, if the entity has been previously identified, as discussed in more detail below.

[0021] After collection, the life and / or care data and information contained within a particular message is transformed (20), including being normalized, processed, evaluated, and translated into a Curated Manifest (CM) 100, a persisted, immutable document compatible with the specific configuration and design of the ILR platform / system in a specific context. The CM is stored in one or more databases, in addition to numerous other CMs. The CM is not limited to the history of an entity, but may include all types of activities and events that the entity has experienced or is experiencing.

[0022] Contextual Best Record (CBR) views 110, which can be standard pre-established views or multiple views built "on the fly" or "on demand" (30), are used to find, locate, identify, and report response data from stored CMs. A rules engine may apply rules 40 to modify and / or enhance the data and CBR views. The application of rules may in turn create data and information, which is then stored as a separate or new CM 100a. A data externalization function 50 manages interactions with external users and queries, including providing API responses 120.

[0023] Figure 2 shows a general diagram of the ILR system architecture, identifying the various services and associated components used to implement the five basic functions described above to create and maintain an ILR (i.e., an individual entity life record). Note that the ILR for an individual entity is not a single object (such as in an object-oriented program) or a single record (such as in a database). Instead, data is stored in multiple immutable, persisted CMs within ILR-defined data structures, which are then used to inform and provide various CBR views, as described in more detail herein.

[0024] 2 includes, but is not necessarily limited to, a Data Acquisition Learning Engine (DALE) 300, a Cognitive AI Service 310, an Entity Resolution Service 320, a Reasoner Service 330, a Content Service 340, an Ontology Service 350, a Persister 360, a JSON Data Store 370, a Security Service 380, a Payload Feeder 202, a Payload Service 204, a Manifest Curator Service 206, a Data Refinement Service 208, an Identification Service 210, a Knowledge Engine Service 212, a Persisted CBR View Service 220, a CBR View Constructor 230, a CBR View Manager 240, and a Bidirectional API Service 400. Communications are handled through a combination of an internal bus 80 and an external bus 90.

[0025] Because the hardware and related resources available for a particular installation of an ILR platform can vary significantly, certain individual processes and components of the ILR system can be organized by assignment to “cooperating monoliths” to appropriately utilize those available resources for greater speed and effectiveness, depending on the needs and context of each particular installation. Generally, a monolith is a set of sets of threads, each of which coordinates to perform one of the primary processing tasks, with the various groups communicating with each other via internal memory-based queues. Thus, for example, FIG. 2 shows six services (payload service, manifest curator service, data refinement service, identification service, persisted CBR view service, and knowledge engine service) along with an ontology service within a single monolith 60. All of these services can communicate rapidly through an internal bus 80. In an alternative configuration, as seen in FIG. 3, these services are subdivided into three cooperating monoliths 60a-c. The ontology service is provided in each, as it is used by each of the other services. Persistence services are similarly provided in each of these diagrams. Services can also be organized in other combinations across multiple monoliths depending on the needs and context of a particular installation.

[0026] Services within each monolith communicate internally through a corresponding internal bus, but also communicate with services in other monoliths through a (generally slower) external bus. The internal bus provides fast queuing and communication between ILR services within the corresponding monolith. Services and associated processes see the internal bus for incoming CM for preceding processes / services. The external bus (or buses) provides the infrastructure that allows different processes / services to collaborate in a decoupled manner, primarily with respect to processes / services interacting with CM, input payload, and / or external API processes and communications. The external bus also provides communication between monoliths and with payload feeders. The use of a shared message bus provides the widest bandwidth for running processes / services in parallel.

[0027] The ILR system architecture design can be scaled for high performance (horizontal scaling as described above, as well as scaling based on end-user / customer infrastructure and objects). One example of scaling using multiple process threads is shown in Figure 4. There are potentially multiple steps within a processor (or multiple processors), i.e., the system can launch as many of each service (e.g., four payload services, five manifest curator services, three data validator services, etc.) as is useful for system performance and balancing. Each process is multi-threaded, and each thread is a specific service (e.g., a manifest curator service).

[0028] The system is therefore flexible and adaptable with a layered approach. The maintainability of the system is high due to the uniform system configuration, which is reliable and provides high availability for data. The failover design (i.e., a failover or backup operating mode in which standby computing equipment, such as a server, hardware component, and / or network, automatically takes over operations when the main system or part thereof fails, thereby preventing, eliminating, or reducing operational outages and any resulting adverse effects) may be based on end-user / customer infrastructure and objects.

[0029] The ILR system receives various types of data input messages from various sources through a payload feeder 202. All data inputs, regardless of type, are referred to herein as "payloads" and include, but are not limited to, data exchange messages and API requests. The feeder can process messages from a queue or topic. In particular, it can monitor and listen for payloads placed in a queue. The system can parse a variety of input message types, including, but not limited to, API, Delimited, HL7 FHIR, HL7v2, HL7 CCD / CDA, NCPDP, and X12.

[0030] The payload feeder monitors and manages connectivity runtime components, including a channel-based interface engine. It provides connectivity to source systems, accepts any inbound message format, provides real-time and bulk loading, provides initial message handling (i.e., rule-based filtering and routing, syntax validation, edit checking, and the like), provides message transformation, queuing, automatic forwarding, and storage, provides message journaling, and manages message priorities. While payloads can be processed based on time of receipt (e.g., first-in, first-out), in a preferred embodiment, payload processing is priority-based (e.g., normal, high, immediate) based on the source and / or type of payload. For example, API interactions involving end users / customers would typically be prioritized as "immediate" priority.

[0031] Payload service 204 parses and converts the input payload into a multi-JSON document called the "Payload Manifest Schema (PMS)." More specifically, it converts the input payload into a series of discrete data key / value pairs that match the parsed data from the payload to a semantic ontology definition. These are called "observables." The processed payload (i.e., the PMS) is then sent over an internal bus to manifest curator service 206. Note that this automated transfer (and subsequent related automated transfers or communications discussed below) is described as if the services involved were within the same monolith, as described above. If automated transfers or other communications are between services within different monoliths, an external bus would be involved.

[0032] The Manifest Curator Service 206 obtains each PMS from the bus, processes the paired observables / data, and converts them into an ILR Multi-JSON Semantic Normalized Representation. Both the context and the externally coded data are represented as ontology concepts. The data are grouped according to context based on interpreting their semantic definitions (see the discussion of Ontology Services below). Related fields are grouped in relation to the observable. Related observables are further grouped by the role of the actor they observe (e.g., service provider, patient, attending physician, etc.). Related observables may also be grouped by the context of the service and the supplied products (i.e., items) used in performing the service. The resulting ILR Multi-JSON Semantic Normalized Representation is the initial curated manifest associated with its payload.

[0033] 5 shows a representative diagram of this transformation of a payload received from a source 502, which is processed to generate a parsed payload 504. The parsed data fields are then matched to observables 506, with subsequent transformation into an ILR-structured, curated manifest 508.

[0034] Figure 6 shows the basic structure of a curated manifest, comprising a header section 510, an actor section 512, an item section 514, and an observable section 516. Each received payload results in a single created CM, resulting from multiple processing operations. Only the data of interest (i.e., "curated") is converted to an ILR representation within the CM. The CM is immutable and persistent.

[0035] Figure 7 shows the data curation process for creating a CM in more detail. The system creates an observable component for each observable / data pair (520) and attaches the observable component to the observable (522), which is then added to an observable partition (524). Next, the system groups observables that describe actor roles (526), ​​which may then be added to an actor partition (528). Next, the system groups observables that describe items (530). The system then invokes services for data refinement 532 and identification service 534, and item and actor identification is added to the item and actor partition (536, 538). The header section of the CM contains general data about the source payload and the identification and creation of the CM itself.

[0036] The CM structure is created from an ontology description language defined for a specific application. Each source data field is represented as an observable component. In some embodiments, this includes a role identified by a key and an ontology concept identifier, which provides domain-specific context. Source data values ​​are represented by separate key-value pairs, with the value-attribute property providing the key for the source data value. Observable components are grouped into observables, which provide context based on the ontology definition. For example: Observable - Blood Pressure Systolic blood pressure -120 Diastolic blood pressure -90 Blood Pressure Method - Doppler Blood pressure patient position - sitting position

[0037] As seen in FIG. 8 , the observable 542 and observable 544 ontology definitions provide both meaning and context to the data represented in the corresponding CM (e.g., CM “D”) 546. Other CMs created from other payloads may contain related or matching data. As discussed in more detail below, matching data across all CMs is compared to determine the “best” data based on the situation or purpose (i.e., context) for which the data was requested. Data that may be considered “best” in one context may not be “best” in another. The best data for a given context is then represented in a multi-JSON document, called a CBR view 548.

[0038] The data refinement service 208 manages the transmission of the CM to the cognitive AI service 310 during the data transformation process to automatically check data integrity and automatically correct or resolve any issues that may be identified. The data refinement service, in turn, receives corrective solutions to data issues and places them in the CM. If issues require resolution / correction beyond the capacity of the cognitive AI service, the issues are marked and notifications are generated and sent.

[0039] The Cognitive AI Service 310 is generally available for all services, as shown in Figure 2. It solves problem data issues based on its learned knowledge. It can solve semantic problems such as ununderstood data (e.g., UnCIDed), data transformation issues (e.g., parsing or combining data values, actor name transformation, address and phone transformation, timestamp transformation, and value transformation). It can also execute validation logic to check the quality and consistency of source data, such as meaningless data (e.g., blood pressure = 0, pregnancy for a male, date of occurrence before a person's birth date or conception date). This validation logic includes the following: Data Type Validation - Comparing individual received data characteristics with expected known primitive data types. Format data validation - demonstrating that a data value satisfies minimum / maximum ranges, sequences, or consistency patterns of expected characteristics. Missing Data Validation - Identifying missing request data (e.g., missing time periods, assigning permissions, missing identifiers). Logical Data Validation - Validating that (i) data fields are consistent with each other, (ii) dates representing activities are appropriate in sequence, and (ii) status correlates with dates.

[0040] This can also identify and resolve issues such as disconnected or isolated data. The service also enhances data beyond what is received, including, but not limited to, inference, reliability assessment and / or rating, event dating, provenance, and the use of semantic knowledge. This further enhances, augments, and / or refines the quality, value, and / or categories of data contained within the CM itself, as described above. This can also provide service variants such as enforcing appropriate CIDs based on characteristic concepts, provided the service has sufficient context to understand what it is looking at.

[0041] An ILR system relies on the ability to accurately identify and / or create entities and accurately link data through or based on them. As discussed above, many types of entities exist. The identification service 210 detects actors in the CM that require actor identification during the data translation process. It submits the actor knowledge structure (actor-related observables) to the entity resolution service 320, which is responsible for determining and / or obtaining the identity of each entity in the CM. The entity resolution service is rule-based, decision-making, and data source specific. It uses only the data in the CM that is submitted, and its focus is on actor classification. The entity resolution service implements an identity matching process to identify entities and returns the resolved actor / entity identity (e.g., the ILR actor key assigned to the entity). The identification service receives the resolved actor / entity identity and updates the actor data in the CM.

[0042] The identification process uses criteria-based matching rules. Criteria are data source system specific (i.e., interface specific). One or more criteria can be associated with a data source / interface. A library of matching criteria exists. This allows criteria to be reused. As best practices are established, they can be easily applied to other data sources. Rules support entity type matching (e.g., person vs. organization) and role-based matching (e.g., patient vs. provider vs. supplier). Each rule set contains one or more criteria that must be satisfied to achieve a successful match.

[0043] If two entities in the ILR system are later identified as the same entity, the system merges them by creating a third entity with its own identification key. Data from the two original entities is essentially merged by also linking it to the third entity. Not only are the CM and payload pointed to the original entity, they are also pointed to the new entity. Any new data generated directly by or based on the new third entity (i.e., the merged entity) will be attached to that entity.

[0044] Merged (linked) entities can be separated by unlinking them (i.e., being "unmerged"). An audit history is created for each entity involved in the unmerger, and previously merged entities can be accessed via the associated audit history. Any CMs based on the merged entity must be manually assigned to the appropriate one of the original two entities.

[0045] The ontology service 350 provides optimal interaction between ILR processes / services and ILR ontologies. Supported behavioral functions include, but are not limited to, ascertaining domain knowledge (including, but not limited to, terminology, relationships, definitions, and definition properties) from ILR semantically encoded data (e.g., CM data) and translating between external terminology (external terms and definitions) and ILR ontology concepts and semantic representations. The ILR semantic knowledge base is a curated formal modal of domain-specific information and conforms to a formal ontology syntax. It provides the fact-based, domain-specific knowledge that underpins the cognitive AI engine discussed above by serving as a knowledge source for the engine's machine learning process. The semantic knowledge base also provides a semantic language for representing all data, both keys and codifiable values. Semantic keys provide data context.

[0046] ILR data is semantically encoded. The coded data received in the payload is semantically transformed. The data is stored as an ILR concept code in addition to a terminology code, code description, and terminology code set.

[0047] The Knowledge Engine Service 212, working in conjunction with the Reasoner Service 330, is a general-purpose ILR rule execution platform that provides semantic-based decision support execution, with the resulting creation of new (i.e., added) data. It is ILR knowledge structure aware and interpretive. It applies rules, defined in the ILR rule language.

[0048] The persister service 360 ​​looks for messages whose state indicates they are ready to be stored in the database. This places the CM in JSON data storage. This can be accompanied by any of the ILR application services.

[0049] The CBR view builder service 230 is responsible for creating new data representations for a given context by aggregating data contained in curated documents (e.g., CMs) and / or perceived views using a context-best process to achieve a context-best view of the data using semantic-based operations. The CBR process is triggered by the persisted CBR view service 220 or the CBR view manager 240 and creates a best view of an entity based on the requested context (e.g., the context of the request). It obtains relevant knowledge structures from a filtered set of CMs and determines the "best" representation based on the requested context. "Best" is determined from contextual criteria. The CBR algorithm is based on matching data and / or selection multi-criteria parameters, such as, but not limited to, time or time period, data source (some data sources are better than others for a particular piece of data), data status (status identifies whether data has been revised, corrected, or updated), and knowledge about conditions, products, or procedures (which provides information used to determine better information or make inferences). For example, it applies an "isBetter" decision when comparing existing data with proposed data (e.g., replacement data) and takes the appropriate action. If the proposed data is better, it takes action A (e.g., update the CBR). If the proposed data is not better, it takes action B (e.g., do not update the CBR).

[0050] The persisted CBR view service 220 is responsible for managing CBR views (i.e., persisted CBR views), which are updated in real time as CMs are created. These are CBR views that are persisted in the ILR database and provide ready availability for delivery upon data request. The views that are persisted CBR views depend on views that are frequently used or important for the user / customer. If a persisted or otherwise pre-existing CBR view does not exist based on the requested data, the CBR view constructor will create a CBR view on demand and deliver the requested data.

[0051] CBR views may be indexed. Figure 9 shows an example of a CBR view index 242 in multiple JSON formats with pointers to existing individual CBR views. The index may be used to create CBR views from other CBR views. The system therefore supports multiple cognitive context views (i.e., CBR views) 244 based on selection data from the CM, as seen in Figure 10.

[0052] The system provides data externalization (i.e., it provides to selected third parties such as users, customers, suppliers, business partners, and the like) with access to resources (e.g., information, applications) that are important to enabling more effective operation (e.g., business operations).

[0053] An API (Application Programming Interface) is a standard set of protocols that allows applications to communicate with each other and exchange information. APIs act as gateways between applications, providing a defined set of rules that allow applications to "talk" with each other and share information. As seen in FIG. 11, an interactive API service (iAPI) 400 mediates between users of external web applications 600 and ILR data processes. ILR user authorization (i.e., security) management is performed by the iAPI service based on security best practices for protecting data using policies enforced by the API gateway. User authentication may be performed by the external web application or service, with the iAPI providing authorized data based on user / submitter / data requester credentials 610 passed to the iAPI, as seen in FIG. 12. Communication between external web applications or users / customers and the iAPI or other components of the ILR system may be via one or more telecommunications or similar networks, wired or wireless, including, but not limited to, the Internet, the World Wide Web, or the "cloud."

[0054] Authorization rights are based on the data requester's credentials, and the system returns only the requested data for which the requester is authorized. Restrictions can include ingestion restrictions (limiting the ILRs that are authorized), operational restrictions (affecting data actions that can be performed, such as adding or accessing data), and data restrictions (limiting the data that can be added or accessed based on class data). With regard to data restrictions, because data is understood through ontology coding, restrictions can be performed at any hierarchical level of the ontology. Examples of restricted data include, but are not limited to, financial data, personal identifiers, health data, and / or behavioral / mental health data.

[0055] An API data request 602 is sent by an external application 600. The iAPI service 400 automatically forwards the appropriate request to the CBR view manager 240, which translates the data request into a query language understandable to the ILR system. ILR data responsive to the request is delivered in the form of a view as described above, or is otherwise converted into the required format for delivery to the external application 604 by the bidirectional API service (e.g., ILR knowledge structure format is converted to HL7 FHIR format).

[0056] JSON data store 370 is a database where persisted ILR data is stored. It manages data storage by providing a mechanism for synchronizing and sharing data with multiple ILR processes in parallel. Data submitted by the persister service is stored here. Data requested by the CBR view builder service is provided here.

[0057] The system provides internalization / location support. Timestamps are translatable to the desired locale. Locale-specific actor name and / or address variants are supported. The semantic knowledge system supports multiple languages, and ontology concept terms can be transmitted in the language or languages ​​associated with the required locale.

[0058] Initial data acquisition is handled by the Data Acquisition Learning Engine (DALE) 300, which implements an integrated machine learning process to develop a robust interface for data acquisition. The target, or goal, is to convert inbound messages into an ILR standardized format while minimizing translation work and involving rapid implementation. The interface creation process includes: 1. Create an interface identification. 2. Feed an example message into the system. 3. Use machine learning through DALE to resolve model inconsistencies and exceptions. 4. Run the example messages through the learning engine to be examined by DALE. 5. DALE uses the suggested solution specification and the suggested solution reliability to generate a proposed interface definition. 6. The proposed interface definition is presented for human review and validation. 7. An example message is invoked through the validated interface definition to validate the interface definition. 8. The process is iterative: test messages that are not validated by item 7 above (i.e., contain "bad data") are resubmitted for review by DALE for further modifications or adjustments to the interface definition (see items 3 and 4 above). 9. Feedback is used to improve DALE.

[0059] The task of DALE is to develop an interface definition that is robust enough to learn when the incoming data stream deviates from the norm (i.e., learns errors) and respond to the context and its user / customer needs, and to initiate ILR system operations (e.g., creating and storing DMs and other operations as described above) for its users / customers. DALE's key components and machine learning processes are typically incorporated into cognitive AI services 310 for use during operation, as discussed above.

[0060] Virtually any type of content can be handled by the ILR system, including, but not limited to, images, text, free text, documents, media, external references, and the like. The present invention effectively separates content from data storage technology, so that content can be easily imported and exported. Supplemental content, including links to websites or text providing instructions or other information, may be delivered in association with the CBR view data manager. Content sent to users / customers / requestors is personalized based on the user / customer / requestor and context. ILR system parameter configurations, including site-specific versions, may also be stored.

[0061] System data backups are robust, with full point-in-time recovery (PITR). The ILR database contains dynamic data, and backups are complete and progressive, including write-ahead log (WAL) files (the system can therefore recover from catastrophic events). Static data (e.g., program files) backups are re-sourced from source control management (SCM). Data backups are automated, performed according to a recommended schedule, and configured to meet customer / user preferences. Backups can be stored in a customer-provided location. Disaster recovery options include hot standby, cold standby, and off-site replication.

[0062] To provide context for various computer-implemented aspects of the invention, the following discussion provides a brief, general description of a suitable computing environment in which various aspects of the invention may be implemented. The computing system environment is one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. A computing environment may contain any one or a combination of the components discussed below, may contain additional components, or some of the illustrated components may not be present. Various embodiments of the invention are operational with numerous general-purpose or special-purpose computing systems, environments, or configurations. Examples of computing systems, environments, or configurations that may be suitable for use with various embodiments of the present invention include, but are not limited to, personal computers, laptop computers, computer servers, computer notebooks, handheld devices, microprocessor-based systems, multiprocessor systems, TV set-top boxes and devices, programmable consumer electronics devices, mobile phones, personal digital assistants (PDAs), tablets, smartphones, touchscreen devices, smart TVs, internet-enabled appliances, internet-enabled security systems, internet-enabled gaming systems, internet-enabled watches, internet-enabled automobiles (or vehicles), network PCs, minicomputers, mainframe computers, embedded systems, virtualization systems, distributed computing environments, streaming environments, volatile environments, and the like.

[0063] Embodiments of the present invention may be implemented in the form of computer-executable instructions, such as program code or program modules, being executed by a computer, virtual computer, or computing device. Program code or modules may include programs, objects, components, data elements and structures, routines, subroutines, functions, and the like, which are used to perform or implement particular tasks or functions. Embodiments of the present invention may also be implemented in distributed computing environments. In such environments, tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium, and data and program code or modules may be located in both local and remote computer storage media, including memory storage devices such as, but not limited to, hard drives, solid-state drives (SSDs), flash drives, USB drives, optical drives, and Internet-based storage (e.g., "cloud" storage).

[0064] In one embodiment, the computer system comprises multiple client devices that communicate with one or more server devices through or via a network, although in some cases no server devices are used. In various embodiments, the network may include the Internet, an intranet, a wide area network (WAN), or a local area network (LAN). It should be noted that many of the methods of the present invention are operable within a single computing device.

[0065] The client devices may be any type of processor-based platform that is connected to a network and interacts with one or more application programs. Each client device includes computer-readable media in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) and random access memory (RAM), in communication with a processor. The processor executes computer-executable program instructions stored in the memory. Examples of such processors include, but are not limited to, microprocessors, ASICs, and the like.

[0066] The client device may further include a computer-readable medium in communication with the processor, which stores program code, modules, and instructions that, when executed by the processor, cause the processor to execute the program and perform steps described herein. The computer-readable medium can be any available medium that can be accessed by a computer or computing device and includes both volatile and nonvolatile media, and removable and non-removable media. The computer-readable medium may further include computer storage media and communication media. The computer storage medium includes media for storage of computer-readable instructions, data, data structures, or information such as program code or modules. Examples of computer-readable media include, but are not limited to, any electronic, optical, magnetic, or other storage or transmission device from which a computer processor may read instructions and store desired information, such as a floppy disk, a hard disk drive, a CD-ROM, a DVD, a magnetic disk, a memory chip, a ROM, a RAM, an EEPROM, a flash memory, or other memory technology, an ASIC, an configured processor, a CD-ROM, a DVD, or other optical disk storage device, a magnetic cassette, a magnetic tape, a magnetic disk storage device, or any other medium. Communication media include media that may transmit or carry instructions to a computer, including, but not limited to, a router, a private or public network, a wired network, a direct-wired connection, a wireless network, other wireless media (such as acoustic, RF, infrared, or the like), or other transmission device or channel. This may include computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism. The transmission may be wired, wireless, or both. Combinations of any of the above should also be included within the scope of computer-readable media. The instructions may include code from any computer programming language, including, for example, C, C++, C#, Visual Basic, Java, and the like.

[0067] Components of a general-purpose client or computing device may further include a system bus that connects various system components, including the memory and the processor. The system bus may be any of several types of bus structures, including, but not limited to, a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. Such architectures include, but are not limited to, an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0068] Computing devices and client devices may also include a basic input / output system (BIOS), which contains the basic routines that help to transfer information between elements within the computer, such as during start-up. The BIOS is typically stored in ROM. In contrast, RAM typically contains data or program code or modules that are accessible to or presently being operated on by the processor, such as, but not limited to, an operating system, application programs, and data.

[0069] A client device may also include various other internal or external components, such as a monitor or display, keyboard, mouse, trackball, pointing device, touchpad, microphone, joystick, satellite television dish, scanner, disk drive, CD-ROM or DVD drive, or other input or output devices. These and other devices are typically connected to the processor through a user input interface that is coupled to the system bus, but may also be connected by other interface and bus structures, such as a parallel port, serial port, game port, or universal serial bus (USB). A monitor or other type of display device is typically connected to the system bus through a video interface. In addition to a monitor, a client device may also include other peripheral output devices, such as speakers and printers, which may be connected through an output peripheral interface.

[0070] A client device may run on any operating system capable of supporting applications of the type disclosed herein. A client device may also support a browser or browser-enabled applications. Examples of client devices include, but are not limited to, personal computers, laptop computers, personal digital assistants, computer notebooks, handheld devices, cellular phones, mobile phones, smartphones, pagers, digital tablets, Internet appliances, and other processor-based devices. Users may communicate with each other and with other systems, networks, and devices through individual client devices over a network.

[0071] It is therefore to be understood that the embodiments and examples described herein have been chosen and described to best illustrate the principles of the invention and its practical application, thereby enabling those skilled in the art to best utilize the invention in various embodiments and with various modifications, as suitable for the particular uses envisioned. Although specific embodiments of the invention have been described, they should not be construed as exhaustive. There are certain variations that will be apparent to those skilled in the art.

Claims

1. 1. A system for managing entity life information, comprising: one or more processors or microprocessors in electronic communication with at least one database on a memory storage device, said one or more processors or microprocessors: receiving data entry messages containing entity care information from one or more data sources via a telecommunications network, at least some of the data entry messages being of different types and / or formats; Transforming a data input message into a payload manifest schema comprising one or more observables, the observables comprising discrete data key / value pairs that align parsed data from the data input message with a semantic ontology definition; Transforming the payload manifest schema into a curated manifest, the curated manifest comprising a multi-JSON semantic normalized representation of selected entity care data; and transmitting the curated manifest for storage in the at least one database; A system that is programmed to:

2. The system of claim 1 , wherein the curated manifest is immutable.

3. The system of claim 1 , wherein there is a single curated manifest created from a single data input message.

4. The system of claim 1 , wherein the curated manifest has a structure comprising a header section, an actor section, an item section, and an observable section.

5. 5. The system of claim 4, wherein the one or more processors or microprocessors are programmed to: create an observable component for each observable data key / value pair; create an observable by grouping one or more observable components; and add the observable to the observable section of the manifest.

6. 6. The system of claim 5, wherein the one or more processors or microprocessors are programmed to identify one or more actors within actor-related observables, perform an identification matching process to identify entities corresponding to the one or more actors, and populate actor and entity data into the actor section of the curated manifest.

7. 6. The system of claim 5, wherein the one or more processors or microprocessors are programmed to identify one or more items within an item-related observable and populate item data into the item categories of the curated manifest.

8. 10. The system of claim 1, wherein the one or more processors or microprocessors are programmed to receive, via a telecommunications network, a data request and, in response to the data request, provide a contextual best record view from best data in one or more curated manifests, the best data being determined from contextual criteria based on the requested context.

9. The system of claim 8 , wherein the contextual criteria comprises a data source.

10. The system of claim 8 , wherein the context criteria comprises a data status.

11. The system of claim 8 , wherein the contextual best record view is created on demand.

12. The system of claim 8 , wherein the contextual best-recorded view is a previously created persisted contextual best-recorded view.

13. The system of claim 12 , wherein the persisted contextual best-record view is updated in real time as curated manifests are created.

14. 2. The system of claim 1, wherein the receiving, converting, and transforming functions are performed using multiple process threads, each thread corresponding to a specific function, and multiple functions may be running simultaneously.

15. 1. A method for managing entity life information, comprising: one or more processors or microprocessors in electronic communication with at least one database on a memory storage device, said one or more processors or microprocessors: receiving, via a telecommunications network, one or more data input messages containing entity care information from one or more data sources by one or more processors or microprocessors in electronic communication with at least one database on a memory storage device, at least some of the data input messages being of different types and / or formats; Transforming a selected data input message into a payload manifest schema comprising one or more observables, the observables comprising discrete data key / value pairs that align parsed data from the data input message with a semantic ontology definition; Transforming the payload manifest schema into a curated manifest, the curated manifest comprising a multi-JSON semantic normalized representation of selected entity care data; and transmitting the curated manifest for storage in the at least one database; A method programmed to perform the above.

16. 16. The method of claim 15, wherein the curated manifest is immutable and there is a single curated manifest created from a single data input message.

17. the curated manifest has a structure comprising a header section, an actor section, an item section, and an observable section; The method comprises: creating an observable component for each observable data key / value pair and creating an observable by grouping one or more observable components; adding the observable to the observable section of the manifest; identifying one or more actors within the actor-related observables; performing an identity matching process to identify entities corresponding to said one or more actors; Populating the actor and entity data into the actor section of the curated manifest; identifying one or more items within the item-related observables; populating the item data into the item categories of the curated manifest; 16. The method of claim 15, further comprising:

18. receiving a data request via a telecommunications network; providing a contextual best-of-record view from the best data in one or more curated manifests in response to the data request; further comprising The method of claim 15 , wherein the best data is determined from contextual criteria based on the requested context, the contextual criteria comprising a data source and / or a data status.

19. 16. The method of claim 15, wherein the contextual best-record view is a previously created, persisted contextual best-record view that is updated in real time as curated manifests are created.

20. 16. The method of claim 15, wherein the process steps of receiving, translating, and converting are performed using multiple process threads, each thread corresponding to a specific process, and multiple processes may be running simultaneously.

Images