WO2024065061A1 - Healthcare record virtualization - Google Patents

Abstract

A method implements healthcare virtualization. The method includes receiving a source event at a collection address from a source system. The source event corresponds to a source record stored by the source system and includes a source patient identifier and a timestamp. The method further includes normalizing the source event to generate a normalized event using a processor to extract a key value pair from the source event. The normalized event federated to the source system. The normalized event includes the source patient identifier and the timestamp. The method further includes matching a unique patient identifier to the source patient identifier to form a matched event federated to the source system and consolidating the matched event to form a consolidated event federated to the source system. The method further includes transmitting the consolidated event to a subscriber system using a subscription address.

Description

HEALTHCARE RECORD VIRTUALIZATION

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of US Provisional Application 63/411,574, filed September 29, 2022, which is incorporated herein by reference.

BACKGROUND

[0002] Healthcare information systems may have data stored in various departments, facilities, and electronic health record (EHR) systems. Each provider may have their own multiple redundant systems that may each duplicate records of events. A single event, e.g., a patient visit, consultation, prescription, etc., may be recorded in records duplicated in multiple systems. The data silos with record duplication for healthcare information systems make it challenging to access and share patient information across different providers and locations.

SUMMARY

[0003] In general, in one or more aspects, the disclosure relates to a method implementing healthcare virtualization. The method includes receiving a source event at a collection address from a source system. The source event corresponds to a source record stored by the source system and includes a source patient identifier and a timestamp. The method further includes normalizing the source event to generate a normalized event using a processor to extract a key value pair from the source event. The normalized event federated to the source system. The normalized event includes the source patient identifier and the timestamp. The method further includes matching a unique patient identifier to the source patient identifier to form a matched event federated to the source system and consolidating the matched event to form a consolidated event federated to the source system. The source record corresponds to the consolidated event, the matched event, the normalized event, and the source event. The source record is matched to a different record from a different system. The method further includes transmitting the consolidated event to a subscriber system using a subscription address.

[0004] In general, in one or more aspects, the disclosure relates to a system implementing healthcare virtualization. The system includes a processor and an application executing on the processor. When executed, the application performs receiving a source event at a collection address from a source system. The source event corresponds to a source record stored by the source system and includes a source patient identifier and a timestamp. The application further performs normalizing the source event to generate a normalized event using a processor to extract a key value pair from the source event. The normalized event federated to the source system. The normalized event includes the source patient identifier and the timestamp. The application further performs matching a unique patient identifier to the source patient identifier to form a matched event federated to the source system and consolidating the matched event to form a consolidated event federated to the source system. The source record corresponds to the consolidated event, the matched event, the normalized event, and the source event. The source record is matched to a different record from a different system. The application further performs transmitting the consolidated event to a subscriber system using a subscription address.

[0005] In general, in one or more aspects, the disclosure relates to a method implementing healthcare virtualization. The method includes transmitting a subscription address to receive a consolidated event. Generating the consolidated event includes receiving a source event at a collection address from a source system. The source event corresponds to a source record stored by the source system and includes a source patient identifier and a timestamp. Generating the consolidated event includes normalizing the source event to generate a normalized event using a processor to extract a key value pair from the source event. The normalized event federated to the source system. The normalized event includes the source patient identifier and the timestamp. Generating the consolidated event includes matching a unique patient identifier to the source patient identifier to form a matched event federated to the source system and consolidating the matched event to form the consolidated event federated to the source system. The source record corresponds to the consolidated event, the matched event, the normalized event, and the source event. The source record is matched to a different record from a different system. The method further includes receiving the consolidated event by a subscriber system using a subscription address. The consolidated event is displayed by the subscriber system.

[0006] Other aspects of the invention will be apparent from the following description and the appended claims.

BRIEF DESCRIPTION OF DRAWINGS

[0007] FIG. 1 shows a system in accordance with disclosed embodiments.

[0008] FIG. 2 shows a flowchart in accordance with disclosed embodiments.

[0009] FIG. 3, FIG. 4, and FIG. 5 show examples in accordance with disclosed embodiments.

[0010] FIG. 6 shows a high level data flow in one or more embodiments.

[0011] FIG. 7 shows an overall architecture diagram in accordance with one or more embodiments.

[0012] FIG. 8 shows a diagram of a data collection service in accordance with one or more embodiments.

[0013] FIG. 9 shows a diagram of an event storage layer in accordance with one or more embodiments.

[0014] FIG. 10 shows an electronic health data communication scenario in accordance with one or more embodiments.

[0015] FIG. 11 shows a diagram of a golden operational model layer in accordance with one or more embodiments. [0016] FIG. 12 shows a diagram of a data virtualization layer in accordance with one or more embodiments.

[0017] FIGS. 13 and 14 show examples of the output messages that the system emits to subscribed clients.

[0018] FIGS. 15 and 16 show the schema of events that are saved in the event storage layer.

[0019] FIG. 17 shows a sample configuration of anchor attributes that are used to provide a matching score to consolidate patient records.

[0020] FIG. 18 shows a diagram describing the workflow of the patient matching service.

[0021] FIGS. 19 and 20 show an example API request and response when querying the data virtualization API.

[0022] FIGS. 21 A and 21B show computing systems in accordance with one or more embodiments of the invention.

[0023] Like elements in the various figures are denoted by like reference numerals for consistency.

DETAILED DESCRIPTION

[0024] To support consolidated experience for patients, one or more embodiments orchestrate processes across multiple heterogeneous systems. Orchestration involves the sharing of information and across data systems. In healthcare, orchestration is complicated by a complex ecosystem, privacy and regulation and service fragmentation. Namely, in healthcare, users may have multiple different accounts on different computing systems, each system having a range of services and views for different users that view the patient's information. The access to the patient information and particular systems is strictly controlled by patient privacy laws.

[0025] Further, patient data is collected across numerous systems. For example, in a single medical group, patient data may be collected from scheduling, patient engagement, clinic administration, care delivery, digital education, quality measurement tracking, and billing. To enable orchestration at a health system level, there is a need for an intermediary technology that can consolidate the federated data from the heterogeneous data sources and re-present it in a normalized data format on which orchestration can be performed. Data virtualization is a tool that can do the orchestration without creating a net-new master data repository (z.e., status quo Health Information Exchange (HIE) consolidation).

[0026] Data Virtualization is a component of the Digital Twin Platform, which integrates and manages data from diverse and siloed systems across the healthcare landscape, providing a unified view of a patient according to data governance, privacy, and security policies. PCT application identified by application serial number PCT/US2021/027812 filed on April 16, 2021, is incorporated herein by reference.

[0027] Turning to FIG. 1, the system (100) is a computing system shown in accordance with one or more embodiments. The system (100) and corresponding components may utilize the computing systems described in FIG. 21A and FIG. 21B to provide healthcare virtualization. Different architectures may be used. The system (100) includes the repository (101) and the servers (141) that communicate with the source systems (171) and the subscriber systems (179).

[0028] The repository (101) stores data and may include a collection of data stores. The data stores may include the event blob store (103), the golden operational model stores (107), the patient index store (111), and the resource index store (113). The repository (101) may include the collection addresses (121), the queued events (123), the normalized events (125), the matched events (127), the consolidated events (129), and the subscription addresses (131).

[0029] The event blob store (103) is a data store that stores the raw events (105) and the stored events (109). The raw events (105) are the source events (175) received by the data collection service (145) from the source systems (171). The raw events (105) are saved as received without processing to the event blob store (103). The stored events (109) include the events generated during the processing of the events from the source systems (171).

[0030] The golden operational model stores (107) are data stores that store the stored records (110). The stored records (110) are records generated from the normalized events (125) that correspond to the raw events (105). One of the golden operational model stores (107) corresponds to one of the source systems (171) to maintain federation of the data and events from the source systems (171).

[0031] The patient index store (111) is a data store that stores patient identifiers. The patient index store (111) stores unique patient identifiers (also referred to as enterprise master patient index universal unique identifiers (EMPI UUIDs)) and includes mappings from the unique patient identifiers to source patient identifiers. The source patient identifiers are the patient identifiers used by the source systems (171) to identify a patient. One unique patient identifier may be mapped to multiple Source patient identifiers. In one embodiment, one unique patient identifier may be mapped to one source patient identifier for each of the source systems (171).

[0032] The resource index store (113) is a data store that stores resource identifiers. The resources identified by the resource identifiers stored in the resource index store (113) may include medications, billing events, patient events, etc. The resources may be identified with unique resource identifiers that are mapped to source resource identifiers. The source resource identifiers are the resource identifiers used by the source systems (171) to identify resources (e.g., medications). One unique resource identifier may map to the source resource identifiers of multiple source systems. The unique resource identifiers are used by the application (143) to uniquely identify the resources identified by the source systems (171) to prevent the same identifier from being used to identify different things (e.g., different medications). [0033] The collection addresses (121) are addresses used by the data collection service (145) to receive events. In one embodiment, the collection addresses (121) are uniform resource identifiers (URIs) provided by the data collection service (145) to the source systems (171) to receive events from the source systems (171).

[0034] The queued events (123) are the events queued by the data collection service (145) for the normalization service (147). The queued events (123) may have a one-to-one correspondence with the raw events (105) and the source events (175). To maintain federation, one of a queued event may include metadata that identifies the source systems that generated the source event corresponding to the queued event.

[0035] The normalized events (125) are normalized versions of the queued events (123). The normalized events (125) may have a structure that is different from the structure of the queued events (123). The data in the normalized events (125) may be the same as the data in the raw events (105) and the corresponding queued events (123).

[0036] The matched events (127) are events that have been matched to a unique patient identifier by the patient matching service (151). One of the matched events (127) may correspond to one of the normalized events (125).

[0037] The consolidated events (129) are events that have been processed by the record consolidation service (153). In one embodiment, a consolidated event is mapped to multiple source events, queued events, normalized events, and matched events, which represent the same real life event. As an example, a laboratory data system and a clinic data system may each store a record for a diagnostic performed on a patient. The laboratory data system and the clinic data system may generate source events processed by the application (143) that are consolidated into a single consolidated event. In one embodiment, the consolidation may be in the form of a unique event identifier that is included in the metadata for each of the events. [0038] The subscription addresses (131) are addresses used by the application (143) to publish events to the subscriber systems (179). In one embodiment, the subscription addresses (131) are uniform resource identifiers (URIs) provided by the subscriber systems (179) for receiving consolidated events from the application (143).

[0039] Continuing with FIG. 1, the system (100) also may include the server (141). The server (141) is one or more computing systems, possibly in a distributed computing environment. An example of the server (141) may be the computing system shown in FIG. 21 A.

[0040] The server (141) may host and/or execute one or more processes, software, applications, etc., including the application (143). The server (141) may interact with the source systems (171) and the subscriber systems (179) to virtualize access to the information from source systems (171).

[0041] The application (143) is a collection of programs that execute on the server (141) to provide healthcare virtualization. The programs of the application (143) may be software services that are self-contained and modular components with defined interfaces that encapsulate specific functionality with the ability to be independently scaled. In one embodiment, the application (143) may include the data collection service (145), the normalization service (147), the golden operational model service (149), the patient matching service (151), and the record consolidation service (153).

[0042] The data collection service (145) is a program executing on the server (141) to collect data from the source systems (171). The data collected by the data collection service (145) may include information from the source records (177), which may be encapsulated in the source events (175). The data collection service (145) listens to the collection addresses (121) to receive the source events (175) published by the source systems (171) and may store the source events (175) as the raw events (105) in the event blob store (103). The data collection service (145) queues the source events (175) to form the queued events (123) for further processing. [0043] The normalization service (147) is a program executing on the server (141) to normalize data from the source events (175). In one embodiment, the normalization service (147) processes the queued events (123) to extract key value pairs and generate the normalized events (125).

[0044] The golden operational model service (149) is a program executing on the server (141) to provide access to the information from the source events (175). In one embodiment, the golden operational model service (149) may store the normalized events (125) as the stored records (110) in the golden operational model stores (107) to which the golden operational model service (149) provides access.

[0045] The patient matching service (151) is a program executing on the server (141) to match patient identifiers between records and events. In one embodiment, the patient matching service (151) may process the normalized events (125) to identify unique patient identifiers from the source patient identifiers from the normalized events (125) and generate the matched events (127).

[0046] The record consolidation service (153) is a program executing on the server (141) to consolidate multiple records or events. In one embodiment, the record consolidation service (153) processes the matched events (127) to generate the consolidated events (129). In one embodiment, the record consolidation service (153) may utilize the resource index store (113) to identify events to be consolidated. In one embodiment, the record consolidation service (153) may publish the consolidated events (129) to the subscription addresses (131).

[0047] The source systems (171) are computing systems that store and manipulate healthcare information and may be embodied by the computing systems of FIG. 21 A and FIG. 21B. The source systems (171) may include multiple servers and applications to generate and process the source events (175) and the source records (177) that may be stored on the source data stores (173). Each of the source systems (171) may have multiple data stores. In one embodiment, a data store of one of the source systems (171) may not be accessed by the other source systems (171).

[0048] The source data stores (173) are stores of healthcare information and may include multiple databases and repositories. The source data stores (173) store the healthcare information in the source events (175) and the source records (177).

[0049] The source events (175) are events generated by the source systems (171). In one embodiment, some of the source events (175) may be generated in response to changes to the source records (177). The source events (175) may include information stored in the source records (177).

[0050] The source records (177) are records containing healthcare information utilized by the source systems (171). The source records (177) may include information about patients, visits, medications, etc.

[0051] The subscriber systems (179) are computing systems that consume and process virtualized healthcare information provided by the server (141). In one embodiment, the subscriber systems (179) may use services of the application (143) to access the information from the source systems (171) in a federated manner.

[0052] Although described within the context of a client server environment with servers and user devices, aspects of the disclosure may be practiced with a single computing system and application. For example, a monolithic application may operate on a computing system to perform the same functions as one or more of the data collection service (145), the normalization service (147), the golden operational model service (149), the patient matching service (151), and the record consolidation service (153).

[0053] Turning to FIG. 2, the process (200) provides virtualization of healthcare information. The process (200) may execute with the system (100) of FIG. 1.

[0054] At Step 202, the process (200) includes receiving a source event at a collection address from a source system. In one embodiment, the source event corresponds to a source record stored by the source system and includes a source patient identifier and a timestamp. In one embodiment, the source event may be received passively by a data collection service in response to a source system pushing the event to the collection address. In one embodiment, the source event may be received actively by the data collection service pulling the event from the source system. In one embodiment the source event is stored to an event blob store.

[0055] At Step 205, the process (200) includes normalizing the source event to generate a normalized event using a processor to extract a key value pair from the source event. In one embodiment, the normalized event is federated to the source system. In one embodiment, the normalized event includes the source patient identifier and the timestamp. In one embodiment, the normalizing includes extracting multiple key value pairs from the source event and storing the key value pairs in a standardized text format, which may be JavaScript object notation (JSON). In one embodiment, the normalized event is federated to the source system using federation data that links the source system, source event, normalized event. In one embodiment, the normalized event is stored to a golden operational model store that is federated to the source system using federation data that links the golden operational model store to the source system. In one embodiment, the normalized event is stored to a golden operational model store that is federated to the source system.

[0056] At Step 208, the process (200) includes matching a unique patient identifier to the source patient identifier to form a matched event federated to the source system. In one embodiment, the matched event includes the unique patient identifier, the source patient identifier, and the timestamp. In one embodiment, a patient matching service may perform the match using a patient index store that stores mappings between unique patient identifiers and source patient identifiers.

[0057] In one embodiment, matching the unique patient identifier to the normalized event uses a processor to match the unique patient identifier to a source patient identifier of the normalized event that is from the source event and is mapped to the unique patient identifier. In one embodiment, the normalized event is windowed and processed with a plurality of normalized events by the source patient identifier and the timestamp before being matched. The unique patient identifier may then be used to window events.

[0058] At Step 210, the process (200) includes consolidating the matched event to form a consolidated event federated to the source system. In one embodiment, the source record corresponds to the consolidated event, the matched event, the normalized event, and the source event. In one embodiment, the source record is matched to a different record from a different system. In one embodiment, a record consolidation service may use a resource index store to identify information that matches between different records. The resource index store may store mappings of unique resource identifiers to source resource identifiers (used by source systems). The record consolidation service may match data or metadata between different records to identify records to consolidate. In one embodiment, the matched event is consolidated to form the consolidated event, wherein the matched event is windowed and processed with a plurality of matched events by the unique patient identifier and the timestamp.

[0059] In one embodiment, the matched event is consolidated to form the consolidated event by searching for the different record in multiple golden operational model stores. The golden operational model stores may include the source system and the different system.

[0060] At Step 212, the process (200) includes transmitting the consolidated event to a subscriber system using a subscription address. In one embodiment, the subscription address is provided by the subscriber system and the consolidated event is published to the subscription address using a hypertext transfer protocol (HTTP) post method. In one embodiment, the subscriber system displays information from the consolidated event in a timeline. In one embodiment, the subscriber system displays consolidated information with information from each of the relevant records across multiple global operational model stores, which may include the source record and a different record.

[0061] In one embodiment, a subscriber system is verified before the consolidated event is transmitted. The subscriber system is verified based on the subscription level of the subscriber system, which include authorization, authentication, consent level and permissions.

[0062] Turning to FIG. 3, the diagram (300) shows a flow of data through a system such as the system (100) of FIG. 1. The source systems (302) generate the source events (308). The source events (308) may include healthcare information from the source data stores (305). In one embodiment, the source systems (302) publish the source events (308) to the collection addresses (310) that are serviced by the data collection service (312).

[0063] The data collection service (312) receives the source events (308) and may store the source events (308) to an event blob store as raw events. The data collection service (312) queues the source events (308) as the queued events (315) for further processing. The queued events (315) may be windowed or sorted by source patient identifier and timestamp.

[0064] The normalization service (318) processes the queued events (315) to generate the normalized events (320). The normalization may include extracting key value pairs from the queued events (315), which may be in a proprietary format, and writing the extracted key value pairs to the normalized events (320) using a standardized format (e.g., JSON).

[0065] The golden operational model service (322) processes the normalized events (320) to generate the stored records (328). The golden operational model service (322) stores the stored records (328) to the golden operational model stores (325). One of the golden operational model stores (325) may correspond to one of the source systems (302).

[0066] The patient matching service (330) processes the store records (328) to generate the Matched events (335). The patient matching service (330) uses the patient index store (332) to identify unique patient identifiers that match the source patient identifiers of the stored records (328).

[0067] The record consolidation service (338) processes the matched events (335) to generate the consolidated events (342). The record consolidation service (338) may use the resource index store (340) to identify unique resource identifiers that match to source resource identifiers from the matched events (335). When a unique resource identifier matches to the source resource identifiers of multiple matched events (335), the multiple matched events (335) may be identified as one of the consolidated events (342).

[0068] The consolidated events (342) or published to the subscription addresses (345). The subscription addresses (345) are monitored by the subscriber systems (348) that may display the consolidated events (342).

[0069] Turning to FIG. 4, the user interface (400) illustrates a data review wizard, which may be used to acquire user feedback for events that may have been identified as events to be consolidated. The user interface (400) includes the event header windows (402) and (408), the event payload windows (405) and (410), and the review window (412).

[0070] The event header windows (402) and (408) include metadata about events being processed by the system. The event header window (402) indicates that the underlying event is from a data processing system identified as "Hospital A" and that the event was added on "2021-10-22". The event header window (405) indicates that the underlying event is from a different data processing system identified as "Lab System 1" but also added on "2021-10-22".

[0071] The event payload windows (405) and (410) include healthcare information related to two different events. As indicated in the event payload windows (405) and (410), the events underlying the event pay load windows (405) and (410) are from different data processing systems recorded on the same day. [0072] The review window (412) provides a match view (415) describing the matching information displayed in the event payload windows (405) and (410). The match view (415) identifies multiple pieces of information that match between the two different events for the event payload windows (405) and (410). The matching information in this case include the "Date of Birth", the "Healthcard number" (e.g., a source patient identifier), the "Phone number", and the "Address" for a patient.

[0073] Turning to FIG. 5, the user interface (500) illustrates a view of data aggregated from the events processed by the system. The user interface (500) includes event view (502), the timeline view (505), and the detail window (508).

[0074] The event view (502) displays a list of types of events. The types of events in the list are the types of events that may be displayed in the timeline view (505). The types of events in the list may be selected by a user.

[0075] The timeline view (505) shows a timeline of events. The events in the timeline are the types of events identified with the list of types of events from the event view (502). The timeline provides a temporal representation of when the events occurred.

[0076] The detail window (508) is a window displayed upon selection of one of the events from the timeline view (505). The selection may be from clicking, hovering, etc., one of the events from the timeline view (505). The detail window (508) provides aggregated information about the events from the timeline view (505). For example, the detail window (508) indicates that events relating to the medication "ipratropium" were contributed from a lab information system which is a data source originating from Hospital B that is in HL7 v2 format.

[0077] Turning to FIG. 6, the data flow of the data flow diagram (600) includes an event storage layer that passes events to a Golden Operational Model (GOM) layer, which is connected to a data virtualization layer. The data virtualization layer passes processed event data to external listeners through subscriptions such as, but not limited to webhooks, websocket messages and pub-sub queue listeners. FIG. 7 shows an exploded view (700) of the data flow diagram (600) of FIG. 6. In the exploded view (700), the overall architecture is shown. Each of the components of the exploded view is presented in the following figures.

[0078] FIG. 8 shows a diagram (800) of a data collection service (802). The data collection service (802) accepts a variety of incoming integrations (e.g., health level 7 version 2 (HL7v2), Javascript Object Notation (JSON), extensible markup language (XML)) and encapsulates data in a standard format to be added to the pipeline. The data collection service is an entry point that is responsible for receiving messages from source systems using various methods such as simple TCP/IP message push, web socket, Kafka stream, etc. The data collection service authenticates incoming messages and determines the source system (e.g., based on header information in the messages). The data collection service further passes data in the messages to the data virtualization pipeline through a publish subscribe (pubsub) queue.

[0079] The data virtualization pipeline (DVP) shown in FIG. 7 executes the steps for each event received from the data collection service to different layers (e.g., an event storage layer, GOM layer, data virtualization layer) that will be described below. Messages are processed through a corresponding queue for each layer, and each layer has a swarm of workers that picks up event objects from the DVP and executes the relevant actions in the layer. Events may be windowed by a patient identifier to ensure that messages for a patient are processed in the order that the messages are received, while maintaining a parallelizable architecture.

[0080] The input of the pipeline is an event message from a source system, for example, an update message from a hospital electronic medical record system, an HL7v2 message from ADT (Admission/Discharge/Transfer) feed, or a webhook from an appointment scheduling service. To integrate with the platform, source systems must choose a method of integration (either a pushbased or pull-based approach to receiving events).

[0081] A push-based integration is the most common use case (ex. Incoming HL7 feed, subscribing the JSON webhooks, websocket connection). The integration is responsible for sending events directly to the Data Collection Service.

[0082] As the system is inherently designed around receiving events, in a pullbased integration a service may be created to simulate a live event stream. The service will be responsible for periodically pulling data from a remote repository (or on request) and pushing the data to the Data Collection Service to simulate push events.

[0083] Continuing with the layers of FIG. 6 and FIG. 7, the Event Storage Layer shown in the diagram (900) of FIG. 9 provides historical logging/backups of events that are passed through the system. The event storage layer further provides the ability to query historical events for insights. The event storage layer includes an event blob storage that is responsible for storing messages received from a source system (pre and post processing by the normalization service). Messages in the event blob storage include an event UUID, timestamp, and integration source. The message (1500) of FIG. 15 and the message (1600) of FIG. 16 provide an example of a saved event both pre and post processing, respectively.

[0084] The event storage layer also includes a data normalization (markup normalization) service. For each incoming message, the data normalization service will identify and label the patient’s unique identifier as the Source Patient Identifier (SPI). The SPI is then used to consolidate the patient’s information scoped by the source system. The data normalization service ingests raw event messages and outputs Golden Operational Model Operations (GOM Operations). The event storage layer implements the operations of FIG. 10, that is also described in application serial number PCT/US2021/027812, incorporated herein by reference. In the healthcare sector, different data sources provide data in heterogeneous data formats. Even data associated with a single patient may be complex and from a diverse set of sources. For example, lab test results may be provided in one format by a lab testing facility; imaging data may be provided in a specific image format by a radiology department of a hospital; in addition, the patient’s primary physician may provide handwritten and scanned notes from a physical exam. Further, additional medical and nonmedical information may be associated with work performed by a hospital’s accounting department, an insurance provider, etc. Because all these data may be provided in native formats, the data are unlikely to be easily combinable to form a comprehensive electronic health record for the patient. In addition, the format of the data being provided may initially be unknown, thus further complicating the effort of generating a comprehensive electronic health record for the patient.

[0085] In one or more embodiments, native messages from multiple data sources are combined in a unified electronic medical record database. When receiving a native message from a data source, the message, in one or more embodiments, is translated into a standard message compatible with the unified electronic medical record database. To perform the translation, a mapping may need to be established between elements of the native message and the corresponding elements of the standardized message. In one or more embodiments, the mapping is established during an initial training phase, when a new data source becomes available. During the training phase, numerous native messages may be analyzed using methods of statistics and/or machine learning to identify a mapping between elements of the native message and elements of the standardized message. Using this approach, many mappings may be established without requiring manual intervention by a supervisor. A supervisor may, however, manually set mappings for those elements for which mappings could not be automatically determined, or where a confidence associated with the mappings was low. After completion of the training phase, native messages provided by the newly-added data source may be automatically translated into standardized messages to enter the data received from the newly-added source into the unified electronic medical record database.

[0086] The described addition of a new source system may be performed for various types of source systems, providing data in various native message formats. Comprehensive electronic health records in a uniform format may, thus, become available. Accordingly, the workflow of healthcare operations may improve by improving efficiency and effectiveness while reducing errors. Many applications, as further discussed below, may benefit from the availability of a unified electronic health record database. For an increasingly data-driven healthcare, the availability of the unified electronic health record database may be essential.

[0087] Turning to FIG. 10, an electronic health data communication scenario (1000), in accordance with one or more embodiments, is shown. The electronic health data communication scenario (1000) includes a system for consolidating electronic health data (1050), at least one data source (1070A-1070C), and at least one user (1080A-1080C) connected by a network (1090). Each of these elements is subsequently described.

[0088] The electronic health data communication scenario (1000) may rely on the system for consolidating electronic health data (1050) to provide the users (1080A-1080C) with access to electronic health data obtained from the various data sources (1070A-1070C).

[0089] The users (1080A-1080C) may be, for example, patients (1080 A), physicians and/or other clinical staff (1080B), insurers (1080C), etc. Any type of user benefitting from electronic health data may be participating. Further, any number of users of any type may be participating. The users may interact with the system for consolidating electronic health data (1050) by retrieving electronic health data, editing electronic health data, entering electronic health data, etc. Users (1080A-1080C) may interact with the system for consolidating electronic health data (1050) via the data sources (1070A-1070C), e.g., hospitals, devices, laboratories, etc., as subsequently described. [0090] The source systems (1070A-1070C) may be hospitals, laboratories, individual devices (e.g., imaging devices, heart monitors, blood glucose meters), or any other component capable of providing electronic health data. Any type and any number of source systems (1070A-1070C) may participate in the electronic health data communication scenario (1050). The source systems (1070A-1070C) may communicate using any type of communication standard as further discussed below.

[0091] The system for consolidating electronic health data (1050), in accordance with one or more embodiments, includes a unified electronic health record database (1030), configured to store electronic health data received from the source systems (1070A-1070C). The unified electronic health record database (1030) is implemented using a standard capable of accommodating any kind of electronic health data from the various data sources (1070A-1070C). For example, a first set of data may include lab test results, a second set of data may include medical images, and a third set of data may include insurance information. The unified electronic health record database (1030) may consolidate all these heterogeneous data to establish comprehensive electronic health records for patients.

[0092] In one embodiment, the system for consolidating electronic health record data (1050) further includes a natural language processing engine (1040) which may be used to extract information from unstructured native messages (free text), for example by annotating biomedical concepts such as symptoms, procedures, medications, diagnoses with attributes/ standard codes. The annotations may be performed using third-party NLP libraries and or tools like the unified medical language system dictionary set (UMLS) and the clinical Text Analysis Knowledge Extraction System (cTAKES). The system for consolidating electronic health record data (1050) may be implemented on one or more computing systems, such as those shown in FIG. 21 A and FIG. 21B.

[0093] The network (1090) may interface the system for consolidating electronic health data (1050) with the data sources (1070A-1070C) and the users (1080A- 1080C). Any combination of wired and/or wireless communication protocols may be used by the network (1090). Further, the network (1090) may include wide area network (e.g. the Internet) segments, and/or a local area network segments (e.g. enterprise networks). Communications over the network (1090) may involve any combination of secured (e.g., encrypted) and non-secure (e.g., un-encrypted) communication. For example, secure site-to-site VPN tunnels, cryptographic protocols such as TLS or SSL, etc. may be used by any of the components shown in FIG. 10. The network (1090) may, thus, enable or facilitate data sharing between the data sources (1070A-1070C) and the system for consolidating electronic health data (1050).

[0094] Returning to the layers and the diagram (900) of FIG. 9, the data normalization service defines and outputs the normalized model that the GOM Layer uses. The normalized events are saved into the Event Blob Storage, to provide an audit trail of all events.

[0095] The next layer is the GOM layer shown in the diagram (1100) of FIG. 11. The GOM layer provides a standardized interface to store and access data from all source systems that were normalized using the data normalization service mentioned previously.

[0096] The GOM layer consists of one GOM store per source system and a GOM API service. The GOM store is a logical data store for a source system. In one or more embodiments a single logical data store exists per source system. Data from one source system is distinctly marked as such, so as to not be interpreted with data from another source system. Furthermore, it is possible to quarantine, isolate, and completely remove a GOM Store without affecting the operations of other GOM Stores.

[0097] Each database includes the same standardized schema, which is the GOM Schema. The database includes a Slowly Changing Dimension (SCD) Data Management Type 1 replica of the data from the source integration, standardized to the GOM schema. A GOM may contain Type 2 data. The data access patterns with each GOM may be based on a use case, including but not limited to the rate of query, scale of query, speed of query, based on the actual requirements, the GOM database could be implemented as a document database, a relational database or even a graph database.

[0098] For smaller integrations where it is feasible to work with the entire data set, the GOM may be initially populated by converting the data dump to a series of backload messages so that the GOM contains all the data available and is then updated via the aforementioned push/pull-based integration methods.

[0099] For integrations with larger systems, obtaining a data dump may not be feasible, and so the initial state of the GOM will be empty. In this case, a Virtual Interface may be created on top of the physical GOM store to create a virtual GOM store. The virtual interface is responsible for fetching data from a separate repository if the data is stale or is not found in the backing physical database. This ensures that the data is properly retrieved when the Data Virtualization / GOM API is queried, even if there was no initial backload.

[00100] A Virtual GOM Store may be defined as a GOM Store that delegates data access to an underlying system. A Virtual GOM Store understands GOM operations and translates them into to a remote system, which may be API calls, direct database calls, etc. A Virtual GOM Store may be used in the case where it is not possible to perform backloading operations from the remote system to a regular GOM store, due to speed or memory limitations. The physical database that backs this GOM store will not have the most up to date data available and relies on external queries or a scheduled job to update the state of the stored data on demand.

[00101] The GOM Service is an application programming interface (API) that takes a GOM Operation as an input, performs the necessary operations on the specified GOM Store, and outputs the data requested by the API user.

[00102] A “GOM Operation” is a domain specific language that translates into DBMS queries, or API calls, if a virtual GOM store is used. A GOM operation must include a source system identifier in each payload, as well as the source patient identifier (SPI). The below example shows an example GOM operation if one wants to update an allergy with code PEANUT to the source patient identifier 123: { integration_id: "OSCAR", patient_identifiers: [ { "system": "FHIR", "value": " 123" } ], models: [ { model: "allergy", body: { "code": "PEANUT" }].

[00103] After the event is processed and saved into the GOM store, a Source Event Data (Type A) message is emitted to subscribed clients. This message contains an EMPI UUID, which is a unique identifier for a patient across multiple source systems, as well as the GOM operations that occurred for the source system only. The message (1300) of FIG. 13 shows an example of this pay load.

[00104] Turning to the data virtualization layer, the data virtualization layer of the diagram (1200) FIG. 12 provides an interface to retrieve the data from a particular patient by querying across all GOM stores, using an Enterprise Master Patient Index (EMPI).

[00105] The Data Virtualization Layer includes the following components: a data virtualization service, a patient matching service, an EMPI store, and a record consolidation service. The Data Virtualization Layer is used because in the previous layer, the GOM layer, patient data is separated in different patient records in different GOM stores. As most data retrieval use cases will demand a consolidated view of GOM data, this service is needed to provide on-demand snapshots of the best summarized GOM data across all GOM layers that are consolidated for immediate use by downstream systems.

[00106] Unlike traditional systems, one physical patient may be registered in multiple source systems, and it is possible that even the most basic information, such as the patient's first and last name is different. To acknowledge this unique problem in healthcare, for each source system, patient anchor attributes can be defined through a patient matcher configuration. By default, existing patients are matched via the unique identifiers specified, but the system may be further configured to match based on non-unique demographic information as well. The text (1700) of FIG. 17 depicts a sample configuration for a potential source system. The configuration supports a straightforward matching criteria - i.e. by provincial health card number match; however, it is also common that patients do not have one, in which case, the matcher configuration specifies alternative matching strategies, such as by Medical Record Number (MRN) of the hospital, or by the successful match of other demographic information. Anchor attributes are assigned a configurable weight, which can be used to modify the threshold for automated matching.

[00107] The patient matching service listens to patient object updates through the Data Virtualization Pipeline (DVP). Based on the patient matcher configuration described above, each patient object is analyzed to determine whether or not the physical patient it refers to already exists in another source system. If it does not exist, then a new EMPI UUID will be created in the EMPI Store. If it does exist, then it will obtain the existing EMPI UUID and link it with the Source Patient Identifier in the patient object that was analyzed. The diagram (1800) depicts this workflow is in FIG. 18. The patient matching service is further an interface to allow for manual or deterministic linking of patient identities.

[00108] The EMPI Store is a database that stores relationships for patient records across source systems that are referring to the same physical patient. Each physical patient will be assigned a EMPI UUID in the EMPI Store. The EMPI UUID will also be linked with patient anchor attributes, such as their provincial health card number, or their medical record number (MRN). Also, the EMPI UUID will link to at least one Source Patient Identifier (SPI).

[00109] The record consolidation service includes logic for matching and combining non-patient records, such as the patient’s conditions or their medications from different systems based on anchoring attributes. For example, if Source System A has noted that the patient is currently taking Metformin, and Verapamil, and Source System B has noted that the patient is currently taking Metformin and Warfarin, the record consolidation service will output Metformin, Verapamil, and Warfarin as the 3 medications the patient is currently taking. In this example, the medications are consolidated using the RxNorm identifier, plus dosage information. Rulesets in the logic may be manually determined based on use case and domain knowledge.

[00110] The record consolidation service is used when emitting a consolidated Event Data (Type B) message to subscribed clients: this message contains the Patient UUID, along with a consolidated record of the patient, representing the net changes that have occurred, if any. For example, if Source System A registers a new medication for a patient, and then Source System B subsequently does the same, there would be no delta in the consolidated record, so no Type B message will be produced. The message (1400) of FIG. 14 shows an example of this pay load for a message that just updates a patient name.

[00111] Finally, the data virtualization service is a read-only API query interface that provides a consolidated view of the patient and its related clinical objects.

[00112] As input, the data virtualization service takes the EMPI UUID, the source systems requested, and a list of requested clinical object names (such as MedicationRequest, Encounter, Condition, etc.). One or more source systems can be requested and only data from the specified source system GOMs will be present in the final output. To address the privacy element, if the consumer of the data virtualization service does not have access to a certain source system, their request to access data from a source system GOM will be ignored. An example API request is shown in the text (1900) of FIG. 19.

[00113] To produce the output, the data virtualization will first query the EMPI Service what Source Patient Identifiers (SPIs) are linked to the EMPI UUID, then fetch the relevant clinical objects from each specified GOM. Then, based on what was described in the record consolidation service above, it will use normalization to group data and show summarized data across source systems in a single response. An example API Response is shown in the text (2000) of FIG. 20.

[00114] The following is an example scenario in accordance with one or more embodiments. Scenario Walkthrough

Scenario: Allergy updated through EMR that triggers a patient alert Allergy creation message is sent from a source system (e.g. JSON webhook) a. Example json: { type: “allergy. add”, patient_id: 123, allergy _id: 456, allergy _code: “PEANUT” } Data Collection Service receives this webhook notification (via HTTPS, for instance) and authenticates the request based on format (i.e. Authorization headers for HTTPS calls) to ensure the request is legitimately sourced a. A standardized event message is constructed by adding metadata about the request (timestamp, source identifier):

{ "_message_id" : "35d54497-4764-45d4-97ec-3de777e47e38", "_message_type" : "allergy. add", "_integration_id" : "TESTEMR",

"_timestamp": "2022-01-01T09:30:00-04:00", "type": "allergy. add", "patient_id": 123, "allergy_id": 456,

" allergy _code": "PEANUT" } b. This message is added to the PubSub queue A worker in the Event Storage layer picks up the message from the PubSub queue a. Note that windowing is not done at this point, as there has been no mapping work done to identify a possible patient identifier The worker saves the event message to Event Blob Storage After the raw event is saved, the event payload is sent to the Data Normalization Service, which outputs a GOM-compatible event payload a. Contains a source patient uuid, a set of patient identifiers, and a series of operations against defined objects in the GOM, along with any references to external models - i.e. { source_patient_uuid: “c7281d01- e2a7-4351-84el-b9d638fa5d82”, patient_identifiers: [{ "system": "EMR", "value": "123" }], models: [ { model: “allergy”, identifiers: [{ "system": "EMR", "value": "456" }], body: { “code”: “PEANUT” }, links: [{“type”: “Patient”, “identifiers”: [{“system”: “EMR”, “value”: 123}] ]] i. Will need to use anchor attributes to account for incoming data that may not have a particular identifier b. The GOM-compatible event payload is saved to the Event Blob Storage for tracking purposes The worker saves the GOM-compatible event payload to the Event Storage layer and adds it to the queue for a GOM worker to pick up Messages are windowed by source patient id and timestamp to ensure that they are consumed in the proper order A worker in the GOM Layer picks up the event pay load from the queue and performs the specified operations. The new allergy is saved to the GOM store for the associated source system a. This must be implemented as an atomic transaction per event to allow for safe retrying b. To facilitate safe retrying, each model must have a last updated timestamp that would reject out of order messages The worker emits this transaction to the queue to be picked up by the Data Virtualization Layer a. This message contains the event payload, as well as the deltas against the saved objects in the integration’s GOM store Messages are windowed by source patient id and timestamp for a Patient Matcher worker to pick up The Patient Matcher worker picks up the transaction and attempts to find a matching entry in the EMPI Store a. Initially checks if an existing EMPI Store entry exists for this source patient ID, if so, immediately returns with the matching UUID b. If not, it optionally searches the other source systems to see if a patient can be matched (if automated matching is enabled) and returns the UUID c. If no matches are found, a new entry is registered in the EMPI Store for this source id (Scenario 2) and the matching UUID is returned i. This would only occur on new patients, so there should not need to be a separate event fired for this specific use case, as a new patient event will be fired regardless The worker appends the returned EMPI UUID to the event pay load, and sends it to be picked up by the Clinical Object Processor The messages to be picked up are now windowed by EMPI UUID to ensure global synchronization of patient events across systems The Population Orchestration Layer emits the Allergy creation event with the patient UUID and source system to the event bus to publish (Type A message) Separately, the Record Consolidation Service is called to pull a consolidated record of the patient. This is necessary to check whether the allergy was previously captured in another system. a. If the allergy was not previously captured, a Type B message is published b. If it was captured in a previous system, the consolidated record will not be updated, and no event will be emitted

16. Subscribing applications listen to the event bus and may choose to act on either message (i.e. display a notification, or update the allergy list in their own system)

[00115] Embodiments may be implemented on a computing system specifically designed to achieve an improved technological result. When implemented in a computing system, the features and elements of the disclosure provide a significant technological advancement over computing systems that do not implement the features and elements of the disclosure. Any combination of mobile, desktop, server, router, switch, embedded device, or other types of hardware may be improved by including the features and elements described in the disclosure. For example, as shown in FIG. 21 A, the computing system (2100) may include one or more computer processors (2102), non-persistent storage (2104), persistent storage (2106), a communication interface (2112) (e.g., Bluetooth interface, infrared interface, network interface, optical interface, etc.), and numerous other elements and functionalities that implement the features and elements of the disclosure. The computer processor(s) (2102) may be an integrated circuit for processing instructions. The computer processor(s) may be one or more cores or micro-cores of a processor. The computer processor(s) (2102) includes one or more processors. The one or more processors may include a central processing unit (CPU), a graphics processing unit (GPU), a tensor processing units (TPU), combinations thereof, etc.

[00116] The input devices (2110) may include a touchscreen, keyboard, mouse, microphone, touchpad, electronic pen, or any other type of input device. The input devices (2110) may receive inputs from a user that are responsive to data and messages presented by the output devices (2108). The inputs may include text input, audio input, video input, etc., which may be processed and transmitted by the computing system (2100) in accordance with the disclosure. The communication interface (2112) may include an integrated circuit for connecting the computing system (2100) to a network (not shown) (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, mobile network, or any other type of network) and/or to another device, such as another computing device.

[00117] Further, the output devices (2108) may include a display device, a printer, external storage, or any other output device. One or more of the output devices may be the same or different from the input device(s). The input and output device(s) may be locally or remotely connected to the computer processor(s) (2102). Many different types of computing systems exist, and the aforementioned input and output device(s) may take other forms. The output devices (2108) may display data and messages that are transmitted and received by the computing system (2100). The data and messages may include text, audio, video, etc., and include the data and messages described above in the other figures of the disclosure.

[00118] Software instructions in the form of computer readable program code to perform embodiments may be stored, in whole or in part, temporarily or permanently, on a non-transitory computer readable medium such as a CD, DVD, storage device, a diskette, a tape, flash memory, physical memory, or any other computer readable storage medium. Specifically, the software instructions may correspond to computer readable program code that, when executed by a processor(s), is configured to perform one or more embodiments of the invention, which may include transmitting, receiving, presenting, and displaying data and messages described in the other figures of the disclosure.

[00119] The computing system (2100) in FIG. 21 A may be connected to or be a part of a network. For example, as shown in FIG. 21B, the network (2120) may include multiple nodes (e.g., node X (2122), node Y (2124)). Each node may correspond to a computing system, such as the computing system shown in FIG. 21 A, or a group of nodes combined may correspond to the computing system shown in FIG. 21 A. By way of an example, embodiments may be implemented on a node of a distributed system that is connected to other nodes. By way of another example, embodiments may be implemented on a distributed computing system having multiple nodes, where each portion may be located on a different node within the distributed computing system. Further, one or more elements of the aforementioned computing system (2100) may be located at a remote location and connected to the other elements over a network.

[00120] The nodes (e.g., node X (2122), node Y (2124)) in the network (2120) may be configured to provide services for a client device (2126), including receiving requests and transmitting responses to the client device (2126). For example, the nodes may be part of a cloud computing system. The client device (2126) may be a computing system, such as the computing system shown in FIG. 21 A. Further, the client device (2126) may include and/or perform all or a portion of one or more embodiments of the invention.

[00121] The computing system of FIG. 21 A may include functionality to present raw and/or processed data, such as results of comparisons and other processing. For example, presenting data may be accomplished through various presenting methods. Specifically, data may be presented by being displayed in a user interface, transmitted to a different computing system, and stored. The user interface may include a GUI that displays information on a display device. The GUI may include various GUI widgets that organize what data is shown as well as how data is presented to a user. Furthermore, the GUI may present data directly to the user, e.g., data presented as actual data values through text, or rendered by the computing device into a visual representation of the data, such as through visualizing a data model.

[00122] As used herein, the term “connected to” contemplates multiple meanings. A connection may be direct or indirect (e.g., through another component or network). A connection may be wired or wireless. A connection may be temporary, permanent, or semi-permanent communication channel between two entities.

[00123] The various descriptions of the figures may be combined and may include or be included within the features described in the other figures of the application. The various elements, systems, components, and steps shown in the figures may be omitted, repeated, combined, and/or altered as shown from the figures. Accordingly, the scope of the present disclosure should not be considered limited to the specific arrangements shown in the figures.

[00124] In the application, ordinal numbers (e.g., first, second, third, etc.) may be used as an adjective for an element (i.e., any noun in the application). The use of ordinal numbers is not to imply or create any particular ordering of the elements nor to limit any element to being only a single element unless expressly disclosed, such as by the use of the terms "before", "after", "single", and other such terminology. Rather, the use of ordinal numbers is to distinguish between the elements. By way of an example, a first element is distinct from a second element, and the first element may encompass more than one element and succeed (or precede) the second element in an ordering of elements.

[00125] Further, unless expressly stated otherwise, or is an “inclusive or” and, as such includes “and.” Further, items joined by an or may include any combination of the items with any number of each item unless expressly stated otherwise.

[00126] In the above description, numerous specific details are set forth in order to provide a more thorough understanding of the disclosure. However, it will be apparent to one of ordinary skill in the art that the technology may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description. Further, other embodiments not explicitly described above can be devised which do not depart from the scope of the claims as disclosed herein. Accordingly, the scope should be limited only by the attached claims.

Claims

CLAIMS What is claimed is:

1. A method comprising: receiving a source event at a collection address from a source system, wherein the source event corresponds to a source record stored by the source system and comprises a source patient identifier and a timestamp; normalizing the source event to generate a normalized event using a processor to extract a key value pair from the source event, wherein the normalized event federated to the source system, wherein the normalized event comprises the source patient identifier and the timestamp; matching a unique patient identifier to the source patient identifier to form a matched event federated to the source system; consolidating the matched event to form a consolidated event federated to the source system, wherein the source record corresponds to the consolidated event, the matched event, the normalized event, and the source event, wherein the source record is matched to a different record from a different system; and transmitting the consolidated event to a subscriber system using a subscription address.

2. The method of claim 1, further comprising: matching the unique patient identifier to the normalized event using the processor to match the unique patient identifier to a source patient identifier of the normalized event that is from the source event and is mapped to the unique patient identifier, wherein the normalized event is windowed and processed with a plurality of normalized events by the source patient identifier and the timestamp before being matched. The method of claim 1, wherein the normalized event is federated to the source system using federation data that links the source system, source event, normalized event. The method of claim 1, further comprising: storing the source event to an event blob store; and storing the normalized event to a golden operational model store that is federated to the source system. The method of claim 1, wherein the normalized event is stored to a golden operational model store that is federated to the source system using federation data that links the golden operational model store to the source system. The method of claim 1, further comprising: consolidating the matched event to form the consolidated event, wherein the matched event is windowed and processed with a plurality of matched events by the unique patient identifier and the timestamp. The method of claim 1, further comprising: consolidating the matched event to form the consolidated event by searching for the different record in a plurality of golden operational model stores corresponding to a plurality of source systems, wherein the plurality of source systems comprises the source system and the different system. The method of claim 1, wherein the subscriber system displays information from the consolidated event in a timeline. The method of claim 1, wherein the subscriber system displays information from the source record with information from the different record. The method of claim 1, further comprising: verifying a subscriber system before transmitting the consolidated event based on a subscription level of the subscriber system. ystem comprising: a processor; and an application executing on the processor to perform: receiving a source event at a collection address from a source system, wherein the source event corresponds to a source record stored by the source system and comprises a source patient identifier and a timestamp; normalizing the source event to generate a normalized event using the processor to extract a key value pair from the source event, wherein the normalized event federated to the source system, wherein the normalized event comprises the source patient identifier and the timestamp; matching a unique patient identifier to the source patient identifier to form a matched event federated to the source system; consolidating the matched event to form a consolidated event federated to the source system, wherein the source record corresponds to the consolidated event, the matched event, the normalized event, and the source event, wherein the source record is matched to a different record from a different system; and transmitting the consolidated event to a subscriber system using a subscription address. system of claim 11, wherein the application further performs: matching the unique patient identifier to the normalized event using the processor to match the unique patient identifier to a source patient identifier of the normalized event that is from the source event and is mapped to the unique patient identifier, wherein the normalized event is windowed and processed with a plurality of normalized events by the source patient identifier and the timestamp before being matched. The system of claim 11, wherein the normalized event is federated to the source system using federation data that links the source system, source event, normalized event. The system of claim 11, wherein the application further performs: storing the source event to an event blob store; and storing the normalized event to a golden operational model store that is federated to the source system. The system of claim 11, wherein the normalized event is stored to a golden operational model store that is federated to the source system using federation data that links the golden operational model store to the source system. The system of claim 11, wherein the application further performs: consolidating the matched event to form the consolidated event, wherein the matched event is windowed and processed with a plurality of matched events by the unique patient identifier and the timestamp. The system of claim 11, wherein the application further performs: consolidating the matched event to form the consolidated event by searching for the different record in a plurality of golden operational model stores corresponding to a plurality of source systems, wherein the plurality of source systems comprises the source system and the different system. The system of claim 11, wherein the subscriber system displays information from the consolidated event in a timeline. The system of claim 11, wherein the subscriber system displays information from the source record with information from the different record. A method comprising: transmitting a subscription address to receive a consolidated event, wherein the consolidated event is generated by: receiving a source event at a collection address from a source system, wherein the source event corresponds to a source record stored by the source system and comprises a source patient identifier and a timestamp; normalizing the source event to generate a normalized event using a processor to extract a key value pair from the source event, wherein the normalized event federated to the source system, wherein the normalized event comprises the source patient identifier and the timestamp; matching a unique patient identifier to the source patient identifier to form a matched event federated to the source system; and consolidating the matched event to form the consolidated event federated to the source system, wherein the source record corresponds to the consolidated event, the matched event, the normalized event, and the source event, wherein the source record is matched to a different record from a different system; and receiving the consolidated event by a subscriber system using a subscription address, wherein the consolidated event is displayed by the subscriber system.