Single entity lifecycle recording engine and system

Abstract

A system, apparatus, and related methods for collecting, standardizing, evaluating, and processing entity lifecycle and care information from different information systems and sources. After collection is completed, life cycle and / or care data and information contained in the specific information will be converted, including standardized, processed, evaluated and converted into a Curred Manifest (CM), which is a persistent and immutable document compatible with specific configuration and design of an ILR platform / system in a specific background. The CMs are stored in one or more databases with the other plurality of CMs. The best context record (CBR) view may be a standard, pre-established view, or a "dynamic" or "on demand" constructed view for searching, locating, identifying, and reporting response data from the stored CMs.

Description

[0001] This application claims the benefit of priority to U.S. Provisional Application No. 63 / 408,501, filed on September 21, 2022, and U.S. Provisional Application No. 63 / 539,574, filed on September 20, 2023, the entire contents of both applications are incorporated herein by reference. Technical Field

[0002] The present invention relates to an apparatus and system for collecting, standardizing, evaluating and processing information about entities, including creating multiple curated entity lifecycle record components that are accessible to various context-optimal record views. Summary of the invention

[0003] In various exemplary embodiments, the present invention includes systems, devices, and related methods for collecting, standardizing, evaluating, and processing entity lifecycle and care information from different information systems and sources. "Entity" refers to an object, item, person, or thing that is cared for, collected, maintained, or similarly operated. An entity can be a living or inanimate object. In multiple embodiments, an entity has high value (such as, but not limited to, financial, emotional, historical, or other forms of value), and therefore, the entity will survive or be maintained or retained for a considerable period of time, and therefore needs to be monitored and recorded during its lifecycle or during maintenance or retention. Examples of “Entities” include, but are not limited to, animals (e.g., dogs, cats, horses, giraffes, etc.), individuals / humans (e.g., family members, service personnel, members, consumers, patients, clinicians, service providers, subscribers, users, etc.), vehicles (e.g., cars, motor vehicles, buses, trucks, vans, motorcycles, airplanes, trains, bulldozers, excavators, construction vehicles, etc.), items or objects (e.g., books, artwork, antiques, manuscripts, furniture, crystal, coins, jewelry, guns, etc.), equipment / machinery (e.g., robots, manufacturing equipment, field analyzers, computers, mobile computing devices, laptops, computer network servers and components, etc.), property (e.g., real estate lots, buildings, houses, bridges, roads, etc.), organizations (e.g., employers, government entities or agencies, commercial entities, payors, service providers, hospitals, laboratories, reference laboratories, imaging centers, nursing homes, etc.), and other forms of significant or valuable business or personal items or entities.

[0004] In several exemplary embodiments, the present invention includes a single Individual Entity Life Record (ILR) platform or system that uses its "connect" functionality to receive or actively mine multiple entity information streams and other data sources to obtain messages containing information about one or more entities, including but not limited to care data. One or more entities may be known in advance or identified by analyzing data. In the case where the entity has been identified, the entity care expert may also obtain the data by directly entering the data, and in some cases, specific entity information elements may also be obtained, which will be discussed in more detail below.

[0005] Once collected, the lifecycle and / or care data and information contained in a particular message is transformed, including being standardized, processed, evaluated, and converted into a Curated Manifest (CM), which is a persistent 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 along with multiple other CMs. The CM is not limited to the history of the entity, but may include all types of activities and events that the entity undergoes or has experienced.

[0006] Contextual Best Record (CBR) views can be standard, pre-built views or built "on the fly" or "on demand" to find, locate, identify, and report responsive data from stored CMs. The Rules Engine can apply rules to modify and / or enhance data and CBR views. The application of rules can create data and information that can then be stored as separate or new CMs. Data Externalization capabilities manage interactions with external users and queries, including providing API responses. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 It is a general relationship diagram between the main functions of the present invention.

[0008] Figure 2 Schematic diagram of the ILR system architecture with various application services.

[0009] Figure 3 Shows when there are three cooperating monomers Figure 2 system architecture.

[0010] Figure 4 Shows an example of an extended service using multi-process threads.

[0011] Figure 5 Schematic diagram of a planned checklist for converting a payload into an ILR structure.

[0012] Figure 6 The basic structure of a curated list is shown.

[0013] Figure 7 It is a detailed diagram of the data curation process.

[0014] Figure 8 Shows the use of Observables and Observations in creating curated lists and representing data in CBR views.

[0015] Fig. 9 An example of a CBR view index is shown.

[0016] Fig.10 Shows the relationships between multiple CBR views based on selected data in the curated list.

[0017] Fig.11 A schematic diagram showing the interactive API services associated with external applications and related ILR data processing.

[0018] Fig.12 Shows Fig.11 The interactive API service uses the credentials. DETAILED DESCRIPTION

[0019] In various exemplary embodiments, the present invention includes systems, devices and related methods for collecting, standardizing, evaluating and processing entity lifecycle and care information from different information systems and sources. "Entity" refers to an object, item, person or thing that is cared for, collected, maintained or similarly operated. An entity can be a living or inanimate object. In multiple embodiments, an entity has high value (for example, but not limited to, financial, emotional, historical or other forms of value), and therefore, the entity will survive or be maintained or retained for a considerable period of time, and therefore needs to be monitored and recorded during its lifecycle or during maintenance or retention. Examples of “Entities” include, but are not limited to, animals (e.g., dogs, cats, horses, giraffes, etc.), individuals / humans (e.g., family members, service personnel, members, consumers, patients, clinicians, service providers, subscribers, users, etc.), vehicles (e.g., cars, motor vehicles, buses, trucks, vans, motorcycles, airplanes, trains, bulldozers, excavators, construction vehicles, etc.), items or objects (e.g., books, artwork, antiques, manuscripts, furniture, crystal, coins, jewelry, guns, etc.), equipment / machinery (e.g., robots, manufacturing equipment, field analyzers, computers, mobile computing devices, laptops, computer network servers and components, etc.), property (e.g., real estate lots, buildings, houses, bridges, roads, etc.), organizations (e.g., employers, government entities or agencies, commercial entities, payors, service providers, hospitals, laboratories, reference laboratories, imaging centers, nursing homes, etc.), and other forms of significant or valuable business or personal items or entities.

[0020] Figure 1 The general relationship between the main functions of the present invention is shown. In general, the present invention includes a single Individual Entity Life Record (ILR) platform or system that uses its "connect" function 10 to receive or actively mine multiple entity information streams and other data sources 8 to obtain messages containing information about one or more entities, including but not limited to care data. The system can receive this data through one or more telecommunications networks or similar wired or wireless networks, including but not limited to the Internet, the World Wide Web, or the "Cloud". One or more entities may be known in advance or identified by analyzing data. In the case where the entity has been identified, the entity care expert can also obtain the data by directly entering the data, and in some cases, specific entity information elements can also be obtained, which will be discussed in more detail below.

[0021] Once collected, the lifecycle and / or care data and information contained in a particular message is transformed 20, including being standardized, processed, evaluated, and converted into a Curated Manifest 100 (CM), which is a persistent 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 along with multiple 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 undergoes or has experienced.

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

[0023] Figure 2 A general schematic diagram of the ILR system architecture is shown, which identifies the various services and related components used to perform the five basic functions described above to create and maintain an ILR (i.e., a single entity lifecycle record). It is important to note that the ILR for a single entity is not a single object (such as in an object-oriented program) nor a single record (such as in a database). Instead, the data is stored in ILR-specified data structures in multiple immutable and persistent CMs, which are then used to generate and provide multiple CBR views, as described in this article.

[0024] Figure 2 Components shown include, but are not necessarily limited to: Data Acquisition Learning Engine (DALE) 300, Cognitive AI Service 310, Entity Resolution Service 320, Rate Regulator Service 330, Content Service 340, Ontology Service 350, Persistent 360, JSON Data Store 370, Security Service 380, Payload Feeder 202, Payload Service 204, Inventory Curation Service 206, Data Refinement Service 208, Identification Service 210, Knowledge Engine Service 212, Persisted CBR View Service 220, CBR View Generator 230, CBR View Manager 240, and Interactive API Service 400. Communications are handled through a combination of internal bus 80 and external bus 90.

[0025] Because the hardware and related resources available to specific installations of the ILR platform can vary widely, certain individual processes and components of an ILR system can be organized by being assigned to "cooperating monads" to make appropriate use of these available resources for speed and efficiency, depending on the needs and context of each specific installation. In general, a monad is a group of threads that coordinate the execution of a primary processing task, and the groups communicate with each other via internal memory-based queues. Thus, for example Figure 2 Six services (payload service, inventory planning service, data refinement service, identification service, persistent CBR view service and knowledge engine service) and ontology service are shown in a single monolith 60. All of these services can communicate quickly through an internal bus 80. In another configuration, such as Figure 3 As shown, these services are re-divided into three mutually cooperating monomers 60a-c. Each monomer provides the main service because it is used by each other service. In this figure, each monomer also provides persistence services. Depending on the needs and environment of a specific installation, these services can be organized in multiple monomers in other combinations.

[0026] Services in each monolith communicate internally via the corresponding internal bus, and communicate with services in other monoliths via the external bus (usually slower). The internal bus provides fast queuing and communication between ILR services in the corresponding monolith. Services and related processes can see the CMs of the previous process / service via the internal bus. The external bus (or multiple buses) provides infrastructure that allows different processes / services to work together in a decoupled manner, mainly involving processes / services interacting with CMs, input payloads 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 processes / services to work simultaneously.

[0027] The ILR system architecture is designed to scale to achieve high performance (horizontally scaling as described above, as well as scaling based on end-user / customer infrastructure and objects). Figure 4 An example of scaling using multi-process threading is shown. The steps in a processor (or multiple processors) may be multiple, i.e., the system can run as many of each service as is useful for system performance and balance (e.g., 4 payload services, 5 inventory curation services, 3 data validator services, etc.). Each process is multi-threaded, where each thread is a specific service (e.g., inventory curation service).

[0028] Therefore, the system adopts a layered approach, which is flexible and adaptable. Due to the unified system configuration, the system is highly maintainable, reliable and has high data availability. Failover design can be performed based on end-user / customer infrastructure and objects (i.e., failover mode or backup operation mode, in which backup computing devices, such as servers, hardware components and / or networks, automatically take over operations when the primary system or part of it fails, thereby preventing, eliminating or reducing operational interruptions and any resulting negative effects).

[0029] The ILR system receives various types of data input messages from various sources through payload feeders 202. All data input, regardless of type, is referred to herein as "payloads", including but not limited to data exchange messages and API requests. The feeder can process messages from queues or topics. In particular, it can monitor and listen to payloads placed on queues. The system can parse various input message types, including but not limited to API, delimiter, HL7 FH1R, HL7v2, HL7 CCD / CDA, NCPDP, and X12.

[0030] The Payload Feeder monitors and manages the connectivity runtime components, including the channel-based interface engine. It provides connectivity to source systems, accepts any inbound message format, provides real-time and batch loading, provides initial message processing (i.e., rule-based filtering and routing, syntax validation, edit checking, etc.), provides message conversion, queuing, forwarding, and storage, provides message logging, and manages message priorities. While payloads can be processed based on the time they are received (e.g., first-in, first-out), in a preferred embodiment, payloads are processed after a priority (e.g., normal, high, immediate) is determined based on their source and / or type. For example, API interactions involving end users / customers will typically be prioritized as "immediate" priority.

[0031] The payload service 204 parses the input payload and converts it 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, matching the parsed data in the payload with the semantic ontology definition. These data are called "observables". The processed payload (i.e., PMS) is then sent to the manifest planning service 206 on the internal bus. It should be noted that, as described above, this transmission (and subsequent related transmissions or communications discussed below) is based on the assumption that the services involved are located in the same monolith. If the transmission or other communication is between services in different monoliths, an external bus will be involved.

[0032] The inventory curation service 206 takes each PMS from the bus and processes and transforms the paired observables into an ILR multi-JSON semantically normalized representation. Both contextual and externally encoded data are represented as ontology concepts. Data is grouped according to context based on the interpretation of semantic definitions (see discussion of ontology services below). Related fields are grouped into related observation groups. Related observation groups are further grouped based on the role of the actor they observe (e.g., service provider, patient, primary care physician, etc.). Related observation groups can also be further grouped based on the context of the service and the context of the supply products (i.e., items) used when performing the service. The final ILR multi-JSON semantically normalized representation is the initial curated inventory associated with the payload.

[0033] Figure 5 A representative diagram of such transformation is shown of a payload received from source 502, which is processed to produce a parsed payload 504. The parsed data fields are then matched to observables 506 and subsequently transformed into an ILR structured curated manifest 508.

[0034] Figure 6 The basic structure of a curated manifest is shown, including a header section 510, an actor section 512, an item section 514, and an observation group section 516. A single CM is created for each payload received, resulting from multiple processing operations. Only the data of interest (i.e., the "curated" data) is converted to an ILR representation in the CM. The CM is immutable and persistent.

[0035] Figure 7 The data curation process for creating a CM is shown in more detail. The system creates an observation component for each observable data pair 520 and attaches the observation component to an observation item 522, which is then added to the observation section 524. Next, the system groups observation groups that describe actor roles 526, which are then added to the actor section 528. Next, the system groups observation groups that describe items 530. The system then calls the data refinement service 532 and the identification service 534 to add the item and actor identifications to the item and actor sections 536, 538. The header section of the CM contains general data about the source payload, as well as the identification and creation of the CM itself.

[0036] The CM structure is created according to the ontology description language defined for a specific application. Each source data field is represented as an observation component. In some embodiments, it includes a role identified by a key and an ontology concept identifier that provides context for the specific field. The source data value is represented by another key-value pair, where the value attribute property provides the key of the source data value. The observation components are grouped into an observation group, thereby providing context based on the ontology definition. For example:

[0037]

[0038] like Figure 8 As shown, the observable item 542 and observation group 544 ontology definitions provide 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 detail below, the matching data of all CMs is compared to determine the "best" data based on the situation or purpose (i.e., context) for which the data is requested. Data that is considered "best" in one situation may not be "best" in another situation. The best data for a given context is then represented in a multi-JSON document called a CBR view 548.

[0039] During the data transformation process, the data refinement service 208 manages the sending of CMs to the cognitive AI service 310 to automatically check data integrity and automatically remediate or resolve issues that may have been discovered. The data refinement service in turn receives remediation solutions to data issues and places them into the CM. If issues that require resolution / remediation are beyond the capabilities of the cognitive AI service, these issues are flagged and notifications are generated and sent.

[0040] like Figure 2 As shown, cognitive AI service 310 is generally available for all services. It solves problems with problem data based on what it has learned. It can solve semantic problems such as incomprehensible data (e.g., UnCIDed), data conversion problems (e.g., parsing or combination of data values, actor name conversion, address and phone conversion, timestamp conversion, and value conversion). It can also perform validation logic to check the quality and consistency of source data, such as meaningless data (e.g., blood pressure = 0; male pregnancy; data generation date is earlier than a person's date of birth or conception date). The validation logic includes:

[0041] Data Type Validation - Compares individual characters of received data to the expected, known primitive data type.

[0042] Format Data Validation - Validates that certain data values ​​conform to expected minimum / maximum ranges, sequences, or consistency patterns of characters.

[0043] Missing data validation - Identify missing required data (e.g., missing time zone, missing identifier for assigned authority).

[0044] Logical data validation - Verifies that (i) data fields are consistent with each other, (ii) dates representing activities are in the appropriate order, and (iii) statuses and dates are related.

[0045] It may also identify and resolve issues such as unconnected or orphaned data. The service may also enhance data beyond the received data, including but not limited to inference, confidence assessment and / or rating, event date determination, provenance, and use of semantic knowledge. As described above, it further enhances, increases, and / or improves the quality, value, and / or scope of the data contained in the CM itself. It may also provide service variations, such as enforcing appropriate CIDs based on feature concepts, provided that the service has sufficient context to identify what it is processing.

[0046] ILR systems rely on the ability to accurately identify and / or create entities, and the ability to correctly link data through or based on entities. As mentioned above, there are many types of entities. During the data conversion process, the identification service 210 detects actors within the CM that require actor identification. It submits the actor knowledge structure (the group of observations associated with the actor) 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, deterministic, and data source specific. It only uses data from the submitted CM, and its focus is on the actor part. The entity resolution service implements an identity matching process to identify the entity and returns the resolved actor / entity identification (e.g., the ILR actor key assigned to the entity). The identification service receives the resolved actor / entity identification and updates the actor data in the CM.

[0047] 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. There is a library of matching criteria so that these criteria can be reused. As best practices are established, they can be easily applied to another data source. Rules support entity type matching (e.g., person vs. organization) and role-based matching (e.g., patient, provider vs. supplier). Each rule set contains one or more criteria that must be met for a successful match to occur.

[0048] When two entities in an ILR system are later identified as the same entity, the system merges them by creating a third entity with its own identifying key. Data from the original two entities is essentially merged by linking to the third entity as well. CMs and payloads point not only to the original entities, but also to the new entity. Any new data generated directly by or on the new third entity (i.e., the merged entity) will be attached to that entity. Merged (linked) entities can be separated by unlinking them (i.e., "unmerging"). An audit history is created for each entity involved in the unmerge, and previously merged entities can be accessed through the relevant audit history. Any CM on the merged entity must be manually assigned to the appropriate one of the original two entities.

[0049] The ontology service 350 provides optimal interaction between ILR processes / services and the ILR ontology. Supported behavioral functions include but are not limited to determining domain knowledge (including but not limited to terms, relationships, definitions, and definitional features) from ILR semantically encoded data (such as CM data), and converting between external terms (external terms and definitions) to ILR ontology concepts and semantic expressions. The ILR semantic knowledge base is a curated formal model of domain-specific information and follows a formal ontology syntax. It provides fact-based, domain-specific knowledge that supports the above-mentioned cognitive AI engine by acting as a source of knowledge for the engine's machine learning process. The semantic knowledge base also provides a semantic language for representing all data, including keys and encodable values. Semantic keys provide data context.

[0050] ILR data is semantically encoded. The encoded data received in the payload is semantically transformed. The data is stored as an ILR concept code (CID) along with the term code, code description and term code set. The knowledge engine service 212 used in conjunction with the rate adjuster service 330 is a general ILR rule execution platform that is capable of performing semantic-based decision support and creating new (i.e., added) data thereby. It understands the knowledge structure of the ILR and has interpretation capabilities. It applies the rules defined in the ILR rule language.

[0051] The persistence service 360 ​​looks for messages in a state that indicates they are ready to be stored in the database. It places the CMs in a JSON data store. Any ILR application service can participate.

[0052] The CBR view generator service 230 is responsible for creating a new data representation for a given context by aggregating data contained in curated documents (e.g., CMs) and / or cognitive views using a contextual best process to achieve a contextual best view of the data using semantic-based operations. The CBR process is triggered by the persistent CBR view service 220 or the CBR view manager 240 and builds an optimal view for an entity based on the requested context (e.g., the requested context). It obtains relevant knowledge structures from a set of filtered CMs and determines the "best" representation based on the requested context. "Best" is determined based on contextual criteria. The CBR algorithm is based on matching data and / or selecting multiple criteria parameters, such as, but not limited to, time or time period, data source (some data sources are better than others for specific data fields), data status (status indicates whether the data has been modified, corrected, or updated), and knowledge about the condition, product, or program (provides information for determining better information or making inferences). For example, when comparing existing data with proposed data (such as replacement data), it applies "isBetter" to make a determination and takes appropriate action. If the proposed data is better, action A (e.g., update CBR) is taken. If the suggested data is not better, then action B is taken (eg, do not update the CBR).

[0053] The persistent CBR view service 220 is responsible for managing CBR views (i.e., persistent CBR views) that are updated in real time as CMs are created. These CBR views are persisted in the ILR database and can be delivered at any time based on data requests. Which views belong to persistent CBR views depends on which views are frequently used or critical to the user / client. Based on the requested data, if there is no persistent or pre-existing CBR view, the CBR view generator will create a CBR view on demand to deliver the requested data.

[0054] CBR views can be indexed. Fig. 9 An example of a multiple JSON formatted CBR view index 242 is shown with pointers to existing individual CBR views. The index can be used to create CBR views from other CBR views. Thus, the system supports multiple cognitive context views (i.e., CBR views) 244 based on selected data from CMs, such as Fig.10 shown.

[0055] The system provides data externalization (i.e., it provides access to key resources (e.g., information, applications) to selected third parties such as users, customers, suppliers, business partners, etc.) to enable more efficient operations (e.g., business operations). APIs (Application Programming Interfaces) are a set of standard protocols that enable applications to communicate with each other to exchange information. APIs act as a gateway between applications, providing a defined set of rules that allow applications to "talk" to each other and share information. Fig.11 As shown, the interactive API service (iAPI) 400 mediates between users of external web applications 600 and ILR data processes. Management of ILR user authorization (i.e., security) is performed by the iAPI service in accordance with security best practices to protect data using policies enforced by the API gateway. User authentication can be performed by the external web application or service, and the iAPI provides authorization data based on the credentials 610 of the user / submitter / data requester passed to the iAPI, such as Fig.12 Communications between external web applications or users / clients and the iAPI or other components of the ILR system may occur over one or more telecommunications networks or similar wired or wireless networks, including but not limited to the Internet, the World Wide Web, or the "Cloud."

[0056] Authorization permissions are based on the credentials of the data requester, and the system only returns requested data that the requester has been authorized to request. Restrictions may include group restrictions (limiting which ILRs can be authorized), operation restrictions (affecting which data operations can be performed, such as adding or accessing data), and data restrictions (limiting which data can be added or accessed based on class data). Regarding data restrictions, since data is understood through ontology encoding, restrictions can be placed at any 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.

[0057] API data request 602 is sent by external application 600. iAPI service 400 forwards the appropriate request to CBR view manager 240, which translates the data request into a query language understandable by the ILR system. As described above, the ILR data in response to the request is delivered in the form of a view, or converted to the requested format (e.g., converting the ILR knowledge structure format to the HL7 FHIR format) by the interactive API service for delivery to the external application 604.

[0058] The JSON Data Store 370 is a database that stores persistent ILR data. It manages data storage by providing a mechanism to synchronize and share data with multiple ILR processes simultaneously. Data submitted by the persistence service is stored here. Data requested by the CBR View Generator service is provided from here. The system provides internalization / localization support. Timestamps can be converted to the required locale. Name changes and / or address changes for actors in a specific region are supported. The semantic knowledge system supports multiple languages, and ontology concept terms can be sent in one or more languages ​​associated with the requested locale.

[0059] Initial data acquisition is handled by the Data Acquisition Learning Engine (DALE) 300, which implements an integrated machine learning process to develop a powerful interface for data acquisition. Its goal or purpose is to convert inbound messages into an ILR standardized format while minimizing the conversion effort and implementing it quickly. The interface building process includes the following:

[0060] 1. Create an interface identifier.

[0061] 2. Enter a sample message into the system.

[0062] 3. Use machine learning through DALE to resolve model inconsistencies and anomalies.

[0063] 4. Run the sample message through the learning engine for DALE to check.

[0064] 5.DALE generates a proposed interface definition, which contains a description of the proposed solution and the confidence level in the proposed solution.

[0065] 6. Provide the proposed interface definition for manual review and verification.

[0066] 7. Run a sample message through the verified interface definition to verify the interface definition.

[0067] 8. This process is iterative. Test messages that fail the validation in item 7 above (i.e. contain "bad data") will be resubmitted to DALE for review for further modification or adjustment of the interface definition (see items 3 and 4 above).

[0068] 9. Feedback is used to enhance DALE.

[0069] The task of DALE is to understand how the incoming data stream differs from the standard (i.e., understand what the error is) and, based on the context and user / customer needs, develop an interface definition that is sufficiently robust to enable operation of the ILR system for that user / customer (e.g., creating and storing DMs, and other operations as described above). As described above, key components of DALE and machine learning processes are typically integrated within cognitive AI services 310 for use during operations.

[0070] In fact, the ILR system can handle almost any type of content, including but not limited to images, text, free text, documents, media, external references, etc. The present invention effectively separates the content from the data storage technology, so the content is easy to import and export. Supplemental content can be associated with the CBR view data manager, including links to websites or text describing instructions or other information. The content delivered to the user / client or requester is personalized based on the user / client / requester and the context. ILR system parameter configurations can also be stored, including versions for specific sites.

[0071] The system data backup function is powerful, with full point-in-time recovery (PITR) capabilities. The ILR database contains dynamic data, and the backup is complete and incremental, including write-aheadlog (WAL) files (so the system can recover from catastrophic events). Static data (such as program files) backup is resourced by Source Control Management (SCM). Data backup is automated, performed according to a recommended schedule, and configured to accommodate customer / user preferences. Backups can be saved to a location provided by the customer. Disaster recovery options include hot backup, cold backup, and offsite replication.

[0072] To provide a background for various computer implementation aspects of the present invention, the following discussion provides a brief, general description of a suitable computing environment in which various aspects of the present invention can be implemented. The computing system environment is an example of a suitable computing environment, but is not intended to impose any limitations on the scope of use or functionality of the present invention. The computing environment may include any one or combination of the components discussed below, and may include other components, or may lack some of the illustrated components. Various embodiments of the present invention may operate with many general or special 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, laptops, computer servers, computer notebooks, handheld devices, microprocessor-based systems, multiprocessor systems, television set-top boxes and devices, programmable consumer electronics, mobile phones, personal digital assistants (PDAs), tablet computers, smart phones, touch screen devices, smart TVs, Internet-enabled appliances, Internet-enabled security systems, Internet-enabled gaming systems, Internet-enabled watches; Internet-enabled cars (or vehicles), networked personal computers, microcomputers, mainframe computers, embedded systems, virtual systems, distributed computing environments, streaming media environments, unstable environments, etc.

[0073] Embodiments of the present invention can be implemented in the form of computer executable instructions, such as program codes or program modules executed by computers, virtual computers or computing devices.Program codes or modules can include programs, objects, components, data elements and structures, routines, subroutines, functions, etc. These are used to perform or implement specific tasks or functions.Embodiments of the present invention can also be implemented in a distributed computing environment.In this environment, tasks are performed by remote processing devices linked by a communication network or other data transmission media, and data and program codes or modules can be located in local and remote computer storage media, including memory storage devices, such as but not limited to hard disk drives, solid-state drives (SSDs), flash drives, USB drives, optical disk drives, and Internet-based storage (such as "cloud" storage).

[0074] In one embodiment, the computer system includes multiple client devices that communicate with one or more server devices via a network, although in some cases no server device is 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 methods of the present invention can be operated in a single computing device.

[0075] The client device can be any type of processor-based platform that is connected to a network and interacts with one or more applications. Each client device includes a computer-readable medium in communication with a processor in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) and random access memory (RAM) that communicate with the 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.

[0076] The client device may also include a computer-readable medium in communication with the processor, the medium storing program codes, modules and instructions, which, when executed by the processor, cause the processor to execute the program and perform the steps described herein. Computer-readable media can be any available media that can be accessed by a computer or computing device, including volatile and non-volatile media, and removable and non-removable media. Computer-readable media may also include computer storage media and communication media. Computer storage media include media for storing information, such as computer-readable instructions, data, data structures, or program codes or modules. Examples of computer-readable media include, but are not limited to, any electronic, optical, magnetic or other storage or transmission device, floppy disk, hard drive, compact disk read-only memory (CD-ROM), digital video disk (DVD), disk, memory chip, ROM, RAM, electrically erasable programmable read-only memory (EEPROM), flash memory or other storage technology, ASIC, configuration processor, CDROM, DVD or other optical disk storage, cassette, tape, disk storage or other magnetic storage device, or any other medium from which a computer processor can read instructions or store required information. Communication media include media that can transmit or carry instructions to a computer, including but not limited to routers, private or public networks, wired networks, direct wired connections, wireless networks, other wireless media (such as acoustic, radio frequency, infrared, etc.) or other transmission devices or channels. 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 transmission mechanism. The transmission may be wired, wireless, or both. Any combination of the above should also be included in the scope of computer-readable media. Instructions may include code from any computer programming language, including, for example, C, C++, C#, Visual Basic, Java, etc.

[0077] Components of a general-purpose client or computing device may also include a system bus that connects various system components (including memory and processors). The system bus can be any of a variety of 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 structures. Such architectures include but are not limited to Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses.

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

[0079] The client device may also include various other internal or external components, such as a monitor or display, keyboard, mouse, trackball, pointer device, touchpad, microphone joystick, satellite dish, scanner, disk drive, CD-ROM or DVD drive, or other input or output device. These devices and other devices are usually connected to the processor through a user input interface coupled to the system bus, but can also be connected through other interfaces and bus structures, such as parallel ports, serial ports, game ports, or universal serial bus (USB). Monitors or other types of display devices are usually connected to the system bus through video interfaces. In addition to monitors, client devices may also include other peripheral output devices, such as speakers and printers, which can be connected through output peripheral interfaces.

[0080] The client device can run on any operating system that can support the application type disclosed herein. The client device can also support a browser or an application that supports a browser. Examples of client devices include, but are not limited to, personal computers, notebook computers, personal digital assistants, computer notebooks, handheld devices, mobile phones, mobile phones, smart phones, pagers, digital tablet computers, Internet devices, and other processor-based devices. Users can communicate with each other through the network through their respective client devices, and communicate with other systems, networks, and devices.

[0081] Therefore, it should be understood that the embodiments and examples selected and described herein are intended to better illustrate the principles of the present invention and its practical application, so that those of ordinary skill in the art can better utilize the present invention in various embodiments and make various modifications to suit the intended specific use. Although specific embodiments of the present invention have been described, these embodiments are not exhaustive. For those skilled in the art, the present application has many variations.

Claims

1. A system for managing entity lifecycle information, including: One or more processors or microprocessors in electronic communication with at least one database on a memory storage device, wherein the one or more processors or microprocessors are programmed to: receiving data input information including entity care information from one or more data sources via a telecommunications network, wherein at least a portion of the data input information is of different types and / or formats; Converting the data input information into a payload manifest schema comprising one or more observable items, wherein the observable items comprise discrete data key-value pairs, and matching parsed data in the data input information with a semantic ontology definition; converting the payload manifest schema into a curated manifest comprising a multi-JSON semantically normalized representation of selected entity care data; as well as The curated list is sent to at least one of the databases for storage.

2. The system according to claim 1, characterized in that The curated list is immutable.

3. The system according to claim 1, characterized in that Contains a single curated list created from a single data input.

4. The system according to claim 1, characterized in that The structure of the curated list includes a title part, an actor part, an item part and an observation part.

5. The system according to claim 4, characterized in that The one or more processors or microprocessors are programmed to create an observation component for each observable data key-value pair, generate an observation group by grouping the one or more observation components, and add the observation group to the observation portion of the manifest.

6. The system according to claim 5, characterized in that The one or more processors or microprocessors are programmed to identify one or more actors in an actor-related observation, perform an identity matching process to identify entities corresponding to the one or more actors, and enter actor and entity data in the actor portion of the curated list.

7. The system according to claim 5, characterized in that The one or more processors or microprocessors are programmed to identify one or more items in the item-related observations and enter item data in the item portion of the curated list.

8. The system according to claim 1, characterized in that The one or more processors or microprocessors are programmed to receive a data request via a telecommunications network and provide a contextual best record view from the best data of one or more of the curated lists in response to the data request, wherein the best data is determined based on the contextual criteria of the request.

9. The system according to claim 8, characterized in that The context criteria include a data source.

10. The system according to claim 8, characterized in that The context criteria include data status.

11. The system according to claim 8, characterized in that The contextual best record view is created on demand.

12. The system of claim 8, wherein: The contextual best record view is a pre-created persistent contextual best record view.

13. The system according to claim 12, characterized in that The persistent context best record view is updated in real time as curated lists are created.

14. The system of claim 1, wherein: The receiving function, the converting function and the transmitting function are executed by multi-process threads, where each thread corresponds to a specific function and multiple functions run simultaneously.

15. A method for managing entity lifecycle information, comprising: One or more processors or microprocessors in electronic communication with at least one database on a memory storage device, wherein the one or more processors or microprocessors are programmed to: The one or more processors or microprocessors are in electronic communication with at least one database on a memory storage device via a telecommunications network to receive one or more data inputs containing entity care information from one or more data sources, wherein at least a portion of the data inputs are of different types and / or formats; Converting the selected data input information into a payload manifest schema comprising one or more observables, the observables comprising discrete data key-value pairs, and matching parsed data in the data input information to a semantic ontology definition; converting the payload manifest schema into a curated manifest comprising a multi-JSON semantically normalized representation of selected entity care data; and said sending of a curated list for storage in at least one of said databases.

16. The method according to claim 15, characterized in that The curated list is immutable and comprises a single curated list created from a single data input information.

17. The method according to claim 15, characterized in that The structure of the curated list includes a title part, an actor part, an item part and an observation part, and further includes the following steps: creating an observation component for each observable data key-value pair, generating an observation group by grouping one or more of the observation components; adding the observation group to the observation section of the checklist; Identify one or more actors in the actor-related observations; performing an identity matching process to identify an entity corresponding to the one or more actors; entering actor and entity data in the actors section of said curated list; identifying one or more items in the observations associated with the item, and Item data is entered in the Items section of the curated list.

18. The method according to claim 15, characterized in that The following steps are also included: receiving a data request via a telecommunications network; as well as providing a contextual best record view from the best data from one or more of said curated lists in response to a request for data; The best data is determined based on contextual criteria of the request, wherein the contextual criteria include data source and / or data status.

19. The method according to claim 15, characterized in that The contextual best record view is a pre-created persistent contextual best record view that is updated in real time as the curated list is created.

20. The method according to claim 15, characterized in that The process steps of receiving, converting and transmitting are executed by multi-process threads, each thread corresponds to a specific process, and multiple processes are carried out simultaneously.

Images