JP6328768B2 - Metadata automation system - Google Patents

Description

  Embodiments of the present invention relate generally to computer databases, and more particularly to facilitating management of data structures including definition, creation, modification, transformation, and population.

  Automatic processing of information has provided tremendous benefits to the business. Because every process of decision-making by decision-makers has greatly improved effectiveness and efficiency. All businesses, whether government, commercial business, or non-profit organizations, have a business need to manage information.

  The information may be, for example, in the case of commercial business, between the employee, customer and supplier, patient treatment, customer acquisition, order entry, product shipment, customer billing, invoice receipt, employee Used to pay suppliers, place orders for products, inventory audits, and maintain transaction records.

  In the natural course of events, information is acquired, processed and integrated utilizing software, computer hardware and digital networks according to each organization's internal operational model. Unfortunately, automated processing of information presents a number of problems that undermine business by hindering the integration, standardization and reporting of available, timely and cost-effective data.

  One traditional approach focused on building an enterprise data warehouse to collect integrated and standardized data from across the organization. A typical enterprise data warehouse requires operational data extracted from many sources, converted, and loaded into a third normal form operational data store database. It is extracted again, converted, and loaded into the Star Snowflake data vault database. The data vault database is then loaded into the data mart and each assigned to a specific department or function.

  Each database in the enterprise data warehouse formation and functional process must be designed, maintained, and populated with custom extract transform load (ETL) functions. In addition, before an organization can generate reports, all phases of development and use must be completed in some way and begin to benefit from the enterprise data warehouse.

  An enterprise data warehouse acquires standardized data that is centrally managed for the entire organization, which is very expensive. Because monetary costs can be astronomical, the resources (development costs) required to implement a comprehensive enterprise data warehouse can be prohibitively high for all but a very limited number of decimals. Even when monetary resources are not a limiting factor, the time required to build and implement an enterprise data warehouse is usually on a yearly basis.

  Other shortcomings of enterprise data warehousing due to enterprise data warehousing focus on decision support applications that highlight summarized information. An essential drawback of these systems is that transaction details regarding the customer's identity are lost. Enterprise data warehouses present shortcomings when applied to applications such as customer data analysis. Customer data analysis is an analysis that assists in the determination of associating data with customer activity, events, transactions, status, and the like. The summarized information usually loses a level of detail about the customer's identity, and the usefulness of the enterprise data warehouse in these applications is limited.

  Other approaches focus on creating a departmental data mart directly from an organization's operational data. In the case of a departmental data mart, it is only necessary to capture data relating to a single department. Therefore, the departmental data mart can be much smaller.

  Departmental data marts are small in size and generally require fewer resources in terms of time and money to build, but these benefits are also expensive. Departmental data marts are not centrally managed and do not have standards that are consistent in terms of quality or data format.

  When a departmental data mart is created, it cannot be integrated across the organization due to inconsistent standards. In addition, each departmental data mart is created without a comprehensive plan, and adding up the resources that each department has invested to hold a data mart is more than creating a single, well-planned enterprise data warehouse. Can also be substantially higher. Resources for maintaining inconsistent departmental data marts can be much more expensive than maintaining a single enterprise data warehouse.

  There is currently no comprehensive solution to the challenge of providing available, timely and cost-effective data integration, standardization and reporting. This need has long been felt within the industry.

  Prior developments have not taught or suggested any solution to overcome all the above limitations. Thus, no solution to overcome these limitations has long been discovered by those skilled in the art.

  The claimed invention is directed to methods, products, and systems that utilize a schema definition language that has metadata defining properties that are linked to entities and grouped together in a module. The schema definition language is utilized to generate physical tables for modules and entities that are linked to each other based on characteristics. The physical table can be populated with data that matches the metadata.

  It is further believed that the schema definition language can be referenced to locate the physical table and determine whether the physical table for the module or entity includes the selected property. In the same way, refer to the schema definition language to locate the physical table and determine whether the physical table contains the next selected characteristic only if the physical table contains the selected characteristic. be able to.

  It is further considered that the one-hop linkage can be specified from the schema definition language when the properties are grouped within the same module as the selected property. It is further believed that entities are classified into matched and unmatched cohorts based on whether the clinical pattern matches the characteristics associated with the entity.

  It is further considered that the report data definition can include the module with reference to the schema definition language if the report data definition includes characteristics associated with the module. It is further contemplated that the physical table can include aged data and aged data associated with modules and entities, respectively.

  The above briefly summarized invention will now be described in more detail with reference to the embodiments illustrated in the accompanying drawings in a manner that allows the above features, advantages and objects of the invention to be achieved and understood in detail. explain.

  It should be noted that the accompanying drawings illustrate only typical embodiments of the present invention and should not be considered as limiting the scope of the invention. This is because the present invention may allow other embodiments that are equally effective. In the accompanying drawings shown below, like reference numerals are intended to refer to the same or corresponding parts.

FIG. 1 represents an exemplary distributed computer system according to an embodiment of the present invention. FIG. 2 depicts an exemplary block diagram of a data processing system according to an embodiment of the present invention. FIG. 3 illustrates an exemplary metadata table according to an embodiment of the present invention. FIG. 4 represents an exemplary schema definition model according to an embodiment of the present invention. FIG. 5 represents an exemplary schema definition model table according to an embodiment of the present invention. FIG. 6 depicts an exemplary physical schema table according to an embodiment of the present invention. FIG. 7 depicts an exemplary control flow for implementing and populating an operational data store according to an embodiment of the present invention. FIG. 8 depicts an exemplary control flow for generating an extracted transformation load function according to an embodiment of the present invention. FIG. 9 depicts an exemplary control flow for cohort filtering according to an embodiment of the present invention. FIG. 10 represents a screen shot of a filter implemented in a business intelligence tool. FIG. 11 illustrates an exemplary control flow for cohort filtering utilizing patterns according to an embodiment of the present invention. FIG. 12 represents a screen shot of a filter implemented in a business intelligence tool. FIG. 13 depicts an exemplary control flow for generating a report, according to an embodiment of the present invention. FIG. 14 represents a screenshot of the definition of report data implemented in a business intelligence tool. FIG. 15 shows a control flow for analyzing a report according to the embodiment of the present invention.

  In the following description of the invention, reference is made to the accompanying drawings that form a part hereof, and in which are shown for the purpose of illustrating exemplary embodiments in which the invention may be practiced. It should be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

  The following embodiments are described in sufficient detail to enable those skilled in the art to make and use the invention. It is to be understood that other embodiments will be apparent based on the present disclosure, and that system, process, and mechanical changes may be made without departing from the scope of the invention. It is.

  In the following description, numerous specific details are given to provide a thorough understanding of the present invention, but it will be apparent that the invention may be practiced without these specific details. In order to avoid obscuring the present invention, some well-known circuits, system configurations, and process steps are not disclosed in detail.

  In addition, in a part in which a plurality of embodiments sharing some features are disclosed and described, in order to clarify and facilitate description, description, and understanding, features similar or similar to each other are referred to by the same reference. Usually described with a sign. For convenience of explanation, these embodiments are numbered as the first embodiment, the second embodiment, etc., but have other significance and are not intended to limit the present invention.

  For explanatory purposes, the term “metadata” as used herein is defined as data about data. As used herein, the term “system” means and refers to the method and apparatus of the present invention according to the context in which the word is used.

  Embodiments of the present invention provide a technique for adopting a unique schema definition language and utilizing a schema definition language when constructing, generating, and populating a database or a data store. Provides a technique for enabling a business intelligence tool that automatically generates an extract-transform-load function and retrieves data from a database or data store. As used herein, a business intelligence tool generally refers to a software application configured to report, analyze and present data. This data is stored in a data warehouse, database, data store, data mart, or a combination thereof.

  According to certain aspects, the schema definition language can be implemented in or presented by a schema definition model that indicates the relationships between properties, entities, and modules defined by the schema definition language. . The schema definition language defines the structure and framework for the physical tables of the operational data store. The schema definition language may include relationships and locations for mapping the schema definition model to one or more physical entities of physical data. Thus, the schema definition language can be used to define and access access to fields of physical data that contain a specific set of physical data.

  Advantageously, embodiments of the present invention provide a schema definition language at a high level of abstraction to enable a business intelligence tool for leveraging operational data stores at low cost and in a short time frame. Provides technology to provide a platform that interfaces with the schema definition language. The schema definition language makes it possible to implement business intelligence tools that operate at a high level of abstraction so that even when the underlying database evolves, these tools no longer need to be changed. Databases evolve easily and unimpeded when utilizing the schema definition language of the present invention.

  Advantageously, business intelligence tools that take advantage of the schema definition language to access physical tables and execute queries provide the user with options related to the type of characteristic selected in the previous step. Provide an intuitive experience. The schema definition language can also be used to give a simple structure to a physical table that enables an easy and effective solution for modeling and designing an operational data store. In addition, leveraging the schema definition language automatically extracts, transforms, and loads functions to quickly populate the operational data store based on the schema definition language structure and metadata contained within the schema definition model. It becomes possible to do.

  In the following, reference is made to embodiments and specific examples of the present invention, but the present invention should not be construed as being limited to the specifically described embodiments or examples. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated for implementing and implementing the present invention. Furthermore, although embodiments of the present invention may achieve advantageous effects over other possible solutions and / or over the prior art, are certain embodiments achieved with certain embodiments? It does not limit the present invention. Thus, the following aspects, features, embodiments, and advantages are for illustrative purposes only and are not to be construed as the features or limitations of the claims, except as explicitly recited in the appended claims. Not. Similarly, references to “the present invention” should not be construed as generalizing any subject matter disclosed herein, but are explicitly recited in the appended claims. Should not be construed as the features or limitations of the claims.

  When any of the appended claims can be read to include a pure software and / or firmware implementation, this allows at least one element of at least one embodiment to include the software and / or firmware. It is explicitly defined to include stored tangible computer readable media.

  An embodiment of the present invention is realized as a program product used in a computer system. Programs of the program product define the functions of the embodiments (including the methods described therein) and can be stored on various computer readable storage media. A computer-readable storage medium as defined herein is a product. Computer readable storage media for illustrative purposes and not limited include the following. (I) a non-writable storage medium in which information is permanently stored (for example, a read-only memory device in a computer such as a CD-ROM disc readable by a CD-ROM drive), or (ii) rewriting A writable storage medium (eg, a flexible disk in a diskette drive or hard disk drive) where possible information is stored. Such a computer readable storage medium is an embodiment of the present invention when it includes computer readable instructions that direct the functions of the present invention. Other media include communication media that conveys information to the computer, such as a computer including a wireless communication network or a telephone network. The latter embodiment specifically includes sending and receiving information to / from the Internet and other networks. Such a communication medium is an embodiment of the present invention when it comprises computer readable instructions that direct the functions of the present invention. In a broad sense, computer readable storage media and communication media may be referred to herein as computer readable media.

  In general, a routine executed to implement an embodiment of the present invention may be part of an operating system or a specific application, part, program, module, object, or instruction sequence. The computer program of the present invention typically consists of a number of instructions that will be translated into executable instructions that can be read and executed by a native computer. A program also consists of variables and data structures that are local to the program or found in memory or storage media. Various programs described below may be specified based on an application for realizing the program in the specific embodiment of the present invention. However, any name of the particular program that follows should be construed as merely being used for convenience. Thus, the present invention should not be limited to be used only in the specific applications identified and / or implied by such names.

  Referring now to FIG. 1, there is shown an exemplary distributed computer system 100 according to an embodiment of the present invention. In general, the distributed computer system 100 is shown as a distributed environment and includes a computer system 102 and a plurality of networked devices 104. Computer system 102 may represent any type of computer, computer system, or other programmable electronic device described below. That is, client computers, server computers, portable computers, embedded controllers, PC-based servers, minicomputers, midrange computers, mainframe computers, and other computers adapted to accommodate the methods, apparatus, and products of the present invention Etc.

  For illustrative purposes, computer system 102 comprises a networked system. However, the computer system 102 may consist of independent devices. In any case, it is understood that FIG. 1 is only one configuration of computer system 100. Embodiments of the present invention can be applied to any comparable configuration. It does not matter whether the computer system 102 is a complex multi-user device, a single-user workstation, or a network device that does not have its own non-volatile storage.

  Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. In this regard, the computer system 102 and / or one or more networked devices 104 may be thin clients that perform little or no processing.

  Computer system 102 may include a number of operators and peripheral systems such as those listed below. For example, a large storage interface 106 operably connected to a direct access storage device 108, a video interface 110 operably connected to a display 112, and a network interface operably connected to a plurality of networked devices 104 114. The display 112 may be a video output device for outputting information that can be viewed.

  Computer system 102 is shown as comprising at least one processor 116 that obtains instructions and data from main memory 120 via bus 118. The processor 116 can be any processor adapted to accommodate the method of the present invention.

  Main memory 120 is any memory large enough to hold the necessary programs and data structures. Main memory 120 may be a single memory device, including random access memory, non-volatile or backup memory (eg, programmable or flash memory, read-only memory, etc.), or a combination of these memory devices. Memory 120 may also be considered to include memory that is physically located somewhere within computer system 102. For example, any storage device may be used as a virtual memory, a large storage device (eg, direct access storage device 108), or other computer connected to the computer system 102 via the bus 118.

  Memory 120 is shown as configured with operating system 122. The operating system 122 is software that is used to manage the operation of the computer system 102.

  The memory 120 further includes an access layer 124, a schema definition language 126, a filter 128, a report data definition 130, one or more applications 132, and a plurality of business intelligence tools 134. Application 132, business intelligence tool 134, and access layer 124 are software products comprised of multiple instructions that exist at various times in various memory and storage devices in computer system 102. When read and executed by one or more processors 116 at computer system 102, application 132, access layer 124, and schema definition language 126 perform various aspects of the invention on computer system 102, either individually or in combination. In order to carry out the necessary steps.

  Access layer 124 (more generally, a requesting entity that includes operating system 122) is configured to issue a query to database 136. For illustrative purposes, the database 136 is shown as part of a database management system (DBMS) in the storage 108. Although only one database is shown for simplicity, the DBMS 138 may include multiple databases.

  Furthermore, these databases may be distributed with each other. Further, one or more databases can be distributed across one or more networked devices 104. For illustrative purposes, the networked system 140 is shown as comprising a DBMS 142 that includes a database 144. Although only one database 144 is shown for simplicity, the DBMS 142 may include multiple databases. Further, these databases 142 may be distributed with each other. All such different embodiments are widely considered. A storage table or networked device 104 is a metadata table used by the application 132 to configure filters, feed back to users, and configure report data definitions for business intelligence tools 134. A physical table, schema definition language 126, or schema definition model may also be included.

  Databases 136 and 144 are representative of a collection of data regardless of the specific physical representation of the data. The physical representation of data defines the structural schema of the data.

  In one embodiment, database 136 includes an operational database and database 144 includes an operational data store. The operational database includes at least a portion of the physical data contained within the data store. According to an aspect, the data store includes data that can execute queries derived from physical data in the operational database. Thus, the data that can be queried in the data store includes a subset of the physical data in the operational database. In addition to the subset of data from the operational database, the data store may contain other data.

  In certain embodiments, the query may be generated in response to input (eg, user input). The query can be constructed using logical fields defined in the schema definition language 126. The query is performed against the database 144 using a filter 128 that can reference the schema definition language 126 for isolating or defining the class of the entity 404 of FIG. 4 represented by the physical data in the database 144. Is done. The operation of filter 128 is described in detail below with reference to FIGS.

  The query is also executed against the database 144 using the schema definition language of FIG. 4, the structure report of the entity 404, the module 406, and the report data definition 130 that can reference the observations 408 of the characteristics. Data is extracted from the physical table in 144. The operation of the report data definition 130 is described in detail below with reference to FIGS.

  Referring now to FIG. 2, there is shown an exemplary block diagram of a data processing system 200 according to an embodiment of the present invention. The data processing system 200 includes a data input block 202 for extracting data 203 from one or more external sources 204 and loading it into a connected operational data store 206. For example, the external source 204 can be the database 136 of the storage device 108 of FIG. The operational data store 206 may be included in the database 144 of the networked device 104 of FIG.

  The management engine 208 is configured to map and locate at least a portion of the data 203 in the operational data store 206 and based on the schema definition language 126 for subsequent allocation processing, mapping, filtering, reporting, etc. Calculate the position and relationship.

  The data processing system 200 also includes an information transmission block 210 for communicating data 203 to a user and is connected to an operational data store 206 and a management engine 208. The communication function can be performed by the business intelligence tool 134. The business intelligence tool 134 can be a filtering tool such as the TransMed System Cohort Explorer or TransMed System Clinical Pattern Matcher described in FIGS. 9 and 11, respectively. The business intelligence tool 134 can be a reporting tool such as the TransMed System Cohort Reporter or TransMed System Cohort Analyzer described in FIGS. 13 and 15, respectively.

  The information transmission block 210 of the data processing system 200 includes a user interface 212 for receiving runtime parameters from the user, and a task controller 214 for starting the management engine 208 in response to an input from the user interface 212. Is provided. User interface 212 may comprise hardware and software for two-way communication with a user. The task controller 214 also communicates with a management engine 208 that allows the user to submit parameters and instructions for grouping, filtering, and returning data 203 via the user interface 212.

  Data input block 202 uses an extract-transform-load (ETL) tool 216 to extract data 203 from one or more external sources 204 and then converts the extracted data 203 into at least one desired data format. The converted data 203 can then be loaded into one or more physical tables 218 in the operational data store 206 for data storage.

  Significantly, the management engine 208 can provide the schema definition language 126 as a framework for the business intelligence tool 134 and the physical table 218. The management engine 208 can automatically generate the ETL tool 216 for populating the physical table 218 in the data 203 from the external source 204 utilizing the schema definition language 126.

  Operations that automate the ETL tool 216 and populate the physical table 218 are described below with respect to FIGS. The management engine 208 further provides the schema definition language 126 as a framework that enables the business intelligence tool 134 to operate to structure the reports and filter searches.

  The schema definition language 126 includes an entity type 220, a characteristic 222, and a module type 224. A characteristic 222 is linked to an entity type 220 having a link 226. Properties 222 can be grouped together in module type 224 based on whether properties 222 are observed together.

  Entity type 220, property 222, and module type 224 provide the structure and formation of the schema definition model 400 described below with respect to FIG. 4 that provides the structure and relationships of the physical table 218 in the operational data store 206. It can be a metadata structure of the schema definition language 126. The schema definition language 126 further provides a framework for how the data 203 will be populated into the physical table 218.

  For ease of explanation and understanding, entity types 220, properties 222, and module types 224 are described below with reference to the healthcare field. Those skilled in the art will recognize that this is done for illustrative purposes and is not intended to limit the invention.

  It is contemplated that the entity type 220 can define the type of physical object. The entity type 220 of the actual entity 404 in FIG. 4 is an abstract that is a data structure and the metadata 302 in FIG. The actual entity 404 is a specific example of the entity type 220 having the property observation 408 and lifetime of FIG. The lifetime used here is defined as the time span in which a physical object exists in a state where a valid observer will recognize the physical object as one of the entity types 220. Here, property observation 408 is defined as an observable fact for entity 404.

  In the context of the healthcare field, entity type 220 can be exemplified as a patient, a surgeon, or a facility. Entity 404 can be exemplified as a particular hospital, patient, surgeon, or payer. In other words, the entity 404 is Dr. Jones or Suburban Hospital.

  The module type 224 is considered to be able to define a specific record or moment that is the observation result of the characteristic observation 408. Module type 224 is the abstract and metadata 302 of the actual module 406 of FIG. The actual module 406 is a specific example of the module type 224. Module 406 may list observations 408 of characteristics observed for entities 404 that are normally observed together. As used herein, module 406 is defined as a collection of observations 408 of related properties of entities 404 that are often observed together. Module type 224 may include start and end dates for observation of characteristic 222. Module type 224 lists characteristics 222 associated with module type 224 and identifies the start and end dates for module type 224. It is further contemplated that module type 224 may only include a single date or time stamp that is the same as the start and end time stamps of the event without a duration.

  The module type 224 can be exemplified as hospitalization (hospital date, discharge date), diagnosis (diagnosis date), treatment (treatment start date and end date), and pathological examination (pathological examination date). Module 406 itself can be illustrated as a specific hospitalization, diagnosis, treatment, and pathology examination. That is, module 406 may be Mike Johnson, who was accepted into the Suburb Hospital emergency room on February 5, 2012, Mike Johnson was diagnosed with pneumonia on February 5, 2012, and Dr. Jones -Benzylpenicillin was administered to Mike Johnson on Feb. 5, 2012 to treat Johnson's pneumonia, or Dr. Jones did a complete blood count for Mike Johnson on Feb. 5, 2012 Order.

  It is contemplated that characteristic 222 may define a single observable property or characteristic observation 408 for entity 404 or entity 404. The characteristic 222 has a name and specifies the particular data type 410 of FIG. 4, such as integer, actual, date / time, text, selection, module pointer or entity pointer. Property 222 is abstraction and metadata 302 which is the data structure of observed property observation 408. Property observation 408 is a specific example of fact observation about entity 404. Characteristic observation 408 is consistent with data type 410 of characteristic 222.

  The characteristic 222 is a diagnostic module type as a diagnosis date with a time data type 410, an ICD9 selection with a selection data type 410, a surgeon note with a text data type 410, or a severity selection with a selection data type 410. Can be exemplified for. Characteristic 222 further includes the type of hospitalization module as hospitalization date with date / time data type 410, discharge date with date / time data type 410, primary payer with selection data type 410, or with selection data type 410. It can be illustrated as a discharge measure.

  Characteristic observation 408 can be illustrated for the diagnostic module as diagnosis date: February 5, 2012, 1:30 pm, ICD9: “480.1”, or surgeon note “Patients have difficulty breathing” . Characteristic observation 408 includes, as an inpatient module, diagnosis date: February 5, 2012, 11:30 am, discharge date: February 7, 2012, 1:30 pm, primary payer “Aetna”, discharge measures: It can be exemplified as “home”.

  Characteristics 222 can include observations 408 of aged and non-aged characteristics. Aged characteristic observation 408 is defined to mean characteristic observation 408 corresponding to an event that is treated as occurring during the lifetime of entity 404, as used herein. Aging trait observations 408 typically have a shorter duration than the lifetime of the entity 404 observed to own them. Non-aged property observations 408 are defined to mean property observations 408 that are treated as life-long entities 404 such as name, blood type, patient ID, as used herein. Non-aged characteristics may change but are not necessarily associated with a particular event. The entity type 220 can be given a special one of the module types 224 to acquire the non-aged characteristics of the entity 404. On the other hand, the aging characteristics are given the date of occurrence of the entity 404 and are grouped together with the standard module type 224.

  Semantic representation of entities 404 linked to the observation of properties grouped by module 406 by leveraging schema definition language 126 implemented as metadata 302 and represented by metadata table 300 of FIG. And thereby found to provide a simple and effective framework for the physical table 218. This framework is tied to the schema definition language 126 of the metadata table 300, but by referring to the metadata table 300, the physical data table 218 can be used quickly, simply and effectively. The physical data table 218 can be filtered and used to generate a report by referring to the schema definition language 126 in the metadata table 300.

  The schema definition language 126 acquired as metadata 302 in the metadata table 300 is used by filtering the physical data table 218 in order to generate reports in an intuitive manner while simultaneously reducing implementation costs and timelines. Enable. Implementation timelines can be significantly reduced by leveraging the schema definition language 126. This is because in a typical data warehouse, the data structure needs to be normalized and placed in a dimension table. However, by utilizing the schema definition language 126, the data 203 can be simply associated with metadata structures and data structures. Once associated, the ETL tool 216 can be automatically generated and the physical data table 218 can be populated. As soon as the physical data table 218 of the operational data store 206 is populated, the business intelligence tool 134 does not require additional normalization steps and creates a dimension table with extraction, transformation and loading operations between each step. Without populating, the schema definition language 126 can be utilized to filter, report, and execute data in the operational data store 206.

  It has further been discovered that a schema definition language 126 that provides a characteristic 222 having a predefined data type 410 allows automatic generation of the ETL tool 216, thereby significantly reducing implementation costs and timelines.

  The information delivery block 210 is connected to a management engine 208 for referencing the schema definition language 126 so that the business intelligence tool 134 can operate effectively to give the user an intuitive experience. The management engine 208 can further include a filter 128 and a report data definition 130. Filter 128 may be a one-dimensional filter used to generate a class of entity 404 based on observation 408 of the characteristics of entity 404. The filter is described in detail below with reference to FIGS. The report data definition 130 includes the entity type 220, module type 224, and characteristic 222 that are required and desired for the report and that will be utilized to retrieve the data 203 from the operational data store 206. Can be a set. The report data definition 130 is described in detail below with reference to FIGS.

  Referring now to FIG. 3, there is shown an exemplary metadata table 300 according to an embodiment of the present invention. The metadata table 300 represents the schema definition language 126 of FIG. The schema definition language 126 can be used as metadata 302 for explaining the data 203 of the physical data table 218 of FIG. A plurality of relationship links 304 can be provided between the metadata tables 300. The metadata table 300 can have an entity type table 306 linked to the characteristics table 308. The entity type table 306 and the characteristic table 308 can be linked to the module type table 310.

  The entity type table 306, the characteristic table 308, and the module type table 310 can be associated with the entity type 220, the characteristic 222, and the module type 224 of FIG. The metadata table 300 may include the entity 404, module 406, and property observation 408 of FIG. 4 as rows in the entity type table 306, module type table 310, and property table 308, respectively.

  The metadata table 300 includes metadata 302 that maps the physical data table 218 with a semantic representation. As an example, the characteristics table 308 may include corresponding rows of the characteristics observation 408. As an example, the ICD 9 selection is a property observation 408 that can be included as a row in the property table 308. The ICD 9 selection of the property table 308 can include a pointer or reference to the module 404 and / or to the entity 404 that can be associated with the property observation 408. For example, the observation 408 of the characteristics of the ICD 9 may point to the diagnostic module 406 and the patient entity 404.

  Since the metadata table 300 includes a semantic representation or a map of the structure of the physical data table 218, the metadata table 300 can be used to locate the data 203 contained within the physical data table 218. The metadata table 300 is also used to specify the relationship link 304 between the data 203 of the physical data table 218.

  The relationship between the module type table 306, the entity type table 306, and the property table 308 shows the relationship between the entity type 220, the property 222, and the module type 224 that have already been described in detail with reference to FIG.

  The relationship link 304 between the metadata tables 300 is a map of how the data 203 will eventually be organized in the physical table 218 of the operational data store 206 of FIG. Relationship link 304 is a pictorial representation of a characteristic observation 408 that points to or references module 406, entity 404, or other data or metadata structure.

  The relationship link 304 of the schema definition language 126 provides a relationship structure for the physical table 218 that will eventually hold the data 203. The schema definition language 126 gives a map for specifying the position of the physical table 218 and the relationship between the physical tables.

  As an example, the business intelligence tool 134 of FIG. 1 refers to the schema definition language 126 to locate the characteristic observation 408 and how the characteristic observation 408 is linked to the entity 404 and the module 406. , The user selects the characteristic observation 408 for filtering the entity 404 or module 406. Once the module 406 and the entity 404 linked to the property observation 408 are identified by the metadata table 300, the other feature observation 408 is transferred to the same module 406 or entity 404 as the user selected feature observation 408. Belongs.

  By providing the property observation 408 relationship for the entity 404 and the module 406, the management engine 208 of FIG. 2 selects the other property observation 408 associated with the selected first property observation 408. Options can be given to the user or the user can be given the option of selecting another module 406. The management engine 208 can leverage the schema definition language 126 to return other characteristic observations 408 to the user from the same module 406 as a selection option for the user. In this way, the schema definition language 126 provides the user with relevant filters or reports based solely on the structure of the data 203 in the physical table 218 as required or included in the schema definition language 126. Can be utilized.

  The relationship link 304 between the metadata 300 indicates a many-to-one link 312. The entity type table 306 and the module type table 310 also include a recursive link 314 that enables a hierarchical relationship between the entities 404.

  Other tables can constitute a metadata table 300 that includes a data type table 316, a selection type table 318, a selection table 320, and an approval table 322. It is contemplated that the metadata table 300 can include more tables without departing from the present invention. As an example, the metadata table 300 may include a module type member table or a unit of measurement table. It is further understood that the tables can be combined or deleted without departing from the invention.

  Referring now to FIG. 4, there is shown an exemplary schema definition model 400 according to an embodiment of the present invention. The schema definition model 400 can apply the schema definition language 126 of FIG. 1 to a data context. Continuing with the healthcare example for illustrative purposes only, entity type 220, module type 224, and characteristic 222 are mapped to entity 404, module 406, and metadata 302 for characteristic observation 408. It was.

  The metadata 302 can be associated with the entity 404, the module 406, and the property observation 408 as well as the entity type 220, the module type 224, and the property 222. As shown through the illustrative examples below, the metadata 302 contained within the schema definition model 400 includes information about how the property observation 408 is linked to the entity 404 and the property observation 408. It can be defined how it is grouped with the module 406.

  As an illustrative example, entity 404 can be a patient, sample, experiment, or genetic variant. Entity 404 is shown as having an aged characteristic observation 408 grouped together. As an illustrative example, the observations 408 of characteristics grouped with the entity 404 identified as a patient include ID, date of birth, death date, gender, ethnicity, primary payer, and current living functioning status. Can do.

  Characteristic observation 408 grouped with module 406 is shown as aged characteristic observation 408. As an illustrative example, the characteristics grouped together with the module 406 having metadata 302 for irradiation include one additional dose, additional irradiation treatment modality, number of treatments, anatomical site to be irradiated, radiation dose , And a local dose. Module 406 can also include a pointer that is a foreign key to other modules 406, such as a pointer for treatment module 406 in module 406 corresponding to irradiation.

  Module 406 and entity 404 are not depicted as actual data 203 in FIG. 2 in schema definition model 400, but are shown as having metadata 302 instead. Characteristic observation 408 is also shown as having metadata 302 in the form of data type 410. The data type 410 can specify the type of data 203 that will eventually populate the physical table 218 of FIG.

  The data type 410 for the property observation 408 can specify integer data, real data, text data, long text data, date, date and time, selection data, module pointer data, and entity pointer data. By utilizing the metadata 302 of the data type 410, the ETL tool 216 of FIG. 2 is automatically generated by the management engine 208 of FIG. The generation of the ETL tool 216 will be described in detail below with reference to FIG.

  Due to the recursive relationship between the entity type table 306 and the module type table 310 of FIG. 3, the entity 404 and the module 406 can include sub-entities and sub-modules, respectively. A sub-entity can be an entity 404 that originates from a particular entity 404. A submodule can be a module 406 that originates from a particular module 406.

  Referring now to FIG. 5, there is shown an exemplary schema definition model table 500 according to an embodiment of the present invention. The schema definition model table 500 is shown in a simplified format for ease of explanation.

  The schema definition model table 500 is shown as having a plurality of rows and columns. Each row corresponds to a characteristic observation 408. The table cells are filled with metadata 302 instead of the actual data 203 that will populate the physical table 218 of the operational data store of FIG.

  Similar to FIG. 4, characteristic observation 408 can be linked with entity type 220 and module type 224. The entity type 220 can be represented by the first column and the module type 224 can be represented by the second column. Similarly, the row of characteristic observations 408 will pass through a column showing other features of characteristic observations 408. The characteristic observation 408 can be associated with: That is, display characteristic 502, sequence 504, characteristic name 506, data type 410, selection type 508, vertical indicator 510, target entity type 512, target module type 514, unit of measure 516, multiple selection indicators 518, and protection indicator 520 It is.

  The first column entity type 220 may be the entity 404 with which the property observation 408 is associated. Entity types 220 can include, for example, patients, samples, experiments, genetic variants, hospitals, or surgeons if they take advantage of previous healthcare field examples. The second column of entity types 224 may be a module 406 with which a characteristic observation 408 is associated. Module type 224 includes patient information (special module for including aged characteristics observation 408 for entity 404), cancer diagnosis, chemotherapy, drug therapy, irradiation, surgery, treatment, pathology and life. Functions, consent, sample information, experimental information, observation of genetic variants, etc. can be included.

  A third column of display characteristics 502 can indicate whether characteristic observation 408 should be displayed as a default ID characteristic for module 406. Display characteristic 502 may identify characteristic observation 408 as being a specified characteristic or an unspecified characteristic. An example of the identified characteristic associated with the patient information module of the patient entity may be a patient ID. An example of an identified characteristic associated with a patient entity diagnostic module may be an ICD9 value. An example of an unspecified characteristic associated with the patient information module of a patient entity may be a birthday because this characteristic would not be very useful as a default value to work with entity 404.

  The fourth column sequence 504 may indicate the order in which the observation of characteristics 408 can be displayed in the module 406. The characteristic name 506 in the fifth column can specify the characteristic by the name. As an example of a drug therapy module property name 506, the property observation 408 can be specified as a dosage, a dosing frequency, a drug name, a dosing order, a drug therapy treatment, or a drug therapy diagnosis. Each module type 224 may include a unique property name 506 corresponding to the data 203 that is mapped to the property observation 408 in the physical table 218.

  The data type 410 in the sixth column may indicate the type of data for which the characteristic observation 408 will be stored. Characteristic observation 408 can identify integer data, real data, text data, long text data, date data, date / time data, selection data, module pointers, and entity pointers.

  The selection type 508 in the seventh column will be used if the data type 410 corresponds to the selection data. Selection type 508 can be a list of all valid selections for observation 408 of the characteristics associated with the selection data. Examples of selection type 508 can include yes / no and male / female. Selection type 508 may also include a long one such as a list of potential chemotherapy types for a treatment or chemotherapy module. This type of selection type 508 may be a list that includes: That is, mechloretamine hydrochloride, cyclophosphamide, chlorambucil, melphalan, ifosfamide, thiotepa, hexamethylmelamine, altamine, procarbazine hydrochloride, dacarbazine, temozolomide, carmustine, lomustine, streptozocin, carboplatin, cisplatin, oxaliplatin, etc. .

  The eighth column vertical indicator 510 may indicate how the characteristic observation 408 will be stored in the physical table 218 of the operational data store 206. If the vertical indicator 510 is “N” indicating that the property observation 408 is not stored vertically, the property observation 408 is stored in a column in the table representing the module 406 with which the property is associated. Will be. If vertical indicator 510 is “Y” indicating that characteristic observations 408 are stored vertically, characteristic observations 408, each having a separate row, will be stored in separate tables.

  The target entity type 512 in the ninth column is used if the data type 410 is an entity pointer. The target entity type 512 can be used to indicate the entity type 220 referenced by the module 406 with which the property observation 408 is associated. As an example, one of the observations 408 of characteristics corresponding to the entity pointer and associated with the cancer diagnostic module refers to the “sample” entity type 220 if the cancer diagnosis is the result of a biopsy. May be.

  The target module type 514 in the tenth column is used if the data type 410 is a module pointer. The target module type 514 can be used to indicate the module type 224 referenced by the module 406 with which the property observation 408 is associated. As an example, one of the observations 408 of the characteristics corresponding to the module pointer and associated with the irradiation module may refer to the “treatment” module type 224.

  The measurement unit 516 in the eleventh column can be used to indicate the unit of measurement for the observation 408 of the characteristic when it is a number. As an example, the unit of measure 516 can be pounds or kilograms.

  The twelfth column multi-select indicator 518 can be leveraged when the data type 410 is a selection that indicates whether the user can select multiple or only one. As an example, if multiple selection indicator 518 is “N”, only one selection is valid, and if multiple selection indicator 518 is “Y”, multiple selections are valid.

  The protection indicator 520 in the thirteenth column can indicate whether the characteristic indicates sensitive information. For example, if the protection indicator 520 is “N”, this characteristic may contain information identifying the patient and should be handled differently.

  The schema definition model table 500 will be used to generate the physical table 218 of the operational data store 206. Each module 406 becomes a separate table in the operational data store 206. Each characteristic observation 408 is a column in the table of module 406 to which they are associated. Data 203 will occupy a cell in the physical table 218.

  Referring now to FIG. 6, there is shown an exemplary physical table 218 according to an embodiment of the present invention. The physical table 218 can be the physical table 218 of the operational data store 206 of FIG.

  As described below, the physical table 218 can be generated by referring to the metadata 302 of FIG. The metadata 302 is included alone in the schema definition language 126 of FIG. 1 or represented in the metadata table 300 of FIG. 3, the schema definition model 400 of FIG. 4, and the metadata 302 of FIG. It is included as a combination with the schema definition model table 500. The physical table 218 may include a table for the modules 406 and entities 404 having links to each other in FIG. 4 based on at least one of the property observations 408 in FIG.

  Continuing with the health care example already described and utilizing the schema definition language 126, the physical table 218 is shown as corresponding to the module 406 defined in the module type 224 column or the second column of the schema definition model table 500. It is. Each module 406 defined in the schema definition model table 500 has its own physical table 602 that is created in the complete list of physical tables 218.

  The physical table 218 can have a table title 604 and then a list of column names 606. A column name 606 is an observation 408 of characteristics included in the row of the schema definition model table 500. Further, when the property observations 408 of the schema definition model table 500 are module pointers or entity pointers, these property observations 408 are depicted in the physical table 218 as links 608. In general, link 608 can include a one-to-one relationship or a many-to-one relationship.

  For example, the entity table 610 can have a one-to-one relationship with the ODS_PatientInfo table 612. This means that the entity table 610 includes one foreign key indicating the ODS_PatientInfo table 612 for each entity. Similarly, the ODS_PatientInfo table 612 includes a foreign key that points to the entity table 610.

  The physical table 218 can further include many-to-one links. For example, the ODS_PatientInfo table 612 can include a number of foreign keys from the multiple ODS_Mediation tables 614, but each ODS_Mediation table 614 will only include a single foreign key for the ODS_PatientInfo table 612.

  Another solution expressed by utilizing the schema definition language 126 is provided by the flag of the vertical indicator 510. Typically, when the vertical indicator 510 flag is negative or “N”, each characteristic observation 408 in the schema definition model table 500 is a column in the physical data table 218. This is illustrated by the ODS_LabsVitals table 616. However, when there are very many characteristic observations 408, the vertical indicator 510 can be set to positive or “Y”. When vertical indicator 510 is positive, characteristic observation 408 should not be configured as a column in physical data table 218, but should be occupied as a row in another table described as ODS_LabsVitals_Vertical table 618. As an example, observations 408 of characteristics such as white blood cell count and red blood cell count may occupy the ODS_LabsVitals_Vertical table 618 along with many other characteristics.

  Similar to the data requirements for the flowcharts of FIGS. 7, 8, 9, 11, 13, and 15, the data requirements described with respect to FIGS. 1-6 are anchored to non-transitory computer readable media. Can be saved. These data requirements cannot be accessed or changed without hardware utilization and implementation, and changes in data values represent physical and non-temporary conversions of hardware records in bit form. Can do.

  Having described the data requirements for implementation and use of the operational data store 206 of FIG. 2, the process for implementing and using the operational data store 206 will now be described. In the flowcharts described with respect to FIGS. 7, 8, 9, 11, 13, and 15, the process steps for implementation and utilization of operational data store 206 are implemented in hardware, software, firmware, or a combination thereof. Can. Furthermore, the step boundaries are generally diverse, and the functions may be performed together or separately in different embodiments.

  Referring now to FIG. 7, there is shown an exemplary control flow 700 for implementing and populating an operational data store according to an embodiment of the present invention. As an example, the operational data store 206 of FIG. 2 may be similarly implemented and populated.

  The control flow 700 includes a schema definition language providing step 702. The provide schema definition language step 702 can be invoked to provide the schema definition language 126. By providing a schema definition language 126, designers can take advantage of data and metadata structures.

  Following the schema definition language providing step 702 is a schema definition modeling step 704. During the schema definition modeling step 704, the designer leverages the schema definition language 126 to define the schema definition model 400 using data elements contained in existing files, existing operational data stores, or existing databases. Will be. The schema definition language 126 is actually implemented by the designer by utilizing the metadata and data structures detailed above with respect to FIGS.

  The schema definition modeling step 704 can continue to the schema definition model acquisition step 706. During the schema definition model acquisition step 706, the schema definition model 400 is acquired in the schema definition model table 500 that provides each row of observations 408 of each characteristic and attaches or associates them to the entity 404 and module 406 of FIG. Can. The schema definition model acquisition step 706 may be skipped, and the schema definition language 126 may be used in place of the schema definition model table 500 for referencing the metadata 302 and executing a query. The schema definition language 126 can be used as the metadata table 300 of FIG. 3, the schema definition model 400, or a combination thereof.

  The schema definition model acquisition step 706 can continue to an operational data store (ODS) generation step 708. The ODS generation step 708 includes generating the physical table 218 of the operational data store 206 from the schema definition language 126 contained within the schema definition model table 500 and creating the link 608 of FIG. 6 therebetween.

  In particular, during the ODS generation step 708, one of the physical tables 218 is first generated for each module 406. If the vertical indicator 510 of the schema definition model table 500 is “N”, then a column is created in the physical table 602 of FIG. 6 for the module 406 associated with the property observation 408. When this column is created for a characteristic observation 408, the data type 410 indicator of FIG. 5 identifies the type of data that this column will contain.

  During the ODS generation step 708, a foreign key will be generated for the observation 408 of the selection characteristics of the data type 410 to reference the selection table. Similarly, during the ODS generation step 708, a foreign key will be generated for the observation 408 of characteristics that include an indicator in the target entity type 512 or that includes the target module type 514 of the schema definition model table 500. If the target entity type 512 includes an indicator, a foreign key referring to the entity table 610 of FIG. 6 will be generated. On the other hand, if the target module type 514 includes an indicator, a foreign key referring to one of the module tables will be created.

  If the vertical indicator 510 of the schema definition model table 500 is “Y”, then no column is generated for the observation of characteristics 408. Instead, the type of characteristic observation 408 will be loaded into the module 406 associated with the vertical table having one characteristic observation 408 per row. Finally, a characteristic observation 408 corresponding to an aging time stamp will be associated with the physical table 218 of the module 406.

  ODS generation step 708 continues to ETL generation step 710. When the physical table 218 of the ODS generation step 708 is completed once along the schema definition model table 500 completed in the schema definition model acquisition step 706, the ETL tool 216 executes the schema definition model table 500 and the schema definition language 126. And can be automatically generated based on The generation of the ETL tool 216 will be described in detail below with reference to FIG.

  The ETL generation step 710 continues to the ODS population step 712. When the ETL tool 216 is automatically generated once based on the schema definition model table 500 and the schema definition language 126 and the physical table 218 is created once, the ETL tool 216 is utilized in the ODS population step 712. The data 203 is extracted from the external source 204 of FIG. 2, and the data 203 of FIG. Once the data 203 conforms to the requirements of the schema definition model table 500 and the schema definition language 126, the data 203 is loaded into the physical table 218 of the operational data store 206.

  When referring to or using an element including the schema definition language 126, the schema definition model 400, or the schema definition model table 500 in the flowcharts of FIGS. It is contemplated that several combinations can be referenced and utilized in place of or in conjunction with the named element. For ease of explanation, the schema definition model table 500 is generally used as an example for reference to a flowchart.

  Referring now to FIG. 8, there is shown an exemplary control flow 800 for generating an extract, transform, and load function according to an embodiment of the present invention. The control flow 800 illustrates an exemplary method for automatically generating the ETL tool 216 of FIG. 2 by referring to the schema definition language 126 of FIG. The schema definition language 126 can be referenced with respect to the metadata 302 included in the metadata table 300 of FIG. 3, the schema definition model 400 of FIG. 4, the schema definition model table 500 of FIG. 5, or a combination thereof. As described below, the physical table 218 of FIG. 2 can be populated with the data 203 of FIG. 2 by automatically generating the ETL tool 216 in accordance with the metadata 302.

  In general, the data 203 from the external source 204 of FIG. 2 flows through the non-compliant staging table 802 and the compliant staging table 804 before being finally stored in the operational data store 206 of FIG. The management engine 208 of FIG. 2 can automatically generate a non-compliant staging table 802 and a compliant staging table 804 from the schema definition language 126.

  Data 203, which is unclean source data, must first be analyzed and scrubbed in non-compliant staging table 802 before moving to compliant staging table 804. An adapter and API can be provided to parse the data 203 and drive out records where syntax validation failed. Clean data 203 can flow directly to the compliant staging table 804. Table and database level verification may be performed in the compliant staging table 804.

  The routine of ETL tool 216, which moves data from non-compliant staging table 802 and compliant staging table 804 to operational data store 206, can be generated automatically. This process is described in detail below with respect to steps 806-824.

  Initially, a retrieve step 806 can retrieve the data 203 as non-compliant source data. This can be a flat file format, but the data may be in any usable format. As a flat file, the data 203 can be a text string type of the data 203. The source data can include data 203 corresponding to entity 404 and module 406 of FIG. As an example, the source data in the non-compliant staging table 802 can include a patient information flat file, which allows a special module type to hold non-aged data for the entity 404 and entity type 220 of FIG. Can respond.

  The non-compliant staging table 802 may further include a module table corresponding to the module 406 and the module type 224 of FIG. As an example, the non-compliant staging table 802 can include flat files for cancer diagnosis corresponding to the diagnostic module type 224 and the cancer diagnosis module 406.

  Data 203 in non-compliant staging table 802 corresponding to module 406 may include a foreign key that points to the associated entity 404. On the other hand, the data 203 in the non-compliant staging table 802 corresponding to the entity 404 is the key as the main key of the entity 404, similar to the module 406 created specifically to hold the non-aged data of the entity 404. A key (such as a patient ID) can be included.

  Retrieve step 806 continues to process step 808. Process step 808 collects and / or organizes the metadata 302 of the schema definition language 126 into a selection type compliant stage table 810 and a selection compliant stage table 812. Each observed selection available from the schema definition language 126 can be placed in a selection type compliant stage table 810 and given a primary key, a selection type ID such as gender, ethnicity, ICD9, etc. Can.

  The selection compliant stage table 812 can include the foreign keys of the selection type compliant stage table 810 and a primary key for each available selection. The selection may include male, female, Caucasian, Hispanic, Asian, 173.0-malignant ... 174.4-paget or 174.6-malignant neoplasm. The last update date can also be included in the selection type compliant stage table 810 and the selection compliant stage table 812. When performing an incremental load, available selections from the operational data store 206 are possible.

  Following the process step 808 is a compliant load step 814. The compliance load step 814 can include a compliance staging table 804. The definitions contained in the metadata 302 of the schema definition language 126 for the module 406 and the property observation 408 of FIG. 4 stored in the metadata table 300, schema definition model table 500, or schema definition model 400 are data Can be used to specify how should be loaded into the compliant staging table 804. For example, the metadata 302 may require that the data type 410 of FIG. 4 is a date. In that case, the data 203 extracted from the non-compliant staging table 802 should be in date format when it is loaded into the compliant staging table 804.

  Entities 404 included in the non-compliant staging table 802 can be loaded into the compliant staging table 804. Each column of the compliant staging table 804 can include a single instance of the entity 404. Each entity 404 is given a primary key of the compliant staging table. Entity 404 is a sub-entity of the entity but will be loaded and given a pointer to the parent entity. For example, the patient may have a sample extracted therefrom. The sample is considered a sub-entity and has a pointer back to the patient. The pointer can be the primary key of the patient's compliance staging table. The entity 404 itself, not the aged data 203, is first loaded into the compliant staging table 804.

  Once the entity 404 is loaded into the compliant staging table 804, the data 203 associated with the module 406 can be loaded into the compliant staging table 804. In compliant load step 814, the non-compliant staging table 802 is opened and analyzed.

  Each row of the non-compliant staging table 802 is processed, and the compliant load step 814 converts the value of the data 203 to the target data type 410 to ensure that the non-zero characteristic observation 408 has a characteristic value. Demonstrate valid limitations for observation 408. When the limitations on the property observation 408 are proven, the limits on the range of values for the date and number property observation 408 are proven, and the valid characters and the effective length of the text property observation 408 are proven. And a valid reference to entity 404 is proved. Proof of validity of references to other modules 406 is made during the second pass.

  An error during the compliance load step 814 results in a record associated with one of the modules 406 that will be placed in the error table 816. The main key of the unique compliant staging table is assigned to each row that has been successfully processed. The compliant staging table 804 may include a first row that indicates primary and foreign keys, a second row that indicates the column data type 410, and a third row that indicates the column name of the compliant staging table 804. The compliant staging table 804 reflects the operational data store 206 with the exception of characteristic observations 408 that reference other modules 406.

  Continuing with the flat file example described above, the text value of the flat file can be converted to the appropriate data type 410. The reference to entity 404 is then replaced with the primary key of the compliant staging table.

  If a record fails the validity check of the compliance load step 814, this record can be placed in the error table 816. For example, if a record that includes aged data 203 for entity 404 includes an inappropriate birthday, this record can be placed in error table 816. Further, when the data corresponds to a module that references entity 404 in error table 816, the record for this module 406 is also placed in error table 816.

  Once the module 406 has been loaded into the compliance staging table 804 in the compliance load step 814, the references between the modules 406 can be updated in the update step 818. Update step 818 continues from compliance loading step 814, but ensures proper dependency of module 406 by including references only after all modules 406 have been loaded into compliance staging table 804.

  The update step 818 can create two preliminary columns for each observation 408 of each property that references other modules 406 in the staging table 804. These two reserved columns can contain the name of the referenced module as well as the foreign key of the referenced module. As an example, the procedure refers to a diagnosis, and the characteristic observation 408 will include an additional column that deals with the diagnosis and diagnostic foreign keys.

  The column containing the foreign key of the referenced module can contain the primary key of the compliant staging table of the referenced module 406. At this point, in the case of the observation 408 where the reference destination is invalid or missing, the module 406 in the error table 816 is deleted and placed in the error table 816. Update step 818 can include adapters, and at this point in the process, installation can perform their own custom verification.

  Following the update step 818 is an operational data store load step 820. After the update step 818, the compliant staging table 804 can include verified data. The operational data store load step 820 generates a SQL server merge statement for each compliant staging table 804. The operational data store load step 820 can generate an SQL server merge statement for the selection type compliant stage table 810, then the selection compliant stage table 812, then the compliant staging table 804 including the entity 404, and then the entity 404 non- SQL server merge statements for the compliant staging table 804 containing the aged data 203 and finally the compliant staging table 804 of the other module 406 can be generated.

  Since all data 203 in the compliant staging table 804 has been verified, only environmental issues can cause merge failures. Environmental issues can include issues such as insufficient disk space. If the merge fails, the operational data store load step 820 is aborted with an error recorded.

  Following the operational data store load step 820 is a delete step 822. The delete step 822 loads the delete flag into the compliant staging table 804 and ODS during incremental load applied during incremental load to the operational data store 206. The delete step 822 verifies that the record to be deleted does not exist in the operational data store 206. If the record to be deleted does not exist in the operational data store 206, this record is sent to the error table 816. Once the load is complete, delete step 822 deletes records that have a cascade delete flag to ensure referential integrity.

  Following the delete step 822 is a truncate step 824. Truncate step 824 may truncate all compliant staging tables 804 to prepare for subsequent incremental loads when the load is successful. Once the data 203 has been loaded into the operational data store 206, the user can fully utilize and access the data 203 using the business intelligence tool 134 of FIG. 1 described in detail below with respect to FIGS. can do.

  Referring now to FIG. 9, there is shown an exemplary control flow 900 for filtering a cohort according to an embodiment of the present invention. The example control flow 900 can be an illustrative diagram of how the filter 128 of FIG. 1 operates on the schema definition language 126 of FIG. The metadata 302 of the schema definition language 126 can be referenced from the metadata table 300 of FIG. 3, the schema definition model table 500 of FIG. 5, the schema definition model 400 of FIG. 4, or a combination thereof.

  As an example, as soon as the operational data store 206 of FIG. 2 is populated, in the ODS Population step 712, the business intelligence tools 134 of FIG. 1 are fully functional as they operate against the schema definition language 126. . When the operational data store 206 is populated, the total cohort 902 becomes available. The total cohort 902 can include all of the entities 404 of FIG. 4 represented in the operational data store 206.

  The total cohort 902 can be a starting point for filtering the operational data store 206. The entities 404 of the total cohort 902 can be filtered using any of the property observations 408 of FIG. The property observation 408 in the schema definition language 126 can be identified by the metadata 302 of FIG. 3 associated with the property observation 408.

  In a property selection step 904, this continues from the ODS population step 712, but the user can select the selected property 905. The selected characteristic 905 can be one of the characteristic observations 408. As an extension of the utilized health care example, the user may want to identify the patient class of entity 404 with an ICD9 diagnosis for breast cancer.

  The business intelligence tool 134 returns from the schema definition language 126 an observation 408 of all properties, such as a valid ICD 9 selection. The user selects one of the characteristic observations 408, such as selecting an ICD9 characteristic as the selected characteristic 905 and filtering the selected characteristic 905 for only the ICD9 code corresponding to breast cancer, The selected characteristic 905 can be further filtered.

  After the user selects the selected characteristic 905 for filtering the total cohort 902, the business intelligence tool 134 selects the schema definition language 126 for the module 406 of FIG. 4 and the characteristic selected in the metadata query step 906. A query can be performed on the entity 404 associated with 905. The query in the schema definition language 126 can return metadata 302 for the module 406, the entity 404, and other property observations 408 associated with the selected property 905. Further, the module 406 and entity 404 associated with the selected characteristic 905 can be identified in the physical data table 218 of FIG. The business intelligence tool 134 can further return the entity type 220 and module type 224 of FIG. 2 associated with the selected characteristic 905.

  After the query is performed against the schema definition language 126, a property association step 908 that follows the metadata query step 906 returns the module 406 and the entity 404 from the schema definition language 126 associated with the selected property 905. Can do. When the selected characteristic 905 is only associated with the entity 404, no module 406 is associated with the selected characteristic 905 and only the entity 404 is returned.

  With the return of the entity 404 and module 406 associated with the selected property 905, the calculation step 910 following the property association step 908 can calculate the current cohort 912 and all one-hop linkages 914. When the calculation step 910 calculates the current cohort 912, the schema definition language 126 may be used to locate the physical table 218 of the operational data store 206 corresponding to a patient having the selected characteristic 905. it can.

  A query is generated based on the metadata 302 of the schema definition language 126 to extract the data 203 of FIG. 2 of the entity 404 associated with the selected property 905. The calculation step 910 queries the physical table 218 and locates the selected property 905 by locating the link 608 and the property observation 408, module 406, and the physical table 602 of FIG. An SQL instruction 915 can be automatically generated to return the associated current cohort 912. The schema definition language 126 can be referred to as a metadata table 300 that can be used to detect multiple columns for each physical data table 218 where the data 203 is physically located.

  The business intelligence tool 134 can return the current cohort 912 as the number of entities 404 associated with the selected characteristic 905. The calculation step 910 may calculate one-hop linkages 914 and present them as options for the user to further refine the filter 128.

  The one-hop linkage 914 can be an observation 408 of other unselected properties corresponding to the entity 404 and a module 406 to which the selected property 905 corresponds. That is, the one-hop linkage 914 is a property that has not been selected from the same module 406 and entity 404 with which the selected property observation 408 is associated. Depending on the calculation of the unselected property, the calculation step 910 can also return the module 406 and the entity 404 as a one-hop linkage 914. The module 406 and entity 404 associated with the selected property 905 are pointed to by the unassociated module 406 or entity 404, and these unassociated module 406 or entity 404 are returned as a one-hop linkage 914. be able to. That is, when the subject entity type 512 of FIG. 5 or the subject module type 514 of FIG. 5 of any property observation 408 includes a data pointer that points to the module 406 or entity 404 associated with the selected property 905, The module 406 and entity 404 associated with the trait observation 408 having that data pointer will be returned as a one-hop linkage 914.

  Taking the example of filtering based on breast cancer and describing the calculation of the one-hop linkage 914, the calculation step 910 associates with the observation 408 of age, gender, weight, and other aged characteristics corresponding to the entity 404. The one-hop linkage 914 for the given entity 404 can be calculated. The calculation step 910 further includes the one-hop linkage 914 of the module 406 associated with the selected characteristic 905, such as the observation date 408 corresponding to the module 406, the date of diagnosis, age at diagnosis, primary site, and other aged characteristics. Can also be calculated.

  The calculation step 910 can also return the one-hop linkage 914 of other modules 406 or entities 404 that are not associated with the selected property 905. For example, if characteristic observation 408 is selected by a user that includes ICD9 for breast cancer, the ICD9 characteristic corresponds to a diagnostic module, and calculation step 910 can return the user with the option to filter by treatment. . This is because the treatment module has a pointer in the target module type 514 to the diagnostic module.

  Following the calculation step 910 is another property selection option 916. If the user decides not to select more property observations 408, another property selection option 916 terminates the operation of filter 128 in an end step 918. When the end step 918 is invoked, the current cohort 912 can continue to be utilized and saved for further use with the business intelligence tool 134.

  When the user decides to select another characteristic in other characteristic selection option 916, the subsequent selected characteristic 919 is selected in other characteristic selection step 920 following other characteristic selection option 916. Can do. The user can select subsequent selected characteristics 919 in the same manner that the user selected the selected characteristics 905 in the selected characteristics step 904.

  The difference in user experience in other property selection step 920 as opposed to property selection step 904 is that in other property selection step 920 the user is given a one-hop linkage 914 as a selection option, and in total cohort 902 The current cohort 912 is displayed.

  Once the user has selected the subsequent selected characteristic 919, the subsequent selected characteristic 919 can be linked to the characteristic 905 selected in the characteristic link step 922 following the other characteristic selection step 920. . A characteristic linking step 922 can link the selected characteristic 905 to a subsequent selected characteristic 919 to refine the filter 128 and limit the current cohort 912. Although the subsequent selected property 919 is assumed to limit the current entity 404 or module 406 of the filter 128, the user may prefer this logical AND operation and observe the subsequent property 408. It is considered that the logical OR function of

  As an illustrative example, the user may select one of the one-hop linkages 914 corresponding to the entity 404 associated with the selected characteristic 905, such as age 35-40 or male. Continuing with the ICD9 breast cancer example, the trait link step 922 is followed by a first selected ICD9 trait (selected trait 905) followed by an observation of the selected age or gender trait 408 (subsequent selected trait). 919). The characteristic linking step 922 will combine both the selected characteristic 905 and the subsequent selected characteristic 919 to further refine the filter 128 only for breast cancer in patients who were male at 35-40 years of age.

  As a second illustrative example, the user may select one of the one-hop linkages 914 corresponding to the module 406 associated with the selected characteristic 905, such as the diagnosis date 2007. Continuing with the ICD9 breast cancer example, characteristic linking step 922 links the first selected ICD9 characteristic (selected characteristic 905) with the selected date characteristic (following selected characteristic 919). right. The characteristic link step 922 will refine both the selected characteristic 905 and the subsequent selected characteristic 919 to refine the filter 128 for the 2007 breast cancer diagnosis only.

  As a third illustrative example, the user may select one of the one-hop linkages 914 corresponding to the linkage 608 to the observation 408 of the property associated with the selected property 905 such as module 406 or treatment type: surgery. One may be selected. Continuing with the ICD9 breast cancer example, characteristic linking step 922 will link the selected ICD9 characteristic (selected characteristic 905) with the subsequently selected pointer characteristic (subsequent selected characteristic 919). The characteristic link step 922 will further refine the filter 128 only for breast cancer diagnoses that have been surgically treated, combining both the selected characteristic 905 and the subsequent selected characteristic 919.

  The property link step 922 continues to the metadata query step 906. Once the user selects a subsequent selected characteristic 919 and the selected characteristic 905 and the subsequent selected characteristic 919 are linked in the characteristic linking step 922, the metadata query step 906 includes the method described above. A query is executed for the schema definition language 126 in the same manner.

  Once the query is performed for the schema definition language 126 in the metadata query step 906, the property association step 908 operates except that all selected properties 905 are used like a logical AND function. It can operate in a manner similar to that described above. Similarly, the calculation step 910 can calculate the one-hop linkage 914 of the subsequent selected characteristic 919 in a manner similar to that described above, and the physical table of the operational data store 206 in a manner similar to that described above. The current cohort 912 can be returned by leveraging the schema definition language 126 for executing queries on 218.

  Referring now to FIG. 10, there is shown a screen shot 1000 of the filter 128 as implemented in the business intelligence tool 126. Screenshot 1000 depicts an example of a selected characteristic 905 that is linked to a subsequent selected characteristic 919. A subsequent selected characteristic 919 can be linked to the selected characteristic 905 as a second characteristic observation 408 for filtering the total cohort 902. This link can represent a logical AND condition, but the user may toggle the link icon to invoke the logical OR filtering of the total cohort 902.

  Total cohort 902 is shown as the starting cohort of filter 128. Selected characteristic 905 is shown to be an ICD9 value filtered for breast cancer. The selected characteristic 905 is contextually linked to a subsequent selected characteristic 919.

  A subsequent selected characteristic 919 is shown to be a diagnostic date that is filtered to return a date between January 1, 2010 and January 1, 2013. The current cohort 912 is depicted as a group of entities 404 with the number of entities 404 in the current cohort 912.

  Referring now to FIG. 11, there is shown an exemplary control flow 1100 for cohort filtering that utilizes patterns according to embodiments of the present invention. The example control flow 1100 may be another or further example illustration of how the filter 128 of FIG. 1 operates on the schema definition language 126 of FIG. The metadata 302 of the schema definition language 126 can be referenced from the metadata table 300 of FIG. 3, the schema definition model table 500 of FIG. 5, the schema definition model 400 of FIG. 4, or a combination thereof.

  This identifies entities 404 of FIG. 4 and scans the operational data store 206 of FIG. 2 to match entities 404 that match a particular series of characteristic observations 408 of FIG. 4 corresponding to clinical events. Represents yet another way to find. The user is selected to define a clinical pattern to utilize the business intelligence tool 134 of FIG. 1 and to identify entities 404 that match the clinical pattern and entities 404 that do not match the clinical pattern. The characteristic observation 408 can be selected as the characteristic 905.

  When populated in the operational data store 206, the total cohort 902 of FIG. 9 becomes available. The total cohort 902 can include all of the entities 404 represented in the operational data store 206. The control flow 1100 can operate from the total cohort 902 calculated in the calculation step 910 or the current cohort 912. In this illustrative example, the calculation step 910 providing the current cohort 912 is used to further refine the filter 128 by using a control flow 1100 to filter the current cohort 912 based on the pattern. Will be.

  Following the calculation step 910 is a property selection step 1102 in which the property observation 408 can be selected as the selected property 905. User-selectable property observations 408 include one-hop linkage 914, but may also include unrelated property observations 408. Once the user has selected the selected characteristic 905, the business intelligence tool 134 will feed back this characteristic and the current cohort 912 in the characteristic display module 1104 following the characteristic selection step 1102. The user then has the option to select another characteristic in option selection 1106 that follows from the characteristic display module 1104. If the user wants to select more property observations 408, option selection 1106 will take the user to property selection step 1102, which allows the user to select a subsequent property. In this way, the user can select a characteristic observation 408 corresponding to a clinical event and define a pattern that restricts the filter 128.

  Continuing with the example of the above utilized healthcare field, assume that the user wishes to identify a patient who has undergone an appendectomy who has been readmitted within 30 days of discharge. The user can select an observation 408 of characteristics about the appendectomy, and the business intelligence tool 134 can detect all entities 404 that have undergone an appendectomy utilizing the control flow of FIG. Once all the entities 404 associated with the characteristic observation 408 for appendectomy have been identified in the current cohort 912, the user can create a new clinical pattern that begins in the characteristic selection step 1102. The user can select a trait observation 408 for discharge following a trait observation 408 for hospitalization. Characteristic observation 408 for hospitalization can be limited by characteristic observation 408 indicating hospitalization that occurred within 30 days after discharge. An example of this clinical pattern would involve selecting two trait observations 408 (discharge and hospitalization) that would lead to selecting a limit for one-hop linkage 914 that was separated by up to 30 days. As described above, the one-hop linkage 914 is an observation 408 of unselected selection characteristics belonging to the same module 406 or entity 404 of FIG. 4 associated with the selected characteristics 905.

  The user saves the pattern named “re-hospitalization within 30 days of appendectomy”.

  When the user has defined a clinical pattern by selecting a characteristic observation 408 corresponding to the clinical pattern, the user can save the clinical pattern and select a match calculation step 1108. The match calculation step 1108 proceeds to a metadata query step 1110 that references the schema definition language 126 to identify the link 608 of FIG. 6 and the location of the physical table 218 of FIG. 2 that includes the selected property 905. It continues with.

  The metadata query step 1110 continues to the SQL generation step 1112. The SQL generation step 1112 can utilize the relationship and position of the physical table 218 returned from the schema definition language 126 in the metadata query step 1110, and execute a query against the physical table 218 of the operational data store 206. The SQL instruction 1114 is automatically generated.

  The SQL execution step 1116 continues to the SQL generation step 1112, but is automatically generated from the SQL generation step 1112 for executing a query against the physical table 218 of the operational data store 206. Following the SQL execution step 1116 is a return step 1118. A return step 1118 can return the matching cohort 1120 and the non-matching cohort 1122.

  The matching cohort 1120 can be the entity 404 corresponding to the characteristic 905 selected as the clinical pattern. The discrepancy cohort 1122 may be an entity 404 that does not correspond to the characteristic 905 selected as the clinical pattern.

  Matching cohort 1120 and mismatching cohort 1122 are saved for later processing or to be further restricted by business intelligence tool 134. When return step 1118 returns match cohort 1120, the user can view details of entity 404 in match cohort 1120. For example, the user can view the ID when something that matches the clinical pattern defined by characteristic 905 occurs.

  Referring now to FIG. 12, there is shown a screenshot 1200 of the filter 128 of FIG. 1 as implemented in the business intelligence tool 126 of FIG. Screen shot 1200 depicts an example of characteristic observation 408. Characteristic observation 408 can be displayed for selection by the user in selection box 1202.

  An observation 408 of a user-selected property can be shown in the pattern box 1204. Selected characteristics 905 along with subsequent selected characteristics 919 can be shown linked together in pattern box 1204. The selected characteristic 905 can be, for example, a filtered procedure or procedure for appendectomy.

  The first subsequent selected characteristic 1206 can be, for example, discharge. The second subsequent selected characteristic 1208 can be, for example, readmission. A pattern filter 1210 may be included to limit the return of the first subsequent selected characteristic 1206 and the second subsequent selected characteristic 1208 within 30 days from each instance of the characteristic observation 408. it can. In other words, the pattern filter 1210 may limit the returned entities 404 of FIG. 4 to those entities 404 that have undergone appendectomy and have been readmitted within 30 days of discharge.

  Referring now to FIG. 13, there is shown an exemplary control flow 1300 for generating a report according to an embodiment of the present invention. The example control flow 1300 may be an example description of how the report data definition 130 of FIG. 2 operates on the schema definition language 126 of FIG. The metadata 302 of the schema definition language 126 can be referenced from the metadata table 300 of FIG. 3, the schema definition model table 500 of FIG. 5, the schema definition model 400 of FIG. 4, or a combination thereof.

  Once the operational data store 206 of FIG. 2 has been populated, the user can report on any of the entities 404 of FIG. 4 in the operational data store 206. The user can define the returned report data. The business intelligence tool 134 of FIG. 1 leverages the metadata 302 of the schema definition language 126 to build the report data definition 130 defined in terms of the entity 404, module 406, and property observation 408 of FIG. The business intelligence tool 134 executes the report data definition 130 for extracting the data 203 of FIG. 2 from the operational data store 206 and presents the results through one or more spreadsheets. The user can also view and summarize the spreadsheet data through various report viewers described in detail below with respect to FIG.

  Report data definition 130 is initiated in a report start step 1302. The report start step 1302 includes the current cohort 912, against which report data definition 130 can be made. The total cohort 902 of FIG. 9, the matching cohort 1120 of FIG. 11, or even the non-matching cohort 1122 of FIG. 11 can be used to define the report data 130.

  Following the report start step 1302 is a data definition step 1304. Data definition step 1304 includes report data definition 130. The report data definition 130 specifies which entities 404 and property observations 408 are to be included in the report 1308. The report data definition 130 includes a default entity 404 and a default property observation 408. The default entity 404 is the current cohort 912 (or the currently selected cohort), while the default property observation 408 is the entity 404 ID, and the property observation 408 is described in detail with respect to FIGS. Used to select entity 404 as described above.

  Once the report data definition 130 has been created and defined along with the property observation 408 and the entity 404, the user has the option to change the report data definition 130 in the option change 1309 following the data definition step 1304. When the user desires to change the report data definition 130, the entity option change 1310 or the characteristic option change 1312 following the option change 1309 can be selected.

  When the entity option change 1310 or characteristic option change 1312 is selected by the user, the schema definition language 126 will be referenced by the business intelligence tool 134. When the user chooses to change the entity 404 in the report data definition 130, the user will select the change entity option 1310.

  When the user decides to change entity 404 by adding an entity, reference step 1314 refers to schema definition language 126 to identify all of the links of FIG. 6 to other entities 404. This is particularly important when adding an entity 404 that is a sub-entity of the current cohort 912. The link 608 is identified in a link step 1316 that follows the reference step 1314.

  Once the link 608 has been identified between the additional entity 404 and the previous entity 404, the one-hop linkage 914 of FIG. The one-hop linkage 914 may be a property observation 408 corresponding to the newly selected entity 404. That is, the one-hop linkage 914 is an observation 408 of characteristics associated with the newly selected entity 404. Module 406 can also be returned as a one-hop linkage 914. If the newly selected entity 404 is pointed to by module 406 or entity 404, or alternatively, if the newly selected entity 404 points to another module 406 or entity 404, these pointers The indicated module 406 or entity 404 can be returned as a one-hop linkage 914.

  The calculation step 1318 continues to a display step 1320 where the option 1322 can be displayed. When the entity 404 is linked to the attachment, addition, or report data definition 130, the user will be provided with an option 1322. Options 1322 include first, last, or all aging options. Options 1322 may further include filtering options such as filtering based on the type of characteristics included in the report. The filtering option will only maintain results that match the filter criteria. Options 1322 further include any constraint options, limited or non-limiting. The constraint option has the same meaning as SQL inner join versus outer join.

  After option 1322 is provided to the user, update step 1324 updates report data definition 130 with newly requested entity 404 and link 608 to current cohort 912. When adding characteristic observation 408 to report data definition 130, business intelligence tool 134 utilizes a similar flow.

  If the user desires to change the property observation 408 that the report 1308 will display the property option change 1312, the property option change 1312 may be selected. The business intelligence tool 134 will determine whether the observation 408 of the characteristic that the user wants to add belongs to the module 406 that currently exists in the report data definition 130 in the decision option 1326. When module 406 is not currently part of report data definition 130, reference step 1314 is used to reference schema definition language 126. Link 608 is calculated at link step 1316 and finally one-hop linkage 914 is calculated at calculation step 1318.

  The one-hop linkage 914 may be another unselected property observation 408 corresponding to the entity 404 and module 406 to which the property observation 408 added to the user corresponds. That is, the one-hop linkage 914 is a property that has not been added from the same module 406 and entity 404 with which the added property observation 408 is associated. The calculation step 1318 may return the module 406 and the entity 404 as a one-hop linkage 914, along with the observation 408 of the properties that have not been added. When the module 406 and entity 404 associated with the selected property 905 are pointed to by other unassociated modules 406 and entities 404, these unassociated modules 406 or entities 404 It can be returned as a one-hop linkage 914. That is, the target entity type 512 or target module type 514 of FIG. 5 with any characteristic observation 408 includes a data pointer to the module 406 or entity 404 associated with the characteristic observation 408 added to the user. If so, the module 406 and entity 404 associated with the observation of properties 408 having this data pointer will be returned as a one-hop linkage 914.

  Similar to adding entity 404 just described, display step 1320 displays option 1322 to the user. Options 1322 displayed when adding entity 404 and module 406 may be the same. However, additional options or entities 404 or module 406 may display different options and may be displayed depending on what is added.

  After option 1322 is provided to the user, update step 1324 updates report data definition 130 with newly requested modules 406, links 608 to their current cohort 912, and modules 406 within them. It will be updated. When the decision option 1326 is invoked and it is determined that the characteristic observation 408 is already associated with the module 406 in the report data definition 130, the reference step 1314 simply references the schema definition language 126 and links Step 1316 identifies the link 608 required to incorporate the property observation 408 into the report data definition 130.

  When the characteristic observation 408 is already associated with the module 406 in the report data definition 130, the calculation step 1318 and display step 1320 are invoked to calculate the one-hop linkage 914 or to display the option 1322. There is no need to be Update step 1324 can be invoked to update report data definition 130 and return option change 1309 to the user.

  Continuing with the utilized ICD9 breast cancer example above, the user may wish to report on quality-related observations 408 corresponding to molecular experiments, and module 406 is a tumor patient tumor returned as the current cohort 912. Performed on the sample entity 404, but stratified by a characteristic observation 408 indicative of the type of breast cancer. Here, the user simply adds the observations 408 of the characteristics “Cel file quality” and “triple negative” to the report data definition 130. The schema definition language 126 provides a link 608 to the diagnosis of the tumor entity 404 in the breast cancer diagnosis characteristic observation 408 when adding the Cel file quality characteristic observation 408, and for these tumor entities 404. Reference is also made to properly link to the molecular experiment module to be performed. This is because the triple negative observation 408 is part of the cancer diagnostic module 406 already included in the report data definition 130.

  When the user no longer wants to change the report data definition 130, the user may execute the report within an execution step 1328 that follows the option change 1309. The schema definition language 126 is the location of the physical table 218 in the operational data store 206 that includes the property observation 408, the module 406, and the entity 404 within the report data definition 130 from the execution step 1328 following the schema reference step 1330. Can be referred to to identify.

  The SQL instruction 1332 can be automatically generated by the SQL generation step 1334 following the schema reference step 1330. The SQL instruction 1332 can be generated based on the information gathered from the schema reference step 1330. This is because the link 608 between the location of the physical table 218 and the requested data 203 can be specified from the schema definition language 126.

  Once the SQL instruction 1332 has been executed against the operational data store 206, the report 1308 can present the spreadsheet to the user in a presentation step 1336 that follows the SQL generation step 1334. The report 1308 can be filtered, displayed and analyzed in a reporting step 1338 that follows the presentation step 1336. The reporting step 1338 is described in detail below with respect to FIG.

  As an example, the reporting step 1338 may provide a pivot table reporting tool and prompt the user to populate the values and dimensions of the pivot table with the data 203 extracted in the report data definition 130.

  Referring now to FIG. 14, there is shown a screen shot of the report data definition 130 of FIG. 1 as implemented in the business intelligence tool 126 of FIG. Screenshot 1400 depicts a sample of characteristic 222 with associated characteristic observation 408.

  Characteristic observations 408 included by default can include patient ID and characteristic observations 408 used to filter entity 404 of FIG. As an illustrative example, the default characteristic observations 408 in screenshot 1400 are patient ID and ICD9.

  To generate a report for the temporary cohort 1402, the user may select an observation 408 of other characteristics that should be included for analysis. As an example, the user can select Cel file quality or triple negative. As depicted, the business intelligence tool 126 can include an entity 404 corresponding to the newly added property observation 408.

  For the Cel file quality characteristic observation 408, the experiment and sample of the entity 404 can be added along with the experiment ID and sample ID of the corresponding characteristic observation 408. As further depicted, the triple negative property observation 408 already includes a module 406 included by default. In particular, cancer diagnosis was already included as module 406 corresponding to ICD9 characteristic observation 408.

  Referring now to FIG. 15, there is shown a control flow 1500 for analyzing a report according to an embodiment of the present invention. Control flow 1500 depicts some of the steps from previous control flow 1300 in FIG. 13 that include additional steps for analyzing report 1308 of FIG.

  As depicted, the refine step 1502 can continue to a data retrieval step 1504. The refinement step 1502 and the data extraction step 1504 can be composed of the steps of the control flow 1300. For example, a refine step 1502 can be used to refine or change the report data definition 130 of FIG. 1, see data definition step 1304, option change 1309, entity option change 1310, characteristic option change 1312 of FIG. It consists of step 1314, link step 1316, calculation step 1318, display step 1320, and update step 1324.

  The data extraction step 1504 includes a step execution step 1328, a schema reference step 1330, and an SQL generation step 1334 shown in FIG. 13 in order to extract the data 203 shown in FIG. be able to. Once the report 1308 has been extracted in the data extraction step 1504, the user can be prompted to select an analysis tool 1508 in the tool selection step 1506 that follows the data extraction step 1504.

  In the tool selection step 1506, the following analysis tools can be selected. ANOVA (one-way) tool, ANOVA (two-way) tool, partitioning tool, Cox regression tool, Cox regression (multi-control variable) tool, Kaplan-Meier tool (two dates), K-means clustering tool, LiMMA tool Logistic regression tools, Mann-Whitney tools, one-sample t-test tools, and other analytical tools. Once the analysis tool 1508 is selected in the tool selection step 1506, the business intelligence tool 134 of FIG. 1 may prompt the user to select the input required to execute the analysis tool 1508. Input can be requested in a prompt step 1510 that follows the tool selection step 1506.

  Once the user has defined the input, the user maps the data 203 from report 1308 to the input in map step 1512. Once the data 203 has been mapped to the input of the analysis tool 1508, the business intelligence tool 134 performs the analysis and displays the analysis results to the user. Continuing with the ICD9 breast cancer example, FIG. 4 illustrates that for a breast cancer patient entity 404 of FIG. 4, the user is grouped by observation 408 of the various treatment protocol characteristics of FIG. Assume that one wants to compare and analyze the observation 408 of the lifetime characteristics of The user refines the report data definition 130 to include the required characteristic observations 408 to complete the analysis. That is, an observation age characteristic observation 408, a survival characteristic observation 408, a treatment protocol characteristic observation 408, and a flag characteristic observation 408 indicating whether the patient died of breast cancer.

  The report 1308 is retrieved in a data retrieval step 1504. The user can then select Cox regression which is the analysis tool 1508 in the tool selection step 1506. The user maps the data 203 from the report 1308 to the input in the mapping step 1512 and performs the analysis. The business intelligence tool 134 performs the analysis and presents the results of the analysis to the user in various forms, such as a visual Kaplan-Meier curve returned by a statistical comparison of each set of treatment protocols.

  The control flow and block diagrams in the above drawings illustrate the structure and function and the possible operations of the system, method and computer program product according to various embodiments of the present invention. In this regard, each block in the control flow or block diagram may represent a module, segment, or portion of code that consists of one or more executable instructions to implement a particular logical function. It should also be noted that in some alternative embodiments, the functions shown in each block may occur in an order other than that shown in the drawings. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or may be executed in reverse order, depending on the functionality that the block has. Each block in the block diagram and / or flowchart diagram, and combinations of blocks in the block diagram or / and flowchart diagram, are based on special purpose hardware based systems or special purpose hardware and computers that perform specific functions or operations. It can be realized in combination with a program.

  Advantageously, embodiments of the present invention can provide a business intelligence tool for providing a high level abstraction of schema definition language and for leveraging operational data stores at low cost and in a short time frame. To provide a platform that serves as an interface with the schema definition language. The schema definition language allows business intelligence tools to operate at a high level of abstraction so that they do not need to be changed as the underlying database evolves. The database evolves easily and unimpeded when utilizing the schema definition language of the present invention.

  The resulting processes and configurations are easy to understand, cost effective, uncomplicated, very versatile, accurate, sensitive, effective, easy to apply, use efficiently and economically Can be implemented by employing well-known components.

  Although the foregoing description relates to embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, the scope of which follows Determined by.

  Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the scope of the appended claims. All matters set forth herein or shown in the accompanying drawings are to be interpreted in an illustrative and non-limiting sense.

Claims (20)

A method performed by one or more processors, comprising:
One or more schema definition languages from computer memory that define observations of properties linked to entities that are observable facts about the entities and grouped in a module with metadata. processor is the provision of,
A row for each observation of the property; an entity type defining a type of entity to which the observation of the property is linked; and a column of module type defining a type of module to which the observation of the property is linked; and The one or more processors obtain a schema definition model table having cells containing the metadata;
In an operational data store, another physical table for the module and the entity linked to each other based on at least one of the observations of the characteristic, for each module type in the schema definition model table The one or more processors generate another physical table having a column for each observation of the characteristic in the schema definition model table;
A method for the one or more processors to populate the other physical table according to the metadata. A method according to claim 1, further comprising:
Referring to the schema definition language metadata to locate the selected property in the other physical table, and another physical table for the module or the entity includes the selected property A method in which the one or more processors determine whether or not. The method according to claim 2, further comprising: referring to metadata of the schema definition language to identify a location of the another physical table, wherein the another physical table for the module or the entity is selected. The method in which the one or more processors determine whether or not the other physical table contains a subsequent selected property only if it contains the property. The method according to claim 1, further comprising: when the observation of the characteristic is grouped in the same module as the selected characteristic, the one or more processors if the observation of the characteristic is a one-hop linkage. How to judge. 2. The method according to claim 1, further comprising the one or more processors classifying the entity into a matching cohort if a clinical pattern of the selected characteristic corresponds to the observation of the characteristic.
A method of classifying the entity as a mismatched cohort if the clinical pattern of the selected characteristic does not correspond to the observation of the characteristic. The method according to claim 1, wherein the one or more processors further determine whether the module is associated with a definition of report data.
A method in which the one or more processors refer to the schema definition language when the module is not associated with a report data definition. A method according to claim 1, comprising:
Said one or more processors to said another physical table is populated, the whether the data by referring to the metadata of the schema definition language is appropriate data type in the observation of the characteristics the one or more A method comprising determining by a processor . A non-transitory computer-readable medium used in connection with a processor,
Providing a schema definition language for observing properties that are observable facts about the entity, linked to the entity, defining the observations of the properties grouped in a module with metadata;
A row for each observation of the property; an entity type defining a type of entity to which the observation of the property is linked; and a column of module type defining a type of module to which the observation of the property is linked; and Obtaining a schema definition model table having cells containing the metadata;
In an operational data store, another physical table for the module and the entity linked to each other based on at least one of the observations of the characteristic, for each module type in the schema definition model table Generate another physical table with a column for each observation of the characteristic in the schema definition model table;
A medium including instructions configured to populate data in the another physical table according to the metadata. 9. A non-transitory computer-readable medium according to claim 8, further comprising: referring to the metadata of the schema definition language to locate a selected characteristic in the other physical table; and A medium including instructions configured to determine whether a module or another physical table for the entity includes the selected property. 10. A non-transitory computer readable medium according to claim 9, further comprising locating the other physical table with reference to the schema definition language metadata for the module or the entity. A medium comprising instructions configured to determine whether or not another physical table includes a subsequent selected characteristic only when the other physical table includes the selected characteristic. 9. The computer readable non-transitory medium according to claim 8, further comprising the step of observing the characteristic when grouped in the same module as the selected characteristic. A medium comprising instructions configured to determine that 9. A computer-readable non-transitory medium according to claim 8, further comprising: classifying the entities into a matching cohort if a selected clinical pattern of characteristics corresponds to observation of the characteristics;
A medium comprising instructions configured to classify the entity as a mismatched cohort if a clinical pattern of the selected characteristic does not correspond to the observation of the characteristic. 9. A non-transitory computer readable medium according to claim 8, further comprising: determining whether the module is associated with a report data definition;
A medium containing instructions configured to reference the schema definition language when the module is not associated with a report data definition. A computer-readable non-transitory medium according to claim 8,
Populating the other physical table is configured to refer to the metadata of the schema definition language to determine whether the data is a data type appropriate for observing the property. Medium containing instructions. An observation of a property linked to an entity, which is an observable fact about the entity, and is an example of a record that includes a start date and an end date along with metadata and is one of the observations of the property A schema definition language for defining observations of the properties grouped in a module is provided by a processor from computer memory;
A row for each observation of the property; an entity type defining a type of entity to which the observation of the property is linked; and a column of module type defining a type of module to which the observation of the property is linked; and Obtaining a schema definition model table having cells containing the metadata;
In an operational data store, another physical table for the module and the entity linked to each other based on at least one of the observations of the characteristic, for each module type in the schema definition model table Configured to generate another physical table having a column for each observation of the characteristic in the schema definition model table;
A system comprising one or more processors that populates said another physical table according to said metadata. A system according to claim 15, wherein
The one or more processors locate the selected property in the another physical table with reference to the schema definition language metadata, and another physical table for the module or the entity A system configured to determine whether a selected characteristic is included. A system according to claim 16, comprising:
The one or more processors locate the other physical table with reference to the schema definition language metadata, and the another physical table for the module or the entity includes the selected characteristic. A system configured to determine whether the other physical table contains subsequent selected characteristics only when A system according to claim 15, wherein
The system wherein the one or more processors are configured to determine that the property observation is a one-hop linkage when the property observation is grouped in the same module as the selected property. A system according to claim 15, wherein
The one or more processors are:
If the clinical pattern of the selected characteristic corresponds to observation of the characteristic, classify the entity into a matching cohort;
A system configured to classify the entity as a mismatched cohort if a clinical pattern of a selected characteristic does not correspond to the observation of the characteristic. A system according to claim 15, wherein
The one or more processors are:
Determine whether the module is associated with a report data definition;
A system configured to reference the schema definition language when the module is not associated with a report data definition.

Images