Patent Application
20190034593
The present disclosure relates to methods and systems for aggregating and filtering disparate data to identify the cost of a healthcare procedure, by treating physician, and to benchmark the physician's cost against other physicians.
Healthcare systems, healthcare delivery, and the costs of receiving and paying for healthcare are becoming increasingly complex. In some cases, hospitals and providers may be compensated for particular procedures under a bundled payment model, where the compensation is not based on the actual cost of a particular physician treating a particular patient at a specific facility, but instead based on a flat rate for the specific procedure. While bundled payments offer potential cost savings through improved care management and provider coordination, they also pose risk management challenges to providers, as the providers may not be compensated over the set bundle price. Thus, bundled payments may not take into account cost differences that may be attributed to a particular physician's treatment approach, the underlying health of a particular patient, or any effect that a patient's home community can have on the success and length of a patient's treatment.
In some cases, hospitals and other care providers are looking for ways to standardize costs across physicians, place of care, and type of care, to make the costs associated with procedures that are compensated under a bundled payments model more consistent and predictable. To do this, it can be helpful to understand how much of the service price variation can be attributed to the treating physician, and to the decisions that are within the physician's control, such as place of discharge and treatment plans. For example, the place that a patient is discharged to (e.g., an outpatient rehabilitation facility, an inpatient rehabilitation facility, etc.) is typically decided by the treating physician and can have a large effect on the cost of the service and the recovery time.
According to a first aspect, the disclosure provides a method for enhancing medical data to determine variation in cost of medical services. The method includes receiving a first set of medical episode data records, whereby the first set of medical episode data records are related to a plurality of medical episodes, and each of the plurality of medical episodes includes an associated patient, an associated physician, and an associated episode cost. The method further includes categorizing each of the plurality of medical episodes in the first set of medical episode data records according to a disease stage categorization rule, and assigning at least one comorbidity classification to each of the categorized medical episode data records. The method also applies at least one data enhancement rule to each of the first set of medical episode data records to form an enhanced set of medical episode data records. According to the disclosed method, the at least one data enhancement rule is related to a parameter of the associated patient for each of the plurality of medical episodes. The method includes identifying a first medical episode data record in the enhanced set of medical episode data records, wherein the first medical episode data record includes an associated first medical episode having a first type, a first associated physician and a first associated episode cost. The method also includes identifying a subset of the enhanced set of medical episode data records, wherein the subset of the enhanced set of medical episode data records includes a subset of associated medical episodes having the first type, a subset of associated physicians and a subset of associated episode costs, wherein the subset of the enhanced set of medical episode data records does not include the first medical episode data record. In addition, the disclosed method includes applying a regression analysis to the subset of associated episode costs to identify a mean episode cost, an upper confidence level episode cost and a lower confidence level episode cost, and comparing the first associated episode cost to the upper confidence level episode cost and the lower confidence level episode cost
According to another aspect, the disclosure provides a system for enhancing medical data to determine variation in cost of medical services. The system includes a data processing engine that is configured to receive a first set of medical episode data records. According to the disclosure, the first set of medical episode data records is related to a plurality of medical episodes, and each of the plurality of medical episodes includes an associated patient, an associated physician, and an associated episode cost. The data processing engine is further configured to categorize each of the plurality of medical episodes in the first set of medical episode data records according to a disease stage categorization rule. The data processing engine is further configured to apply at least one data enhancement rule to each of the first set of medical episode data records to form an enhanced set of medical episode data records, and the at least one data enhancement rule is related to a parameter of the associated patient for each of the plurality of medical episodes. The data processing engine is also configured to identify a first medical episode data record in the enhanced set of medical episode data records. According to the disclosure, the first medical episode data record includes an associated first medical episode having a first type, a first associated physician and a first associated episode cost. The data processing engine is also configured to identify a subset of the enhanced set of medical episode data records. The enhanced set of medical episode data records includes a subset of associated medical episodes having the first type, a subset of associated physicians and a subset of associated episode costs, and the subset of the enhanced set of medical episode data records does not include the first medical episode data record. In addition, the data processing engine is configured to apply a regression analysis to the subset of associated episode costs to identify a mean episode cost, an upper confidence level episode cost and a lower confidence level episode cost, and to compare the first associated episode cost to the upper confidence level episode cost and the lower confidence level episode cost.
In yet another aspect, the disclosure provides a computer program product for enhancing medical data to determine variation in cost of medical services. The computer program product includes a computer readable storage medium having program instructions embodied therewith whereby the program instructions are executable by a data processing engine. The program instructions cause the data processing engine to receive a first set of medical episode data records, wherein the first set of medical episode data records is related to a plurality of medical episodes, and wherein each of the plurality of medical episodes includes an associated patient, an associated physician, and an associated episode cost. The program instructions also cause the data processing engine to assign at least one comorbidity classification to each of the plurality of medical episodes in the plurality of medical episode data records, and to apply at least one data enhancement rule to each of the first set of medical episode data records to form an enhanced set of medical episode data records. According to the disclosure the at least one data enhancement rule is related to a parameter of the associated patient for each of the plurality of medical episodes. The program instructions of the computer program product also cause the data processing engine to identify a first medical episode data record in the enhanced set of medical episode data records, whereby the first medical episode data record includes an associated first medical episode having a first type, a first associated physician and a first associated episode cost. The program instructions also cause the data processing engine to identify a subset of the enhanced set of medical episode data records, whereby the subset of the enhanced set of medical episode data records includes a subset of associated medical episodes having the first type, a subset of associated physicians and a subset of associated episode costs. However, according to the disclosure, the subset of the enhanced set of medical episode data records does not include the first medical episode data record. The program instructions of the computer program product also cause the data processing engine to apply a regression analysis to the subset of associated episode costs to identify a mean episode cost, an upper confidence level episode cost and a lower confidence level episode cost, and to compare the first associated episode cost to the upper confidence level episode cost and the lower confidence level episode cost.
These and other aspects, objects, and features of the present disclosure will be understood and appreciated by those skilled in the art upon studying the following specification, claims, and appended drawings.
In the drawings:
The present disclosure provides a method and system to aggregate, filter, and enhance numerous disparate data sets to help explain the variance in the cost of various medical procedures, by treating physician. In particular, the disclosure provides rules to merge, filter and enhance the data in order to better understand differences in cost among physicians and to be able to optimize management of the healthcare system, such as a hospital system. According to some embodiments, the method builds and examines episode costs to take into account various parameters of a specific medical episode that may have an effect on the cost of the medical procedure. For example, in at least one case, the method enhances the data to take into account aspects of the patient (age, race, diagnosis-based measures, etc.); the type of case (e.g., total knee replacement, partial hip replacement, etc.); the treatment; and, how to and where the physician discharges the patient. As described in more detail below, according to embodiments described herein, after the data enhancements, the method computes each physician's average cost by episode type for a given place of care, such as a hospital, and then benchmarks the physician's average cost against a predictive model of the average cost for all physicians' at the same place of care performing similar episodes. Accordingly, aspects described herein facilitate predictive modeling of what a physician's cost should be, per episode type, at a given treatment location. If the physician's real average cost per episode is below a specified prediction confidence interval, the physician may be considered efficient compared to the benchmark model. Conversely, if the physician's real average cost per episode is above the specified prediction confidence interval, the physician may have be considered to have inefficiencies that can be addressed. The information may be used by healthcare systems as a starting point to find physicians that are high outliers in a specific bundled episode spend. With this information, healthcare systems can make healthcare decisions that have an effect on fiscal, operational, and staff (e.g. physician) efficiency to improve performance for bundled payment models, and to intervene where physicians may need more oversight.
Referring to
In at least one case, data processing engine 12 may be configured to receive medical episode data from a healthcare system 30, and specifically from one or more data stores 32 associated with healthcare system 30. Data processing engine 12 may include one or more functional sub-engines for separately enhancing and filtering the data, including, but not limited to, data pre-processing engine 14, data merging, filtering and enhancement engine 16, and statistical model build engine 18. Data pre-processing engine 14 may be configured to apply one or more rules to the episode data, including but not limited to pre-processing logic 20, as described in more detail below in relations to
As described in more detail below, data processing engine 12 may also include, or be coupled with, one or more database(s) to store information such as input variables and algorithms for implementing data processing rules. Accordingly, data processing engine 12 may receive and process the input variables based on the data processing rules. Data processing engine 12 may also include one or more servers including any processor, server (including a cloud server), mainframe computer, or other processor-based device capable of facilitating communication and running software programs or other applications.
With reference to
Accordingly, aspects of the present disclosure provide methods, systems and computer program products to receive input data in the form of medical episode record data; apply rules to merge, filter and enhance the data to account for various parameters related to the patient, the physician and the treatment location that may have an effect on the cost of the medical episode; and then assess a specific physician's cost across other physicians having similar parameters. In some cases, the disclosure provides rules that allow otherwise disparate data to be merged, merged, analyzed in a statistical model, the results of which may be used to facilitate healthcare system decisions.
At step 54, various data pre-processing steps may be applied to the data received at step 52. For example, the medical episode data records may be mapped to one or more grouping schemes to further categorize the patient, the diagnosis, the treating physician, or other attributes, associated with each medical episode data record. In some cases, the medical episode data records may be mapped to indicate the severity of the medical episode, e.g. the disease stage, and/or the existence of comorbidities in a specific patient. In at least one case, as described in more detail in relation to
After the data enhancement and preprocessing at step 54, the method proceeds to step 56 and applies a number of rules to merge, filter and enhance various portions of the medical episode data records and the data associated with each record. For example, step 56 may include filtering out portions of the medical episode data records and merging the data with additional input files to further explain aspects of the input data. The method may also create new data variables associated with the medical episode data records.
Once the data in the medical episode data records has been merged, filtered and enhanced at step 56, at step 58 the process includes applying regression analysis to compare the enhanced medical episode data (steps 54 and 56) against one or more sets of historical medical episode data to determining variance in cost by treating physician. According to an embodiment described herein, step 58 may include the process flows depicted in
Medical Episode Data Input
As set forth at step 52 of
In at least one embodiment, medical episode data input may be input as bundled episode data from the Centers for Medicaid and Medicare Services (CMS) for a specific healthcare system, such as medical episode data record 70 in
Medical Data Input Preprocessing
According to aspects described herein, after the medical episode data input is received at step 52, as shown in
In at least one case the medical episode data records may be pre-processed to map them with one or more disease staging categories and one or more functional comorbidity categories.
In at least one case, the medical claims data records may be assigned to a disease staging categorization scheme, such as the Disease Staging® classification system from Truven Health Analytics, Inc. Table 140 of
Referring back to
Referring back to
Enhancing Medical Input Data
Referring back to flowchart 50 in
Referring first to
In at least some embodiments, variables may be created to help describe one or more medical episodes for a specific patient or beneficiary. For example, variables may be created to ensure that the correct demographic information is associated with the patient for a given point in time. Moving to step 164 in flowchart 160, in at least one case, an anchor year variable may be created based on the episode data table from step 162. The anchor year variable may be created for each episode ID 72 and used to signify the year that the medical episode took place, and, as shown in
At step 166, data merging, filtering and enhancement engine 16 may receive inpatient admission data as input from the medical episode data records.
At step 168 within the selected data all claims related to a specific DRG code may be selected to focus the analysis on a specific type of medical event. For example, using joint replacement procedures to simplify the description herein, DRG codes 469 and 470 may be selected from the inpatient admission data pulled at step 166. As is known in the art, DRG code 469 and 470 both refer to joint replacement procedures, and specifically, DRG code 469 refers to a joint replacement procedure with a presence of comorbidities, while DRG code 470 refers to a joint replacement procedure with an absence of comorbidities. Then, at step 170, the selected claims are sorted by episode ID 72 and the resultant files are merged with the anchor year variable created at step 164, as related to each episode ID 72. As described in more detail below, the merged files may be used as input in the flowchart 174 depicted in
In some embodiments, variables may be created that can be good predictors of medical procedural outcomes and costs. For example, when a patient elects to have a medical procedure, the patient may follow recovery instructions more closely and be more vested in a speedy and full recovery. In at least one embodiment, at step 180, a new variable “elective admission” may be created. The variable “elective admission” may also constitute a flag, wherein the flag is set to “1” if the inpatient admission was an elective procedure, i.e., a procedure that is initiated by the patient, and the elective admission variable is set to “0” if the inpatient admission is not elective. As shown in
With further reference to the illustrated embodiment,
In some cases, the method may include procedures to remove duplicate data entries from the medical episode data input. Backtracking to step 188, diagnosis and procedure data may be pulled from the medical episode data input to create a separate input table. Specifically, according to an embodiment of the disclosure and referencing
According to aspects described herein, indicator variables may be created to help predict cost variance. For example, steps 194-208 in
At step 202, rows with the claim value sequence number “1” are selected. Next, at steps 204-208, one or more variables may be created that are related to the specific DRG code. For example, at step 204a variable, “total knee replacement,” may be created. The “total knee replacement” variable may be indicated as a flag, and if the ICD coding version is “9” and the value for the procedure code is “8154,” then the flag may be set as “1,” however, for any other coding version or procedure version, the flag may be set as “0.” Similarly, at step 206, the variable, “total hip replacement,” may be created. The “total hip replacement” variable is specified as a flag, and if the ICD coding version is “9” and the value for the procedure code is “8151,” the flag may be set at “1.” At step 208, yet another variable, “partial hip replacement,” may be created and, again, specified with a flag. For the variable “partial hip replacement,” if the ICD coding version is “9” and the value of the procedure code is “8152,” then the flag may be set as “1.” However, if the ICD coding version is anything other than “9” and the value of the procedure code is anything other than “8152,” the flag may be set at “2.”
At step 210, all variables may be filtered again to avoid the creation of duplicate copies of variables. Specifically, at step 210, according to embodiments described herein, only the following variables may be retained: episode ID 72; ICD coding version; procedure code; total knee replacement; total hip replacement; and partial hip replacement are retained. It should be noted again, that in the illustrated embodiment, for purposes of explanation, the variables are related to CJR episodes. However, it should be understood that for other types of episodes, different types of variables may be created to describe the specific DRG code, and those skilled in the art will readily contemplate the various procedural and cost predictors related to other types of medical episodes. As shown in
Referring to
The filtered medical episode data may also be cross-referenced to a measure for a specific community's access and/or barriers to healthcare. Some communities experience significant barriers to healthcare which can have an effect on the severity of the episode that is being treated, the outcome of the treatment, and other aspects of the episode care. For example, treating an episode in a community that is predominantly a non-native language speaking community may present barriers that effect, for example, the length of the treatment and specific follow-up actions. The system may use various types of community assessment information, such as governmental census information or CMS data. In other cases, the system may use proprietary sources of community assessment data. In at least one case, the system may attribute a score level, such as a score from 1 to 5, to areas based on zip code throughout the United States.
Accordingly, referring again to
In some cases, additional variables may be created that identify the patient by various parameters that may have an effect on the type and duration of the medical episode. For example, for some types of medical episodes, gender, race as well as the underlying reason for Medicare eligibility may have bearing on medical procedure outcomes, complexity and cost. For example, statistics indicate that some patients may have lower access to home care and therefore worse recovery times or higher readmissions. According to some embodiments, at step 236, a variable, “male,” may be created, and assigned a flag of “1” if the beneficiary gender is male, otherwise assigned a flag of “0.” At step 236a variable, “African American,” may be created, and assigned a flag of “1” if the beneficiary race is African American, otherwise assigned a flag of “0.” At step 240 the variable, “Mcreason” may be created and assigned a flag “0” if the variables “OREC” and “CREC” have a value of “0,” and otherwise, assigned a flag “1.” At step 241, according to some embodiments, the variables reference year, OREC, CREC, and zip code may be dropped from the data file. The process then moves to flowchart 242 of
Apply Rules to Identify Cost Variance
As previously stated, aspects described herein facilitate analytics to identify variations in total allowed costs by physicians at a specific healthcare facility, such as a hospital. More specifically, the process includes provisions to identify significantly predicted patient characteristics along with physician-level effects on costs. For example, the model allows for indicators such as a patient's functional comorbidities and physician-specific contributors, to be attributed to the overall cost of a medical episode. In at least some embodiments, the model will allow for outlier physicians, i.e, physicians showing particularly high or low costs for standard medical procedures, to be highlighted. Accordingly, for each focus physician, the model provides a regression system where, for a focus physician, that physician's data is compared to a model of all other physicians' data for the same procedure at the same facility. The other physicians' data may be used to model and predict spend for the focus physician, which may be conditional on patient indicators, e.g. functional comorbidities, stage level, or other variables specific to a patient's diagnosis and treatment, as well as physician-specific contributors, e.g., how and to what type of facility a patient is discharged.
According to aspects described herein, the model provides for a confidence interval prediction and thus the ability to classify the actual spend of the focus physician as a high or low outlier. In other words if the focus physician cost is above a certain confidence interval, such as but not limited to a 95% confidence interval, the focus physician would be a high outlier. Conversely, if the focus physician cost is below the confidence interval, e.g. a 95% confidence interval, the focus physician would be a low outlier. Flowchart 330 of
According to an embodiment of the disclosure, at step 332, the physician variation statistical model build engine 18 (
At step 335a non-linear regression model on all remaining physicians' data for the focus facility ID 100 may be fitted to predict a total episode allowed amount, using the focus physician's peers as well as the focus physicians case mix (i.e., same types of episodes, patient comorbidities, complexities, as well as other physician case mix indicators known in the art), e.g. “Model A.” In some cases, data on all other physicians may be pulled from the same database used to create the focus physician data set. However, in cases where there is not enough data from other physicians, similar data from historical medical databases having historical episode data records for the same facility ID 100 may be used to create “Model A.”
At step 338 the focus physician's mean actual allowed amount per episode is compared to the selected confidence interval for the predicted allowed mean amount per episode from “Model A.” Then, at step 340, as described above, it is determined if the focus physician's allowed amount is a low outlier, an average outlier, i.e., within the selected confidence interval, or a high outlier. As would be understood in the art, a model prediction typically exhibits a 95% confidence interval based on uncertainty about the model coefficients due to factors, including but not limited to sampling error and uncertainty about future outcomes. Accordingly, to account for the uncertainty, the focus physician's actual mean cost per episode may be compared to the 95% model prediction interval (PI). If the focus physician's mean cost is lower than the 95% PI, the focus physician may be identified as a low outlier. Conversely, if the focus physician's mean cost is above the 95% PI, the focus physician may be identified as a high outlier. Otherwise, the focus physician may be identified to be in line with his peers.
As shown in table 350, physician 1 represents a low outlier according to methods described herein because the physician's mean actual amount ($6,446.97) is lower than the predicted lower confidence interval 366 for physician 1 ($7,116.66). Specifically, according to the data, physician 1 consistently treats patients for the particular episode ID type at a lower cost, and more efficiently, than other physicians at the same facility. Accordingly, physician 1 may be used as a model for identifying techniques and efficiencies for other physicians when making decisions for bundled payments, e.g. in identifying successful treatment plans and discharge locations.
Conversely, physician 2 represents a high outlier according to methods described herein because the physician's mean actual amount ($43,919.54) is higher than the predicted higher confidence interval 368 for physician 2 ($40,646.63). Specifically, according to the data, physician 2 consistently treats patients for the particular episode ID type at a higher cost than other physicians at the same facility. Accordingly, physician 2 may be identified as a source for improvement, to help lower costs for bundled payment services.
Physician 3 represents an average cost model according to methods described herein because the physician's mean actual amount ($24,284.16) falls between the predicted lower confidence interval 366 and the predicted higher confidence interval 368 for physician 3. Specifically, according to the data, physician 3 consistently treats patients for the particular episode ID for about the same cost as other physicians at the same facility. Accordingly, physician 3 may be identified as a physician not requiring intervention.
Exemplary Operating Environment
Embodiments of the methods and system described herein may utilize various computer software and hardware components, including but not limited to, servers, mainframes, desktops computers, databases, computer readable media, input/output devices, networking components and other components as would be known and understood by a person skilled in the art.
Server 402 is generally representative of one or more servers suitable for processing medical claims data and serving data in the form of webpages or other markup language forms with associated applets, ActiveX controls, remote-invocation objects, or other related software and data structures, to service clients of various “thicknesses.” Server 402 may be configured as would be known by a skilled artisan and may include one or more processing engines 404, memory 406, one or more network interfaces 412, one or more input/output devices 410 (such as a keyboard, mouse, display, etc.). Memory 406 may include a logic module 408 for processing medical claims data. In some embodiments, processing engine 404 may include one or more local or distributed processors, controllers, or virtual machines. As described above in relation to
As would be understood in the art, processing engine 404 may be configured in any convenient or desirable form as would be known by a skilled artisan. Memory 406 may comprise one or more electronic, magnetic, or optical data-storage devices, and may include different types of memory. As would be known in the art, memory 406 may store instructions, such as logic module 408, for processing by processing engine 404. As described above in relation to
Databases 424 may include one or more electronic, magnetic, optical data-storage devices, or other data-storage devices which can include or are otherwise associated with respective indices (not shown). In some embodiments, databases 424 include medical, drug, and lab-related medical claims data. In other embodiments, databases 424 include and/or extract healthcare administrative data, such as medical claims and encounter data, from health plan, employer and government databases. In some embodiments, databases 424 additionally include medical guidelines data sources, such as government and/or other public sources, government regulations and proprietary databases. According to aspects described herein, databases 424 may be connected to server 402 via network 414.
Server 402 may be accessed by one or more access devices, including, but not limited to, personal computers, enterprise workstations, handheld devices, mobile telephone, or any other device capable of providing an effective user interface with a server or database. As depicted, in an embodiment of the disclosure, server 402 is connected to one or more access devices 432 via network 414. Network 414 may be any type of data communications network known in the art, including, but not limited to a LAN, WAN, public-switched, satellite, or any other type of network as would be contemplated by a skilled artisan.
Accordingly, the present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
