Systems and methods for providing electronic veterinary healthcare data and for facilitating the query of such

Abstract

Systems and methods for providing decentralized electronic veterinary healthcare data and for facilitating the query of electronic veterinary healthcare data are disclosed. A computerized method for providing decentralized veterinary healthcare data connectivity includes receiving a query from a user, accessing a plurality of Local Veterinary Databases (LVDB) to identify data corresponding to the query, obtaining data records associated with the accessed LVDBs, where each data record includes aggregated level data of the corresponding data, combining all the obtained data records to generate a comprehensive aggregated view of the corresponding data per LVDB, and causing the display of the comprehensive aggregated view to the user. Each LVDB of the plurality of LVDBs is based on and associated with a separate Veterinary Electronic Health Records (VEHR) source.

Description

SYSTEMS AND METHODS FOR PROVIDING ELECTRONIC VETERINARYHEALTHCARE DATA AND FOR FACILITATING THE QUERY OF SUCHFIELD

[0001] The present disclosure generally relates to veterinary healthcare data, and more specifically, to systems and methods for providing decentralized electronic veterinary healthcare data and for facilitating the query of electronic veterinary healthcare data.BACKGROUND

[0002] The veterinary industry is highly fragmented from a technological perspective. There are many different Electronic Medical Records systems (EMR), also commonly referred to as Practice Information Management Systems (PIMS), that have attained high market share. Some of the main ones include Cornerstone, EzyVet and Neo (owned by Idexx, Maine, US), Avimark, Impromed and eVetPractice (owned by Covetrus, Maine, US), and many more.

[0003] A considered issue with this fragmented environment is that each PIMS stores data in a different architecture or schema. Analyzing data from multiple PIMS requires a lot of manual work to merge datasets together. Moreover, a lot of the data is stored in unstructured medical notes, making it difficult to query it at scale to determine statistics on disease populations or treatment outcomes.SUMMARY

[0004] In accordance with aspects of the present disclosure, a computerized method for providing decentralized veterinary healthcare data connectivity is provided. The method includes: receiving a query from a user; accessing a plurality of Local Veterinary Databases (LVDB) to identify data corresponding to the query; obtaining data records associated with the accessed LVDBs, where each data record includes aggregated level data of the corresponding data; combining all the obtained data records to generate a comprehensive aggregated view of the corresponding data per LVDB; and causing the display of the comprehensive aggregated view to the user; where each LVDB of the plurality of LVDBs is based on and associated with a separate Veterinary Electronic Health Records (VEHR) source.

[0005] In various embodiments of the method, the VEHR sources include structured data and unstructured data, and each LVDB is generated by mapping structured data extracted from the respective VEHR source to a predefined unified data schema; and enriching the extracted structured data by tagging medical terms in the unstructured data.

[0006] In various embodiments of the method, the medical terms included in the unstructured data are tagged by using a Named Entity Recognition algorithm.

[0007] In various embodiments of the method, each LVDB is further generated by mapping medical terms in the structured data and in the unstructured data to corresponding standardized terms.

[0008] In various embodiments of the method, the tagging of medical terms in the unstructured data comprises using the corresponding standardized terms.

[0009] In various embodiments of the method, the standardized terms are defined based on the Systematized Medical Nomenclature for Medicine-Clinical Terminology (SNOMED CT).

[0010] In various embodiments of the method, the query includes one or more search criteria, and the comprehensive aggregated view includes a total number of patients corresponding to the one or more search criteria per VEHR source.

[0011] In various embodiments of the method, the comprehensive aggregated view further includes high-level statistics for each patient population.

[0012] In various embodiments of the method, the method further includes generating the plurality of LVDB s.

[0013] In various embodiments of the method, the method further includes generating the data record for each LVDB of the accessed LVDB comprising data corresponding to the query.

[0014] In various embodiments of the method, the method further includes providing the user with a connection to data of interest stored in one or more LVDBs following an approved user request.

[0015] In various embodiments of the method, the providing of the connection includes: receiving the user request to access the data of interest, where the data of interest is indicated by the comprehensive aggregated view; generating one or more notifications of the user request to access the data of interest, respectively; and upon receiving an approval to the user access request, providing the user with a connection to the data of interest included in the approved respective LVBD.

[0016] In various embodiments of the method, the connection includes direct access to at least one LVBD of the respective one or more LVDBs.

[0017] In various embodiments of the method, VEHR sources of the multiple VEHR sources store data by using different database schemas.

[0018] In various embodiments of the method, data displayed to the user via the comprehensive aggregated view is deidentified.

[0019] In various embodiments of the method, at least one of: the identity of the VEHR sources or the identity of the patients is obfuscated to the users.

[0020] In various embodiments of the method, the data included in the data record is deidentified.

[0021] In various embodiments of the method, one or more users of a VEHR source of the plurality of VEHR sources may directly query the associated LVDB.

[0022] In various embodiments of the method, the LVDBs are continuously updated according to updates applied to the VEHR sources, respectively.

[0023] In various embodiments of the method, each LVDB of the plurality of LVBDs is stored in a separate environment.

[0024] In various embodiments of the method, the method further includes providing a user interface, where the user interface is used for generating a user query and viewing the comprehensive aggregated view.

[0025] In various embodiments of the method, the providing of data included in the plurality of LVDBs is based on a federated data architecture.

[0026] In various embodiments of the method, the data stored in each LVBD of one or more LVBDs of the plurality of LVBDs is a mirror copy of the data stored in the respective VEHR source.

[0027] In various embodiments of the method, the data stored in each LVBD of one or more LVBDs of the plurality of LVBDs includes the structured data and at least a portion of the unstructured data is stored in the respective VEHR source.

[0028] In accordance with aspects of the present disclosure, a method for generating a database based on a VEHR source, where the VEHR source includes structured data and unstructured data, includes: mapping structured data extracted from the respective VEHR source to a predefined unified data schema; enriching the extracted structured data by tagging medical terms in the unstructured data; and mapping medical terms in the extracted structured data and in the unstructured data to corresponding standardized terms.

[0029] In various embodiments of the method, the medical terms included in the unstructured data are tagged by using a Named Entity Recognition algorithm.

[0030] In various embodiments of the method, the tagging of medical terms in the unstructured data includes using the corresponding standardized terms.

[0031] In various embodiments of the method, the standardized terms are defined based on the Systematized Medical Nomenclature for Medicine-Clinical Terminology (SNOMED CT).

[0032] In various embodiments of the method, the database is continuously updated according to updates applied to the VEHR source.

[0033] In various embodiments of the method, the method further includes generating a mirror copy of the structured data and at least a portion of the unstructured data included in the VEHR source.

[0034] In various embodiments of the method, the method further provides decentralized veterinary healthcare data connectivity, by: generating a plurality of LVDBs, wherein each LVDB of the plurality of LVDBs is based on and associated with a separate VEHR source; and using at least one hardware processor to: receive a query from a user; access LVDBs of the plurality of LVDBs to identify data corresponding to the query; obtain data records associated with the accessed LVDBs, where each data record includes aggregate level data of the corresponding data; combine all the obtained data records to generate a comprehensive aggregated view of the corresponding data per LVDB; and cause the display of the comprehensive aggregated view to the user.

[0035] In various embodiments of the method, the query includes one or more search criteria, and the comprehensive aggregated view includes a total number of patients corresponding to the one or more search criteria per VEHR source.

[0036] In various embodiments of the method, the comprehensive aggregated view further includes high-level statistics for each patient population.

[0037] In various embodiments of the method, the method further includes generating the data record for each LVDB of the accessed LVDBs including data corresponding to the query.

[0038] In various embodiments of the method, the method further includes providing the user with a connection to data of interest included in one or more LVDBs following an approved user request.

[0039] In various embodiments of the method, the providing of the connection includes: receiving the user request to access the data of interest, where the data of interest is indicated by the comprehensive aggregated view; generating one or more notifications of the user request to access the data of interest, respectively; and upon receiving an approval to the user accessrequest, providing the user with a connection to the data of interest included in the approved respective LVBD.

[0040] In various embodiments of the method, the connection includes direct access to at least one LVBD of the respective one or more LVDBs.

[0041] In various embodiments of the method, VEHR sources of the multiple VEHR sources store data by using different database schemas.

[0042] In various embodiments of the method, data displayed to the user via the comprehensive aggregated view is deidentified.

[0043] In various embodiments of the method, at least one of: the identity of the VEHR sources or the identity of the patients is obfuscated to the users.

[0044] In various embodiments of the method, the data included in the data record is deidentified.

[0045] In various embodiments of the method, one or more users of a VEHR source of the plurality of VEHR sources may directly query the associated LVDB.

[0046] In various embodiments of the method, each LVDB of the plurality of LVBDs is stored in a separate environment.

[0047] In various embodiments of the method, the method further includes generating a user interface, wherein the user interface is used for generating a user query and for displaying the comprehensive aggregated view to a user.

[0048] In various embodiments of the method, the providing of data included in the plurality of LVDBs is based on a federated data architecture.

[0049] In accordance with aspects of the present disclosure, a system for facilitating the provision of decentralized veterinary health data includes at least one hardware processor and at least one computer readable storage device storing instructions for execution by the at least one hardware processor. The instructions, when executed, cause the system to: receive a query from a user; access a plurality of LVDBs to identify data corresponding to the query; obtain data records associated with the accessed LVDBs, each data record comprising aggregate level data of the corresponding data; combine all the obtained data records to generate a comprehensive aggregated view of the corresponding data per LVDB; and cause the display of the comprehensive view to the user, where each LVDB of the plurality of LVDBs is based on and associated with a separate VEHR source.

[0050] In various embodiments of the system, the VEHR sources includes structured data and unstructured data, and each LVDB is generated by mapping structured data extracted fromthe respective VEHR source to a predefined unified data schema; and enriching the extracted structured data by tagging medical terms in unstructured data.

[0051] In various embodiments of the system, the medical terms included in the unstructured data are tagged by using a Named Entity Recognition algorithm.

[0052] In various embodiments of the system, each LVDB is further generated by mapping medical terms in the structured data and in the unstructured data to corresponding standardized terms.

[0053] In various embodiments of the system, the tagging of medical terms in the unstructured data includes using the corresponding standardized terms.

[0054] In various embodiments of the system, the standardized terms are defined based on the Systematized Medical Nomenclature for Medicine-Clinical Terminology (SNOMED CT).

[0055] In various embodiments of the system, the query includes one or more search criteria, and wherein the comprehensive aggregated view includes a total number of patients corresponding to the one or more search criteria per VEHR source.

[0056] In various embodiments of the system, the comprehensive aggregated view further includes high-level statistics for each patient population.

[0057] In various embodiments of the system, the instructions further cause the system to generate the plurality of LVDBs.

[0058] In various embodiments of the system, the instructions further cause the system to generate the data record for each LVDB of the accessed LVDB including data corresponding to the query.

[0059] In various embodiments of the system, the instructions further cause the system to provide the user with a connection to data of interest stored in one or more LVDBs following an approved user request.

[0060] In various embodiments of the system, the providing of the connection includes: receiving the user request to access the data of interest, where the data of interest is indicated by the comprehensive aggregated view; generating one or more notifications of the user request to access the data of interest, respectively; and upon receiving an approval to the user access request, providing the user with a connection to the data of interest included in the approved respective LVBD.

[0061] In various embodiments of the system, the connection includes direct access to at least one LVBD of the respective one or more LVDBs.

[0062] In various embodiments of the system, VEHR sources of the multiple VEHR sources store data by using different database schemas.

[0063] In various embodiments of the system, data displayed to the user via the comprehensive aggregated view is deidentified.

[0064] In various embodiments of the system, at least one of: the identity of the VEHR sources or the identity of the patients is obfuscated to the users.

[0065] In various embodiments of the system, the data included in the data record is deidentified.

[0066] In various embodiments of the system, one or more users of a VEHR source of the plurality of VEHR sources may directly query the associated LVDB.

[0067] In various embodiments of the system, the LVDBs are continuously updated according to updates applied to the VEHR sources, respectively.

[0068] In various embodiments of the system, each LVDB of the plurality of LVBDs is stored in a separate environment.

[0069] In various embodiments of the system, the instructions further cause the system to provide a user interface, wherein the user interface is used for generating a user query and for viewing the comprehensive aggregated view.

[0070] In various embodiments of the system, the providing of data included in the plurality of LVDBs is based on a federated data architecture.

[0071] In various embodiments of the system, the data stored in each LVBD of one or more LVBDs of the plurality of LVBDs is a mirror copy of the data stored in the respective VEHR source.

[0072] In various embodiments of the system, the data stored in each LVBD of one or more LVBDs of the plurality of LVBDs includes the structured data and at least a portion of the unstructured data stored in the respective VEHR source.

[0073] In accordance with aspects of the present disclosure, a system for facilitating the query of veterinary health data includes: a VEHR source; a database associated with the VEHR source; at least one hardware processor; and at least one computer readable storage device storing instructions for execution by the at least one hardware processor. The instructions, when executed, cause the system to: receive a query from a user; access the database to identify data corresponding to the query; and cause the display of the corresponding data to the user. The database is generated by mapping structured data extracted from the respective VEHR source to a predefined unified data schema; enriching the extracted structured data by tagging medicalterms in the unstructured data; and mapping medical terms in the extracted structured data and in the unstructured data to corresponding standardized terms.

[0074] In various embodiments of the system, the instructions further cause the system to continuously update the database according to updates applied to the VEHR source.

[0075] In various embodiments of the system, the database is stored in the at least one computer readable storage device.

[0076] In various embodiments of the system, the instructions further cause the system to deidentify the corresponding data displayed to the user.

[0077] In various embodiments of the system, the medical terms included in the unstructured data are tagged by using a Named Entity Recognition algorithm.

[0078] In various embodiments of the system, the database is further generated by mapping medical terms in the structured data and in the unstructured data to corresponding standardized terms.

[0079] In various embodiments of the system, the tagging of medical terms in the unstructured data includes using the corresponding standardized terms.

[0080] In various embodiments of the system, the standardized terms are defined based on the Systematized Medical Nomenclature for Medicine-Clinical Terminology (SNOMED CT).

[0081] In various embodiments of the system, the instructions further cause the system to provide a user interface, where the user interface is used for generating the user query and for viewing the corresponding data.

[0082] In various embodiments of the system, the data stored in the database is a mirror copy of the data stored in the VEHR source.

[0083] In various embodiments of the system, the data stored in the database includes the structured data and at least a portion of the unstructured data stored in the VEHR source.BRIEF DESCRIPTION OF THE DRAWINGS

[0084] The above and other aspects and features of the disclosure will become more apparent in view of the following detailed description when taken in conjunction with the accompanying drawings wherein like reference numerals identify similar or identical elements.

[0085] FIG. 1 is a diagram of an exemplary system for providing decentralized veterinary healthcare data in accordance with aspects of the disclosure;

[0086] FIG. 2 is a flow diagram of an exemplary method for providing decentralized veterinary healthcare data in accordance with aspects of the disclosure;

[0087] FIG. 3A shows exemplary comprehensive aggregated view 300 and exemplary corresponding display of data of interest 320, in accordance with aspects of the present disclosure;

[0088] FIG. 3B shows a screen shot of an exemplary user interface displaying a comprehensive aggregated view 330 in response to a user query and a screen shot of the user interface including a display of data of interest 340 as provided by a specific LVBD in response to a user request, in accordance with aspects of the present disclosure;

[0089] FIG. 4A is a flow diagram of a method for generating a database based on a VEHR source, in accordance with aspects of the present disclosure;

[0090] FIG. 4B is a diagram exemplifying in a simplified manner the harmonization of data from two different VEHR sources to a simplified unified data schema, in accordance with aspects of the present disclosure;

[0091] FIG. 4C is a diagram exemplifying the enrichment of the harmonized data of Fig. 4B by tagging unstructured data, in accordance with aspects of the present disclosure;

[0092] FIG. 4D is a diagram exemplifying the standardization of the harmonized data of Fig. 4B by using a standard taxonomy, in accordance with aspects of the present disclosure; and

[0093] FIG. 5 is a diagram of an exemplary system for facilitating the query of veterinary health data, in accordance with aspects of the disclosure.

[0094] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions and / or aspect ratio of some of the elements can be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals can be repeated among the figures to indicate corresponding or analogous elements throughout the serial views.DETAILED DESCRIPTION

[0095] The present disclosure relates to systems and methods for providing veterinary healthcare data. More particularly, the present disclosure relates to systems and methods for providing decentralized electronic veterinary healthcare data and for facilitating the query of electronic veterinary healthcare data. Disclosed systems and methods allow, on one hand, querying decentralized veterinary data originated from multiple various data sources and viewing aggregate-level results in a unified, comfortable, and user-friendly manner. Following that, the disclosed systems and methods may further allow requesting access to a specific subsetof that data and may provide such access. On the other hand, disclosed systems and methods enable veterinary data owners or sites having such data to share the data in, e.g., a federated architecture, and such that the confidentiality and privacy of patient information is maintained. Disclosed systems and methods may further provide high-quality comprehensive databases based on electronic Veterinary Health Data (VHD) sources.

[0096] In the following detailed description, specific details are set forth in order to provide a thorough understanding of the disclosure. However, it will be understood by those skilled in the art that the disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present disclosure. Some features or elements described with respect to one system may be combined with features or elements described with respect to other systems. For the sake of clarity, discussion of same or similar features or elements may not be repeated.

[0097] The disclosed systems and methods allow for and facilitate the querying of decentralized electronic VHD stored across patient databases from multiple sites. Aggregated data from the multiple data sources is then presented in a unified manner. A request may then be made to get access to a specific site’s (e.g., a hospital) data based on a specific query and a direct access may be provided, all ‘at the push of a button’. The disclosed systems and methods may further provide a user interface that users can use to remotely interact with the multiple databases.

[0098] The disclosed systems and methods allow for better comparison of data between VHD sites coming from different sources of EMR data in veterinary medicine including PIMS for the purpose of benchmarking or building industry standards.

[0099] The disclosed systems and methods may provide querying of the data across patient databases from multiple sites or VED environments that maintains the confidentiality and privacy of patient data through aggregation and deidentification. The systems and methods described herein may allow each site, such as a hospital, to maintain its detailed patient records separately. Each site data may be stored in a separate cloud or local environment that is aggregated using, e.g., a federated query only. Upon being queried, the records are aggregated and may be deidentified, and presented, e.g., in a user interface. This way, private data from different sites may not be combined. A request may then be made to get access to a specific site’ s data based on a specific query; that site can then share the data requested, without sharing its entire dataset.

[0100] Systems and methods described herein may provide a data cleanup operation for VEHR sources and may provide a high-quality veterinary database. Systems and methods described herein may enable the harmonization and enrichment of veterinary patient data coming from PIMS or other electronic VHD sources to generate or build high-quality datasets or databases (e.g., LVBDs) that can be used, for example, for statistical analysis of disease populations, marketing veterinary products or services to pet owners, building machine learning algorithms, and providing operational analytics about veterinary facilities such as hospitals.

[0101] The data cleanup operation includes an improved harmonization operation, an enrichment operation and may also include a standardization operation. The improved harmonization operation maps data using a comprehensive data schema which includes an expansive breadth of the patient medical record, such as diseases, lab results, diagnostics, and procedures. The data enrichment operation takes unstructured data such as medical notes, discharge summaries, surgery reports and pathology reports, and extracts medical terms such as diagnoses, symptoms, procedures, medication, diagnostics and more. This tagged data can then be queried and used to supplement the existing structured data. The standardization operation of the medical concepts coming from the first two operations allows to accurately compare terms across different datasets and following that to properly and comprehensively aggregate data. Advantageously, the SNOMED-CT medical terminology, which is considered a highly comprehensive and precise health terminology, and one that is common to both animals and humans, may be used.

[0102] Furthermore, a major issue with studying disease data from electronic VHD sources or systems like PIMS is that the clinician is expected to enter a patient’s diagnoses and / or preexisting conditions into a specific “diagnosis” data entry field in the system. However, compliance with this practice is low, likely due to the fact that clinicians are already inputting this information, e.g., in the medical notes and / or in a discharge summary, and so do not feel the need to duplicate it again somewhere else. Therefore, the number of patients with a specific disease is underrepresented when searching through a diagnosis field in the data.

[0103] Systems and methods disclosed herein allow for a more comprehensive study of diseases across populations of veterinary patients by identifying these diseases not just in the “diagnosis” field coming from, e.g., the PIMS, but also in all other unstructured sources such as medical notes, discharge summaries, etc.. Thus, the number of patients of a given diseasefound using disclosed systems and methods will be higher and more representative of the true population.

[0104] Moreover, systems and method described herein allow the comparative study of diseases between human and animal through the use of the SNOMED-CT terminology, which has the same disease codes across species. In addition, the SNOMED-CT terminology maps multiple synonyms of diagnoses or symptoms to the same root concept.

[0105] Although the disclosure is not limited in this regard, discussions utilizing terms such as, for example, “processing,” “computing,” “calculating,” “determining,” “establishing,” “analyzing,” “checking,” or the like, may refer to operation(s) and / or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and / or transforms data represented as physical (e.g., electronic) quantities within the computer’s registers and / or memories into other data similarly represented as physical quantities within the computer’s registers and / or memories or other information non-transitory storage medium that may store instructions to perform operations and / or processes.

[0106] Although the disclosure is not limited in this regard, the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more.” The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. The term “a plurality of’ when referred to a quantity or a group of components, devices, elements, units, parameters, or the like, may refer to two or more or to all of such quantified or to all of such in the group. The term “one or more of’ when referred to a quantity or a group of components, devices, elements, units, parameters, or the like, may refer to one or more or to all of such quantified or to all of such in the group.

[0107] Although the disclosure is not limited in this regard, the term “obtain” may refer to operation(s) and / or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, and may include, inter alia, requesting, accessing, receiving, or generating.

[0108] Unless explicitly stated, the methods described herein are not constrained to a particular order or sequence. Additionally, some of the described methods or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

[0109] Reference is now made to FIG. 1, which shows a diagram of an exemplary system100 for providing decentralized veterinary healthcare data. System 100 includes a memory unit120 and a processing unit 130. In accordance with aspects of the present disclosure, system100 may further include a User Interface (UI) 140. Exemplary system 100 is a cloud-based system using the infrastructure or platform of cloud 110. According to some aspects, system 100 may be an on-premise system. Cloud 110 may be, for example, a private, public or a hybrid cloud.

[0110] Processing unit 130 may be or may include at least one hardware processor or controller that may be or may include, for example, one or more central processing unit processor(s) (CPU), one or more Graphics Processing Unit(s) (GPU or GPGPU), and / or other types of processors, such as a microprocessor, digital signal processor, microcontroller, programmable logic device (PLD), field programmable gate array (FPGA), or any suitable computing or computational device. According to some aspects, system 100 may also include an operating system, a storage, or a communication or networking device (not shown).

[0111] Memory unit 120 may be or may include at least one computer readable storage device which may be or may include, for example, one or more Random Access Memory (RAM), read-only memory (ROM), flash memory, volatile memory, non-volatile memory, cache memory, and / or other memory devices. The one or more storage devices may store, for example, executable instructions that carry out an operation (e.g., an executable code) and / or data. The executable code may be any executable code, e.g., an app / application, a program, a process, task, or script. The executable instructions may be executed by one or more hardware processors or controllers of processing unit 130. The executable instructions may cause system 100 to operate according to or apply method steps of the methods disclosed herein below, such as method 200 of Fig. 2 and method 400 of Fig. 4A.

[0112] The storage may be or may include one or more of a hard disk drive, a solid-state drive, an optical disc drive (such as DVD or Blu-Ray), a USB drive or other removable storage device, and / or other types of storage devices. Data such as instructions, code, veterinary healthcare data, among other things, may be stored in the storage and may be loaded from the storage into memory unit 120 where it may be processed by processing unit 130. According to some aspects, memory unit 120 may include the storage.

[0113] Fig. 1 further shows exemplary separate VHD environments 150A, 150B and 150C. Each VHD environment (or “environment”) 150A, 150B and 150C includes a respective site 152A, 152B and 152C, a respective VEHR source 154A, 154B and 154C and respective EVDB 156A, 156B and 156C stored therein. System 100 is in communication with EVDB 156A, 156B and 156C. Each site 152A, 152B and 152C is in communication with its respective VEHR source 154A, 154B and 154C. Sites 152 A and 152C are also in communication withrespective LVDB 156A and 156C. Each VEHR source 154A, 154B and 154C is in communication with the respective LVDB 156 A, 156B and 156C. According to some aspects, for each VEHR source there is a single corresponding LVDB. According to some aspects, each LVDB is stored in a separate VHD environment.

[0114] A site such as sites 152A, 152B and 152C may be, for example, a veterinary health facility such as a veterinary hospital or clinic, an academic research institution, a contract research organization, or a pharmaceutical company. Each different or separate VHD environment is defined, inter alia, by having a different VEHR source. Each different or separate VHD environment requires the establishment of a separate or different access to allow the query of data kept by the environment. According to some aspects, a VHD environment may include plurality of sites (e.g., two or more) having a common respective VEHR source.

[0115] The VHD environments may have different layouts, architectures, or configurations. VHD environments 150A, 150B and 150C exemplify a few such different environments. In VHD environments 150A, VEHR source 154A and LVDB 156A are located on-premise, e.g., located or installed on local servers or computers of site 152A. In VHD environments 150B, VEHR source 154B is located on-premise. However, LVDB 156B is located off-premise, specifically in this configuration hosted on remote servers in cloud 160. In VHD environments 150C, VEHR source 154C and LVDB 156C are both located off-premise, specifically in this configuration hosted on remote servers in cloud 164. Cloud 160 and cloud 164 may be, for example, a public cloud, a private cloud, or a hybrid cloud.

[0116] Each site 152A, 152B and 152C has access to and typically has control of its respective VEHR source 154A, 154B and 154C. For example, if a site is a veterinary health facility, the respective VEHR source would store medical data of patients treated by the veterinary health facility such as information relating to patients visits, diagnosis, treatment, medical procedures, lab results, surgery reports, medical images, and the like. The VEHR source may also include non-medical information relating to the treatment of the patients such as financial information (e.g., invoices).

[0117] The VEHR source may be or may include veterinary electronic records including medical data (EMR). According to some aspects, the VEHR source may include additional information beyond standard clinical data relating to the health of veterinary patients, such as data records referring to the mental health of the veterinary patients. According to some aspects, the VEHR source may be managed by an EMR system or a medical PIMS, such asCornerstone, EzyVet or Neo Software (by IDEXX, Maine, US) or any other data management software. VEHR sources may store data by using different database schemas.

[0118] Users of the site, e.g., medical staff employed by a veterinary health facility, may be granted access to the VEHR source (e.g., via a UI). Sites 152A and 152C also have access to the respective LVDB 156A and 156C. Accordingly, users of the site such as medical staff employed by a veterinary health facility, may be granted access to the respective LVDB source. Each LVDB 156A, 156B and 156C is generated based on its respective VEHR source 154A, 154B and 154C. LVDB 156A, 156B and 156C may facilitate the query of VEHR source 154A, 154B and 154C, respectively. The LVDBs may be generated according to method 400 of Fig. 4A, as will be elaborated below. Alternatively, or additionally (e.g., in combination), the LVDBs may be generated according to various methods as known to a person skilled in the art.

[0119] System 100 may provide users, inter alia, with an easy, integrative, and homogenous query of veterinary health data provided by different distributed VEHR sources, as will be further elaborated below. Exemplary users 170A, 170B and 170C of system 100 may query LVDBs 156A, 156B and 156C via system 100. Users 170A, 170B and 170C may be, for example, veterinarians, medical researchers, practice managers, marketers, contract research organizations, or pharmaceutical companies. Users 170A, 170B and 170C may, for example, access UI 140 and place queries. Processing unit 130 may then query LVDBs 156A, 156B and 156C accordingly. Processing unit 130 may further communicate results of the queries to users 170A, 170B and 170C, e.g., via UI 140. The results may then be displayed to users 170A, 170B and 170C. Users 170A, 170B and 170C may use a computing device 180A, 180B and 180C, respectively, to communicate with system 100, place queries, display UI 140 and display queries results. Computing devices 180A, 180B and 180C exemplify different computing devices which may be used by the users of system 100. Computing devices 180A, 180B and 180C include one or more input devices and one or more output devices. Computing device 180A is a desktop computer further including a hardware processor and a memory device. Computing device 180B is a terminal, e.g., of an organizational network, connected with a server, e.g., via an intranet. Computing device 180C is a hand-held device, such as a tablet computer or a smartphone, further including a hardware processor and a memory device. The one or more input devices may include, for example, a mouse, a keyboard, a touch screen or pad, or any other type of input device. The one or more output devices may include visual output devices such as monitors, screens, or displays. According to some aspects, UI 140 may be a web-based application. According to some aspects, UI 140 may be installed on ordownloaded to the user’s computing device (e.g., computing device 180A or 180C). According to some aspects, only a portion of UI 140 may be installed on or downloaded to the user’s computing device.

[0120] According to some aspects, the disclosed systems and methods may employ a federated data architecture. For example, system 100 and LVDBs 156A, 156B and 156C may form a federated data architecture. System 100 may include a federated data source. For example, memory unit 120 may include a federated data source.

[0121] The illustrated components of FIG. 1 are exemplary, and variations are contemplated to be within the scope of the present disclosure. For example, the numbers of components may be greater or fewer than as described and the types of components may be different than as described.

[0122] Reference is now made to FIG. 2, which is a flow diagram of an exemplary method 200 for providing decentralized veterinary healthcare data. Method 200 may be applied by a system such as system 100 of Fig. 1 and will be illustrated below by reference to system 100 and Fig. 1.

[0123] At a step 210, a query is received from a user. With reference to Fig. 1, System 100 receives a query entered by a user 180A, 180B, or 180C, e.g., via UI 140. The query may include one or more search criteria, for example, a given patient species (dogs) with history of a given disease (diabetes). A user can build simple queries (e.g., dogs with diabetes) or advanced queries (e.g., golden retrievers with liver masses who had surgery) to search all sites (e.g., hospitals) databases (e.g., LVDBs) for the relevant patient populations.

[0124] At a step 220, a plurality of LVDBs is accessed to identify data corresponding to the query. With reference to Fig. 1, system 100 (e.g., via processing unit 130) may access and query LVDBs 156A, 156B, and 156C of environments 152A, 152B and 152C, respectively. According to some aspects, during the querying, SQL is used to query the separate LVDBs 156A, 156B, and 156C.

[0125] At a step 230, a data record associated with each accessed LVDB is obtained. The data record includes aggregated level data of the corresponding data. The data record may include a plurality of fields, as will be exemplified below. According to some aspects, a data record is obtained only for LVDBs identified as including data corresponding to the query. According to some aspects, a data record is obtained for all LVDBs. With reference to Fig. 1, system 100 obtains a data record from each LVDB 156A, 156B and 156C as a result ofquerying LVDBs 156A, 156B and 156C, e.g., via processing unit 130. According to some aspects, method 200 may further include the generating of the data records.

[0126] At a step 240, all the obtained data records are combined to generate a comprehensive aggregated view (or “aggregated view”) of the corresponding data per LVDB, site or environment. The aggregated view may be comprised of the obtained data records. The aggregated view may include a plurality of fields. For example, the comprehensive aggregated view may include a total number of patients corresponding to the one or more search criteria per VEHR source. Reference is now made to Fig. 3A, which shows an exemplary comprehensive aggregated view 300 (or aggregated view 300). Aggregated view 300 includes two fields: “Site” field 310A and “Number of Patients” field 310B and four view records 305A, 305B, 305C and 305D corresponding to a site 1, a site 2, a site 3 and a site 4 (a data record per site). Each view record includes a value for each field. The “Site” field 310A identifies the site or VHD environment, e.g., site 1, site 2 etc.. “Number of Patients” field 310B includes the number of patients found in the respective LVDB as corresponding to the query criteria, e.g., canine patients with osteoarthritis. With reference to system 100, processing unit 130 may generate an aggregated view by combining the obtained data records.

[0127] According to some aspects, the obtained data records are further processed, e.g., by processing unit 130 of system 100, prior to combining them to a comprehensive aggregated view. According to some aspects, further processing of the obtained data records may include adding one or more fields to the data records or changing the structure of the data records. According to some aspects, the obtained data records, or the comprehensive aggregated view may further include high-level statistics for each patient population, such as distribution by gender, average age, overall survival time, etc. According to some aspects, the further processing may include deidentification or obfuscation of data, as will be detailed herein below.

[0128] Reference is now made to FIG. 3B, which shows a screen shot of an exemplary user interface displaying a comprehensive aggregated view 330 (or aggregated view 330) in response to a user query, e.g., feline patients with hyperthyroidism. Aggregated view 330 includes view records 332A, 332B, 332C and 332D. Each view record 332A, 332B, 332C and 332D includes a plurality of fields, some including high-level statistics: “Site” (identifying the VHD environment), “Patients” (number of patients found in the respective LVDB as corresponding to the query criteria), “M” for Male (number of male patients found in the respective LVDB as corresponding to the query criteria), “F” for Female (number of female patients found in the respective LVDB as corresponding to the query criteria), “Med age” formedian age (median age of patients found in the respective LVDB as corresponding to the query criteria), “Breeds” (number of type of breeds of patients found in the respective LVDB as corresponding to the query criteria), “Avg OST” for average Overall Survival Time (average OST of patients found in the respective LVDB as corresponding to the query criteria), “Deceased” (number of deceased patients found in the respective LVDB as corresponding to the query criteria), “Uncertain” (number of patients found in the respective LVDB as corresponding to the query criteria for which it is unclear if they are alive or deceased), and “Alive” (number of alive patients found in the respective LVDB as corresponding to the query criteria). View record 332C has null values, indicating that no feline patients with hyperthyroidism were found in the LVDB of site 7.

[0129] At a step 250, a display of the comprehensive aggregated view to the user is performed. With reference to Fig. 1, the aggregated view may be displayed on a display of computing device 180A, 180B or 180C. Processing unit 130 of system 100 may cause the display of the comprehensive aggregated view. Reference is also made to Fig. 3B which shows a display of comprehensive aggregated view 330.

[0130] According to some aspects, the query is a federated query (e.g., a virtual query) allowing users to access the remote data stored in the different LVDBs, e.g., LVDBs 156A, 156B and 156C of system 100. Accordingly, data included in the LVDBs is provided based on a federated data architecture. The federated query results are sent from the different LVDBs as a temporary table. The results are combined to generate the comprehensive aggregated view (e.g., a unified view) via a federated data source (e.g., included in memory unit 120 of system 100). The federated data source allows data from the multiple LVDBs to be combined and accessed as if it were a single source. While the data remains in its original location (e.g., LVDBs 156A, 156B and 156C), the federated data source (e.g., memory unit 120) provides a unified view of the data.

[0131] According to some aspects, the data displayed to the user via the comprehensive aggregated view is deidentified. For example, only the total number of patients corresponding to the search criteria (e.g., dogs with osteoarthritis, as shown in aggregated view 300 of Fig. 3A) for each site (e.g., site 152A, 152B or 152C) is presented to the user, optionally along with some high-level statistics for each patient population (e.g., distribution by gender, average age, overall survival time, etc., as shown in aggregated view 330 of Fig. 3B).

[0132] According to some aspects, the identity of the VEHR sources or VHD environments(e.g., by providing the name or identity of the respective site) or the identity of the patients orboth are obfuscated to the users. According to some aspects, deidentification or obfuscation is performed before data is displayed to the users via the aggregated view. According to some aspects, the data included in the data records or received from the LVDBs is already deidentified or obfuscated. According to some aspects, at no point a combined dataset from different sites or environments is stored, e.g., by system 100.

[0133] According to some aspects, method 200 may further include the generation of the LVDBs. An LVDB may be generated according to method 400 of Fig. 4 A, as will be elaborated below. Alternatively, or additionally (e.g., in combination), the LVDBs may be generated according to various methods as known to a person skilled in the art.

[0134] After viewing the results via the aggregated view, the user may wish to access the data from one or more sites (or environments). Thus, according to some aspects, method 200 may further include a step of providing the user with a connection to data of interest (e.g., data that matches the query) stored in or available via one or more LVDBs following an approved user request. According to some aspects, the providing of the connection may include the receipt of a user request to access data of interest indicated by the comprehensive aggregated view. A notification of the user request may then be generated and communicated to the respective site (e.g., via a site account or email). The site may then choose to approve or deny access from the user. According to some aspects, the notification includes one or more user identification details. Upon receiving an approval from the site to the user access request, the user is provided with a connection to the data of interest included in or available via the respective LVDB. According to some aspects, the connection may include a direct access to the respective LVDB, such as a hyperlink. According to some aspects, the connection may include the identity of the site and its contact details. Only patient data corresponding to the initial user query (e.g., dogs with osteoarthritis) is shared with the requesting user.

[0135] Reference is now made to Figs. 3A and 3B. FIG. Figure 3A shows comprehensive aggregated view 300 and an exemplary corresponding data of interest 320. FIG. 3B shows comprehensive aggregated view 330 and a screen shot of the display of data of interest 340 as provided by a specific LVDB in response to a user request.

[0136] With further reference to Fig. 1, a user such as user 180A, 180B or 180C may enter a query with system 100 (e.g., via a web-based UI such as UI 140) having search criteria: canine patients with osteoarthritis. System 100 (e.g., via processing unit 130) may query LVDBs 156A, 156B and 156C. System 100 receives a data record from each LVDB including aggregated level data in response to the query. According to some aspects, the data recordsmay be further processed. System 100 may then generate aggregated view 300 which will be then displayed to the user. Exemplary aggregated view 300 includes four view records 305A, 305B, 305C and 305D for four queried LVDBs of four different respective sites or environments. For each view record, aggregated view 300 includes a request access button 310A, 310B, 310C and 310D, respectively. The user may then initiate a request to access the data presented (e.g., in an aggregated form) or represented by each view record by activating the respective request access button. In Fig. 3A, request access button 310B is indicated as activated (indicated in-bold). Accordingly, system 100 may generate a notification to site 2 (such as site 152A, 152B or 152C) of the user request to receive access to data corresponding to the query (e.g., canine patients with osteoarthritis) stored in or available via the respective EVDB (such as EVDB 156 A, 156B or 156C). The notification may further include identification details of the user. The results of the querying of the EVDB associated with site 2 are then displayed to the user via system 100, e.g., as data of interest display 320. According to some aspects, the received data is further processed, e.g., by system 100, before its display to the user. Display 320 includes or shows detailed data (e.g., all the data) pertaining to the query, and on which, or at least on a portion of it, the aggregated data of aggregated view 300 was based on. Display 320 includes a table including a plurality of fields: field 33OA “Patient ID”, field 33OB “Breed” and field 33OC “Age” while each record 340A, 340B, 340C and 340D represents a different relevant patient (e.g., a dog with osteoarthritis). Referring now to Fig. 3B, aggregated view 330 includes high-level data in response to the query: feline patients with hyperthyroidism. Aggregated view 330 further includes a request button 334A, 334B, 334C and 334D for each view record 332A, 332B, 332C and 332D, respectively. The user may enter a request for accessing data represented by a view record or originating at a specific site by activating the respective request button. If the access request is approved, then the data of interest, such as display 340 may be presented to the user. Display 340 includes detailed relevant data (feline patients with hyperthyroidism) provided or shared by an LVDB associated with the requested specific site or environment. The display includes an upper row display 345 including high level data and some statistics based on the extracted data. According to some aspects, upper row display 345 is part of the data provided or shared by the respective LVDB. According to some aspects, upper row display 345 or other relevant information (e.g., statistical information) is generated and added to the data provided or shared by the respective LVDB by system 100. The detailed data is arranged in a table. The table includes a plurality of fields 350: Patient ID, Site, Species, Sex, OST, Date of Birth, Age, Date of death and Deceased status.Each view record 350 of the table refers to a different specific patient. Views and displays 300, 320, 330 and 340 are mere examples of a graphical presentation of the requested data and other forms of presentations and Graphical User Interface (GUI) elements may be used in generating the aggregated view and detailed data display in response to an access request.

[0137] According to some aspects, method 200 may further include a step of providing a UI. The UI may be used, for example, for generating user queries, reviewing the queries results (e.g., the comprehensive aggregated view) and for accessing patients’ detailed data as provided by the LVDBs of sites (e.g., clinics, hospitals, and the like).

[0138] Reference is now made to FIG. 4A, which is a flow diagram of a method 400 for generating a database based on a VEHR source, such as an LVDB. A VEHR source may include structured data and unstructured data. Structured data may have a standardized format or may be organized and formatted to facilitate efficient access by computers software and efficient computer processing. Unstructured data has no predefined format or organization, making it more difficult to collect, process or analyze. VEHR sources may store data by using various or different database schemas. Method 400 may be applied, inter alia, by the systems described herein and such as system 100 of Fig. 1. According to some aspects, the LVDBs described herein may be generated according to or based on method 400.

[0139] At a step 410, structured data extracted from a VEHR source is mapped to a predefined unified data schema. With reference to Fig. 1, each of VEHR 154A, 154B and 154C may utilize a different data schema. Structured data extracted from each of VEHR 154A, 154B and 154C may be mapped to a predefined unified data schema. Structured data may include data stored in a structured database (e.g., a table), while the stored data itself, e.g., text, may be of unstructured data type, e.g., free text.

[0140] According to some aspects, data pipelines may be built that connect to the initial location of the data, e.g., to the VEHR source, and extract it in its raw format to a client- specific database, e.g., the respective LVDB. According to some aspects, the client database is on the client’s own cloud environment that the client manages by himself. According to some aspects, the client database is on its own cloud environment that also includes managed services. The data pipelines may use code such as SQL and Pyspark to extract the data in its raw format into the final database location. Once the raw data has been extracted, it may be transformed using SQL and Pyspark to map the raw data fields to the harmonized schema. According to some aspects, the schema includes flags that map invoice line items from the raw data to known entities such as procedures or treatments. For example, different line items related to aradiograph (e.g., X-Ray 1 view, X-ray 2 view, X-ray 3 view) may be tagged as “X-ray” to be used as a filter. According to some aspects, the pipelines may be continuously or periodically updated, such as a few times a day (e.g., once, twice, three or four times a day). According to some aspects, only new data, identified e.g., based on the record modified date and time as well as the record ID, is added to the database. PIMS, for example, may be mapped to a data schema which its main concepts include the patient, patient visits, invoices tied to these visits, as well as diagnoses, medical notes, diagnostics, lab results and procedures.

[0141] Reference is now made to FIG. 4B, which is a diagram exemplifying in a simplified manner the harmonization of data from two different VEHR sources (VEHR 1 and VEHR 2) having two different data schemas 440 and 450 to a unified data schema 460. Each of the VEHR sources may be or may include, for example, a PIMS. Each of data schema 440, data schema 450 and unified data schema 460 is formed as a table including a plurality of fields. The table of data schema 440 includes a “Patient” field 442A, a “Visit Date” field 442B, a “SOAP” (Subjective, Objective, Assessment and Plan) field 442C and “Diagnosis” field 442D. The table of data schema 450 includes an “Animal” field 452A, an “Appointment” field 452B, a “History” field 452C and a “Master Problem” field 452D. The table of unified data schema 460 includes a “Patient Name” field 462A, a “Consult Date” field 462B, a “Medical Notes” field 462C and “Diagnosis” field 462D. The table according to data schema 440 includes a data record 444. The table according to data schema 450 includes a data record 454 and the table of unified data schema 460 includes the data of both data records 444 and 454 as new data record 464A and data record 464B, respectively. Accordingly, the data in fields 442A (“Patient”) and 454A (“Animal”) was stored in the corresponding unified field 462A (“Patient Name”); the data in fields 442B (“Visit Date”) and 454B (“Appointment”) was stored in the corresponding unified field 462B (“Consult Date”); the data in fields 442C (“SOAP”) and 454C (“History”) was stored in the corresponding unified field 462C (“Medical Notes”); and the data in fields 442D (“Diagnosis”) and 454D (“Master Problem”) was stored in the corresponding unified field 462D (“Diagnosis”).

[0142] At a step 420, the extracted structured data of the VEHR source is enriched by tagging medical terms in the unstructured data of the VEHR source. Medical terms and concepts may be extracted from text data stored in unstructured fields such as medical notes, discharge summaries, surgery reports, pathology reports and other free text fields. The resulting medical terms and concepts are outputted back into the harmonized database. According to some aspects, this process may occur continuously or periodically, e.g., daily, with any newrecords identified based, e.g., on the record modified date and time as well as the record ID. According to some aspects, the concept of negation (e.g., the patient is not vomiting) may be also recognized. The negated terms are not added back into the database as they represent the absence of a situation. The resulting populations of patients with specific diseases, symptoms, procedures, or treatments is much larger based on the data extracted from the unstructured medical text. According to some aspects, the medical terms included in the unstructured data are tagged by using a Named Entity Recognition (NER) algorithm. The NER algorithm is based on the Unified Medical Language System (UMLS) and can identify UMLS terms such as findings, disorders, procedures, morphological abnormalities, and medications, among others.

[0143] Reference is now made to FIG. 4C, which is a diagram exemplifying the enrichment of the harmonized data of Fig. 4B by tagging unstructured data. Table 470 includes the “Medical Notes” field 462C of the table of the unified data schema 460 of Fig. 4B, which is a free text field thus including unstructured data. Table 470 further includes a “Tagged Entity” field 472 which indicates the tagged entities. The tagged entities are indicated in bold in the data included in field 462C.

[0144] At an optional step 430, medical terms in the structured data and optionally also in the unstructured data of the generated database (e.g., an LVDB) may be mapped to corresponding standardized terms. A mapping table with a large number of common medical terms such as diseases, symptoms, findings, and procedures may be used to map medical terms to corresponding standardized terms. This may occur with all diseases, symptoms and procedures identified in the harmonized dataset. Such mapping may enable users to more easily search for terms that are the same but recorded differently. For example, tumor (U.S. spelling) and tumour (UK spelling) would both map to Tumor. According to some aspects, the standardized terms are defined based on the Systematized Medical Nomenclature for Medicine-Clinical Terminology (SNOMED CT) Fully Specific Name. According to some aspects, the Veterinary NOMencalture (VeNOM) may be used for standardization or any other standardized terminology. Reference is now made to FIG. 4D, which is a diagram exemplifying the standardization of the harmonized data of Fig. 4B by using a standard taxonomy. A table 480 includes the “Diagnosis” field 462D of the table of the unified data schema 460 of Fig. 4B. Table 480 further includes a “SNOMED-CT Fully Specified Name” field 482 which indicates the standardized terms into which the diagnosis terms are mapped.

[0145] According to some aspects, the tagging of medical terms in the unstructured data according to step 420 may include using the corresponding standardized terms according tostep 430, e.g., by using the corresponding standardized terms as tagged entities. According to some aspects, the databases generated according to method 400 (e.g., LVDBs) may be continuously or periodically updated according to updates applied to the respective VEHR sources. According to some aspects, only new data identified, e.g., based on the record modified date and time as well as the record ID, is added to the database.

[0146] According to some aspects, the data stored in one or more LVDBs is a mirror copy of the data stored in the respective VEHR sources. According to some aspects, an LVDB may include or may be generated by creating a mirror copy of the structured data and at least a portion of the unstructured data included in the respective VEHR source. According to some aspects, medical images, such as Magnetic Resonance Imaging (MRI) and Computerized Tomography (CT) images may not be copied or stored in an LVDB. According to some aspects, the LVDB may include a link to the medical images.

[0147] According to some aspects, one or more users of a VEHR source may directly query the associated LVDB. The LVDB may be generated, for example, according to method 400 or any other method as described herein.

[0148] According to some aspects, systems and methods described herein above may be used to facilitate the query of a veterinary health data. Reference is now made to FIG. 5, which is a diagram of an exemplary system for facilitating the query of veterinary health data. A system for facilitating the query of VHD may include a VEHR source, such as VEHR source 540, a database associated with the VEHR source, such as LVDB 550, a processing unit, such as processing unit 570 and a memory unit, such as memory unit 580. The memory unit may store instructions for execution by the processing unit. The instructions, when executed, may cause the system to receive a query from a user, such as user 530A or user 530B, access the database (e.g., LVDB 550) to identify data corresponding to the query and cause the display of the corresponding data to the user. The database associated with the VEHR source, e.g., LVDB 550 which is associated with VEHR 540, is generated according to method 400 of Fig. 4A. VEHR source 540, may be as described with respect to Fig. 1. Processing unit 570 may be similar to processing unit 130 and memory unit 580 may be similar to memory unit 120 of system 100 of Fig. 1 and function in a similar manner with alterations or adaptations obvious to one skilled in the art. Site 520 may be similar to site 152A, 152B or 152C of Fig. 1. Site 520 may control or own the data stored in VEHR source 540. For example, site 520 may be a hospital while VEHR source 540 may store health or medical information of patients treated by the hospital. Users 530A and 530B may be employees of site 520 (e.g., hospital medicalstaff) or any other users provided with access to data stored in VEHR source 540. Processing unit 570 and memory unit 580 may be a part of a computing system or computing resources used by site 520. The computing system or resources may be on-premise or remote, e.g., via a cloud infrastructure. VEHR source 540 and LVDB source 550 may be each located on-premise or remotely to site 520, e.g., via a cloud infrastructure. The display of the corresponding data to the user may be, for example, via a display device, a terminal or a mobile or handheld device. According to some aspects, the system (e.g., subsystem 500) may further include one or more displays (e.g., of a desktop computer or a terminal).

[0149] According to some aspects, the database (e.g., LVDB 550) is continuously or periodically updated according to updates applied to the corresponding VEHR source (e.g., VEHR 540). According to some aspects, the database is stored in the memory unit. According to some aspects, the system may deidentify the corresponding data displayed to the user. According to some aspects, a user interface is provided. The user interface may be used for generating the user’s query and for viewing the corresponding data.

[0150] Remote computing, a remote computing system or remote computing resources and the like as disclosed hereinabove can be or can include any system that performs computing and can be configured in various ways, including, without limitation, a cloud system / platform, a shared computing system, a server farm, a proprietary system, a networked Intranet system, a centralized system, or a distributed system, among others, or a combination of such systems.

[0151] The computing systems, devices or resources, as referred to hereinabove, may include a processor or controller that may be or include, for example, one or more central processing unit processor(s) (CPU), one or more Graphics Processing Unit(s) (GPU or GPGPU), and / or other types of processor, such as a microprocessor, digital signal processor, microcontroller, programmable logic device (PLD), field programmable gate array (FPGA), or any suitable computing or computational device. The computing systems, devices or resources, as referred to hereinabove, may also include an operating system, a memory, a storage, input devices, output devices, and a communication device, all as The communication device may include one or more transceivers which allow communications with remote or external devices and may implement communications standards and protocols, such as cellular communications (e.g. 3G, 4G, 5G, CDMA, GSM), Ethernet, Wi-Fi, Bluetooth, low energy Bluetooth, Zigbee, Internet-of-Things protocols (such as mosquitto MQTT), and / or USB, among others, all according to the context.

[0152] The illustrated components of the drawings are exemplary and variations are contemplated to be within the scope of the present disclosure. For example, the numbers of components may be greater or fewer than as described and the types of components may be different than as described. When a disclosed computing system, for example, implements a data storage system, a large number of storages may be utilized. As another example, when a disclosed computing system implements a server system, a large number of central processing units or cores may be utilized. Other variations and applications are contemplated to be within the scope of the present disclosure.

[0153] Accordingly, systems, devices, and methods for providing decentralized veterinary healthcare data and for facilitating the query of veterinary healthcare data have been described herein. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of aspects of the disclosed technology. However, it is apparent to one skilled in the art that the disclosed technology can be practiced without using every aspect presented herein.

[0154] Different aspects are disclosed herein. Features of certain aspects can be combined with features of other aspects; thus certain aspects can be combinations of features of multiple aspects.

[0155] While several embodiments of the disclosure have been described herein and / or shown in the drawings, it is not intended that the disclosure be limited thereto, as it is intended that the disclosure be as broad in scope as the art will allow and that the specification be read likewise. Therefore, the above description should not be construed as limiting, but merely as exemplifications of particular embodiments. Those skilled in the art will envision other modifications within the scope and spirit of the claims appended hereto.

Claims

CLAIMSWhat is Claimed is:

1. A computerized method for providing decentralized veterinary healthcare data connectivity, the method comprising: receiving a query from a user; accessing a plurality of Local Veterinary Databases (LVDB) to identify data corresponding to the query; obtaining data records associated with the accessed LVDBs, each data record comprising aggregated level data of the corresponding data; combining all the obtained data records to generate a comprehensive aggregated view of the corresponding data per LVDB ; and causing the display of the comprehensive aggregated view to the user, wherein each LVDB of the plurality of LVDBs is based on and associated with a separate Veterinary Electronic Health Records (VEHR) source.

2. The computerized method according to claim 1, wherein the VEHR sources comprise structured data and unstructured data, and wherein each LVDB is generated by: mapping structured data extracted from the respective VEHR source to a predefined unified data schema; and enriching the extracted structured data by tagging medical terms in the unstructured data.

3. The computerized method according to claim 2, wherein the medical terms comprised in the unstructured data are tagged by using a Named Entity Recognition algorithm.

4. The computerized method according to claim 2, wherein each LVDB is further generated by mapping medical terms in the structured data and in the unstructured data to corresponding standardized terms.

5. The computerized method according to claim 4, wherein the tagging of medical terms in the unstructured data comprises using the corresponding standardized terms.

6. The computerized method according to claim 4, wherein the standardized terms are defined based on the Systematized Medical Nomenclature for Medicine-Clinical Terminology (SNOMED CT).

7. The computerized method according to claim 4, wherein the query comprises one or more search criteria, and wherein the comprehensive aggregated view comprises a total number of patients corresponding to the one or more search criteria per VEHR source.

8. The computerized method according to claim 7, wherein the comprehensive aggregated view further comprises high-level statistics for each patient population.

9. The computerized method according to claim 1, further comprising generating the plurality of LVDBs.

10. The computerized method according to claim 1, further comprising generating the data record for each LVDB of the accessed LVDB comprising data corresponding to the query.

11. The computerized method according to claim 1, further comprising providing the user with a connection to data of interest stored in one or more LVDBs following an approved user request.

12. The computerized method according to claim 11, wherein the providing of the connection comprises: receiving the user request to access the data of interest, wherein the data of interest is indicated by the comprehensive aggregated view; generating one or more notifications of the user request to access the data of interest, respectively; and upon receiving an approval to the user access request, providing the user with a connection to the data of interest comprised in the approved respective LVDB .

13. The computerized method according to claim 11, wherein the connection comprises direct access to at least one LVDB of the respective one or more LVDBs.

14. The computerized method according to claim 1, wherein VEHR sources of the multiple VEHR sources store data by using different database schemas.

15. The computerized method according to claim 1, wherein data displayed to the user via the comprehensive aggregated view is deidentified.

16. The computerized method according to claim 15, wherein at least one of: the identity of the VEHR sources or the identity of the patients is obfuscated to the users.

17. The computerized method according to claim 1, wherein the data comprised in the data record is deidentified.

18. The computerized method according to claim 1, wherein one or more users of a VEHR source of the plurality of VEHR sources may directly query the associated LVDB.

19. The computerized method of claim 1, wherein the LVDBs are continuously updated according to updates applied to the VEHR sources, respectively.

20. The computerized method according to claim 1, wherein each LVDB of the plurality of LVDBs is stored in a separate environment.

21. The computerized method according to claim 1, further comprising providing a user interface, wherein the user interface is used for generating a user query and viewing the comprehensive aggregated view.

22. The computerized method according to claim 1, wherein the providing of data comprised in the plurality of LVDBs is based on a federated data architecture.

23. The computerized method according to claim 1, wherein the data stored in each LVDB of one or more LVDBs of the plurality of LVDBs is a mirror copy of the data stored in the respective VEHR source.

24. The computerized method according to claim 1, wherein the data stored in each LVDB of one or more LVDBs of the plurality of LVDBs comprises the structured data and at least a portion of the unstructured data stored in the respective VEHR source.

25. A method for generating a database based on a Veterinary Electronic Health Record (VEHR) source, wherein the VEHR source comprises structured data and unstructured data, the method comprising: mapping structured data extracted from the respective VEHR source to a predefined unified data schema; enriching the extracted structured data by tagging medical terms in the unstructured data; and mapping medical terms in the extracted structured data and in the unstructured data to corresponding standardized terms.

26. The method according to claim 25, wherein the medical terms comprised in the unstructured data are tagged by using a Named Entity Recognition algorithm.

27. The method according to claim 25, wherein the tagging of medical terms in the unstructured data comprises using the corresponding standardized terms.

28. The method according to claim 25, wherein the standardized terms are defined based on the Systematized Medical Nomenclature for Medicine-Clinical Terminology (SNOMED CT).

29. The method of claim 25, wherein the database is continuously updated according to updates applied to the VEHR source.

30. The method of claim 25, further comprising generating a mirror copy of the structured data and at least a portion of the unstructured data comprised in the VEHR source.

31. A method for providing decentralized veterinary healthcare data connectivity, the method comprising:generating a plurality of Local Veterinary Databases (LVDBs), wherein each LVDB of the plurality of LVDBs is based on and associated with a separate VEHR source, and wherein each LVDB of the plurality of LVDBs is generated according to claim 25; and using at least one hardware processor to: receive a query from a user; access LVDBs of the plurality of LVDBs to identify data corresponding to the query; obtain data records associated with the accessed LVDBs, each data record comprising aggregate level data of the corresponding data; combine all the obtained data records to generate a comprehensive aggregated view of the corresponding data per LVDB; and cause the display of the comprehensive aggregated view to the user.

32. The method according to claim 31, wherein the query comprises one or more search criteria, and wherein the comprehensive aggregated view comprises a total number of patients corresponding to the one or more search criteria per VEHR source.

33. The method according to claim 32, wherein the comprehensive aggregated view further comprises high-level statistics for each patient population.

34. The method according to claim 31, further comprising generating the data record for each LVDB of the accessed LVDBs comprising data corresponding to the query.

35. The method according to claim 31, further comprising providing the user with a connection to data of interest comprised in one or more LVDBs following an approved user request.

36. The method according to claim 35, wherein the providing of the connection comprises: receiving the user request to access the data of interest, wherein the data of interest is indicated by the comprehensive aggregated view; generating one or more notifications of the user request to access the data of interest, respectively; andupon receiving an approval to the user access request, providing the user with a connection to the data of interest comprised in the approved respective LVDB .

37. The method according to claim 35, wherein the connection comprises direct access to at least one LVDB of the respective one or more LVDBs.

38. The method according to claim 31, wherein VEHR sources of the multiple VEHR sources store data by using different database schemas.

39. The method according to claim 31, wherein data displayed to the user via the comprehensive aggregated view is deidentified.

40. The method according to claim 39, wherein at least one of: the identity of the VEHR sources or the identity of the patients are obfuscated to the users.

41. The method according to claim 31, wherein the data comprised in the data record is deidentified.

42. The method according to claim 31, wherein one or more users of a VEHR source of the plurality of VEHR sources may directly query the associated LVDB.

43. The method according to claim 31, wherein each LVDB of the plurality of LVDBs is stored in a separate environment.

44. The method according to claim 31, further comprising generating a user interface, wherein the user interface is used for generating a user query and for displaying the comprehensive aggregated view to a user.

45. The method according to claim 31, wherein the providing of data comprised in the plurality of LVDBs is based on a federated data architecture.

46. A system for facilitating the provision of decentralized veterinary health data, the system comprising:at least one hardware processor; at least one computer readable storage device storing instructions for execution by the at least one hardware processor, the instructions, when executed, cause the system to: receive a query from a user; access a plurality of Local Veterinary Databases (LVDB) to identify data corresponding to the query; obtain data records associated with the accessed LVDBs, each data record comprising aggregate level data of the corresponding data; combine all the obtained data records to generate a comprehensive aggregated view of the corresponding data per LVDB; and cause the display of the comprehensive view to the user, wherein each LVDB of the plurality of LVDBs is based on and associated with a separate Veterinary Electronic Health Records (VEHR) source.

47. The system according to claim 46, wherein the VEHR sources comprise structured data and unstructured data, and wherein each LVDB is generated by: mapping structured data extracted from the respective VEHR source to a predefined unified data schema; and enriching the extracted structured data by tagging medical terms in unstructured data.

48. The system according to claim 47, wherein the medical terms comprised in the unstructured data are tagged by using a Named Entity Recognition algorithm.

49. The system according to claim 47, wherein each LVDB is further generated by mapping medical terms in the structured data and in the unstructured data to corresponding standardized terms.

50. The system according to claim 49, wherein the tagging of medical terms in the unstructured data comprises using the corresponding standardized terms.

51. The system according to claim 49, wherein the standardized terms are defined based on the Systematized Medical Nomenclature for Medicine-Clinical Terminology (SNOMED CT).

52. The system according to claim 46, wherein the query comprises one or more search criteria, and wherein the comprehensive aggregated view comprises a total number of patients corresponding to the one or more search criteria per VEHR source.

53. The system according to claim 52, wherein the comprehensive aggregated view further comprises high-level statistics for each patient population.

54. The system according to claim 46, wherein the instructions further cause the system to generate the plurality of LVDBs.

55. The system according to claim 46, wherein the instructions further cause the system to generate the data record for each LVDB of the accessed LVDB comprising data corresponding to the query.

56. The system according to claim 46, wherein the instructions further cause the system to provide the user with a connection to data of interest stored in one or more LVDBs following an approved user request.

57. The system according to claim 56, wherein the providing of the connection comprises: receiving the user request to access the data of interest, wherein the data of interest is indicated by the comprehensive aggregated view; generating one or more notifications of the user request to access the data of interest, respectively; and upon receiving an approval to the user access request, providing the user with a connection to the data of interest comprised in the approved respective LVDB .

58. The system according to claim 56, wherein the connection comprises direct access to at least one LVDB of the respective one or more LVDBs.

59. The system according to claim 46, wherein VEHR sources of the multiple VEHR sources store data by using different database schemas.

60. The system according to claim 46, wherein data displayed to the user via the comprehensive aggregated view is deidentified.

61. The system according to claim 60, wherein at least one of: the identity of the VEHR sources or the identity of the patients are obfuscated to the users.

62. The system according to claim 46, wherein the data comprised in the data record is deidentified.

63. The system according to claim 46, wherein one or more users of a VEHR source of the plurality of VEHR sources may directly query the associated LVDB.

64. The system of claim 46, wherein the LVDBs are continuously updated according to updates applied to the VEHR sources, respectively.

65. The system according to claim 46, wherein each LVDB of the plurality of LVDBs is stored in a separate environment.

66. The system according to claim 46, wherein the instructions further cause the system to provide a user interface, wherein the user interface is used for generating a user query and for viewing the comprehensive aggregated view.

67. The system according to claim 46, wherein the providing of data comprised in the plurality of LVDBs is based on a federated data architecture.

68. The system according to claim 46, wherein the data stored in each LVDB of one or more LVDBs of the plurality of LVDBs is a mirror copy of the data stored in the respective VEHR source.

69. The system according to claim 46, wherein the data stored in each LVDB of one or more LVDBs of the plurality of LVDBs comprises the structured data and at least a portion of the unstructured data stored in the respective VEHR source.

70. A system for facilitating the query of veterinary health data, the system comprising: a Veterinary Electronic Health Records (VEHR) source; a database associated with the VEHR source; at least one hardware processor; at least one computer readable storage device storing instructions for execution by the at least one hardware processor, the instructions, when executed, cause the system to: receive a query from a user; access the database to identify data corresponding to the query; and cause the display of the corresponding data to the user, wherein the database is generated by: mapping structured data extracted from the respective VEHR source to a predefined unified data schema; enriching the extracted structured data by tagging medical terms in the unstructured data; and mapping medical terms in the extracted structured data and in the unstructured data to corresponding standardized terms.

71. The system according to claim 70, wherein the instructions further cause the system to continuously update the database according to updates applied to the VEHR source.

72. The system according to claim 70, wherein the database is stored in the at least one computer readable storage device.

73. The system according to claim 70, wherein the instructions further cause the system to deidentify the corresponding data displayed to the user.

74. The system according to claim 70, wherein the medical terms comprised in the unstructured data are tagged by using a Named Entity Recognition algorithm.

75. The system according to claim 70, wherein the database is further generated by mapping medical terms in the structured data and in the unstructured data to corresponding standardized terms.

76. The system according to claim 70, wherein the tagging of medical terms in the unstructured data comprises using the corresponding standardized terms.

77. The system according to claim 70, wherein the standardized terms are defined based on the Systematized Medical Nomenclature for Medicine-Clinical Terminology (SNOMED CT).

78. The system according to claim 70, wherein the instructions further cause the system to provide a user interface, wherein the user interface is used for generating the user query and for viewing the corresponding data.

79. The system according to claim 70, wherein the data stored in the database is a mirror copy of the data stored in the VEHR source.

80. The system according to claim 70, wherein the data stored in the database comprises the structured data and at least a portion of the unstructured data stored in the VEHR source.

Images