Patent Application
20080059238
The foregoing and other objects, features, and advantages of the present invention, as well as the invention itself, will be more fully understood from the following description of various embodiments, when read together with the accompanying drawings, in which:
Automating medical practice workflow and billing presents difficulties in many aspects, e.g., installation of a system, processing the eligibility or other statuses of patients, interacting with the workflow, other health care providers, and within the constraints of payor requirements, as well as measuring the success of a practice once it has been established. The invention encompasses several aspects, embodied in varying implementations that address these shortcomings.
The medical practice client-server network 30 and the payor server network 40 can be a local-area network (LAN), a medium-area network (MAN), or a wide area network (WAN) such as the Internet or the World Wide Web. In one embodiment, the medical practice client-server network 30 (e.g., the medical practice client-server communication path 25) supports secure communications. In a further embodiment, communications occur after a medical care provider's, or user's, password is verified by the medical practice management server 15. Exemplary embodiments of the communication paths 25, 35 include standard telephone lines, LAN or WAN links (e.g., T1, T3, 56 kb, X25), broadband connections (e.g., ISDN, Frame Relay, ATM), and wireless connections. The connections over the communication paths 25, 35 can be established using a variety of communication protocols (e.g., TCP/IP, IPX, SPX, NetBIOS, Ethernet, RS232, and direct asynchronous connections).
The medical practice client 10 can be any personal computer, Windows-based terminal, network computer, wireless device, information appliance, RISC Power PC, X-device, workstation, mini computer, main frame computer, personal digital assistant, or other computing device that has a windows-based desktop, can connect to a network and has sufficient persistent storage for executing a small, display presentation program. Windows-oriented platforms supported by the medical practice client 10 can include, without limitation, Windows 3.X, Windows 95, Windows 98, Windows NT 3.51, Windows NT 4.0, Windows 2000, Windows XP, Windows Vista, Windows CE, Windows Mobile, Mac/OS, OS X, Java, and Unix/Linux. The medical practice client 10 can include a visual display device (e.g., a computer monitor), a data entry device (e.g., a keyboard), persistent or volatile storage (e.g., computer memory) for storing downloaded application programs, a processor, and a pointing device such as a mouse or digitized pen.
The medical practice client 10 includes a medical practice client user interface 45. The interface 45 can be text driven (e.g., DOS) or graphically driven (e.g., Windows). In one embodiment, the medical practice client user interface 45 is a web browser, such as Internet Explorer™ developed by Microsoft Corporation (Redmond, Wash.), to connect to the medical practice client-server network 30. In a further embodiment, the web browser uses the existing Secure Socket Layer (SSL) support, developed by Netscape Corporation, (Mountain View, Calif.) to establish the medical practice client-server network 30 as a secure network.
The medical practice management server 15 and the payor server 20 can be any personal computer. In one embodiment, the medical practice management server 15 hosts one or more applications 50 that the medical practice client 10 can access. Moreover, the payor server 15 can host one or more applications 55 that the medical practice management server 15 can access. In one version, the medical practice management server 15 (and/or the payor server 20) is a member of a server farm, which is a logical group of one or more servers that are administered as a single entity. In the embodiment depicted in
In one implementation, a second medical payor server computer (not shown) communicates with the server 15 through the payor server network 40.
Typically, the medical practice client 10 is used by a medical care provider. Examples of the medical care provider include, but are not limited to, medical physicians, medically trained individuals, medical specialists, medical experts, receptionists, and the like. The medical practice client 10 is typically located in a medical practice. In one embodiment, the medical practice is the office of the medical care provider (e.g., a doctor's office), a hospital, other facilities providing medical treatment, and the like. Further, in one embodiment, a payor organization, or payor, uses the payor server 20. Although also referred to below as an insurance company, example embodiments of a payor organization also include, but are not limited to, health maintenance organizations (HMOs). More specifically, examples of payor organizations include, without limitation, Century Health and Benefits, HMO Blue, Harvard Pilgrim Health Care, MassHealth, Medicare, Neighborhood Health Plan, Tufts Associated Health Plan, United Healthcare, and the like.
Beneficially, many medical practices may utilize the same medical practice server 15 via medical practice clients 10 located at the respective medical practice locations. In some implementations providing service for multiple medical practices is achieved by providing data storage (not shown), e.g., databases and/or database tables, file systems, and the like, for each practice. For example, Dr. Smith, an internist, may utilize the medical practice management system 5 and Dr. Jones, an oral surgeon, who is not affiliated or associated with Dr. Smith, may also use the medical practice management system 5. Information associated with Dr. Smith's practice is stored in one practice database, while information associated with Dr. Jones' practice is stored in another database. In some implementations, there is one database and the information associated with the respective doctors' practice is stored in separate tables. In other implementations the information associated with the respective doctors' practices is stored as different rows in the same database table.
Providing the system 5 to multiple practices is mutually advantageous to the participating medical practices and the implementer of the system 5. The medical practices can communicate between each other via the server 15 and can modify the patient workflow of a patient common to each practice. Continuing the previous example, by both using the medical practice management system 5, Doctors Smith and Jones may easily refer patients between themselves, or approve procedures recommended by the other, etc. The system 5 is benefited because configuring the server 15 to interact with a payor for one medical provider obviates the need to configure the server 15 to interact with the payor for a second provider because the configuration is already done. Continuing the prior example, if in configuring the system 5 for Dr. Smith's practice, the medical practice management system 5 was configured to interact with Blue Cross/Blue Shield of Massachusetts (BCBSMA), if Dr. Jones also accepts BCBSMA, the system 5 does not need to be configured a second time. Rather, when configuring the server 15 for Dr. Jones' practice, only that Dr. Jones accepts BCBSMA need be provided. Beneficially, the more medical practices that use the same payor, the greater the return on investment in initially configuring the medical payor.
Additionally or alternatively, in some implementations, the medical practice management system 5 is operated as a subscription-based model, with pricing and/or support levels determined by a contract between the medical practice and the implementer and/or operator of the medical practice server 15. Some embodiments provide the full functionality of the system 5, while other embodiments provide only limited functionality to certain medical practices, e.g., only batch processing of claims instead of real-time claim processing, twenty four-hour daily support versus sixteen hour, five days a week support, or other functional limitations. In some embodiments, only a small amount of functionality is provided to those medical practices that do not subscribe to the medical practice management system service. Medical practices that subscribe to the service are typically referred to as “group practices.” Medical practices that do not subscribe to the service are usually referred to as “non-group practices.” Non-group practices may, for example, see patient records upon approval but cannot affect the patient workflow, or, where messaging capabilities are provided (described herein) the medical practice may leave messages for group practices. Other versions of the system provide mixed levels of service, or provide different levels of service to both group and non-group medical practices that are using the system 5, e.g., in some versions non-group practices make changes to a patient workflow.
Referring to
In one embodiment, the workflow processing engine 70 is a software application that controls and manages the features and functions of the medical practice management system 5. The workflow processing engine 70 and the medical practice client 10 communicate over the medical practice client-server network 30. In operation, the medical practice client 10 transmits a medical care provider request containing information to the medical practice management server 15 using, for example, a common gateway interface (CGI) request. For example, when registering a new patient, a medical care provider operating the medical practice client 15 enters the relevant patient information on a patient registration template that the workflow processing engine 70 delivered to the medical practice client user interface 45.
The workflow processing engine 70 also checks the structure and composition of information entered by a medical care provider at the medical practice client 10 to ensure that the information is correct (i.e., structure and/or composition). Examples of information entered by a medical care provider at the medical practice client 10 include the patient's address, phone number, medical history, insurance information, diagnosis and procedure codes, and the like.
The workflow processing engine 70 is additionally in communication with the rules engine 75. The rules engine 75 enables real-time application of “rules” stored in the rules database 90. A rule is coded logic that evaluates data and then performs an action.
The rules engine 75 can access and update information stored in the rules database 90 using the rules database interface 85. Although not shown in
The rules database 90 and/or the rules database interface 85 may be written in a structured query language, such as SQL. In one embodiment, the rules database interface 85 uses a Lightweight Directory Access Protocol (LDAP) to access information in the rules database 90. Additionally or alternatively, the rules database 90 can be external to the server 15 or may be internally situated in the server 15.
The rules database 90 includes insurance company rules that define the appropriate format and content of clinical and claim information that the payor server 20 processes. In one embodiment, the rules are subdivided into various classes. For example, the rules are divided into rules that have universal applicability to all claims for a specified payor, rules that apply only to one or more specific insurance packages from among the variety of insurance packages that the payor offers to medical care providers, and rules that apply only to specific medical care providers who provide care under one or more specific insurance packages.
Typically, a trigger invokes the application of a particular rule. For example, the submission of an insurance claim for a first payor could invoke the rules engine 75 to apply particular formatting rules associated with the first payor to format the claim to the first payor's specification. Typically rules are checked and applied in real-time.
To ensure that the rules database 90 contains current rules, the rules database 90 is frequently updated. In one embodiment, individual payors transmit rule updates/creations to the medical practice management server 15 via their payor server 20. Rule specialists review the rules transmitted by the payor server 20 and subsequently update the rules database 90. In one embodiment, the rules specialist performs any and all updates to the rules database 90. Alternatively, the updating of the rules database 90 can be automated upon receipt of a rule transmission from the payor server 20 or the medical practice client 10.
Additionally, a medical care provider can submit information to the medical practice management server 15 for subsequent update of the rules database 90 based on the medical care provider's experience with one or more payors. In another embodiment, the rules database 90 is updated with the server's historical analysis of previously submitted claims, especially those that were denied, to identify the reasons for denial. The historical analysis of previously submitted claims can facilitate the development of new rules for the rules database 90.
Referring to
For example, the rules engine 75 applies the rules to the information 110 for the first payor 95 and subsequently transforms the originally received information 110 into first information 110′ having a form acceptable to the first payor 95. Likewise, the rules engine 75 applies the rules to the information 110 for the second payor 100 and subsequently transforms the originally received information 110 into second information 110″ having a form acceptable to the second payor 100. The rules engine 75 performs the same process to the information 110 to format the information 110 into third information 110′″ acceptable to the third payor 105.
Referring again to
Similarly, the workflow processing engine 70 can store all of the information associated with an insurance company in the insurance information database 120, such as the insurance company's address, the amount of insurance coverage for a particular patient, and the like. Moreover, the workflow processing engine 70 can access the insurance information database 120 using an insurance information database interface 130.
In operation, as the workflow processing engine 70 receives information from the medical practice client 10, the workflow processing engine 70 determines on a real time basis whether all of the required information has been provided and whether the information is in the correct format. In the event that there is a deficiency in the information, the workflow processing engine 70 alerts the medical care provider (e.g., receptionist), or user, for additional information. Alternatively, the workflow processing engine 70 corrects the defect.
For instance, if the rules engine 75 contains a rule about member identification formatting for a particular payor, the rules engine 75 determines the rule in the rules database 90 and communicates the information to the workflow processing engine 70. The workflow processing engine 70 communicates this information to the medical practice client 10 when a medical care provider (e.g., receptionist) is registering a patient. If the medical care provider (e.g., receptionist) errs, the medical practice management server 15 alerts the medical care provider (e.g., with a warning message) to correct the error. This enables medical care providers to generate claims with no errors (i.e., referred to as clean claims) for the mutual benefit of the medical care provider and the payor. Additionally, the medical care providers can obtain the information associated with an alert while the patient is physically present, e.g., while the patient is still at the hospital or medical service provider during their procedure or before checking out.
The workflow processing engine 70 is also in communication with the ITR module 80. The ITR module 80 executes transactions sent to and received from the payor server 20. Thus, the majority of provider/payor transactions can be accomplished electronically, with little or no human intervention. Examples of these transactions include, without limitation, claim submittals, claim receipt acknowledgements, claim status checks, patient eligibility determinations, authorization and referral requests and grants, and remittance advice. For example, a predetermined number of days before a scheduled patient visit, the ITR module 80 automatically checks patient eligibility with the applicable payor identified during the patient registration process. After a patient visit and the completion of the claim template, the claim is submitted to the payor server 20 via the ITR module 80.
In one embodiment, upon receipt of an insurance claim, the payor 20 transmits a confirmation back to the medical practice management server 15. Later, on a schedule determined by the medical care provider, the ITR module 80 checks the claim status and notifies the medical practice client 10 accordingly. After the ITR module 80 analyzes the claim and generates remittance advice, the ITR module 80 parses the electronic payment and allocates the payment among the individual charge line items for the services provided. Once the medical care provider approves the allocations, the payments are posted to the provider's accounts.
Although described above as individual components, the engines 70, 75 and the ITR module 80 can be combined into one component or any number of components. Similarly, the databases, 90, 115, 120 could also be combined into one database and can be external or internal to the server 15. In other embodiments, the patient information and/or the insurance information is stored on a disk, such as a compact disk or a ZipDrive, developed by Iomega Corporation (Roy, Utah).
Incorporating new technology into an existing medical practice is often difficult. Documents associated with a patient, for example, a patient's medical charts, are typically provided physically, i.e., as “hard copies,” when a patient is being serviced by multiple health care providers, e.g., after being referred to a specialist by a primary care physician, or when a hospital receives a patient's charts from a family doctor. In some cases, a patient's documents, charts, and medical history are stored electronically by a healthcare provider. These documents can then be printed out and mailed to another healthcare provider if necessary. Typically if charts, e.g., images or faxes, are stored electronically they are generally stored as originally received, i.e., unaltered.
The image is received 305 by the medical practice management server 15 via a communications network 30. In some versions the image is received by the medical practice management server 15 via a LAN, MAN, WAN, the Internet, over a phone line, or the like. In other embodiments the image is received via a facsimile machine 68 in communication with the medical practice management server 15. In some embodiments the image is communicated by the fax machine via the communications network 30. In other embodiments the image is communicated to the medical practice management server via a direct data connection, e.g., Ethernet cable, or parallel or serial connection. Additionally or alternatively, the medical practice management system 5, in some versions, employs software that converts a received facsimile into an image file. The software, in some embodiments, is executed on the medical practice management server 15. In other embodiments the software executes on a server (not shown) that is signally located on the communications network 30 between the fax machine and the medical practice management server 15. In any of these scenarios, the image may be received and/or stored in virtually any format, e.g., a CompuServe's Graphics Interchange Format file (GIF), a file of the type defined by the Joint Photographic Experts Group (JPEG), a Tagged Image File Format file (TIFF), a Portable Network Graphic file (PNG) or the like. The image is then presented 310 to a user, the user usually being a medical care provider such as a doctor or nurse or staff member at a medical care provider location, e.g., a receptionist. Typically the image is presented to the user via a web browser, the web browser usually executed on a medical practice client 10.
Referring now to
Referring back to
In some versions, the medical practice management server 15 transmits 330 the annotations and the image to, for example, the original sender of the image or to a third-party, e.g., a payor. The transmission may occur over a different medium than was originally received, e.g., if received via fax, the annotated image may be sent via a LAN, MAN, WAN, the Internet, or the like. Alternatively, the image may be transmitted via the original means, e.g., if the image was received via fax, the medical practice management server 15 transmits the annotated image to the fax machine or fax client the sender used to transmit the image originally. In some embodiments where the third-party is a payor, a payor server 20 may require annotated images for the processing of claims. The ITR module 80 of the medical practice management server 15, before, during, or after submitting a claim, determines if a claim requires an annotated image and if so, submits the image to the payor server 20 via methods described herein. Additionally or alternatively, the medical practice management server 15 receives 305 and/or transmits 320, 330 the images and annotated images via a secure connection, e.g., a secure file transfer protocol (SFTP), secured web browser session, or the like.
In some embodiments, the images and annotations are maintained and transmitted 330 to the sender separately, for example if the original sender utilizes the medical practice management system 5, the medical practice management server 15 (e.g., as part of a medical practice management application service provider subscription model), or a compatible system that has the ability to store the image and annotations separately. Determining if the sender has the capability to receive and/or maintain the image and the annotations separately is typically done via software logic on the medical practice management server 15, e.g., determining that the sender also is a user of the medical practice management system 5. If the original sender is not a user of the medical practice management system 5, determining if the original sender can receive the image and annotations separately is typically accomplished via negotiations between the user/medical care provider and the original sender.
Alternatively, the image and annotations, if stored separately, may be combined and “flattened” together into one image, e.g., the original image with the annotations overlaid, and the combination transmitted to the original sender or third-party. Combining the image and annotations before sending is advantageous for scenarios where the original sender used technology, such as a fax machine, that does not support image layers. In that scenario, the sender of the original image transmitted a fax of a patient's chart to the user and the original sender receives a fax back with the annotated image. The original sender may then incorporate the annotated image into their patient workflow and document storage system, whether their patient workflow and document storage system is electronic or paper-based.
In some embodiments, the annotations are submitted as part of a medical patient workflow. For example, a primary care physician may have a question about a patient's X-ray and wants the opinion of a specialist. The primary care physician submits the request for clarification to the medical practice management server 15 and transmits the X-ray to the specialist, via, e.g., fax, e-mail, or as an image served by the medical practice management server 15. A workflow task is created for the request on the medical practice management server 15 and a notification is sent to the specialist. The request for clarification appears as part of a task list viewable by the specialist (via a medical practice client 10). The specialist then annotates the image using the techniques described herein and submits the response and the annotations to the medical practice management server 15. A notification is sent to the primary care physician that the specialist responded and the annotations and the X-ray are provided to the primary care physician. Additionally, multiple users can review and revise the annotations of others, and multiple users can make multiple annotations to the same image. Advantageously, annotating the image, rather than utilizing a proprietary annotation format, allows a medical care provider to send the annotated image to a medical provider that uses a different medical practice management software package to view the annotated image.
The annotations to the image are captured in several ways. The software for capturing annotations typically provides brushes, color palettes, shapes, and erasing functionality for users to make annotations in different shapes, colors, to create uniform circles, rectangles, etc, and to erase or undo prior annotations, respectively. In some embodiments, capturing involves receiving an electronic signal corresponding to a location of a pixel of the image. As an example, in one version, an X-ray is represented as a 1024×768 image. A pixel of that image located at the 500th horizontal position and the 200th vertical position, i.e., x/y coordinates 500, 200, may be white and represents a piece of bone. In one embodiment an annotation made to the image captures that the user moved the pointing device as part of an annotation over the 500, 200 pixel. The pixel locations that the user moved the pointing device over are stored as the annotation yet no changes are made to the actual image. In some versions, the annotation involves editing the image itself, e.g., changing the color of the pixels that make up the image. Using the prior example, moving the pointing device over the 500, 200 pixel changes the pixel color from white to red, e.g., as if the user wrote directly on the X-ray image using a red pen. As stated herein, the color of annotations is user-selectable using a palette provided by the plug-in.
In some embodiments, rather than change the image directly, an annotation is captured in a second layer or overlay. For example, rather than changing the 500, 200 pixel from white to red, in some implementations a second 1024×768 layer is created and the 500, 200 pixel of the second layer is made red. Where the image type supports layers, the second layer may be part of the image itself and may be transmitted to and/or stored on the medical practice management server 15. This allows the annotation to be present when the image is viewed, but may be hidden when so desired, i.e., by viewing software that allows the user to hide or show different layers of an image. Where multiple users have annotated the image, each annotation is preserved in a separate layer. Alternatively, in some versions, the layer is a separate electronic image that is transmitted and/or stored on the medical practice management server 15.
Where the image type does not support layers, the software creates a virtual layer, e.g., a layer in memory representing a 1024×768 layer, and allow for the “flattening” of the image and the second layer into one layer, wherein the second layer is imposed on the first layer, effectively overlaying the annotations onto the image. Beneficially, the annotations are stored as part of a medical patient's record and are viewable by anyone authorized to view the patient's records, e.g., doctors, nurses, or insurance companies.
The above-described techniques can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The implementation can be as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
Method steps can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). Modules can refer to portions of the computer program and/or the processor/special circuitry that implements that functionality.
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor receives instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also includes, or is operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Data transmission and instructions can also occur over a communications network. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.
To provide for interaction with a user, the above described techniques can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer (e.g., interact with a user interface element). Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
The above described techniques can be implemented in a distributed computing system that includes a back-end component, e.g., as a data server, and/or a middleware component, e.g., an application server, and/or a front-end component, e.g., a client computer having a graphical user interface and/or a Web browser through which a user can interact with an example implementation, or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet, and include both wired and wireless networks.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
The invention has been described in terms of particular embodiments. The alternatives described herein are examples for illustration only and not to limit the alternatives in any way. The steps of the invention can be performed in a different order and still achieve desirable results. Other embodiments are within the scope of the following claims.
