Data pipeline for heterogeneous clinical data ingestion, normalisation, augmentation and management

Abstract

A data pipeline for heterogeneous clinical data ingestion, canonicalization, augmentation, and management is described. In an example, a method can include receiving, by a system comprising a processor, a healthcare resource bundle configured according to a Fast Healthcare Interoperability Resources (FHIR) standard. The method also includes tracking, by the system, information about existing healthcare resources in a FHIR data store stored in a tracking database, where the information includes a logical identifier of the existing healthcare resource and a healthcare identifier of the existing healthcare resource associated with the existing healthcare resource in the FHIR data store, and processing, by the system, the bundle using a data refinement process and the tracking database, where the data refinement process includes updating the tracking database to include new information extracted from the bundle.

Description

Technical Field

[0001] This disclosure relates in general to a data pipeline for the ingestion, normalization, enhancement, and management of heterogeneous clinical data. Background Technology

[0002] Clinical data interoperability refers to the ability of different healthcare systems, applications, and devices to seamlessly exchange, interpret, and use clinical information. It ensures that patient data flows effectively across different systems and stakeholders (e.g., hospitals, clinics, pharmacies, laboratories) to improve care collaboration, enhance decision-making, and support better patient outcomes.

[0003] However, achieving effective integration of clinical information across different systems presents numerous challenges. Specifically, clinical information originates from a variety of information systems, such as electronic medical record (EMR) systems, electronic health record (EHR) systems, laboratory systems, imaging systems, and real-time patient monitoring devices. These systems often use different data models and file formats, making it difficult to align data structures. Furthermore, different hospital systems employ different data models and file formats. For example, shared clinical data from one hospital to another typically has different structures, different healthcare identifiers, and different codes, posing problems for any cross-content integration project. Although protocols such as Layer 7 Health Protocol (HL7) exist... ®） and Fast Healthcare Interoperability Resources (FHIR) ® While there have been standardization efforts such as [standards], not all systems fully comply with or support these standards, or can only provide limited datasets through them. For example, some EMR vendors design their systems to operate primarily within their ecosystem, thus limiting interoperability. Summary of the Invention

[0004] The following is a simplified summary of the invention presented in order to provide a basic understanding of certain aspects of this specification. This summary is not an exhaustive overview of the specification. It is not intended to identify key or essential elements of the specification, nor is it intended to describe any scope of any particular embodiment or claim. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that follows.

[0005] According to one embodiment, a system includes at least one memory storing a computer-executable component, and at least one processor executing the computer-executable component stored in the at least one memory. The computer-executable component may include a receiving component that receives data according to the Fast Healthcare Interoperability Resource (FHIR). ®The computer-executable component may also include a standard configuration of a healthcare resource package. This tracking database tracks information about existing healthcare resources stored in the FHIR data repository, including logical identifiers and healthcare identifiers of existing healthcare resources associated with them in the FHIR data repository. The computer-executable component may also include a data refinement component that processes the package using a data refinement process and the tracking database, and updates the tracking database to include new information extracted from the package.

[0006] In some implementations, the computer-executable component also includes a storage component that transfers the package or a refined version of the package to the FHIR data repository after the data refinement process.

[0007] In various implementations, the data refinement process includes determining whether each resource corresponds to an existing healthcare resource stored in the FHIR data repository, based on a comparison of the extracted healthcare identifier for each resource in the healthcare resources with the healthcare identifiers of existing healthcare resources in the tracking database. In some specific implementations of these schemes, based on the determination that a resource in the healthcare resources does not correspond to an existing healthcare resource, the data refinement process includes retaining the resource in the package and updating the tracking database to include a new entry for that resource.

[0008] In other specific implementations of these schemes, based on the determination that a resource in a healthcare resource corresponds to an existing healthcare resource, the data refinement process includes extracting an existing logical identifier for the resource from a tracking database, using that logical identifier to replace a new logical identifier associated with the resource, thereby generating an updated version of the resource, and retaining that updated version of the resource in the package, resulting in the generation of a refined version of the package. In some implementations, a storage component may further transmit the refined version of the package to the FHIR data repository after the data refinement process. Furthermore, based on the determination that the resource corresponds to an existing healthcare resource, the data refinement process also includes updating all (or, in some implementations, one or more) other references to the resource in the package using the existing logical identifier.

[0009] In some implementations, the information in the tracking database also includes sequence identifiers and source identifiers of existing healthcare resources.

[0010] According to these implementations, based on the determination that a resource in a healthcare resource corresponds to an existing healthcare resource, the data refinement process includes determining whether a source identifier corresponding to an existing healthcare resource corresponds to a new source identifier associated with that resource. Based on a second determination that the source identifier does not correspond to the new source identifier, the data refinement process further includes determining whether the new source identifier has a higher weight than the source identifier. The data refinement process further includes a third determination that, based on the new source identifier not having a higher weight than the source identifier, removing the resource from the package, thereby resulting in the generation of a refined version of the package.

[0011] Additionally or alternatively, the data refinement process also includes a third determination, based on the premise that the new source identifier has a higher weight than the source identifier, determining whether the new sequence identifier associated with the resource is superior to the sequence identifiers corresponding to existing healthcare resources in the tracking database. In some embodiments, based on a fourth determination that the new sequence identifier is not superior, the resource is removed from the package, resulting in the generation of a refined version of the package. In other embodiments, based on a fourth determination that the new sequence identifier is superior, the data refinement process includes retaining the resource in the package.

[0012] In some implementations, the elements incorporated in the disclosed system description can be embodied in different forms, such as computer-implemented methods, computer program products, or another form.

[0013] For example, in another embodiment, a computer-implemented method may include: receiving data from a system including a processor according to a Fast Healthcare Interoperability Resource (FHIR). ® The system provides a standard configuration of a healthcare resource package; it tracks information about existing healthcare resources stored in an FHIR data repository in a tracking database, including logical identifiers of existing healthcare resources associated with existing healthcare resources in the FHIR data repository and healthcare identifiers of existing healthcare resources; and it processes the package using a data refinement process and a tracking database, wherein the data refinement process includes updating the tracking database to include new information extracted from the package.

[0014] In another embodiment, a non-transitory machine-readable storage medium may include executable instructions that, when executed by a processor, facilitate the execution of operations including: receiving data according to the Fast Healthcare Interoperability Resource (FHIR). ®The package includes a standard configuration of healthcare resources; it tracks information about existing healthcare resources stored in an FHIR data repository in a tracking database, including logical identifiers of existing healthcare resources associated with existing healthcare resources in the FHIR data repository and healthcare identifiers of existing healthcare resources; and it processes the package using a data refinement process and a tracking database, wherein the data refinement process includes updating the tracking database to include new information extracted from the package. Attached Figure Description

[0015] Many aspects, specific embodiments, objects, and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which the same reference numerals denote the same parts, and wherein:

[0016] Figure 1 A high-level schematic diagram illustrating an example clinical data ingestion and standardization pipeline according to one or more implementation schemes described herein is provided.

[0017] Figure 2 A high-level block diagram illustrates an example system for facilitating the uptake and normalization of proprietary formatted clinical data according to one or more embodiments described herein.

[0018] Figure 3 A flowchart illustrating an example process for converting clinical data in a proprietary format into an FHIR resource according to one or more embodiments described herein;

[0019] Figure 4 Example mapping scripts for normalizing proprietary formatted clinical data are illustrated according to one or more embodiments described herein;

[0020] Figure 5 The relationship between example mapping scripts and example clinical data identifier scripts according to one or more embodiments described herein is illustrated;

[0021] Figure 6 Example mapping data for normalizing proprietary formatted clinical data according to one or more embodiments described herein are illustrated;

[0022] Figure 7 An example computer-implemented method for normalizing proprietary formatted clinical data according to one or more embodiments described herein is illustrated.

[0023] Figure 8 A high-level block diagram illustrates an example system for facilitating data deduplication management and clinical data identity resolution according to one or more embodiments described herein;

[0024] Figure 9A high-level flowchart illustrating an example process for facilitating data deduplication management and clinical data identity resolution according to one or more implementations described herein is shown.

[0025] Figure 10 Example tracking databases are illustrated according to one or more embodiments described herein;

[0026] Figure 11 A high-order flowchart illustrating an example process for facilitating the handling of race conditions according to one or more embodiments described herein is shown.

[0027] Figure 12 A high-order flowchart illustrating another example data refinement process according to one or more implementations described herein is shown.

[0028] Figure 13 An example computer-implemented method for facilitating data deduplication management and clinical data identity resolution according to one or more embodiments described herein is illustrated.

[0029] Figure 14 An example computer-implemented method for facilitating race condition processing according to one or more embodiments described herein is illustrated;

[0030] Figure 15 It is a schematic block diagram illustrating a suitable operating environment; and

[0031] Figure 16 This is a schematic block diagram of the sample computing environment. Detailed Implementation

[0032] The following specific embodiments are merely illustrative and are not intended to limit the implementation and / or application or use of the embodiments. Furthermore, they are not intended to be construed as being bound by any express or implied information presented in the foregoing "Background Art" section, "Summary of the Invention" section, or "Specific Embodiments" section.

[0033] This disclosure describes a cloud-based clinical data processing pipeline that addresses many challenges associated with clinical data integration, including how to consume and coordinate large volumes of heterogeneous clinical data received in parallel over time.

[0034] This disclosure describes a technique for coordinating and ingesting all received heterogeneous data in a single format (FHIR format).

[0035] Rapid Healthcare Interoperability Resource (FHIR) ®FHIR is a standard developed by HL7 (Layer 7 of Health International) to facilitate the electronic exchange of healthcare information. Designed to enable interoperability between different healthcare systems, FHIR is widely used to build modern healthcare applications. It combines existing healthcare data standards with web technologies to make data sharing easier and more efficient.

[0036] The proposed pipeline offers several solutions. Specifically, it normalizes heterogeneous structured clinical data into a single, unique model (based on FHIR). The pipeline also enhances clinical data through code and concept normalization and indexing. Furthermore, it addresses data duplication from dissimilar sources. Finally, the pipeline provides a high-performance method for resolving data race conditions.

[0037] The data ingestion and normalization pipeline offers numerous technological advantages. Specifically, this pipeline enables data manipulation and utilization by third-party products such as command centers and clinical applications. By normalizing data into a single, unique output structure, the pipeline enables efficient software development for new technologies that consume FHIR resources. Data augmentation using standardized code further enables downstream applications and entities (e.g., hospitals, clinicians, researchers, etc.) to search for and access data in the same way across different deployment scenarios or domains. The proposed pipeline also enables data capabilities to improve clinical information processing algorithms through artificial intelligence (AI) and accelerate patient access to healthcare, while improving intervention outcomes for patient care.

[0038] One or more embodiments will now be described with reference to the accompanying drawings, wherein the same reference numerals are used to denote the same elements throughout. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a more thorough understanding of the one or more embodiments. However, it will be apparent, in various cases, that one or more embodiments may be practiced without these specific details.

[0039] Now turn to the attached image. Figure 1An example clinical data ingestion and normalization pipeline 100 according to one or more embodiments described herein is illustrated. Pipeline 100 may include or correspond to one or more computing devices, machines, virtual machines, computer executable components, data repositories, etc., which may be directly or communicatively coupled to each other via one or more wired or wireless communication frameworks. For example, pipeline 100 may include ingestion gateway 104, “HL7 to FHIR” pipeline 106, FHIR pipeline 108, “proprietary to FHIR” pipeline 110, terminology normalization component 114, data refinement component 118, and FHIR data repository 122. These elements may accordingly include or correspond to one or more computing devices, machines, virtual machines, computer executable components, data repositories, etc., which may be directly or communicatively coupled to each other via one or more wired or wireless communication frameworks.

[0040] Pipeline 100 facilitates the ingestion of clinical data 102 in various formats from various clinical information systems, normalizes the clinical data 102 to FHIR format, and stores the FHIR formatted clinical data in an FHIR data repository 122. Pipeline 100 involves five main processes, including data ingestion, data structure normalization, data augmentation, data refinement, and storage. In this regard, the first process of pipeline 100 involves ingesting various clinical data 102 in various formats received from various clinical information systems via ingestion gateway 104. Therefore, clinical data 102 includes or corresponds to heterogeneous clinical data. For example, clinical information systems may include various types of electronic healthcare information systems, such as EHR systems, imaging systems, laboratory systems, medical devices, patient monitoring devices, bed management systems, administrative systems (e.g., billing systems, scheduling systems, etc.), and various other systems. Healthcare information systems may be associated with the same healthcare enterprise (e.g., the same hospital or hospital enterprise) and / or different healthcare enterprises. Clinical data 102 may include data pushed to ingestion gateway 104 periodically or continuously from these different healthcare information sources at the time of generation (e.g., in real time) or in response to another defined event or condition. In this respect, clinical data 102 may include or correspond to clinical data streams received periodically or continuously by ingestion gateway 104 from various clinical information sources over time.

[0041] According to various embodiments, the ingestion gateway 104 includes or corresponds to an application programming interface (API) that classifies the received clinical data 102 into one of three types based on the format of the received clinical data. These three types include HL7 clinical data in HL7 format, FHIR clinical data in FHIR format, and clinical data in any other proprietary format besides HL7 or FHIR. In various embodiments, the proprietary format may include JSON format. Additionally or alternatively, the proprietary format may include CSV format. These three different types of clinical data are normalized through separate normalization pipelines. In this case, normalization refers to converting the data to FHIR format. For example, the ingestion gateway 104 transmits HL7 clinical data to an "HL7 to FHIR" pipeline, which converts the HL7 clinical data to FHIR format. The ingestion gateway 104 also transmits clinical data received in FHIR format via an FHIR pipeline 108, which ensures that the data is correctly structured according to the FHIR format. Ingestion gateway 104 also transmits clinical data received in proprietary formats (such as CSV and JSON files) via a proprietary-to-FHIR pipeline 110, which converts the clinical data from proprietary formats to FHIR format. Therefore, the output of these three corresponding pipelines is a normalized representation of the clinical data 102 in FHIR format. In other words, after normalization via the corresponding pipelines 106, 108, and 110, the relevant data messages, files, data objects, etc., included in the clinical data 102 are converted into FHIR resources 112 according to the FHIR format.

[0042] In this regard, the FHIR format organizes healthcare data into modular units called “resources.” FHIR resources are the building blocks of the FHIR standard and represent key entities and concepts in healthcare. Each FHIR resource is a structured, reusable, and standardized representation of specific healthcare data. These resources can be combined and extended to cover a wide range of healthcare use cases, including patient records, clinical workflows, and public health reporting. Each resource contains a well-defined dataset representing a specific concept, such as a patient, observation, medication, and various other concepts. FHIR resources are categorized based on their purpose. Some key categories include clinical, administrative, financial, infrastructure, and more. Clinical FHIR resources represent clinical data and workflows. Some examples of clinical FHIR resources include: patient resources, which may include demographic data about patients; condition resources, which include data about clinical conditions or diagnoses; observation resources, which may include physiological measurements or examination results (e.g., blood pressure); and allergy / intolerance resources, which include information about patients’ allergies. Administrative resources relate to non-clinical workflows such as scheduling and billing. Examples of administrative resources include: practitioner resources, which include information about healthcare professionals; and organizational resources, which include data about healthcare organizations; appointment resources, which include scheduling and booking information; and reception resources, which include details of patient visits or interactions. Financial resources support billing, payment, and claims processing. Examples of financial resources include: claims resources, which include information related to payment requests for services; and insurance resources, which include details of insurance or payment agreements. Infrastructure resources support system-level operations and data exchange.

[0043] FHIR currently defines over 140 resources. Each FHIR resource has a standard structure, including mandatory and optional fields, making it flexible for a variety of use cases. For example, each resource includes key fields, including a unique identifier (ID) for the resource, metadata about the resource (e.g., version, source, last update time, etc.), and resource-specific data elements or core fields. Resources can also be extended to meet specific local or organizational needs, allowing for additional fields while maintaining compatibility with the basic standards. FHIR resources can be represented in JSON, XML, or Turtle (RDF) formats for interoperability. Resources are designed to work seamlessly with RESTful APIs, enabling CRUD (Create, Read, Update, Delete) operations using standard Hypertext Transfer Protocol (HTTP) methods such as GET, POST, PUT, and DELETE. FHIR resources provide the foundation for a flexible and interoperable healthcare ecosystem. Their modular design, scalability, and conformity to web standards make them powerful tools for modern healthcare IT solutions.

[0044] In various implementations, the HL7 to FHIR mapping can be performed by the "HL7 to FHIR" pipeline 106 through different commercial or proprietary tools (such as Microsoft Converter). ® Google Converter ® IBM converter ® (Or another proprietary converter) to perform this. The FHIR pipeline 108 only performs data cleaning and validation upon receiving FHIR data. The "Proprietary to FHIR" pipeline 110 converts these proprietary format clinical data into FHIR resources 112 through a proprietary mapping process between proprietary file formats such as CSV and / or JSON and the FHIR resources. (See reference...) Figures 2 to 7 The proprietary mapping process will be described in more detail.

[0045] When generating FHIR resource 112, regardless of the pipeline used (e.g., HL7 to FHIR pipeline 106, FHIR pipeline 108, or proprietary to FHIR pipeline 110), terminology standardization component 114 performs a terminology standardization process to convert FHIR resource 112 into enhanced FHIR resource 116. The terminology standardization process involves mapping terms included in FHIR resource 112 to corresponding standard terms based on a standardized ontology or nomenclature. For example, some hospitals may use their own coding systems with unique terms and codes to refer to specific data elements. The terminology standardization process matches these unique terms and codes with corresponding standardized versions of these terms and replaces the unique terms and codes with their corresponding standardized versions. This process essentially corresponds to converting terms in a first language into the same terms in a second standardized language. Terminology standardization component 114 may use a one-to-one mapping and / or a pre-configured AI conversion algorithm for code / terminology conversion to perform this process. Data augmentation using normalized code allows consumer applications to search for and access data in the same way across different deployment environments or domains.

[0046] Data refinement component 118 further refines the enhanced FHIR resource to transform the enhanced FHIR resource 116 into a refined FHIR resource 120. The refined FHIR resource 120 is then stored in the FHIR data repository 122. The data refinement performed by data refinement component 118 involves processing the enhanced FHIR resource to ensure that the same resource is not duplicated more than once in the FHIR data repository 122; this process is referred to herein as “data deduplication.” As used herein, “data deduplication” refers to the process of identifying and resolving duplicate instances of the refined FHIR resource and the FHIR resource within the FHIR data repository 122. In the healthcare industry, duplicate data is frequently generated due to system fragmentation, duplicate data inputs, or the consolidation of data from multiple sources. Deduplication mechanisms ensure that information is accurate, consistent, and free of redundancy, thereby improving data quality and system efficiency. Data deduplication is a core component of pipeline 100. The data deduplication process performed by data refinement component 118 eliminates inconsistencies caused by duplicate entries, thereby ensuring that healthcare providers and systems process reliable data. This reduces confusion when exchanging data between systems by ensuring that there is only one authoritative version of each resource. Furthermore, the data deduplication process reduces the storage requirements of the FHIR data repository by avoiding the storage of redundant data. Additionally, by ensuring that each resource in the FHIR data repository is unique, downstream errors caused by conflicting or redundant records (e.g., duplicate drug orders) are eliminated.

[0047] In some implementations, the data refinement component 118 also performs race condition management in conjunction with data deduplication. A race condition in FHIR refers to a situation where the outcome of an operation on an FHIR resource depends on the order or timing of concurrent events. This typically occurs when multiple systems, users, or processes attempt to access or modify the same resource simultaneously, leading to potential conflicts, data inconsistencies, or unexpected behavior. When applied to pipeline 100, a race condition may occur when updates to the same FHIR resource are processed by pipeline 100 from different sources at the same or similar time. For example, a healthcare source corresponding to a practitioner's IT system may provide updates to a patient's demographic details, while another IT system simultaneously transmits an update to the patient's address through the pipeline, potentially overwriting the data. Race conditions may also occur when two operations depend on the state of a resource and their outcomes conflict due to timing. For example, a status update marking a patient as "inactive" or "deceased" may be received at the same time as a patient's prescription resource. Race conditions may also occur when one process creates a resource while another process simultaneously attempts to reference it, causing the operation to fail if the resource is not yet available. The consequences of race conditions observed through pipeline 100 may include data rewriting in FHIR data repository 122, where critical updates may be unintentionally rewritten by conflicting changes, and data loss, where valuable information in FHIR data repository 122 may be erased or replaced due to uncoordinated actions. Furthermore, resources may end up in an invalid or incomplete state, leading to potential errors downstream.

[0048] The disclosed topics specifically relate to the "proprietary-to-FHIR" pipeline 110 and the data refinement component 118. (Reference) Figures 2 to 7 The features and functions of the "Proprietary to FHIR" pipeline 110 are described in more detail, and references are provided. Figures 8 to 13 The features and functions of the data refinement component 118 are described in more detail.

[0049] Figure 2 A high-level block diagram of an example system 200 for facilitating the uptake and normalization of proprietary formatted clinical data according to one or more embodiments described herein is illustrated. Reference Figure 1 and Figure 2 In various embodiments, system 200 corresponds to proprietary FHIR pipeline 110. Aspects of the systems, apparatus, or processes explained herein may constitute computer-executable or machine-executable components embodied within a machine (e.g., embodied in one or more computer-readable media associated with one or more machines). When executed by one or more machines (e.g., computers, computing devices, virtual machines, etc.), such components can enable the machines to perform the operations described herein.

[0050] For example, system 200 may include at least one memory 224 storing computer-executable component 202 and at least one processor or processing unit 226 executing computer-executable component 202 stored in the at least one memory 224. Computer-executable component 202 may include, but is not limited to, a receiving component 204, an initiating component 206, an extraction component 208, a mapping component 212, a template filling component 214, a forwarding component 216, an FHIR profile 218, a mapping script 220, and a Clinical Data Identifier Script (CDIS) 222. In various embodiments, computer-executable component 202 corresponds to a proprietary-to-FHIR pipeline 110. In other words, proprietary FHIR pipeline 110 may include or correspond to a computer-executable component including sub-components, such as receiving component 204, initiating component 206, extraction component 208, mapping component 212, template filling component 214, forwarding component 216, FHIR profile 218, mapping script 220, and CDIS 222. Examples of the memory 224 and processing unit 226, as well as other suitable computer or computing-based components, can be found in [reference]. Figure 15 Locate (e.g., system memory 1516 and processing unit 1514 respectively), and can be combined to achieve integration. Figure 2 Or use with one or more components shown and described in the other accompanying drawings disclosed herein.

[0051] Receiving component 204 (e.g., from ingestion gateway 104) receives clinical data 228, which is in a proprietary format. In some embodiments, the proprietary format may include JSON. In other embodiments, the proprietary format may include a non-JSON format, such as CSV. In embodiments where the proprietary format does not include JSON, initiating component 206 converts the clinical data from a non-JSON format to JSON format before transforming the clinical data 228 into FHIR resource 230. The clinical data 228 may be structured or unstructured depending on the proprietary format. The clinical data 228 may correspond to data messages, JSON files, CSV files, etc. In this regard, although various features and functions of the computer-executable component 202 have been described in association with the transformation of a single file or message into one or more FHIR resources 230, it should be understood that system 200 is configured to receive and process a continuous stream of clinical data 228 corresponding to messages or files received periodically or continuously over time. In this case, clinical data 228 may be received over time from various different healthcare information systems.

[0052] As described above, the computer-executable component 202 performs a conversion process to convert clinical data 228 into one or more FHIR resources 230 according to the FHIR format. The one or more FHIR resources 230 may include or correspond to one or more of the FHIR resources 112 output from the "Proprietary to FHIR" pipeline 110. At a higher level, this conversion process performed by the "Proprietary to FHIR" pipeline 110 involves converting proprietary-format clinical data into FHIR resources 230 based on mapping data elements extracted from the clinical data to one or more FHIR profiles defined for the clinical data. (Reference) Figure 3 The conversion process and the corresponding features and functions of the computer executable component 202 are described.

[0053] Figure 3 A flowchart illustrating an example process 300 for converting clinical data 228 in a proprietary format into an FHIR resource 230 according to one or more embodiments described herein is provided. Reference Figure 2 and Figure 3 Process 300 begins at 302 with the receipt of clinical data 228 in a proprietary format (e.g., via receiving component 204). After receiving clinical data 228 at 304, if the proprietary format is JSON, process 300 proceeds to 308. However, if the proprietary format is not JSON, but rather a CSV format or another type of non-JSON format, at 306, the initiating component converts the clinical data to JSON format, producing clinical data 228' in JSON format.

[0054] At 308, the initiating component 206 first indicates one or more FHIR profiles included in FHIR profile 218 corresponding to clinical data 228 (or clinical data 228'), and generates a corresponding template FHIR profile including template FHIR resource 305.

[0055] FHIR profiles are customized definitions of FHIR resources that specify how those resources should be used in a particular context or for a specific use case. They extend or constrain the basic FHIR standard to meet the requirements of a particular organization, project, or region, thereby ensuring consistent data exchange and interpretation. For example, as mentioned above, FHIR currently defines more than 140 different resources corresponding to different categories of healthcare information, including clinical and non-clinical information (e.g., administrative, financial, etc.). These basic defined resources define the format for representing FHIR resources and define the required data elements and optional data elements for each FHIR resource. Profiles extend the FHIR standard by adding custom elements through extensions. They also constrain basic FHIR resources by restricting allowed values, enforcing specific fields (e.g., making birthDate a required field for the "Patient" resource), and adding additional rules or business logic.

[0056] For example, "Observation" is one type of FHIR resource included among different types of FHIR resources. Many types of clinical data can be considered observations. For example, vital signs such as heart rate, blood pressure, and temperature can be different types of observations. In another example, laboratory data such as blood glucose, imaging results, clinical findings, device measurements, eye color, and other personal characteristics, as well as various other information, can also be types of observations. The FHIR resource type "Observation" defines the JSON template to be used for each observation and includes the required data fields, and constraints on the values ​​or text that can be included in each data field. Profiles, for example, are used to further refine FHIR resources classified as "Observations" into various subtypes tailored to specific use cases. In this respect, FHIR profiles are restrictions on a generic FHIR resource type by adding constraints to align resources with use cases. For example, vital signs are a type of "Observation," but require additional constraints, such as the observation category should have a fixed value: "vital-signs". In another example, "Location" is another type of FHIR resource included among different defined FHIR resource types. Hospitals can define custom configuration files for "location" resources to define different types of "location" resources, such as bed locations, room locations, and facility locations.

[0057] In this regard, FHIR profile 218 includes or corresponds to a list of predefined FHIR profiles that can be customized for a specific organization, project, or region. In other words, FHIR profile 218 may include customized sub-definitions of various FHIR resources, where each profile defines required and fixed elements, optional elements, and constraints on data (i.e., values, text, etc.) that may be included in the FHIR resource.

[0058] Typically, a corresponding FHIR profile 218 represents a single FHIR resource. In other words, a single FHIR profile typically defines constraints for a single resource. For example, a custom “Patient” profile might specify: mandatory fields such as ID number and date of birth, restrictions on gender values, and extensions to additional fields such as “preferred language.” This custom profile applies only to the “Patient” resource type. However, FHIR profile 218 may also reference other profiles to ensure consistent relationships between resources. For example, a custom profile for “Observation” might need to reference specific profiles for related resources, such as the “Patient” profile for Observation.subject or the “Practitioner” profile for Observation.performer. This creates a network of profiles covering multiple resources. For example, suppose FHIR profile 218 includes multiple profiles related to the use case of reporting clinical data 228 of laboratory results. These multiple profiles could include a first profile for the “Observation” resource that requires Observation.code to use a specific laboratory code. The same profile could also require references to the Patient profile. Therefore, the FHIR profile will also include a separate "Patient" profile with specific constraints. Together, these profiles ensure that laboratory results conform to the "Observation" profile, and that the patients referenced in the results conform to the "Patient" profile.

[0059] According to procedure 300, at 308, initiating component 206 identifies one or more FHIR profiles included in FHIR profile 218 that correspond to clinical data 228 (or clinical data 228'). This involves identifying terms or elements included in the clinical data that correspond to one or more defined profiles in the FHIR profile. For example, suppose clinical data 228 corresponds to a bed request message in JSON format. In FHIR, a bed request typically corresponds to a patient needing to be assigned to a hospital bed, usually as part of an admission or care management process. While FHIR does not have a proprietary resource specifically named "Bed Request," the concept can be modeled using a combination of existing FHIR resources, customized using one or more custom FHIR profiles based on the context and requirements of the workflow. For example, a bed request message may include a message identifier indicating that the message type is a bed request, and an FHIR profile may include a specific profile for the bed request that also considers combinations of different FHIR resources, such as a "Service Request" resource, a "Patient" resource, a location resource, etc.

[0060] In most implementations, clinical data 228 will reference a collection of multiple FHIR resources. This collection of FHIR resources is referred to as an FHIR package. In some implementations, a single FHIR profile may be defined for an FHIR package. Using these implementations, a template FHIR resource 305 created at 308 may represent multiple FHIR resources. In other implementations, at 308, initiating component 206 may identify multiple FHIR profiles referenced in the clinical data and create a template FHIR resource for each of these multiple FHIR profiles. In any of the foregoing, one or more template FHIR resources 305 correspond to a structured JSON file having data fields including one or more fixed values ​​(such as the fixed value "vital signs" for the "observation" category field defined via the FHIR profile) and one or more framed data fields that need to be populated with text and / or values ​​extracted from clinical data 228 (or clinical data 228'). In other words, FHIR profile 218 is used to initiate the generated FHIR resource 305 using the required and fixed elements. For example, if the FHIR profile selected at 308 is the "VitalSign" profile, the template FHIR resource may include many elements, including fixed elements for classifying elements containing the value "vital-sign", and other framed data fields that need to be populated, such as required fields referencing the patients involved.

[0061] At 310, extraction component 208 extracts identifiers and corresponding values ​​of clinical data elements from clinical data 228 (or clinical data 228'), and mapping component 212 generates identifier-to-value mapping data 307. The identifiers correspond to the identifiers of data elements corresponding to the framed data fields to be populated, and the values ​​correspond to the actual values ​​to be included in the corresponding framed data fields. To facilitate this purpose, extraction component 208 and mapping component 212 employ mapping script 220. At 312, based on CDIS 222, mapping data 307, and template FHIR resource 305, template filling component 214 then uses the extracted clinical data to populate the framed data fields of template FHIR resource 305 to generate FHIR resource 230.

[0062] As described above, FHIR resource 230 corresponds to a portion of the outflow "proprietary-to-FHIR" pipeline 110 of FHIR resource 112. In various embodiments, forwarding component 216 transmits these FHIR resources 230 (and / or FHIR resources 112) to terminology standardization component 114, which then transforms them into enhanced FHIR resources 116.

[0063] In this regard, CDIS 222 allows the template-filling component 214 to identify non-fixed values ​​in the FHIR profile using specific identifiers to be used. For example, when applied to a resource in a custom “Observation” profile corresponding to vital signs, “effectiveDateTime” can be defined in the profile as an element that needs to be collected from a proprietary clinical data structure. CDIS 222 is a JSON file containing key-value elements, including identifiers and JSON paths to the FHIR resource. For example, for vital sign dates, the key-value pair could be: (DATETIME, Observation.effectiveDateTime).

[0064] Mapping script 220 enables mapping component 212 to map clinical data between proprietary formats to identifiers of clinical data described in CDIS 222 (another JSON document). The mapping script is also a JSON file with key-value elements, where the keys are identifiers from the CDIS document and the values ​​are JSON paths describing links to the proprietary data.

[0065] For example, Figure 4An example of a portion of a mapping script 400 according to one or more embodiments described herein is illustrated. In this example, the mapping script 400 identifies a JSON file of clinical data elements by identifiers. The identifiers for the keys correspond to field names. For example, in this example, the key data elements are applicable to the bedRequest FHIR profile and include information such as facility ID, facility legal name, facility abbreviation, unit ID, and unit full name. In addition to the field names, the mapping script also includes other key elements associated with the clinical data elements, including the value type and whether the corresponding FHIR resource requires the data element. Furthermore, the mapping script provides a JSON path for each data element corresponding to a field name in a proprietary format. In this regard, to identify the corresponding value for the corresponding identifier (i.e., field name), the extraction component 208 executes the JSON path within the proprietary clinical data structure. In other words, at 310 of process 300, for each field name included in the mapping script, the extraction component 208 executes the corresponding JSON path to identify and extract the corresponding value, such as actual facility ID, actual facility abbreviation, etc., from the proprietary clinical data 228. Therefore, the output at 310 includes mappings of identifiers in the mapping script (e.g., field names to actual extracted values). The JSON path for each data element depends on the proprietary clinical data structure. In this respect, mapping script 400 (and mapping script 220) includes the JSON paths for all data elements received in clinical data 228, which have a proprietary format identified by their corresponding identifiers (i.e., field names).

[0066] After the mapping data 307 has been generated, at 310, the values ​​need to be mapped to the corresponding FHIR resource fields included in the template FHIR resource 305 in order to use these values ​​to populate the framed data file. To facilitate this purpose, the clinical data identifier script 222 provides a mapping between identifiers and corresponding FHIR resource fields included in the template FHIR resource.

[0067] in this regard, Figure 5 The relationship between mapping script 220 and CDIS 222 according to one or more embodiments described herein is illustrated. Mapping script 220 includes mapping list 502 and path mapping information 504. Mapping list identifies the types of data elements that need to be extracted from proprietary clinical data 228. Path mapping information 504 provides the JSON path, field name (which corresponds to the identifier of the data element), definition of the data element, value type, and whether it is required for each element included in mapping list 502.

[0068] CDIS 222 includes CDIS file 506, which contains corresponding information for path mapping 508. Path mapping 508 provides FHIR paths and definitions to the corresponding FHIR identifiers for the corresponding field names included in path mapping information 504. The field names in path mapping 508 from CDIS 222 reference field name elements in path mapping 504 from mapping script 220.

[0069] Figure 6 Table 600, presented in a simplified representation of an example CDIS file 506, describes the elements of the path mapping 508 associated with the CDIS file 506. As in the example in Table 600, column A includes identifiers of data elements extracted from proprietary clinical data. Column B includes their definitions, and column C includes their corresponding FHIR paths associated with template FHIR resource 305.

[0070] Figure 7An example computer-implemented method 700 for normalizing proprietary formatted clinical data according to one or more embodiments described herein is illustrated. Method 700 corresponds to an example method executable by system 200 according to one or more embodiments. Method 700 includes: at 702, receiving clinical data in JSON format by a system including a processor (e.g., via receiving component 204). For example, the proprietary format may be JSON, CSV, or another proprietary format other than HL7 or FHIR. In a specific implementation where the proprietary format is not JSON, initiating component 206 converts the clinical data to JSON format before converting the clinical data to an FHIR resource, as described in process 300. At 704, method 700 includes identifying an FHIR profile (e.g., FHIR profile 218) from a defined set by the system (e.g., via initiating component 206) that corresponds to an FHIR resource included in the clinical data. At 706, method 700 includes the system generating a template FHIR resource comprising fixed data fields and framed data fields based on the FHIR profile (e.g., via initiation component 206). At 708, method 700 includes the system extracting information corresponding to the framed data fields from the clinical data using JSON paths of identifiers such as those defined in a mapping script (e.g., via extraction component 208). At 710, method 700 includes the system mapping values ​​to identifiers to generate mapping information (e.g., mapping data 307) (e.g., via mapping component 212). At 712, method 700 includes the system mapping identifiers to framed data fields using corresponding FHIR paths of identifiers included in a clinical data identifier script. At 714, method 700 includes the system using the mapping information to populate values ​​for the framed data fields, resulting in a conversion of clinical data to an FHIR resource (e.g., via template population component 214).

[0071] Figure 8 A high-level block diagram of an example system 800 for facilitating data deduplication management and clinical data identity resolution according to one or more embodiments described herein is illustrated. In some embodiments, system 800 may include system 200, and vice versa. For example, in some embodiments, system 800 may include one or more computer-executable components of computer-executable component 202. Reference Figure 1 and Figure 8The aspects of the systems, apparatus, or processes explained in this disclosure may constitute computer-executable or machine-executable components embodied within a machine (e.g., embodied in one or more computer-readable media associated with one or more machines). When executed by one or more machines (e.g., computers, computing devices, virtual machines, etc.), such components may enable the machines to perform the operations described herein.

[0072] For example, system 800 may include at least one memory 818 storing a computer-executable component 802 and at least one processor or processing unit 820 executing the computer-executable component 802 stored in the at least one memory 818. The computer-executable component 802 includes a data refinement component 118, which may include a receiving component 804, an extraction component 806, an identifier resolution component 808, a race condition component 812, a storage component 814, and a tracking database 816. Examples of the memory 818 and processing unit 820, as well as other suitable computer or computing-based elements, may be found in [reference needed]. Figure 15 Locate (e.g., system memory 1516 and processing unit 1514 respectively), and can be combined to achieve integration. Figure 8 Or use with one or more components shown and described in the other accompanying drawings disclosed herein.

[0073] Combination Figure 1 For reference Figure 8 In various embodiments, receiving component 804 receives FHIR resource 801, data refinement component 118 refines FHIR resource 801 into refined FHIR resource 803, and then sends it to FHIR data repository 122 for storage therein (e.g., via storage component 814). In some embodiments, FHIR resource 801 may correspond to enhanced FHIR resource 116 generated by terminology normalization component 114 according to pipeline 100, and refined FHIR resource 803 may include or correspond to refined FHIR resource 120. Additionally or alternatively, FHIR resource 801 may include or correspond to FHIR resource 112, and terminology normalization component 114 may be removed from pipeline 100.

[0074] For reference Figure 1The main problems that may occur when clinical data 102 is received in parallel over time from different sources (or even the same source) via ingestion gateway 104 involve receiving clinical data that references existing resources in FHIR data repository 122. Typically, this can lead to duplicate FHIR resources in FHIR data repository 122, or different instances of the same resource being referenced using different identifiers, causing confusion regarding the correct representation of the data. Furthermore, because clinical data 102 is received in parallel through different pipelines (e.g., "HL7 to FHIR" pipeline 106, FHIR pipeline 108, and "Proprietary to FHIR" pipeline 110) related to the same FHIR resource or existing resources in FHIR data repository 122, race conditions frequently occur, leading to errors such as inconsistencies between data and data overwriting.

[0075] In various implementations, the data refinement component 118 reviews and refines the FHIR resources 801 before transferring them to the FHIR data repository 122 (e.g., via storage component 814, as refined FHIR resources 120) to ensure that the FHIR resources are not duplicated and to mitigate problems related to competitive conditions. In this respect, the refinement of FHIR resources 801 is a complex process. The goal is to be able to process clinical data from multiple dissimilar sources and avoid duplication of resources created in the FHIR data repository 122. If duplicate resources are not resolved before being pushed to the FHIR data repository 122, the data may become cluttered, duplicated, and related FHIR resources may be improperly linked. Therefore, the data refinement component 118 is a cornerstone of any successful cross-source integration project.

[0076] In various implementations, data refinement component 118 performs a data refinement process that uses extraction component 806, identifier resolution component 808, and tracking database 816 to facilitate data deduplication and clinical data identity resolution. (Reference) Figure 9 and Figure 10 The data refinement process and the corresponding features and functions of the components applied to it are discussed. Additionally or alternatively, data refinement component 118 may use extraction component 806, identifier resolution component 808, race condition component 812, and trace database 816 to perform another data refinement process. (See reference) Figure 10 The data refinement process and the corresponding characteristics and functions of the components applied to it are discussed.

[0077] Now combine Figure 8 Come to Figure 9 , Figure 9A high-level flowchart illustrating an example data refinement process (i.e., process 900) facilitating data deduplication management and clinical data identity resolution according to one or more embodiments described herein is provided. Process 900 begins at 902, where receiving component 804 receives an FHIR resource package (FHIR resource package 903) included in FHIR resource 801. In this regard, in some embodiments, FHIR resource 801 may include a single FHIR resource. In other embodiments, FHIR resource 801 may include a group of FHIR resources generated and aggregated together from the same clinical data message or file or group of clinical data messages / files as an FHIR package. For example, as referenced... Figure 3 Generally speaking, clinical data 228 can reference multiple FHIR resources, such as observation, patient, location, etc. This applies to clinical data processed via the "HL7 to FHIR" pipeline 106 and the FHIR pipeline 108.

[0078] Process 900 is described in connection with the processing of the FHIR resource package (also referred to as FHIR resource package 903). According to these embodiments, process 900 assumes that FHIR resource 801 comprises the FHIR resource package, and at 904, subprocess 906 is executed independently for each resource in the package. In some embodiments, after each resource in package 903 has been examined according to process 900 (and in some specific embodiments, process 900 and process 1100), the package, or a refined or updated version of the package (if created), is then sent to the FHIR data repository 122.

[0079] In this regard, an FHIR package (e.g., FHIR resource package 903) has multiple entries, and each entry corresponds to an FHIR resource. Associated with receiving clinical data 102, regardless of the initial format of the received clinical data (e.g., HL7, FHIR, or proprietary JSON or CSV format, or other types of proprietary formats), the clinical data is associated with a request action (also known as a query type) indicating its purpose or how it should be processed. In this regard, each FHIR resource in FHIR resource 801 is associated with a query type. In this regard, FHIR resources are designed to work seamlessly with a RESTful API, enabling CRUD (create, read, update, delete) operations using standard Hypertext Transfer Protocol (HTTP) methods such as GET, POST, PUT, and DELETE operations. In this regard, GET operations correspond to requests to read or retrieve a specific FHIR resource, POST operations correspond to explicit requests to create a new FHIR resource for the first time, PUT operations correspond to requests to update or replace an existing resource or create a new resource (if it does not already exist in FHIR data repository 122), and DELETE operations correspond to requests to delete an FHIR resource from FHIR data repository 122. Process 900 specifically addresses PUT requests because these requests involve implicit requests to update an existing resource or create a new resource (if it does not already exist in FHIR data repository 122). Conversely, POST requests received through pipeline 100 correspond to explicit requests to create new FHIR resources, and process 900 assumes that all POST requests are valid, therefore duplication of FHIR resources in FHIR data repository 122 is not a problem.

[0080] Furthermore, each FHIR resource included in a new package (e.g., FHIR resource package 903) processed by system 800 includes one or more healthcare information identifiers, also referred to herein as healthcare identifiers (HIDs), which are assigned by the healthcare information source providing the data to uniquely identify the data. For example, when applied to a patient, an HID may include an organization-unique medical record number (MRN) for the treating patient. In another example, when applied to medical image data, an HID may include a unique examination number. Additionally, a single FHIR resource may include multiple unique HIDs. For example, a patient resource may also be associated with a specific visit or reception and include a corresponding unique HID for that visit or reception. Furthermore, each FHIR resource stored in FHIR data repository 122 includes a unique logical ID (LID), which is an ID used to identify the resource in FHIR data repository 122.

[0081] With processing included in FHIR resource package 903, a single FHIR resource (in Figure 9The sub-process 906 is described in association with a resource identified as FHIR resource 903k. The number k of FHIR resources included in the FHIR resource package 903 can vary and may include one or more resources. As described above, the data refinement component 118 executes the sub-process 906 for each resource in the FHIR resource package 903.

[0082] According to subprocess 906, at 908, the extraction component first extracts one or more HIDs for FHIR resource 903k. At 910, the extraction component identifies or extracts the query type associated with FHIR resource 903k. As mentioned above, the query type may include, but is not limited to, GET, POST, PUT, or DELETE. At 910, the extraction component determines whether the query type is PUT, i.e., a request to update the resource or an implicit request to create a new resource. If at 910 the extraction component 806 determines that the query request is not PUT, then the query request is GET, POST, or DELETE. In this case, subprocess 906 continues to 914, where the identifier resolution component 808 does not perform an update on resource 903k or the package 903 associated with resource 903k. However, at 916, the identifier resolution component creates a new entry for resource 903k in the tracking database 816.

[0083] In this respect, the tracking database 816 corresponds to a local database or index used by the data refinement component 118 to track information relating to FHIR resources (referred to herein as existing FHIR resources) that already exist in the FHIR data repository 122. In this regard, associated with reviewing a new package (e.g., FHIR resource package 903) before it is delivered to the FHIR data repository, process 900 employs the tracking database 816 to ensure that each resource in the package includes the correct LID before the package is delivered to the FHIR data repository 122, and to update the tracking database 816 to include new information about any new resources included in the package before the package is delivered to the FHIR data repository 122.

[0084] Figure 10 An example tracking database 1000 is illustrated according to one or more embodiments described herein. Combined with Figure 8 and Figure 9 For reference Figure 10 Trace database 1000 corresponds to an example of trace database 816. For example... Figure 10As shown, the tracking database 1000 corresponds to a spreadsheet or index of information related to FHIR resources stored in the FHIR data repository 122. Each row corresponds to a single FHIR resource. Column A corresponds to the resource type and identifies the type of resource (e.g., patient, service request, etc.). Column B corresponds to the LID, which is the ID used for the resource in the FHIR data repository 122. In this respect, in addition to the one or more HIDs, each FHIR resource received by the system 800 also includes a LID assigned to it, which has been generated by the entity or pipeline that created it (e.g., one of pipelines 106, 108, and 110). Each FHIR resource received by the system 800 also includes information indicating the resource type.

[0085] Column C corresponds to one or more HIDs used for FHIR resources. Column C also corresponds to the sequence number. This is an identifier that tracks the receiving order of resources. In various implementations, each resource received by system 800 also includes a sequence number assigned to it, indicating the order in which the system received the resources. Additionally or alternatively, receiving component 804 may assign sequence numbers to received resources, where the sequence numbers are numerically ordered in ascending order, such that newer or more recently received resources are assigned larger numbers than older resources. In some specific implementations, two or more resources may be received at the same time or nearly at the same time. In these scenarios, the sequence numbers of the corresponding resources may be the same. For example, as shown in Table 1000, sequence number 1001 is applied to both the patient resource in row 2 and the service request resource in row 3, indicating that both resources were received simultaneously via gateway 104 and / or system 800. Therefore, the sequence number here is a numerically ordered number. However, the sequence number may also include or correspond to a timestamp.

[0086] The source ID (SID) indicates the source from which the resource is provided. For example, a source can be an electronic medical record (EMR) system, a radiology information system (RIS), a laboratory system, a bed management system, a scheduling system, a patient monitoring device, or any other type of healthcare information source associated with a specific location (e.g., location 1, location 2, etc.). Each FHIR resource received by system 800 also includes its source ID.

[0087] Returning to reference procedures 900 and 906, as described above, if the resource query is not a PUT request, then resource 903k or the associated package 903 does not need to be updated before the resource query is transmitted to the FHIR data repository 122. However, at 916, the identifier resolution component creates a new entry for the resource in the tracking database 816. This corresponds to adding a new row to the tracking database 1000 for the package corresponding to resource 903k. For example, the new entry for the resource will include information about the resource extracted by the extraction component 806 from FHIR resource 903k corresponding to columns A, B, C, and D; namely, resource type, LID, one or more HIDs, sequence number, and source ID. At 918, resource 903k is further maintained in the package. Subprocess 906 is further executed for the remaining resources in package 903 until all resources in package 903 have been examined.

[0088] If at 910 the extraction component 806 determines that the query request is a PUT request, then at 912, the identifier resolution component 808 checks the trace database to determine whether the HID of the resource has been included in the trace database 816. In this regard, if the HID of resource 903k extracted at 908 is not yet referenced in the trace database 816, it means that resource 903k does not yet exist in the FHIR data repository 122. Therefore, if at 912 the identifier resolution component 808 determines that one or more HIDs are not included in the trace database, process 900 proceeds again to 914, where the identifier resolution component 808 does not perform an update on resource 903k or the package associated with resource 903k. However, at 916, the identifier resolution component 808 creates a new entry for resource 903k in the trace database 816. At 918, resource 903k is further maintained in the package. Subprocess 906 is further executed for the remaining resources in package 903 until all resources in package 903 have been reviewed.

[0089] If at 912, the identifier resolution component 808 determines that any HID among the one or more HIDs extracted at 908 has already been included in the tracking database 816, this means that the FHIR resource 903k already exists in the FHIR data repository 122. In this case, process 900 proceeds to 920, where the extraction component 808 extracts the existing LIDs in the tracking database 816 corresponding to the existing entries for resource 903k. More specifically, the identifier resolution component 808 identifies entries in the tracking database 816 that have existing HIDs corresponding to the one or more HIDs extracted at 908 and of the same resource type. For example, looking at table 1000, if the FHIR resource is a patient type, and the one or more HIDs extracted at 908 correspond to the HIDs shown in the cell corresponding to column C, row 2, then in this case, resource 903k has already been stored in the FHIR data repository 122, where the existing LID corresponds to column B, row 2. In this case, resource FHIR 903k needs to be updated using its existing LIDs in the tracking database.

[0090] In this regard, at 922, the identifier resolution component 808 updates the FHIR resource 903k to include the existing LID already associated with the resource in the tracking database 816. This corresponds to replacing the new LID associated with the resource 903k received by the system 800 with the existing LID of the resource included in the tracking database 816, transforming the FHIR resource 903k into the updated FHIR resource 903k'. The identifier resolution component 808 also updates the PUT request associated with the resource 903k. This means that the identifier resolution component 808 uses the existing LID to update the header of the PUT request.

[0091] In addition to updating FHIR resource 903k, at 924, identifier resolution component 808 utilizes existing LIDs to update all (or, in some specific implementations, one or more) other references to the same resource in FHIR package 903. In this regard, see the references above. Figure 2 The FHIR resources in the package can be related and include reference information referencing related resources. Therefore, each time resource 903k is referenced in the package, at 924, the identifier resolution component uses the existing LID extracted at 920 to replace any LID associated with each (or, in some specific implementations, one or more) instance of resource 903k. At 926, the updated FHIR resource 903k' is then retained in package 903. Subprocess 906 is further executed on the remaining resources in package 903 until all resources in package 903 have been reviewed.

[0092] In this respect, the result of process 900 includes FHIR package 903 with no resources updated, or an updated or revised version of FHIR package 903 with one or more FHIR resources updated using the correct LID, and an updated FHIR package 903 with references to those updated resources updated using the correct LID. For example, in some implementations, if the decision result is no for each resource after decision boxes 910 and 912, the FHIR package generated by process 900 corresponds to FHIR resource package 903. This means that FHIR package 903 does not include any duplicate instances of FHIR resources with incorrect LIDs stored in FHIR data repository 122. In other implementations where at least one resource is updated after a "yes" decision at 912, the FHIR resource package generated from process 900 corresponds to an updated or refined resource package.

[0093] In some implementations, the FHIR resource package generated from process 900 may be transferred to and stored in FHIR data repository 122 (by storage component 814 as refined FHIR resource 803). Additionally or alternatively, the corresponding resources included in the FHIR package 903 may also be processed according to process 1100 to check and remove resources associated with detected race conditions.

[0094] in this regard, Figure 11 A high-order flowchart illustrating an example data refinement process (i.e., process 1100) for facilitating the handling of race conditions according to one or more embodiments described herein is provided. Combined with... Figure 1 , Figure 8 and Figure 9 For reference Figure 11 Process 1100 involves managing race conditions. In this regard, in the context of pipeline 100, competitive consumption of clinical data refers to the parallel ingestion of clinical data 102 from multiple healthcare information sources over time. Depending on the source and the type of clinical information derived from it, some clinical data messages may be received via the "HL7 to FHIR" pipeline 106, via the FHIR pipeline 108, and / or the "proprietary to FHIR" pipeline 110, and reference the same or related FHIR resources. In this regard, race conditions may occur when multiple processes or systems attempt to update or create related FHIR resources simultaneously, leading to inconsistent or unintended states.

[0095] For example, suppose system 800 receives and processes a first FHIR packet containing a new "reception" resource for a specific "patient" resource, where both the "reception" resource and the "patient" resource are components of the received first packet. A second FHIR packet is received immediately after a few milliseconds, containing an update to the patient demographics as part of a new version of the first shared "patient" resource. If system 800 processes the second packet and transmits it to the FHIR data repository 122 before processing the first FHIR packet and transmitting it to the FHIR data repository 122, it results in the use of outdated patient information included in the first FHIR packet to overwrite the update to the patient resource included in the second FHIR packet. As a result of this race condition, the "patient" resource in the FHIR data repository 122 will now reflect the state prior to the update from the second packet, effectively losing the new demographic information added by the second packet. In this respect, the "reception" resource has been successfully created, but the integrity of the "patient" record is compromised.

[0096] To prevent or mitigate such errors, process 1100 also relies on information in the tracking database 816, as well as a rule-based weighting protocol used to determine whether to retain or remove the corresponding resource with an existing entry in the tracking database 816 before transmitting package 903k or its revision 903k' to the FHIR data repository 122.

[0097] Process 1100 involves processing each FHIR resource included in an FHIR package (e.g., FHIR resource package 903) individually until race conditions for all resources have been checked. In this respect, when applied to an FHIR package, process 1100 corresponds to an iterative process, wherein in each iteration, the individual FHIR resources included in the package (e.g., FHIR resource package 903k) (or an updated version of the package with one or more resources removed) are processed before being sent to the FHIR data repository 122. For illustrative purposes, process 1100 is described as being applied to a single FHIR resource 903k included in FHIR package 903.

[0098] In this regard, process 1100 begins at 1102, where extraction component 803 extracts one or more HIDs from FHIR resource 903k. At 1104, race condition component 812 checks whether an entry exists in the tracking database 816 that includes any of the one or more HIDs. If not, this means that no resource associated with the same HID exists in FHIR data repository 122, and therefore resource 903k can be transferred to FHIR data repository 122 without causing a race condition. In this case, process 1100 proceeds to 1114, where race condition component 812 retains resource 903k in packet 903. However, if at 1104, race condition component 812 determines that any of the HIDs in the tracking database 816 exist, process 1100 proceeds to 1106.

[0099] At 1106, race condition component 812 then checks the source of resource 903k to determine if the source is the same as an existing source of an entry for the resource in the trace database. Specifically, race condition component 812 identifies an existing source of an existing resource in trace database 816 (e.g., in column E of example trace database 1000) that corresponds to an entry with an existing HID that corresponds to the HID retrieved at 1102. For example, as shown in example trace database 1000, race condition component 812 checks the source ID of the existing resource corresponding to the HID and compares it with the source ID associated with resource 903k to determine if the corresponding source IDs are the same. If the source IDs are not the same, process 1100 proceeds to 1108.

[0100] At 1108, the race condition component 812 further determines which of the two resource IDs is better, which corresponds to determining which of the two sources has a stronger or higher weight. In this regard, all resources that provide clinical information 102 may have predefined weights according to a predefined weighting scheme. Information identifying the corresponding weights of possible resource IDs may be stored in memory 818. For example, an EMR may have a higher weight than a patient monitoring device. In another example, a radiology information system (RIS_1) may have a higher weight than another RIS (RIS-2). At 1108, if the race condition component 812 determines that the source ID of resource 903k is not better (or has a lower weight) relative to existing source IDs in the tracking database 816, process 1100 proceeds to 1112, and the race condition component 812 removes resource 903k from package 903, resulting in the generation of an updated version of the package with resource 903k removed (e.g., an updated FHIR resource package 903').

[0101] However, if at 1106, the race condition component 812 determines that the corresponding source ID is the same, then process 1100 proceeds to 1110. Additionally, if at 1108 the race condition component determines that the new source ID associated with resource 903k is superior to the corresponding existing source ID in the tracking database 816, then process 1100 also proceeds to 1110. Process 1100 proceeds if the new source ID is the same as or has a higher weight than the existing resource ID.

[0102] At 1110, race condition component 812 examines the sequence number associated with resource 903k and compares it with the corresponding existing sequence number of an existing resource in tracking database 816 (e.g., column D of example tracking database 1000). Race condition component 812 then determines whether the sequence ID associated with resource 903k is newer (or larger, indicating it is newer or was received by system 800 after the existing resource) than the existing sequence ID of the existing resource. For example, if the sequence number associated with resource 903k is 1001, and the sequence number of the existing resource is less than 1001 (e.g., 1000, 999, 998, etc.), then resource 903k is considered newer than the existing resource. In this case, race condition component 812 determines that resource 903k is newer than the existing resource, and process 1100 proceeds to 1114, where race condition component 812 retains resource 903k in the package (FHIR resource package 903). However, if the sequence number of resource 903k indicates that it is older than the corresponding existing resource, process 1100 proceeds to 1112, and race condition component 812 removes resource 903k from the package, thereby producing an updated FHIR resource package 903'.

[0103] As described above, process 1100 is repeated for each resource in package 903. In this regard, at 1114, the race condition component 812 determines whether all resources in FHIR resource package 903 have been processed via steps 1102-1114. If not, as indicated at 1118, process steps 1102-1114 are executed again for the next resource in the package. After all resources in package 903 have been processed via steps 1102-1114, an unmodified FHIR package 903 is generated, or an updated version of the package with one or more resources removed (e.g., an updated FHIR resource package 903'). At 1120, the storage component 814 transmits the resulting package to the FHIR data repository 122, and the corresponding resources in the package are subsequently stored in the FHIR data repository 122.

[0104] In various implementation schemes, the data refinement component 118 can perform actions such as Figure 12 The process shown is a combination of processes 900 and 1100.

[0105] in this regard, Figure 12 Another example data refinement process 1200 according to one or more embodiments described herein is presented. Combined with... Figures 8 to 12 For reference Figure 13 Process 1200 combines elements of processes 900 and 1100. Process 1200 corresponds to process 1100, with the differences indicated at 1202 and 1204. In this respect, according to process 1200, if at 1104 the identifier resolution component 808 determines that the HID is not in the tracking database, process 1200 proceeds to 1202, where steps 914, 916, and 918 are executed. Furthermore, if at 1110 it is determined that resource 903k is newer, process 1200 proceeds to 1204, where steps 920, 922, 924, and 926 are executed. For brevity, repeated descriptions of similar elements used in the corresponding embodiments are omitted.

[0106] Figure 13 An example computer-implemented method 1300 for facilitating data deduplication management and clinical data identity resolution according to one or more embodiments described herein is illustrated. Method 1300 includes: at 1302, a system including a processor (e.g., system 800) receiving a package of healthcare resources configured according to the Fast Healthcare Interoperability Resource (FHIR) standard (e.g., via receiving component 804). At 1304, method 1300 includes the system (e.g., via tracking database 816 and identifier resolution component 808) tracking information about existing healthcare resources stored in an FHIR data repository in the tracking database (e.g., tracking database 816), wherein the information includes logical identifiers of existing healthcare resources associated with existing healthcare resources in the FHIR data repository and healthcare identifiers of existing healthcare resources. At 1306, method 1300 includes the system processing the package using a data refinement process and a tracking database (e.g., process 900), wherein the data refinement process includes updating the tracking database to include new information extracted from the package.

[0107] In some implementations, method 1300 may also include the system (e.g., via storage component 814) transmitting the package or a refined version of the package to the FHIR data repository after the data refinement process.

[0108] In some embodiments of method 1300, the data refinement process includes: determining, by the system, whether each resource corresponds to an existing healthcare resource stored in the FHIR data repository, based on a comparison of the extracted healthcare identifier of each resource in the healthcare resources with the healthcare identifiers of existing healthcare resources in the tracking database. In some specific implementations of these embodiments, based on the first determination that a resource in the healthcare resources does not correspond to an existing healthcare resource, the data refinement process further includes retaining the resource in the package and updating the tracking database by the system to include a new entry for that resource.

[0109] In other specific implementations of these schemes, based on a second determination that a resource in a healthcare resource corresponds to an existing healthcare resource, the data refinement process includes: the system extracting an existing logical identifier for the resource from a tracking database; using this logical identifier to replace a new logical identifier associated with the resource, thereby generating an updated version of the resource; and the system retaining this updated version of the resource in the package, resulting in the generation of a refined version of the package. In some implementations, the storage component 814 may further transmit the refined version of the package to the FHIR data repository after the data refinement process. Furthermore, the identifier resolution component may utilize the existing logical identifier to update all references to the resources in the package.

[0110] Figure 14An example computer-implemented method 1400 for facilitating race condition processing according to one or more embodiments described herein is illustrated. Method 1400 includes: at 1402, a system including a processor (e.g., system 800) receiving a package of healthcare resources configured according to the Fast Healthcare Interoperability Resource (FHIR) standard (e.g., via receiving component 804). At 1404, method 1400 includes the system (e.g., via tracking database 816 and identifier resolution component 808) tracking information about existing healthcare resources stored in an FHIR data repository in the tracking database (e.g., tracking database 816), wherein the information includes a logical identifier of the existing healthcare resource associated with an existing healthcare resource in the FHIR data repository, a healthcare identifier of the existing healthcare resource, a sequence identifier of the existing healthcare resource, and a source identifier of the existing healthcare resource. At 1406, method 1400 includes the system determining whether each resource corresponds to an existing healthcare resource stored in the FHIR data repository based on a comparison of the extracted healthcare identifier of each resource in the healthcare resources with the healthcare identifier of the existing healthcare resource in the tracking database. At 1408, method 1400 includes: based on determining that a resource corresponds to an existing healthcare resource, the system removes the resource from the package based on the resource identifier being different from an existing resource identifier of an existing healthcare resource in the tracking database and based on the resource identifier having a lower weight relative to the existing resource identifier, thereby generating an updated version of the package. At 1410, method 1400 includes the system transmitting the updated version of the package to the FHIR data repository.

[0111] In some implementations, based on another determination that the resource corresponds to an existing healthcare resource, method 1400 may further include: removing the resource from the package based on the resource including a resource identifier that is different from an existing resource identifier of an existing healthcare resource in the tracking database and based on the resource identifier having a higher weight relative to the existing resource identifier, but the resource being older than the existing resource (based on the corresponding sequence identifier).

[0112] In some implementations, based on another determination that the resource corresponds to an existing healthcare resource, method 1400 may further include: retaining the resource in the package based on the fact that the resource includes a resource identifier that is different from an existing resource identifier of an existing healthcare resource in the tracking database, but the resource has a source ID with a higher weight than the corresponding existing source ID and the resource is newer than the existing resource.

[0113] In other embodiments, based on another determination that the resource corresponds to an existing healthcare resource, method 1400 may further include: retaining the resource in the package based on the resource including a resource identifier that is the same as an existing resource identifier of an existing healthcare resource in a tracking database, and wherein the resource is newer than the existing resource.

[0114] Method 1400 may further include: retaining the resource in the package based on another determination that the resource does not correspond to an existing healthcare resource.

[0115] In order to provide context for the various aspects of the disclosed topic, Figure 15 and Figure 16 The following discussion aims to provide a brief overview of the suitable environments in which the various aspects of the disclosed topics can be realized.

[0116] refer to Figure 15 A suitable environment 1500 for implementing various aspects of this disclosure includes a computer 1512. The computer 1512 includes a processing unit 1514, system memory 1516, and a system bus 1518. The system bus 1518 couples system components, including but not limited to system memory 1516, to the processing unit 1514. The processing unit 1514 can be any processor from a variety of available processors. Dual microprocessors and other multiprocessor architectures may also be used as the processing unit 1514.

[0117] The system bus 1518 can be any of a variety of bus architectures, including memory bus or memory controller, peripheral bus or external bus, and / or local bus using a variety of available bus architectures, including but not limited to Industry Standard Architecture (ISA), Micro Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronic Devices (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), PCMCIA Bus, FireWire (IEEE 1394), and Small Computer System Interface (SCSI).

[0118] System memory 1516 includes volatile memory 1520 and non-volatile memory 1522. The Basic Input / Output System (BIOS), which contains basic routines for transferring information between components within computer 1512, such as during startup, is stored in non-volatile memory 1522. By way of illustration and not limitation, non-volatile memory 1522 may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, or non-volatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM)). Volatile memory 1520 includes random access memory (RAM) that acts as an external cache memory. To illustrate rather than limit, RAM can be provided in a variety of forms, such as Synchronous RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), Direct Rambus RAM (DRRAM), Direct Rambus Dynamic RAM (DRDRAM), and Rambus Dynamic RAM.

[0119] Computer 1512 also includes removable / non-removable, volatile / non-volatile computer storage media. Figure 15 Example of a disk storage device 1524 is shown. Disk storage device 1524 includes, but is not limited to, devices such as disk drives, floppy disk drives, magnetic tape drives, Jaz drives, Zip drives, LS-150 drives, flash memory cards, or Memory Sticks. Disk storage device 1524 may also include storage media alone or in combination with other storage media, including but not limited to optical disc drives, such as optical disc ROM devices (CD-ROM), CD recordable drives (CD-R drives), CD rewritable drives (CD-RW drives), or digital universal disk ROM drives (DVD-ROM). To facilitate connection of disk storage device 1524 to system bus 1518, a removable or non-removable interface, such as interface 1526, is typically used.

[0120] Figure 15Software that acts as an intermediary between the user and the basic computer resources described in the suitable operating environment 1500 is also depicted. For example, such software includes an operating system 1528. The operating system 1528, which may be stored on a disk storage device 1524, is used to control and allocate the resources of the computer system 1512. System application programs 1530 utilize the operating system 1528 to manage the resources through program modules 1532, for example, stored in system memory 1516 or on disk storage device 1524, and program data 1534. It should be appreciated that this disclosure can be implemented with various operating systems or combinations of operating systems.

[0121] Users input commands or information into computer 1512 via input device 1536. Input device 1536 includes, but is not limited to, pointing devices such as mouse, trackball, stylus, touchpad, keyboard, microphone, joystick, gamepad, satellite dish, scanner, TV tuner, digital camera, digital video camera, webcam, etc. These and other input devices are connected to processing unit 1514 via interface port 1538 through system bus 1518. Interface port 1538 includes, for example, serial port, parallel port, game port, and Universal Serial Bus (USB). Output device 1540 uses some of the same type of ports as input device 1536. Thus, for example, a USB port can be used to provide input to computer 1512 and output information from computer 1512 to output device 1540. Output adapter 1542 is provided to exemplify some output devices 1540 such as monitors, speakers, and printers, as well as other output devices 1540 that require special adapters. By way of example and not limitation, output adapter 1542 includes a video card and a sound card that provide means of connection between output device 1540 and system bus 1518. It should be noted that other devices and / or systems of devices provide both input and output capabilities, such as remote computer 1544.

[0122] Computer 1512 can operate in a networked environment using a logical connection to one or more remote computers, such as remote computer 1544. Remote computer 1544 can be a personal computer, server, router, network PC, workstation, microprocessor-based device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computer 1512. For simplicity, only memory storage device 1546 is illustrated for remote computer 1544. Remote computer 1544 is logically connected to computer 1512 via network interface 1548 and then physically connected via communication connection 1550. Network interface 1548 encompasses wired and / or wireless communication networks, such as local area networks (LANs), wide area networks (WANs), cellular networks, etc. LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring, etc. WAN technologies include, but are not limited to, point-to-point links, such as Integrated Services Digital Network (ISDN) and its variants, circuit-switched networks, packet-switched networks, and Digital Subscriber Line (DSL).

[0123] Communication connection 1550 refers to the hardware / software used to connect network interface 1548 to bus 1518. Although communication connection 1550 is shown inside computer 1512 for clarity, this communication connection may also be located outside computer 1512. For illustrative purposes only, the hardware / software required to connect to network interface 1548 includes internal and external technologies such as modems, including conventional telephone-grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.

[0124] Figure 16 This is a schematic block diagram of a sample computing environment 1600 with which the subject matter of this disclosure can interact. System 1600 includes one or more clients 1610. Client 1610 can be hardware and / or software (e.g., threads, processes, computing devices). System 1600 also includes one or more servers 1630. Thus, among other models, system 1600 can correspond to a two-tier client-server model or a multi-tier model (e.g., client, middleware server, data server). Server 1630 can also be hardware and / or software (e.g., threads, processes, computing devices). For example, server 1630 can accommodate threads to perform transformations by employing this disclosure. One possible communication between client 1610 and server 1630 can be in the form of data packets transferred between two or more computer processes.

[0125] System 1600 includes a communication framework 1650 that can be used to facilitate communication between client 1610 and server 1630. Client 1610 is operatively connected to one or more client data repositories 1620, which can be used to store information locally on client 1610. Similarly, server 1630 is operatively connected to one or more server data repositories 1640, which can be used to store information locally on server 1630.

[0126] It should be noted that various aspects or features of this disclosure can be utilized in virtually any wireless telecommunications or radio technology, such as Wi-Fi; Bluetooth; Global Microwave Access Interoperability (WiMAX); Enhanced General Packet Radio Service (Enhanced GPRS); 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE); 3rd Generation Partnership Project 2 (3GPP2) Ultra Mobile Broadband (UMB); 3GPP Universal Mobile Telecommunications System (UMTS); High-Speed ​​Packet Access (HSPA); High-Speed ​​Downlink Packet Access (HSDPA); High-Speed ​​Uplink Packet Access (HSUPA); GSM (Global System for Mobile Communications) EDGE (GSM Evolution with Enhanced Data Rates) Radio Access Network (GERAN); UMTS Terrestrial Radio Access Network (UTRAN); LTE Advanced (LTE-A); and so on. Furthermore, some or all of the aspects described herein can be utilized in conventional telecommunications technologies (e.g., GSM). In addition, mobile and non-mobile networks (e.g., the Internet, data service networks such as Internet Protocol Television (IPTV), etc.) can utilize the aspects or features described herein.

[0127] Although the subject matter has been described above in the general context of computer-executable instructions of a computer program running on one or more computers, those skilled in the art will recognize that the present disclosure may also be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc., that perform specific tasks and / or implement specific abstract data types. Furthermore, those skilled in the art will recognize that the methods of the present invention can be practiced with other computer system configurations, including single-processor or multi-processor computer systems, small computing devices, mainframe computers, personal computers, handheld computing devices (e.g., PDAs, telephones), microprocessor-based or programmable consumer or industrial electronics, etc. The aspects shown can also be practiced in a distributed computing environment where tasks are performed by remote processing devices linked via a communication network. However, some (if not all) aspects of the present disclosure can be practiced on a standalone computer. In a distributed computing environment, program modules can reside in both local and remote memory storage devices.

[0128] As used herein, the terms “component,” “system,” “platform,” “interface,” etc., may refer to and / or include computer-related entities or entities related to an operator having one or more specific functionalities. Entities disclosed herein may be hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, and / or a computer. By way of example, both an application running on a server and the server itself can be components. One or more components may reside within a process and / or a thread of execution, and components may reside on a single computer and / or be distributed across two or more computers.

[0129] In another example, the corresponding component may execute on various computer-readable media on which various data structures are stored. The component may communicate via local and / or remote processes, such as based on signals having one or more data packets (e.g., data from a component that interacts with a local system, another component in a distributed system, and / or interacts with other systems across a network (such as the Internet) via signals). As another example, the component may be a device having specific functionality provided by mechanical parts operated by electrical or electronic circuitry, which is operated by software or firmware applications executed by a processor. In such cases, the processor may be internal or external to the device and may execute at least a portion of the software or firmware application. As yet another example, the component may be a device that provides specific functionality through electronic components rather than mechanical parts, wherein the electronic components may include a processor or other components for executing software or firmware that at least partially endows the electronic components with functionality. In one aspect, the component may be emulated via a virtual machine, for example, within a cloud computing system.

[0130] Furthermore, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or clearly stated from the context, "X adopts A or B" is intended to mean any natural inclusive permutation. That is, if X adopts A; X adopts B; or X adopts both A and B, then "X adopts A or B" is satisfied in any of the foregoing cases. Furthermore, unless otherwise specified or clearly stated from the context to be for the singular form, the articles "a" and "an" used in this specification and the accompanying drawings should generally be understood to mean "one or more".

[0131] As used herein, the terms “example” and / or “exemplary” are used to indicate that something is used as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited to such examples. Furthermore, any aspect or design described herein as “example” and / or “exemplary” should not be construed as being preferred or advantageous over other aspects or designs, nor does it exclude equivalent exemplary structures and techniques known to those skilled in the art.

[0132] The various aspects or features described herein can be implemented as methods, apparatus, systems, or articles of art using standard programming or engineering techniques. Furthermore, the various aspects or features disclosed herein can be implemented by program modules that implement at least one or more of the methods disclosed herein, the program modules being stored in memory and executed at least by a processor. Other combinations of hardware and software, or hardware and firmware, can implement or carry out the aspects described herein, including the disclosed methods. As used herein, the term "article of art" can encompass a computer program accessible from any computer-readable device, carrier, or storage medium. For example, computer-readable storage media can include, but is not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes, etc.), optical discs (e.g., CDs, DVDs, Blu-ray discs, etc.), smart cards, and flash memory devices (e.g., cards, sticks, key drives, etc.).

[0133] As used herein, the term "processor" can refer substantially to any computing processing unit or device, including but not limited to a single-core processor; a single processor with software multithreading capabilities; a multi-core processor; a multi-core processor with software multithreading capabilities; a multi-core processor with hardware multithreading technology; a parallel platform; and a parallel platform with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Furthermore, processors can utilize nanoscale architectures (such as, but not limited to, molecular and quantum dot-based transistors, switches, and gates) to optimize space usage or enhance the performance of user equipment. Processors can also be implemented as a combination of computing processing units.

[0134] In this disclosure, terms such as “repository,” “storage device,” “data repository,” “data storage device,” “database,” and virtually any other information storage component relating to the operation and functionality of a component are used to refer to a “memory component,” an entity embodied in “memory,” or a component that includes memory. It should be understood that the memory and / or memory component described herein may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0135] By way of illustration and not limitation, non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or non-volatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM)). For example, volatile memory may include RAM that can serve as external cache memory. By way of illustration and not limitation, RAM can be provided in a variety of forms, such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). Furthermore, the memory components disclosed in the systems or methods herein are intended to include, but are not limited to, these and any other suitable types of memory.

[0136] It should be recognized and understood that components described with respect to a particular system or method may include the same or similar functionality as corresponding components (e.g., separately named components or similarly named components) described with respect to other systems or methods disclosed herein.

[0137] The foregoing description includes examples of systems and methods that provide the advantages of this disclosure. Of course, it is impossible to describe every conceivable combination of components or methods for the purposes of describing this disclosure, but those skilled in the art will recognize that many other combinations and substitutions of this disclosure are possible. Furthermore, when the terms “comprising,” “having,” and “possessing” are used in the detailed description, claims, appendices, and drawings, such terms are intended to have a similar inclusiveness to “comprising” as a transitional term in the claims.

Claims

1. A system comprising: At least one memory, the at least one memory storing computer-executable components; and At least one processor, said at least one processor executing said computer-executable component stored in said at least one memory, wherein said computer-executable component includes: A receiving component that receives a healthcare resource package configured according to the Fast Healthcare Interoperability Resource (FHIR) standard; A tracking database tracks information about existing healthcare resources stored in an FHIR data repository, wherein the information includes logical identifiers of the existing healthcare resources associated with them in the FHIR data repository and healthcare identifiers of the existing healthcare resources; and A data refinement component that uses a data refinement process and the tracking database to process the package and updates the tracking database to include new information extracted from the package.

2. The system of claim 1, wherein the computer-executable component further comprises: A storage component that transmits the package or a refined version of the package to the FHIR data repository after the data refinement process.

3. The system according to claim 1, wherein the data refinement process includes: Based on a comparison of the extracted healthcare identifier of each of the healthcare resources with the healthcare identifier of the existing healthcare resources in the tracking database, it is determined whether each resource corresponds to an existing healthcare resource stored in the FHIR data repository.

4. The system of claim 3, wherein the data refinement process, based on determining that a resource in the healthcare resources does not correspond to an existing healthcare resource, includes: The resources are retained in the package; as well as Update the tracking database to include new entries for the resource.

5. The system of claim 3, wherein, based on determining that the resources in the healthcare resources correspond to existing healthcare resources, the data refinement process includes: Extract the existing logical identifier of the resource from the tracking database; The new logical identifier associated with the resource is replaced with the logical identifier to generate an updated version of the resource; as well as The updated version of the resource is retained in the package, resulting in the generation of a more refined version of the package.

6. The system of claim 5, wherein the computer-executable component further comprises: A storage component that transmits the refined version of the package to the FHIR data repository after the data refinement process.

7. The system of claim 5, wherein, based on determining that the resource corresponds to the existing healthcare resource, the data refinement process further includes: Use the existing logical identifier to update one or more other references to the resource in the package.

8. The system of claim 7, wherein the information in the tracking database further includes a sequence identifier of the existing healthcare resource and a source identifier of the existing healthcare resource, and wherein the data refinement process includes, based on determining that a resource in the healthcare resource corresponds to an existing healthcare resource: Determine whether the source identifiers corresponding to the existing healthcare resources in the source identifiers correspond to new source identifiers associated with the resources; A second determination based on the fact that the source identifier does not correspond to the new source identifier; as well as Determine whether the new source identifier has a higher weight than the source identifier.

9. The system according to claim 8, wherein the data refinement process further includes: Based on a third determination that the new source identifier does not have a higher weight than the source identifier, the resource is removed from the package, resulting in the generation of a refined version of the package.

10. The system according to claim 8, wherein the data refinement process further comprises: Based on a third determination that the new source identifier has a higher weight than the source identifier, it is determined whether the new sequence identifier associated with the resource is higher than the sequence identifier in the sequence identifier that corresponds to the existing healthcare resource in the tracking database.

11. The system of claim 10, wherein the resource is removed from the package based on a fourth determination that the new sequence identifier is not higher, thereby generating a refined version of the package.

12. The system of claim 10, wherein the resource is retained in the package based on a fourth determination higher than the new sequence identifier.

13. The system of claim 1, wherein the computer-executable component further comprises: The "Proprietary to FHIR" pipeline converts proprietary-format clinical data into healthcare resources configured according to the FHIR standard by mapping data elements extracted from the clinical data to one or more FHIR profiles defined for the clinical data.

14. A method, the method comprising: The system, including the processor, receives a healthcare resource package configured according to the Fast Healthcare Interoperability Resource (FHIR) standard; The system tracks information about existing healthcare resources stored in an FHIR data repository in the tracking database, wherein the information includes a logical identifier of the existing healthcare resource associated with the existing healthcare resource in the FHIR data repository and a healthcare identifier of the existing healthcare resource; as well as The system processes the packet using a data refinement process and the tracking database, wherein the data refinement process includes updating the tracking database to include new information extracted from the packet.

15. The method according to claim 14, further comprising: The system transmits the packet or a refined version of the packet generated by the data refinement process to the FHIR data repository after the data refinement process.

16. The method of claim 14, wherein the data refinement process comprises: The system determines whether each resource corresponds to an existing healthcare resource stored in the FHIR data repository by comparing the extracted healthcare identifier of each resource in the healthcare resources with the healthcare identifier of the existing healthcare resources in the tracking database.

17. The method of claim 16, wherein the data refinement process, based on determining that a resource in the healthcare resources does not correspond to an existing healthcare resource, includes: The system retains the resources in the package; as well as The system updates the tracking database to include new entries for the resource.

18. The method of claim 16, wherein, based on determining that the resources in the healthcare resources correspond to existing healthcare resources, the data refinement process includes: The system extracts the existing logical identifier of the resource from the tracking database; The system uses the logical identifier to replace the new logical identifier associated with the resource, thereby generating an updated version of the resource; The system retains the updated version of the resource in the package, thereby generating a more refined version of the package; as well as The system transmits the refined version of the package to the FHIR data repository after the data refinement process.

19. The method of claim 14, wherein the information in the tracking database further includes a sequence identifier of the existing healthcare resource and a source identifier of the existing healthcare resource, and wherein, based on determining that a resource in the healthcare resource corresponds to an existing healthcare resource, the data refinement process includes: The system removes the resource from the package based on a second determination that the source identifier in the source identifier does not correspond to the existing healthcare resource and a third determination that the new source identifier has a lower weight than the source identifier, thereby resulting in the generation of a refined version of the package; as well as The system transmits the refined version of the package to the FHIR data repository.

20. A non-transitory machine-readable storage medium comprising executable instructions that are operable when executed by a processor, the operation comprising: Receive healthcare resource packages configured according to the Fast Healthcare Interoperability Resource (FHIR) standard; Track information about existing healthcare resources stored in an FHIR data repository in a tracking database, wherein the information includes a logical identifier of the existing healthcare resource associated with the existing healthcare resource in the FHIR data repository and a healthcare identifier of the existing healthcare resource; as well as The packet is processed using a data refinement process and the tracking database, wherein the data refinement process includes updating the tracking database to include new information extracted from the packet.

Images