Patent Application
20170235883
The present application relates generally to an improved data processing apparatus and method and more specifically to mechanisms for identifying missing medical codes for re-coding in patient registry records and mechanisms for updating patient registry records accordingly.
Various programs have been established for compensating medical personnel for treating patients based on the medical codes associated with their patient medical records. With such programs, if the medical personnel miss coding the patient medical record with an applicable medical code, then the medical personnel may not be properly compensated for the care that they are providing. Due to the large number of patients most doctors and other medical personnel treat, and the detailed nature of the patient records, it is sometimes difficult for doctors and medical personnel to identify such missed opportunities. For example, a patient may have a medical code entered into their patient medical record in one calendar year, and then in the next calendar year, the medical code may not be re-coded even though the patient is still receiving care from the medical personnel for the same medical condition that existed in the previous year. Thus, the doctor or medical personnel may not receive adequate compensation for the care they are providing.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described herein in the Detailed Description. This Summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
In one illustrative embodiment, a method is provided, in a data processing system comprising a processor and a memory comprising instructions which, when executed by the at least one processor, cause the at least one processor to implement a medical code re-coding system. The method comprises analyzing, by the medical code re-coding system, a patient medical record corresponding to a patient, to identify at least one previous occurrence of a medical code in the patient medical record. The method further comprises applying, by the medical code re-coding system, at least one medical code re-coding rule corresponding to the at least one previous occurrence of the medical code to the patient medical record. Moreover, the method comprises determining, by the medical code re-coding system, based on results of the application of the at least one medical code re-coding rule, whether the medical code is a candidate for re-coding. In addition, the method comprises outputting, by the medical code re-coding system, a notification of the medical code being a candidate for re-coding in response to the determination indicating that the medical code is a candidate for re-coding.
In other illustrative embodiments, a computer program product comprising a computer useable or readable medium having a computer readable program is provided. The computer readable program, when executed on a computing device, causes the computing device to perform various ones of, and combinations of, the operations outlined above with regard to the method illustrative embodiment.
In yet another illustrative embodiment, a system/apparatus is provided. The system/apparatus may comprise one or more processors and a memory coupled to the one or more processors. The memory may comprise instructions which, when executed by the one or more processors, cause the one or more processors to perform various ones of, and combinations of, the operations outlined above with regard to the method illustrative embodiment.
These and other features and advantages of the present invention will be described in, or will become apparent to those of ordinary skill in the art in view of, the following detailed description of the example embodiments of the present invention.
The invention, as well as a preferred mode of use and further objectives and advantages thereof, will best be understood by reference to the following detailed description of illustrative embodiments when read in conjunction with the accompanying drawings, wherein:
Before beginning the discussion of the various aspects of the illustrative embodiments, it should first be appreciated that throughout this description the term “mechanism” will be used to refer to elements of the present invention that perform various operations, functions, and the like. A “mechanism,” as the term is used herein, may be an implementation of the functions or aspects of the illustrative embodiments in the form of an apparatus, a procedure, or a computer program product. In the case of a procedure, the procedure is implemented by one or more devices, apparatus, computers, data processing systems, or the like. In the case of a computer program product, the logic represented by computer code or instructions embodied in or on the computer program product is executed by one or more hardware devices in order to implement the functionality or perform the operations associated with the specific “mechanism.” Thus, the mechanisms described herein may be implemented as specialized hardware, software executing on general purpose hardware, software instructions stored on a medium such that the instructions are readily executable by specialized or general purpose hardware, a procedure or method for executing the functions, or a combination of any of the above.
The present description and claims may make use of the terms “a”, “at least one of”, and “one or more of” with regard to particular features and elements of the illustrative embodiments. It should be appreciated that these terms and phrases are intended to state that there is at least one of the particular feature or element present in the particular illustrative embodiment, but that more than one can also be present. That is, these terms/phrases are not intended to limit the description or claims to a single feature/element being present or require that a plurality of such features/elements be present. To the contrary, these terms/phrases only require at least a single feature/element with the possibility of a plurality of such features/elements being within the scope of the description and claims.
In the following description, reference is made to embodiments of the invention. However, it should be understood that the invention is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, although embodiments of the invention may achieve advantages over other possible solutions and/or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the following aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).
In addition, it should be appreciated that the present description uses a plurality of various examples for various elements of the illustrative embodiments to further illustrate example implementations of the illustrative embodiments and to aid in the understanding of the mechanisms of the illustrative embodiments. These examples are intended to be non-limiting and are not exhaustive of the various possibilities for implementing the mechanisms of the illustrative embodiments. It will be apparent to those of ordinary skill in the art in view of the present description that there are many other alternative implementations for these various elements that may be utilized in addition to, or in replacement of, the examples provided herein without departing from the spirit and scope of the present invention.
As noted above, programs of various types, such as government sponsored programs, insurance company sponsored programs, and other private and public party organization based programs, have been established for compensating medical personnel for treating patients based on the medical codes associated with their patient medical records. For example, Medicare, Medicaid, medical insurance payment programs, and the like, have all been established and each have their own sets of rules or criteria that are required for a medical doctor or other medical personnel (hereafter assumed to be a “doctor” for ease of explanation) to be compensated for the care that they provide to their patients. Many times, these rules or criteria are based on medical codes associated with the patient in the patient's medical record. For example, a doctor, when meeting with the patient and providing medical care, must input the correct medical codes into the patient's medical record, typically stored electronically, in order to obtain adequate compensation for the care provided by the doctor to the patient. Thus, if the doctor wishes to receive compensation for treating a diabetes patient with regard to an amputation, then the correct medical codes for diabetic amputation must be input to the patient medical record and corresponding payment system for reporting to the appropriate program supporter, e.g., insurance company, government regulatory agency, or the like.
With such programs, if the doctor of other medical personnel miss coding the patient medical record with an applicable medical code, then the medical personnel may not be properly compensated for the care that they are providing. For example, a doctor may have a patient that uses the United States of America federal health insurance plan referred to as “Medicare” to assist with payment of medical expenses. The Medicare payment methodology may be established such that the doctor is paid a flat fee for treating patients having a particular medical code, e.g., a type 2 diabetes patient with an amputation. In this situation, if the doctor properly enters the medical code for the patient as being a type 2 diabetes patient with an amputation, then the doctor will be paid the flat fee as agreed by Medicare during the year that the patient was coded with this medical code, e.g., the code “L5000”. However, if the doctor then continues to treat the patient the following year and fails to re-code the original diagnosis of the patient, i.e. re-codes the code “L5000”, then Medicare may fail to continue to compensate the doctor for the treatment provided to the patient as a type 2 diabetes patient with an amputation and may only compensate the doctor for a sub-part of the treatment provided by the doctor that is associated with new medical codes entered by the doctor during these subsequent visits. Thus, from the point of view of the payment methodology of the Medicare system, while the patient was coded as a type 2 diabetes patient with an amputation, the patient in a subsequent year, due to the missed medical code re-coding, e.g., the patient is properly coded as a type 2 diabetes patient but the coding for the amputation is missed, may appear to have re-grown the amputated appendage and the doctor is not properly compensated for the fact that the doctor is also treating the amputation.
The illustrative embodiments provide mechanisms for identifying instances of medical codes in a patient registry record that may have been missed from one time frame to another, as specified by various established programs, and thus, may be candidates for re-coding in the patient registry record. The illustrative embodiments then generate an alert or notification of the medical code candidates for re-coding in response to information indicating that the patient is scheduled for further treatment by the doctor, e.g., the patient has a scheduled doctor visit in the doctor's scheduling system. That is, in one illustrative embodiment, as part of the notification of the patient's scheduled appointment output to the doctor or other medical professional, the notification is augmented with an alert or other notification informing the doctor of the potential need to re-code the patient with a previously applied code that may have been missed or may potentially be missed. This notification may be cross-practitioner applied such that if the patient sees various medical personnel at various medical practices or locations, regardless of which doctor or medical personnel that originally coded the medical code that is a candidate for re-coding, the other medical practitioners that the patient sees may be informed of the candidate medical code for re-coding, e.g., if the patient's primary care physician codes the patient with a malady A, and if the time period for coding the patient has expired with regard to the patient's medical insurance provider, in a later visit with a specialist the notice of the candidate medical code for re-coding malady A may be output to the specialist even though the specialist was not the one that originally coded the patient with the candidate medical code for re-coding.
The illustrative embodiments, in response to trigger conditions, analyze historic data for a patient, e.g., patient electronic medical records (EMRs), to identify occurrences of medical codes previously associated with the patient's EMRs. For example, the trigger conditions may include a patient scheduling an appointment with a doctor or other medical personnel, the elapse of a time period, a user initiated request to perform analysis of historic data for a patient, or the like. For example, if a patient schedules an appointment with a doctor or other medical practitioner, the analysis of the historic patient data may be automatically initiated with results of the analysis, as discussed hereafter, being appended or otherwise added to an entry for the scheduled appointment. In addition, or alternatively, a payment provider, such as an insurance company, government regulatory agency, or the like, may set a predetermined time period at which patient medical codes are to be re-evaluated, e.g., payment periods may be established on a calendar or fiscal year basis and patient medical codings may need to be re-evaluated at the beginning of each payment period. Any suitable trigger condition may be used without departing from the spirit and scope of the illustrative embodiments.
In response to analysis of the historic data for the patient being initiated, re-coding rules are applied to the identified occurrences of the medical codes to determine if patterns of occurrences of medical codes meet criteria specified by the re-coding rules. The re-coding rules identify different types of medical codes that are likely persistent medical maladies or conditions that need to be re-coded from time to time by the doctor or medical professional. Such medical codes may be specified based on medical knowledge of the various medical maladies, payment provider guidelines, and the like. For example, it may be known from medical knowledge that type 2 diabetes is an ongoing medical malady that will persist from one year to the next and a payment provider guideline may state that doctors or medical personnel will only be paid on a flat fee basis per calendar year for treatment of a patient with type 2 diabetes. This information together indicates that a patient that has been previously coded as having type 2 diabetes should be checked for re-coding every calendar year.
Thus, for example, a recoding rule may look to the patient's historical medical data in the patient's EMRs to determine if a medical code exists for type 2 diabetes. In response to finding a previous occurrence of a medical code for type 2 diabetes, medical codes that have been entered into the patient's EMR in the current calendar year may be evaluated to determine if any of the medical codes correspond to a medical code for type 2 diabetes. If such a medical code does not exist within the current calendar year, then an alert or notification may be appended or added to the scheduled appointment of the patient such that when the doctor or medical personnel is notified of the patient's scheduled appointment, the alert or notification of the potential need to re-code the patient's previously coded medical malady is also output to the doctor/medical personnel.
The identification of occurrences of such medical codes in the patient's historical medical data may be filtered according to date/time criteria such that only medical codes that have occurred within a particular period of time may be considered as triggers for applying re-coding rules, e.g., only medical codes that were coded within the last 5 years. Such periods of time may be specific to the particular type of medical code as may be determined based on criteria associated with each medical code indicative of how long a particular medical malady may persist, or how long a particular payment provider's guidelines indicate the payment provider will compensate the doctor or medical personnel for treatment of the patient, or the like.
Moreover, the re-coding rules may look for complex patterns of medical codes, timing criteria between medical codes, and the like. For example, a re-coding rule may identify a previous coding of the patient in the patient's EMRs for a medical malady A, which in turn triggers an analysis of the patient's EMRs to determine if the patient was also coded with a medical code for medical malady B within a specified period of time after the entry of the medical code for medical malady A, which in turn triggers an analysis of the patient's EMRs to determine if the patient has been previously coded with a medical code for medical malady C within a second specified time period before the coding of medical malady B. If the pattern of medical codes exist in the patient's historical medical data in the patient's EMRs, then a corresponding medical code re-coding recommendation is output, e.g., added to a patient's scheduled appointment or otherwise sent as an alert or notification to the doctor or medical personnel.
Based on the alert or notification output by the mechanisms of the illustrative embodiments, the doctor or other medical personnel can evaluate whether to re-code the medical code in the patient's EMRs such that re-coding is not necessarily automatically performed. This is because some medical maladies may no longer persist with the patient and re-coding is not appropriate. In some cases, re-coding of a medical code may be performed automatically and the alert or notification may indicate that that the medical code has been automatically re-coded and providing the doctor or medical personnel to override the automatic re-coding of the medical code. The automatic re-coding may be medical code specific such that some medical codes are automatically re-coded while others are not. As a result, some alerts/notifications may specify that a medical code has been automatically re-coded while other alerts/notifications may specify that a medical code is a candidate for re-coding at the doctor or medical personnel's authorization. Interface elements may be provided, based on the nature of the alert/notification, to either override the automatic re-coding of the medical code or to initiate re-coding of the medical code in the patient's EMRs. Thus, for example, for a medical code that corresponds to type 2 diabetes with amputation, this medical code may be automatically re-coded since it is unlikely that the type 2 diabetes with amputation condition no longer persists. However, a medical code that corresponds to influenza may not be automatically re-coded since there is a high likelihood that this medical malady is no longer persisting with the patient.
Thus, with the mechanisms of the illustrative embodiments, doctors and medical personnel are informed of potentially missed medical codes for a patient such that they may evaluate whether such re-coding should be performed. In some instances, re-coding of medical codes may be automatically performed. In some illustrative embodiments, final decision making regarding re-coding is provided to the doctor or medical personnel via interface elements for overriding or authorizing the re-coding of the medical code. In this way, doctors and medical personnel are given greater opportunities to ensure that they are properly compensated for the care that they are providing.
From the above general overview of the mechanisms of the illustrative embodiments, it is clear that the illustrative embodiments are implemented in a computing system environment and thus, the present invention may be implemented as a data processing system, a method implemented in a data processing system, and/or a computer program product that, when executed by one or more processors of one or more computing devices, causes the processor(s) to perform operations as described herein with regard to one or more of the illustrative embodiments. 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, 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 Java, Smalltalk, C++ or the like, and conventional 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 block 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.
As shown in the figures, and described hereafter, one or more computing devices comprising a distributed data processing system, may be specifically configured to implement a personalized patient care plan system in accordance with one or more of the illustrative embodiments. The configuring of the computing device(s) may comprise the providing of application specific hardware, firmware, or the like to facilitate the performance of the operations and generation of the outputs described herein with regard to the illustrative embodiments. The configuring of the computing device(s) may also, or alternatively, comprise the providing of software applications stored in one or more storage devices and loaded into memory of a computing device for causing one or more hardware processors of the computing device to execute the software applications that configure the processors to perform the operations and generate the outputs described herein with regard to the illustrative embodiments. Moreover, any combination of application specific hardware, firmware, software applications executed on hardware, or the like, may be used without departing from the spirit and scope of the illustrative embodiments.
It should be appreciated that once the computing device is configured in one of these ways, the computing device becomes a specialized computing device specifically configured to implement the mechanisms of one or more of the illustrative embodiments and is not a general purpose computing device. Moreover, as described hereafter, the implementation of the mechanisms of the illustrative embodiments improves the functionality of the computing device(s) and provides a useful and concrete result that facilitates creation, monitoring, and adjusting personalized patient care plans based on personalized lifestyle information and assessment of patient adherence to the personalized patient care plan.
As mentioned above, the mechanisms of the illustrative embodiments may be implemented in many different types of data processing systems, both stand-alone and distributed. Some illustrative embodiments implement the mechanisms described herein in a cloud computing environment. It should be understood in advance that although a detailed description on cloud computing is included herein, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed. For convenience, the Detailed Description includes the following definitions which have been derived from the “Draft NIST Working Definition of Cloud Computing” by Peter Mell and Tim Grance, dated Oct. 7, 2009.
Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models. Characteristics of a cloud model are as follows:
On-demand self-service: a cloud consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with the service's provider.
Broad network access: capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).
Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).
Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.
Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.
Service models of a cloud model are as follows:
Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based e-mail). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.
Infrastructure as a Service (IaaS): the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).
Deployment models of a cloud model are as follows:
Private cloud: the cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on-premises or off-premises.
Community cloud: the cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on-premises or off-premises.
Public cloud: the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.
Hybrid cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds).
A cloud computing environment is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprising a network of interconnected nodes. A node in a cloud computing network is a computing device, including, but not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like. A cloud computing node is capable of being implemented and/or performing any of the functionality set forth hereinabove.
The server 102 generally includes a processor 104 connected via a bus 115 to a memory 106, a network interface device 124, a storage 108, an input device 126, and an output device 128. The server 102 is generally under the control of an operating system 107. Examples of operating systems include UNIX, versions of the Microsoft Windows™ operating system, and distributions of the Linux™ operating system. More generally, any operating system supporting the functions disclosed herein may be used. The processor 104 is included to be representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like. Similarly, the memory 106 may be a random access memory. While the memory 106 is shown as a single identity, it should be understood that the memory 106 may comprise a plurality of modules, and that the memory 106 may exist at multiple levels, from high speed registers and caches to lower speed but larger DRAM chips. The network interface device 124 may be any type of network communications device allowing the server 102 to communicate with other computers via the network 130.
The storage 108 may be a persistent storage device. Although the storage 108 is shown as a single unit, the storage 108 may be a combination of fixed and/or removable storage devices, such as fixed disc drives, solid state drives, floppy disc drives, tape drives, removable memory cards or optical storage. The memory 106 and the storage 108 may be part of one virtual address space spanning multiple primary and secondary storage devices.
As shown, the storage 108 of the server contains a plurality of databases. In this particular drawing, four databases are shown, although any number of databases may be stored in the storage 108 of server 102. Storage 108 is shown as containing databases numbered 118, 120, and 122, each corresponding to different types of patient related data, e.g., electronic medical records (EMRs) and demographic information, lifestyle information, treatment guidelines, personalized patient care plans, and the like, for facilitating the operations of the illustrative embodiments with regard to personalized patient care plan creation, monitoring, and modification. Storage 108 is also shown containing metadata repository 125, which stores identification information, pointers, system policies, and any other relevant information that describes the data stored in the various databases and facilitates processing and accessing the databases.
The input device 126 may be any device for providing input to the server 102. For example, a keyboard and/or a mouse may be used. The output device 128 may be any device for providing output to a user of the server 102. For example, the output device 108 may be any conventional display screen or set of speakers. Although shown separately from the input device 126, the output device 128 and input device 126 may be combined. For example, a display screen with an integrated touch-screen may be used.
As shown, the memory 106 of the server 102 includes a medical code re-coding engine application 110 configured to provide a plurality of services to users via the network 130. As shown, the memory 106 of server 102 also contains a database management system (DBMS) 112 configured to manage a plurality of databases contained in the storage 108 of the server 102. The memory 106 of server 102 also contains a web server 114, which performs traditional web service functions, and may also provide application server functions (e.g. a J2EE application server) as runtime environments for different applications, such as the medical code re-coding engine application 110.
As shown, client computer 132 contains a processor 134, memory 136, operating system 138, storage 142, network interface 144, input device 146, and output device 148, according to an embodiment of the invention. The description and functionality of these components is the same as the equivalent components described in reference to server 102. As shown, the memory 136 of client computer 132 also contains web browser 140, which is used to access services provided by server 102 in some embodiments.
The particular description in
Referring now to
Referring now to
The hardware and software layer 360 includes hardware and software components. Examples of hardware components include mainframes, in one example IBM™ zSeries™ systems; RISC (Reduced Instruction Set Computer) architecture based servers, in one example IBM pSeries™ systems; IBM xSeries™ systems; IBM BladeCenter™ systems; storage devices; networks and networking components. Examples of software components include network application server software, in one example IBM Web Sphere™ application server software; and database software, in one example IBM DB2™ database software. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation registered in many jurisdictions worldwide.).
The virtualization layer 362 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers; virtual storage; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients. In one example, management layer 364 may provide the functions described below. Resource provisioning provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources may comprise application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal provides access to the cloud computing environment for consumers and system administrators. Service level management provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.
Workloads layer 366 provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation; software development and lifecycle management; virtual classroom education delivery; data analytics processing; transaction processing; and, in accordance with the mechanisms of the illustrative embodiments, a medical code re-coding engine functionality.
As discussed above, the illustrative embodiments provide a medical code re-coding engine which may be implemented in various types of data processing systems.
As shown in
The medical code re-coding engine 410 provides the various engines and logic for evaluating patient electronic medical records (EMRs) to determine instances of previous medical codes associated with a patient that may have been missed or otherwise are candidates for re-coding during a current time period. The patient's EMRs 425 are provided by one or more patient EMR sources 420 to the medical code re-coding engine 410 via the information communication interfaces 411. The information communication interfaces 411 provides one or more data communication interfaces through which patient data may be obtained from various patient EMR data sources 420 as well as medical knowledge and payment provider guideline sources 430. Moreover, the interfaces 411 comprise interfaces for interfacing with a scheduling system 440 to receive requests 402 to initiate evaluations for medical code recoding and provide alerts/notifications 419 of candidate medical codes for re-coding or medical codes that have automatically been re-coded.
The EMR data sources 420 may comprise various sources of electronic medical records including individual doctor medical practice systems, hospital computing systems, medical lab computing systems, personal patient devices for monitoring health of the patient, dietary information, and/or activity information of the patient, or any other source of medical data that represents a particular patient's current and historical medical condition. The EMR data sources 420 may further comprise data representing the patient demographics since such information is typically gathered by providers of such medical data. In accordance with the illustrative embodiments, the patient EMRs represent patient medical history information that is evaluated by the medical code re-coding engine 410 to determine whether any medical codes may have been missed by the doctor or other medical personnel during a current medical treatment compensation time frame and are candidates for re-coding.
The medical knowledge and payment provider guideline sources 430 provide information to the medical code re-coding engine 410 indicating general medical knowledge regarding various medical maladies from established medical knowledge bases as well as information regarding policies of various payment providers as specified in payment provider guidelines. For example, the medical knowledge may comprise medical knowledge bases, either in a structured format or a natural language format, which provide, among other information, the persistency of medical maladies, comorbidities, and the like. This information may be used by the medical code re-coding engine 410 to determine whether a particular medical malady associated with a medical code in a patient EMR is of a type that is likely to persist across medical treatment compensation time frames, what other medical maladies are comorbidities to the medical malady corresponding to a medical code present in a patient EMR, and the like. In the case of comorbidities, this information may be used to trigger the medical code re-coding engine 410 to look for additional medical codes in the patient's EMRs 425 and/or identify additional medical codes that may have been missed as potential candidates for coding or re-coding.
With regard to payment provider guidelines, the medical knowledge and payment provider guideline sources 430 may provide information indicating the guidelines that payment providers have established for compensating medical care providers for the treatment of patients. For example, a guideline may be of the type that a flat fee of $X is paid to a doctor on a calendar year basis for each type 2 diabetes patient that the doctor treats while a flat fee of $Y is paid to the doctor on a calendar year basis if the type 2 diabetes patient is also an amputee. Other guidelines may indicate that the payment provider authorizes payment of $Z each time the doctor has a scheduled appointment with a patient coded with a medical code Q. Many different types of guidelines may be established by the payment providers for compensating medical care providers and each payment provider may have their own established guidelines. These guidelines are provided to the medical code re-coding engine 410 for use in determining which medical codes previously coded to a patient in the patient's EMR, or comorbidities of medical maladies associated with medical codes previously present in the patient's EMR, are candidates for coding or re-coding, as described hereafter.
The scheduling system 440 comprises a computing system used for scheduling appointments between the doctor(s)/medical personnel and patients. Various types of computing system based appointment scheduling systems are generally known in the art. The mechanisms of the illustrative embodiments augment such scheduling systems 440 to include an alert/notification module 446 which operates in concert with the medical code re-coding engine 410 to provide alerts/notifications of automatically applied re-codings or candidates for re-coding, as well as provide interfaces through which a doctor/medical personnel (hereafter referred to simply as the “doctor”) may confirm, reject, or otherwise authorize/deny coding or re-coding of a medical code identified as a candidate for coding/re-coding by the medical code re-coding engine 410.
The scheduling system 440 may send communications to a doctor communication system 450 and patient communication system 460 in any suitable communication form, e.g., automated telephone call, electronic mail message, instant message, text message, scheduling system 440 proprietary message output, or the like. The doctor communication system 450 and patient communication system 460 may comprise any suitable communication system including desktop and portable or tablet type computing devices, smart phones, personal digital assistants, conventional telephones, or the like. In one illustrative embodiment, the patient communication system 460 and doctor communication system 450 are computing devices.
With regard to the communications sent to the doctor communication system 450, the communications informing the doctor of a scheduled appointment with a patient may include additional alerts/notifications 442 of medical codes determined to be candidates for re-coding as determined by the medical code re-coding engine 410 and integrated into the scheduled appointment by the alert/notification module 446. In some illustrative embodiments, the communications may inform the doctor of a medical code having been automatically coded or re-coded by the medical code re-coding engine 410. In both cases, user interface elements may be provided for allowing the doctor to confirm/reject or authorize/deny the coding/re-coding that is proposed or already automatically performed. The alert/notification module 446 of the scheduling system 440 may receive doctor inputs from the doctor 455 and determine whether to re-code a medical code based on the doctor's input or not-record the medical code. Moreover, in some illustrative embodiments, the alert/notification module 446 may determine whether to roll-back a previously automatically coded or re-coded medical code in response to the doctor 455 input. The alert/notification module 446, based on the doctor 455 input, may communicate with the medical code re-coding engine 410 to cause the medical codes that are candidates for coding/re-coding to be coded in the patient's EMR 425 or previous updates to code/re-code the medical code rolled-back.
With regard to communications sent to the patient 465, the appointment notification 444 is sent to the patient communication system 460 to inform the patient 465 of their scheduled appointment. This appointment notification 444 does not include the alerts/notifications of candidate medical codes for coding/re-coding as with the communications sent to the doctor 455.
With regard to the operation of the medical code re-coding engine 410, the patient EMRs analysis engine 412, in response to a trigger event (patient scheduling an appointment, elapse of specified time period such as a payment provider's medical treatment compensation time period, user initiated request, or the like), identifies instances of medical codes in a patient EMR 425 that may have been missed from one medical treatment compensation time frame to another, as specified by various established programs as defined by the payment provider guidelines obtained from the payment provider guideline sources 430, and thus, may be candidates for re-coding in the patient EMR. In some illustrative embodiments, medical knowledge and payment provider guidelines may further indicate to the patient EMRs analysis engine 412 possible comorbidities that are potential candidates for coding or re-coding in the patient EMR.
In response to analysis of the patient EMRs 425 being initiated, re-coding rules from the recoding rules database 417 are applied to the identified occurrences of the medical codes in the patient's EMRs 425 to determine if patterns of occurrences of medical codes meet criteria specified by the re-coding rules. The re-coding rules identify different types of medical codes that are likely persistent medical maladies or conditions that need to be re-coded from time to time by the doctor 455. Such medical codes may be specified based on medical knowledge of the various medical maladies, payment provider guidelines, and the like, such as obtained from the medical knowledge and payment provider guideline sources 430. The rules themselves may be automatically generated from a natural language processing of this information from sources 430 or from a subject matter expert or other user that manually constructs the rules and stores them as part of the recoding rules database 417.
The re-coding rules engine 413 applies the re-coding rules in the re-coding rules database 417 to the occurrences of medical codes identified by the patient EMRs analysis engine 412 that are present in the patient's EMR 425 to determine if criteria or conditions of the re-coding rules are satisfied. In response to finding a previous occurrence of a medical code in a previous medical treatment compensation time period for which a re-coding rule is applicable, medical codes that have been entered into the patient's EMR 425 in a current medical treatment compensation time period may be evaluated to determine if any of the medical codes correspond to the previous occurrence of a medical code. If such a re-coding of the medical code does not exist within the current medical treatment compensation period, then an alert or notification may be appended or added to appointment information for the patient via the scheduling system 440 such that when the doctor 455 is notified of the patient's scheduled appointment via the doctor communication system 450, the alert or notification 442 of the potential need to re-code the patient's previously coded medical malady is also output to the doctor 455 via the scheduling system 440.
The identification of occurrences of such medical codes in the patient's EMR 425 may be filtered by the patient EMR analysis engine 412 according to date/time criteria such that only medical codes that have occurred within a particular period of time may be considered as triggers for applying re-coding rules 417 by the re-coding rules engine 413. Such periods of time may be specific to the particular type of medical code found as may be determined based on criteria associated with each medical code indicative of how long a particular medical malady may persist, or how long a particular payment provider's guidelines indicate the payment provider will compensate the doctor or medical personnel for treatment of the patient, or the like. For example, if a payment provider only pays for the first 3 years of treatment of a malady, then if this medical code is found more than 3 years prior to the current time point, then the occurrence of the medical code may be filtered out by the patient EMRs analysis engine 412 as a basis for application of re-coding rules 417.
The re-coding rules engine 413 may apply re-coding rules 417 to occurrences of medical codes found by the patient EMRs analysis engine 412 which look for complex patterns of medical codes, timing criteria between medical codes, and the like. The re-coding rules engine 413 may work in conjunction with the patient EMRs analysis engine 412 to analyze the patient EMRs 425 to identify whether such patterns exist in the patient's EMRs 425. If the pattern of medical codes, timings between codes, and other pattern criteria exist, e.g., specific patient demographics being present, in the patient's historical medical data in the patient's EMRs 425, then the re-coding alert/notification engine 414 is signaled to generate a corresponding medical code re-coding recommendation. This alert/notification is output by the alert/notification output engine 415 to the alert/notification module 446 of the scheduling system 440 is output, e.g., added to a patient's scheduled appointment or otherwise sent as an alert or notification to the doctor 455.
Based on the alert or notification 442 output by the scheduling system 440 to the doctor communication system 450, the doctor 455 is given information to evaluate whether to re-code the medical code in the patient's EMRs 425 such that re-coding is not necessarily automatically performed. In some cases, re-coding of a medical code may be performed automatically by the automated re-coding engine 416 and the alert or notification 442 may indicate that that the medical code has been automatically re-coded and provide the doctor 455 graphical user interface elements or options to override the automatic re-coding of the medical code already performed by the automated re-coding engine 416. The automatic re-coding may be medical code specific such that some medical codes are automatically re-coded while others are not with such determinations being performed by the automated re-coding engine 416 when it is informed of the decision of the re-coding rules engine 413 that the medical code is a candidate for coding (such as in the case of comorbidities) or re-coding. The actual automatic coding or re-coding may be performed with the patient EMR sources 420 via the information communication interfaces 411.
As a result, some alerts/notifications 442 may specify that a medical code has been automatically re-coded while other alerts/notifications 442 may specify that a medical code is a candidate for re-coding at the doctor's authorization. Interface elements may be provided, based on the nature of the alert/notification 442, to either override the automatic re-coding of the medical code or to initiate re-coding of the medical code in the patient's EMRs 425.
In response to the operation being triggered, the patient's EMRs are retrieved and analyzed to identify occurrences of medical codes in the patient's EMRs (step 520). A set of medical code occurrences is selected for further evaluation for re-coding (step 530). The selection of such medical codes may be based on filter criteria applied to the medical code occurrences based on the type of medical code, e.g., for a medical code of type X, only occurrences of this medical code within the past 3 years are selected for further evaluation. Other filters may be applied such as looking for particular types of medical codes directed to a selected set of medical maladies, for example. Any suitable filter criteria for selecting a set of medical codes for further evaluation directed to re-coding may be used without departing from the spirit and scope of the illustrative embodiments.
Re-coding rules are then applied to the selected set of medical code occurrences (step 540). The re-coding rules may be automatically generated from natural language processing of medical knowledge, payment provider guidelines, or the like. Alternatively, the re-coding rules may be manually generated by subject matter experts. The re-coding rules may be part of a re-coding rule database and may be associated with particular medical codes for particular payment providers. Thus, a re-coding rule is matched to an occurrence of a medical code based on the re-coding rule being associated with the medical code. For those re-coding rules matching a medical code in the set of medical code occurrences, the rule is applied to identify whether or not the medical code, other medical codes, timings between medical codes, other EMR data, and the like, match a pattern specified in the re-coding rule. Those that match are identified as medical codes that are candidates for re-coding (step 550) while those that do not match the specified pattern are not identified as candidates for re-coding.
A notification of the candidates for re-coding is generated (step 560). The notification is then added to or appended to the patient's EMRs, a patient appointment record in a scheduling system, or otherwise output for review by a doctor or other medical personnel (step 570). In other illustrative embodiments, a step (not shown) of automatically applying the re-coding may be performed and the notification may indicate that the re-coding was already performed and give the doctor an opportunity to roll-back the re-coding. The notification is sent to the doctor (step 580). In the depicted example operation, the notification is sent as part of the appointment record, however the illustrative embodiments are not limited to such and any suitable form of output to the doctor may be used without departing from the spirit and scope of the illustrative embodiments.
Thus, with the mechanisms of the illustrative embodiments, doctors and medical personnel are informed of potentially missed medical codes for a patient such that they may evaluate whether such re-coding should be performed. In this way, doctors and medical personnel are given greater opportunities to ensure that they are properly compensated for the care that they are providing.
As noted above, it should be appreciated that the illustrative embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In one example embodiment, the mechanisms of the illustrative embodiments are implemented in software or program code, which includes but is not limited to firmware, resident software, microcode, etc.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems and Ethernet cards are just a few of the currently available types of network adapters.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form 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 embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated. 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.
