Patent Application
20120323598
Physicians and other healthcare professionals (referred to herein generally as “healthcare providers”) must document their encounters with patients so that the resulting documentation can be submitted to the appropriate payer, such as an insurance company or the Centers for Medicare and Medicaid Services (CMS). Failure to create such documentation and to include the required information in the required format can result in refusal by the payer to reimburse the healthcare providers for the medical services they have provided and the costs they have incurred.
Each payer has its own requirements for the content and format of the documentation that must be submitted to obtain payment. For example, to obtain reimbursement for a medical procedure, the corresponding documentation must typically describe both the procedure that was performed and the medical justification for that procedure. Furthermore, payers typically will only provide reimbursement for a medical procedure if the documentation of that procedure was written and/or approved by a physician. Documentation from other sources, such as electronic medical records (EMRs) and notes written by nurses, is not considered admissible for purposes of reimbursement. Therefore, if a particular procedure is documented, for example, in a nurse's notes but not in any physician's notes, then the payer typically will not provide reimbursement for the procedure because no admissible source of evidence has been provided.
Such a system both places a significant burden on physicians to take responsibility for creating records that are admissible as evidence for billing purposes, and excludes a significant amount of documentation for use in justifying and generating bills. What is needed, therefore, are improved techniques for generating bills based on available documentation.
A computerized billing code generator reviews billing source data containing both admissible data (such as physician's notes) and inadmissible data (such as nurse's notes). The billing code generator determines whether to generate a request to review the first data based on both the first data and the second data. For example, the billing code generator may generate the request in response to determining that the second data contains information that is inconsistent with information contained in the first data. As another example, the billing code generator may generate the request in response to determining that the second data contains information that is not contained within the first data.
In one aspect, a method includes identifying first data relating to a fact, wherein the first data is admissible in a billing process. The method includes identifying second data relating to the fact, wherein the second data is not admissible in the billing process. The method includes deciding, based on the first data and the second data, whether to generate a request to review the first data.
In another aspect, a system includes a billing code generator executing on a computing device. The system includes a data identification component executed by the billing code generator, identifying first data relating to a fact, wherein the first data is admissible in a billing process and identifying second data relating to the fact, wherein the second data is not admissible in the billing process. The system includes a data analysis component executed by the billing code generator and deciding, based on the first data and the second data, whether to generate a request to review the first data.
In still another aspect, a method includes determining to generate a request to review first data relating to a fact, based on an analysis of the first data and second data relating to the fact, wherein the first data is admissible in a billing process and the second data is not admissible in the billing process. The method includes generating a proposed request to review the first data. The method includes requesting, from a user, review of the proposed request. The method includes determining that the user accepted the proposed request. The method includes generating a final request based on determining that the user accepted the proposed request
Other features and advantages of various aspects and embodiments of the present invention will become apparent from the following description and from the claims.
The foregoing and other objects, aspects, features, and advantages of the disclosure will become more apparent and better understood by referring to the following description taken in conjunction with the accompanying drawings, in which:
Despite the increasingly widespread use of electronic medical records (EMRs) and other structured data in the healthcare field, many physicians still create medical reports in the form of freeform narrative notes, which are a kind of unstructured data. Such notes often are stored in conventional word processing documents, such as Microsoft Word documents. For example, after a physician has completed a visit with a patient, the physician may type or dictate a report of the visit into a word processing document. Such a record may include, for example, information such as the date of the visit, the patient's name and other identifying information, the patient's recent medical history, any complaints voiced by the patient, the physician's observations, any diagnoses made by the physician, any medications prescribed by the physician, and any procedures performed by the physician on the patient. Such indications in the record may be referred to as “facts.”
At some time after the visit, a human expert, known as a “billing coder,” reads the physician's report (or possibly the report in addition to other related reports and documents) to derive appropriate billing codes that may be used to generate a bill for the patient's visit. For example, if the billing coder finds that the report indicates that the physician performed a certain procedure on the patient, the billing coder may generate a billing code corresponding to that procedure. Different procedures typically are, but need not be, associated with different billing codes.
Because the physician's report and other documents reviewed by the billing coder may contain freeform narrative text, the billing coder's task typically requires not only the ability to read and understand such text, but also a knowledge of the applicable billing codes and of the rules that permit billing codes to be generated based on available evidence. Such rules include, for example, rules defining the correspondence between medical procedures and billing codes, and rules governing the admissibility of evidence for generating billing codes. For example, such rules may dictate that only information generated or approved by a physician is admissible, and that only such information may therefore be used as the justification for generating billing codes.
The data reviewed by a human billing coder may contain incomplete or inconsistent information (or “facts”), in which case the billing coder may need to contact the physician to ask for additional information or clarification, respectively. Any such information received from the physician is typically provided as an addendum to the originally-provided information. For example, if the physician's notes indicate that the physician administered cortisone to the patient but the notes do not indicate the dosage applied, the billing coder may need to contact the physician to obtain the administered dose and to provide an indication of the administered dose in an addendum.
In the example provided above, the billing coder could determine that required information was missing merely by examining the physician's notes. As mentioned above, the physician's notes are admissible evidence for purposes of bill generation. In other cases, however, the billing coder may determine that information required to generate a bill is missing, or that inconsistent information has been provided, based in whole or in part on inadmissible evidence, such as the contents of electronic medical records and/or nurse's notes. One example of inadmissible data is data in an HR7-CCD (Continuity of Care Document). Certain regulations require EMR systems to provide data in an HR7-CCD record. Yet the information contained in an HR7-CCD record typically is inadmissible as evidence for billing purposes.
If the billing coder discovers that the physician's notes indicate that the physician administered 50 mg of cortisone but the nurse's notes indicate that the dosage was 100 mg, this inconsistency may cause the billing coder to contact the physician for clarification. As another example, if the physician's notes do not indicate that cortisone was administered, but the nurse's notes indicate that 100 mg of cortisone was administered, this inclusion of information in the nurse's notes that is not contained in the physician's notes may cause the billing coder contact the physician to provide the missing information or to confirm that the nurse's notes are incorrect.
Computer-assisted billing coding (CAC) systems apply natural language processing (NLP) technology to improve the productivity and consistency of human billing coders. An example of such a CAC system is described in co-pending and commonly-owned U.S. patent application Ser. No. 13/025,051, filed on Feb. 10, 2011, entitled, “Providing Computable Guidance to Relevant Evidence in Question-Answering Systems,” which is hereby incorporated by reference herein.
Embodiments of the present invention may be used to increase the accuracy and completeness of the billing codes generated by CAC systems by enabling such systems to make use of alternative sources of data (i.e., data sources that are not admissible as evidence for purposes of bill generation) to generate billing codes.
Referring to
As discussed above, facts may be information included in a data source admissible in a billing process that the billing code generator 102 reviews and associates with a billing code. Examples include information such as the date of the visit, the patient's name and other identifying information, the patient's recent medical history, any complaints voiced by the patient, the physician's observations, any diagnoses made by the physician, any medications prescribed by the physician, and any procedures performed by the physician on the patient. By way of example, the data identification component 104 may identify a fact (such as an indication that the physician administered medicine to a patient), first data relating to the fact (such as a physician's note indicating that a physician administered a certain dosage of medication for a patient) and second data relating to the fact (such as a nurse's note indicating that the physician administered a different dosage of medication for the patient).
In general, a computerized billing code generator 102 implemented according to embodiments of the methods and systems described herein may have access to a variety of data which may possibly contain information that is relevant to the generation of billing codes for a bill. The set of data accessed by the billing code generator when generating a bill is referred to herein as “billing source data.” Information that is “relevant” to the generation of billing codes may include both admissible and inadmissible information. In one embodiment, and as depicted in
Billing source data may include any of a variety of data, such as freeform text documents, structured documents, electronic medical records, scanned documents (e.g., handwritten progress notes), and other kinds of database records. Such data may have been entered manually or created (manually and/or automatically) based on speech. Structured documents in billing source data may, for example, have been created using techniques disclosed in U.S. Pat. No. 7,584,103 B2, issued on Sep. 1, 2009, entitled, “Automated Extraction of Semantic Content and Generation of a Structured Document from Speech.”
When generating a bill for a particular patient encounter, the billing source data may include only data related to that particular patient encounter, or may include both such data and other data, such as information about other encounters with the same patient or other information about the patient. By way of example, the data identification component 104 may identify data (either admissible data 112 or inadmissible data 114 or both) that relates to a specific patient encounter such as, without limitation, a specific appointment between a healthcare professional and a patient, a specific diagnosis made during the specific appointment, and a specific prescription written for the patient. In one embodiment, the data analysis component 106 determines, based upon second data including data associated with a patient encounter, to generate the request to review the first data. As another example, the data identification component 104 may identify data (either admissible data 112 or inadmissible data 114 or both) that relates to a plurality of patient encounters such as, without limitation, previous diagnoses, previous prescriptions, and previous medical procedures. In another embodiment, the data analysis component 106 determines, based upon second data including data associated with a plurality of patient encounters, to generate the request to review the first data.
Referring ahead to
In some embodiments, the billing code generator 102 receives a plurality of data including the first data and the second data (as well as, in some instances, documentation related to a patient encounter) with a request to generate billing codes. For example, a component such as an electronic master patient index (eMPI) may search the billing source database 110 for data relevant to the request and provide that data to the billing code generator 102. Alternatively, the billing code generator 102 may receive the plurality of data (such as documentation related to a patient encounter) with the request. As another example, the billing code generator 102 may receive a structured data source containing the plurality of data. For example, the data identification component 104 may be a component that accesses structured data sources to identify a plurality of records relevant to a request for generating billing codes. In other embodiments, the billing code generator 102 has access to the billing source database 110 and retrieves the first data and the second data. For example, the billing code generator 102 may search for data in the billing source database 110 having a common identifier (e.g., a common medical record number, patient identifier, or other common identifier). In one example, the billing code generator 102 is in communication with an electronic master patient index (eMPI) and may use the eMPI to identify user identifiers (such as patient or physician identifiers) across clinical systems (e.g., from one or more systems including, without limitation, lab systems, admissions systems, and electronic medical records systems); with that user identifier, the billing code generator 102 can then query clinical systems for data relating to particular facts.
Referring now to
In one embodiment, the data identification component 104 stores the generated data source 116 (e.g., on the computing device 101). In such an embodiment, the data identification component 104 may include a link to or identifier of the unit of data associated with the data source 116. In yet another embodiment, and as depicted in shadow in
In some embodiments, rather than generate new data sources, the data identification component 104 identifies a data source within an admissible unit of data 112 or an inadmissible unit of data 114. In one of these embodiments, the unit of data explicitly identifies the data source. As one example, information in the unit of data may identify a name or title of a person or system generating the unit of data (e.g., Dr. Smith or an identification of an Electronic Medical Records System). Examples of data sources include categories (such as “physician,” “nurse,” and “automatically generated”) and identifiers of individual sources (such as “Dr. Mary Carpenter” and “Nurse Jane Williams”). A unit of data may be associated with multiple data sources 116 (e.g., both “physician” and “Dr. Mary Carpenter”).
Referring now to
In one embodiment, the data identification component 104 stores the generated admissibility value 118 (e.g., on the computing device 101). In such an embodiment, the data identification component 104 may include a link to or identifier of the unit of data associated with the admissibility value 118. In yet another embodiment, and as depicted in shadow in
Referring now to
Referring now to
Referring back to
In one embodiment, the billing code generator 102 generates a request to review a billing code generated based upon at least one of the first data and the second data, which may provide a user of the system with an opportunity to confirm that the billing code generator 102 generated an appropriate billing code. As another example, requesting review of data may provide a user with an opportunity to clarify inconsistencies between data or otherwise lessen a level of impact that omitted or inaccurate data may have on the user, on the accuracy of billing data, and/or on a level of care provided. Billing code generators implemented according to embodiments of the methods and systems described herein may process billing source data to determine whether to generate a request to obtain missing information and/or to clarify inconsistent information for the purpose of generating billing codes. The decision to generate such a request may be based in whole or in part on inadmissible evidence.
Referring now to
As another example, the billing code generator 102 may identify inconsistencies other than inconsistencies between the first data and the second data, such as, without limitation, omissions of data. For example, a coder may omit a billing code that would be supported by inadmissible evidence (e.g., a physician omitted a billing code while a nurse's note provided inadmissible evidence that would have supported the inclusion of the billing code by the doctor). The billing code generator 102 may also identify an inconsistency when the billing code generator 102 does not have access to a unit of data. For example, if there is admissible information in a patient's chart, such as a scanned note included in the data provided to the billing code generator 102, but the billing code generator 102 does not have the functionality to analyze the format or type of information, the billing code generator 102 may rely on inadmissible data to support a billing code, while determining to generate a request to review the billing code.
Alternatively, the billing code generator 102 may determine to generate the request if there are no inconsistencies. For example, the billing code generator 102 may analyze data related to a fact, determine that the data are consistent, and generate a suggested billing code; however, in some instances, the billing code generator 102 may determine that a level of confidence in generating the suggested billing code is below a predetermined threshold. In such an example, the billing code generator 102 may increase a level of confidence associated with a generated billing code based on analysis of second data, which may be inadmissible data but which provides sufficient support to increase the level of confidence. In this example, the billing code generator 102 may avoid having to request review of the billing code if, for example, the increased level of confidence exceeds the predetermined threshold for triggering required review.
Referring now to
Referring now to
As shown in
In some embodiments, the data analysis component 106 takes multiple factors into account when determining whether to generate a request for review of data. In one of these embodiments, an analysis, for example, of just the weight value or of just the admissibility value might indicate that no request should be made. For example, referring to
Referring now to
Referring now to
Referring now to
In some embodiments, the billing code generator 102 may analyze a cost of generating the request to determine whether to generate the request. For example, the billing code generator 102 may analyze how expensive a request is in terms of physician disruption. In such an embodiment, the cost might vary depending on what user, or type of user, receives the request—a doctor's time in reviewing and responding to a request may be more expensive than a nurse's time and the nurse's time may be more expensive than that of a computerized system, such as an electronic medical records system. Additionally, the cost might vary depending on when the request is generated. For example, a real time interruption of a physician may be more costly than generating the request but storing it for review by the physician at a convenient time.
In other embodiments, the billing code generator 102 may analyze a value of generating the request to determine whether to generate the request. For example, if generating the request and receiving confirmation or modification of the first data would have a substantially material impact on the generated billing codes or a level of care, the billing code generator 102 may determine to generate the request. As another example, the billing code generator 102 may determine that an inconsistency between the first data and the second data or an inaccuracy in a billing code would have a level of impact exceeding a predetermined threshold. For instance, the billing code generator 102 may identify a second data and a third data each of which have a low admissibility value and a low weight but an inconsistency between the first data and the combined second data and third data may have a level of impact that exceeds a particular threshold. In determining whether to generate the request to review, the billing code generator 102 may take into account multiple factors including any combination of one or more of weight, admissibility, cost, and value.
In one embodiment, the billing code generator 102 transmits the request for review to a user of the billing code generator 102. In another embodiment, the billing code generator 102 transmits the request for review to a user of a second computing device 101b, the user having generated a report including the first data. Note that any of the requests disclosed herein may be generated and provided to the physician or other user at any time. For example, the techniques disclosed herein may be applied while a physician or other user is dictating or otherwise generating a report. As a result, a request may be generated and provided to the physician or other user in real-time, i.e., while the user is generating the report (e.g., while the user is dictating the report, immediately or soon after the user has dictated the portion of the report that triggered the request, but before the user has dictated the entire report). In other words, it is not required that the entire report be generated before a request is made to the user who dictated or otherwise generated the report.
In some embodiments, to apply the techniques described herein while a user is generating data, the billing code generator 102 receives a first portion of the data during generation of a second portion of the data; the billing code generator 102 analyzes the first portion of the first data and identifies the first portion as first data relating to the fact and admissible in the billing process, based on the analysis. For example, in an embodiment where a physician is dictating a physician's report, the physician may provide completed portions of the report to the billing code generator 102 for analysis while finishing other, uncompleted portions of the report; in this way, the system can alert the physician about additional information required before the physician completes an initial version of the report. In one of these embodiments, the billing code generator 102 transmits the request for review to a user of the billing code generator 102 during generation of the first data.
Although described herein as a system in which a user directly accesses the billing code generator 102, in some embodiments, a second computing device 101b interacts with the billing code generator 102 instead. In one of these embodiments, a user accesses the second computing device 101b to generate data and the second computing device 101b interacts with the billing code generator 102 for analysis of the data and a determination as to whether to issue a request to the user for review of the data. By way of example, the second computing device 101b may execute an automatic speech recognition engine (ASR) with which a user of the second computing device 101b generates data (e.g., because the ASR creates source data based on the user's speech). Continuing with this example, the ASR may create a first portion of the first data based on the user's speech while the user is speaking and provide the first portion to the billing code generator 102 for analysis while the user continues to speak and the ASR continues to generate and transmit to the billing code generator 102 subsequent portions of the first data for additional analyses.
Alternatively, for example, the techniques disclosed herein may be applied after the physician or other user has dictated or otherwise generated a report. For example, a user may dictate a report, and the dictated report may be stored and/or transmitted to another location, and the dictation may be transcribed in another location and/or at another time, possibly by a computer or other system controlled by a user other than the speaker who dictated the report; for instance, a user of a second computing device 101b may dictate the report and store the dictation on the second computing device 101b, while the transcription of the dictation may occur on a third computing device 101c. At this later time, the techniques disclosed herein may be applied to the transcript; for example, the third computing device 101c may transmit the transcript to the billing code generator 102 executing on the computing device 101. As a result, in this scenario it may be necessary to contact the physician or other dictating user after the user has finished dictating or otherwise creating the report.
Although in the examples above the “request” is described as a request to a physician, this is merely an example and does not constitute a limitation of the present invention. More generally, the request may be a request to any source of data, such as a source of data that has a high weight and/or a high admissibility value. The request may be a request to a human or to a computer-based system, such as an EMR system. The response to the request may, therefore, be provided manually (as in the case of a request made to a physician) or automatically (as in the case of a request made to an EMR system). Furthermore, the request may include requests to individuals or systems other than a physician. For example, in some situations, the billing code generator 102 may generate a request to an electronic medical records system. As another example, the billing code generator 102 may store the request as a data record and not transmit the data record. Once stored, the request may subsequently be transmitted to another computing device or retrieved for display by the billing code generator 102; for example, the billing code generator 102 may transmit the request to a second computing device 101b, and another system may request access to the request or a user may request a display of the request. As an alternative example, the billing code generator 102 may generate an indication that the first data is missing information or that there is information that conflicts with the first data; the billing code generator 102 may associate such an indication with the first data such that a reviewer of the first data will also see the indication (e.g., by embedding text into the first data, rendering the indication when the first data is rendered, or otherwise bringing the indication to a reviewer's attention). As discussed above in connection with
The request itself may be generated automatically, or may be made only after review and approval by a human billing coder. Referring now to
Embodiments of the present invention have a variety of advantages. For example, embodiments of the present invention enable billing coding information to be generated more accurately and with a higher degree of completeness than is possible when using existing Computer Assisted Billing Coding (CAC) systems, because embodiments of the present invention are capable of using evidence that is not directly admissible for billing to determine whether to request missing information or to request clarification of inconsistent information. As a result, embodiments of the present invention may enable healthcare providers to achieve a higher rate of reimbursement at a lower cost than is now presently achievable.
It is to be understood that although the invention has been described above in terms of particular embodiments, the foregoing embodiments are provided as illustrative only, and do not limit or define the scope of the invention. Various other embodiments, including but not limited to the following, are also within the scope of the claims. For example, elements and components described herein may be further divided into additional components or joined together to form fewer components for performing the same functions.
Inadmissible sources of data that may be used by embodiments of the present invention may include narrative freeform text (such as the text typically found in word processing documents), discrete data elements (such as the data elements typically found in an EMR or other database record), or any combination of the two.
Any of the functions disclosed herein may be implemented using means for performing those functions. Such means include, but are not limited to, any of the components disclosed herein, such as the computer-related components described below.
The techniques described above may be implemented, for example, in hardware, one or more computer programs tangibly stored on one or more computer-readable media, firmware, or any combination thereof. The techniques described above may be implemented in one or more computer programs executing on (or executable by) a programmable computer including any combination of any number of the following: a processor, a storage medium readable and/or writable by the processor (including, for example, volatile and non-volatile memory and/or storage elements), an input device, and an output device. Program code may be applied to input entered using the input device to perform the functions described and to generate output using the output device.
Each computer program within the scope of the claims below may be implemented in any programming language, such as assembly language, machine language, a high-level procedural programming language, or an object-oriented programming language. The programming language may, for example, be a compiled or interpreted programming language.
Each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps of the invention may be performed by one or more computer processors executing a program tangibly embodied on a computer-readable medium to perform functions of the invention by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives (reads) instructions and data from a memory (such as a read-only memory and/or a random access memory) and writes (stores) instructions and data to the memory. Storage devices suitable for tangibly embodying computer program instructions and data include, for example, all forms of non-volatile memory, such as semiconductor memory devices, including EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROMs. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits) or FPGAs (Field-Programmable Gate Arrays). A computer can generally also receive (read) programs and data from, and write (store) programs and data to, a non-transitory computer-readable storage medium such as an internal disk (not shown) or a removable disk. These elements will also be found in a conventional desktop or workstation computer as well as other computers suitable for executing computer programs implementing the methods described herein, which may be used in conjunction with any digital print engine or marking engine, display monitor, or other raster output device capable of producing color or gray scale pixels on paper, film, display screen, or other output medium.
Any data disclosed herein may be implemented, for example, in one or more data structures tangibly stored on a non-transitory computer-readable medium. Embodiments of the invention may store such data in such data structure(s) and read such data from such data structure(s).
This application claims priority from U.S. Provisional Patent Application Ser. No. 61/498,589, filed on Jun. 19, 2011, entitled, “Using Alternative Sources of Evidence in Computer-Assisted Billing Coding,” Attorney Docket Number M0002-1038L; which is hereby incorporated by reference. This application is related to U.S. patent application Ser. No. 13/025,051, filed on Feb. 10, 2011, entitled, “Providing Computable Guidance to Relevant Evidence in Question-Answering Systems,” Attorney Docket Number M0002-1028; U.S. patent application Ser. No. 13/242,532, filed on Sep. 23, 2011, entitled, “User Feedback in Semi-Automatic Question Answering Systems,” Attorney Docket Number M0002-1032; all of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61498589 | Jun 2011 | US |
