[go: up one dir, main page]

WO2000057264A1 - Systeme de gestion en pratique medicale - Google Patents

Systeme de gestion en pratique medicale Download PDF

Info

Publication number
WO2000057264A1
WO2000057264A1 PCT/US2000/007773 US0007773W WO0057264A1 WO 2000057264 A1 WO2000057264 A1 WO 2000057264A1 US 0007773 W US0007773 W US 0007773W WO 0057264 A1 WO0057264 A1 WO 0057264A1
Authority
WO
WIPO (PCT)
Prior art keywords
patient
information
management system
medical management
logic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2000/007773
Other languages
English (en)
Other versions
WO2000057264A8 (fr
Inventor
Sandra R. Weitz
David J. Weitz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to AU40243/00A priority Critical patent/AU4024300A/en
Publication of WO2000057264A1 publication Critical patent/WO2000057264A1/fr
Publication of WO2000057264A8 publication Critical patent/WO2000057264A8/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q99/00—Subject matter not provided for in other groups of this subclass
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/20—ICT specially adapted for the handling or processing of medical references relating to practices or guidelines

Definitions

  • the present invention relates to methods and systems for facilitating the entry of patient data and the management of a medical practice.
  • Reimbursement is directly related to documentation.
  • Medicare serves as the benchmark for all insurers and has defined specific documentation requirements.
  • the level of service for an initial consult, and the reimbursement is directly linked to the detail included in the documentation.
  • each patient encounter may require several forms of documentation to be completed (e.g. initial consult, letter of medical necessity to the insurer, and letter to the referring physician).
  • a 30-minute initial visit commonly results in a minimum of 10-15 minutes worth of documentation/paperwork.
  • the penalties for not maintaining proper records can be severe. If a provider is audited by an insurer and found to not have adequate documentation to support the bill, the penalties include repayment with interest, a fine and potentially prison.
  • Clinical pathways are vehicles for explicitly designing, managing and improving clinical processes and the ancillary systems that support clinical care.
  • Built into a clinical pathway is data gathering concerning outcomes, utilization, process compliance, functional goal achievement, and identification of outlyers.
  • Clinical pathways serve to create predictable costs and utilization, promote consistency, and create proven treatment strategies for optimal patient care. Standardization of care and the ability to demonstrate improved outcomes and reduced utilization improves profitability. Because pain management is a new evolving specialty made up of multiple disciplines with few providers having formal training, few clinical pathways are available.
  • the present invention relates to a medical management system.
  • the medical management system comprises a database of diagnosis profiles; logic of entering patient information into the medical management system; logic for comparing the patient information relative to the diagnosis profiles; and logic for selecting one or more possible diagnoses which have a diagnosis profile sufficiently similar to patient information entered into the system.
  • the medical management system may further include a database of clinical pathways where different clinical pathways are associated with different diagnoses, and logic for displaying those clinical pathways associated with the selected one or more possible diagnoses.
  • the medical management system may also further include outcome reports associated with the plurality of clinical pathways, and logic for displaying outcome reports associated with those clinical pathways associated with the selected one or more possible diagnoses.
  • the medical management system may also further include information regarding the one or more possible diagnoses, and logic for displaying the information regarding the one or more possible diagnoses.
  • the logic of entering patient information may be adapted to receive patient information selected from the group consisting of background patient information, insurer information, present illness history, past medical history, social history, family history, medications, allergies, physical examination, and diagnostic studies.
  • the logic of entering patient information may be adapted to receive information entered into the system by a method selected from the group consisting of manual data entry, voice-recognition data entry, and scanning of a form.
  • the medical management system may also further include logic for suggesting to a user when additional patient information is needed.
  • the medical management system may also further include logic for suggesting additional patient information to obtain from the patient by a physical examination or a diagnostic study.
  • the medical management system may also further include logic for suggesting additional patient information to obtain from the patient in order to obtain a higher level of insurer reimbursement.
  • the medical management system may be adapted to be simultaneously used by a plurality of healthcare providers remote from each other.
  • the system may also be adapted to have a patient enter a portion of the patient information by an Internet connection to the system.
  • the system may also be adapted to be accessed by the plurality of different users through the Internet or phone lines.
  • a medical management system comprising: a database of insurer requirements for a plurality of different insurance coverages; logic of entering information about a patient encounter into the medical management system; logic of entering information identifying a patient's insurance coverage into the medical management system; and logic for producing documentation regarding the patient encounter customized to the insurer requirements of the patient's insurance coverage.
  • the database of insurer requirements may include information selected from the group consisting of information regarding pre-certification, patient co-payments, payment schedules, and codes for coding diagnoses and procedures.
  • the medical management system may further include logic for providing billing suggestions based on the patient's insurance coverage and the insurer information stored in the system.
  • the medical management system may further include logic for providing documentation suggestions based on the patient's insurance coverage and the insurer information stored in the system.
  • the medical management system may further include information regarding the one or more possible diagnoses, and logic for displaying the information regarding the one or more possible diagnoses.
  • the logic of entering patient information may be adapted to receive patient information selected from the group consisting of background patient information, insurer information, present illness history, past medical history, social history, family history, medications, allergies, physical examination, and diagnostic studies.
  • the logic for entering patient information may be adapted to receive physical examination information and information from one or more diagnostic studies.
  • the medical management system may further include logic for suggesting additional patient information to obtain from the patient by a physical examination or a diagnostic study.
  • the medical management system may further include logic for suggesting additional patient information to obtain from the patient in order to obtain a higher level of insurer reimbursement.
  • the medical management system may further include logic for transmitting at least a portion of the documentation produced electronically to the insurer.
  • the system may be adapted to be simultaneously used by a plurality of healthcare providers remote from each other.
  • the system may also be adapted to have a patient enter a portion of the patient information by an Internet connection to the system or be accessed by the plurality of different users through the Internet.
  • the present invention also relates to an automated method for suggesting patient diagnoses.
  • the method comprises: entering patient information into a medical management system; having the medical management system compare the patient information relative to a plurality of diagnosis profiles stored in the medical management system; and having the medical management system select one or more possible diagnoses which have a diagnosis profile sufficiently similar to the patient information entered into the system.
  • the medical management system may also include a plurality of clinical pathways, the method further including displaying one or more clinical pathways associated with the one or more diagnoses selected by the medical management system.
  • the medical management system may also include outcome reports associated with the plurality of clinical pathways, the method further including displaying at least one of the outcome reports.
  • the medical management system may also include information regarding the one or more possible diagnoses, the method further including displaying the information regarding the one or more possible diagnoses.
  • the patient information may comprise information selected from the group consisting of background patient information, insurer information, present illness history, past medical history, social history, family history, medications, allergies, physical examination, and diagnostic studies.
  • the patient information may be entered into the system by a method selected from the group consisting of manual data entry, voice-recognition data entry, and scanning of a form.
  • entering patient information into the medical management system may include having the system suggest to a user when patient information is needed.
  • entering patient information into the medical management system may also include having the system suggest additional patient information to obtain from the patient by a physical examination or a diagnostic study.
  • entering patient information into the medical management system may include having the system suggest additional patient information to obtain from the patient in order to obtain a higher level of insurer reimbursement.
  • entering patient information into the medical management system may be performed by a plurality of healthcare providers.
  • entering patient information into the medical management system may include having a patient enter a portion of the patient information by an Internet connection to the system.
  • the medical management system may be maintained in a central location and accessed remotely by a plurality of different users.
  • access to the medical management system may be achieved by the plurality of different users through the Internet.
  • an automated medical documentation method comprising: entering information identifying a patient's insurance coverage into a medical management system, the medical management system including insurer requirements for a plurality of different insurance coverages; entering information about a patient encounter into the medical management system; and having the medical management system produce documentation regarding the patient encounter customized to the insurer requirements of the patient's insurance coverage.
  • the insurer requirements may include information selected from the group consisting of information regarding precertification, patient co-payments, payment schedules, and codes for coding diagnoses and procedures.
  • entering information about the patient encounter may include entering physical examination information or information from one or more diagnostic studies.
  • the method may further comprise having the system provide billing suggestions based on the patient's insurance coverage and the insurer information stored in the system.
  • the method may further comprise having the system provide documentation suggestions based on the patient's insurance coverage and the insurer information stored in the system.
  • entering information about the patient encounter into the medical management system may include having the system suggest to a user when patient information is needed.
  • entering information about the patient encounter into the medical management system may include having the system suggest additional patient information to obtain from the patient by a physical examination or a diagnostic study.
  • entering patient information into the medical management system may include having the system suggest additional patient information to obtain from the patient in order to obtain a higher level of insurance reimbursement based on the insurer requirements of the patient's insurance coverage.
  • the method may further include transmitting at least a portion of the documentation produced electronically to the insurer.
  • the medical management system may be maintained in a central location and accessed remotely by a plurality of different users.
  • the medical management system may be accessed by the plurality of different users through the Internet.
  • Figure 1 illustrates an overview of information flow within the medical practice management system.
  • Figure 2 illustrates an example of a multidisciplinary medical practice.
  • Figure 3 illustrates an example of the process for searching and reporting potential drug interactions.
  • Figure 4A illustrates an example of raw data being converted into medical documents.
  • Figure 4B illustrates an example of the process flow for producing documents.
  • Figure 4C illustrates an example of a sentence from the initial consult template.
  • Figure 5 A illustrates an example of the interaction between the Scheduling and Billing modules.
  • Figure 5B illustrates an example of the process used to identify insurer requirements.
  • Figure 5C illustrates an example of key elements used to determine the level of service provided in a patient encounter.
  • Figure 5D illustrates an example of the process flow for determining the diagnosis with highest reimbursement.
  • Figure 6A illustrates an example of raw data having been converted into outcome reports.
  • Figure 6B illustrates an example of the data that has been sorted by the system.
  • Figure 6C illustrates an example of possible billing outcome analyses done by the system.
  • Figure 6D illustrates an example of the outcome measure process flow for determining an optimal treatment.
  • Figures 7A-C illustrate user interfaces for initiating a user session.
  • Figure 7A illustrates a user interface for accessing the system.
  • Figure 7B illustrates a user interface as the user enters security data to access the system.
  • Figure 7C illustrates a user interface after the user gains initial access to the system.
  • Figures 8 A-B illustrate user interfaces for transferring of scheduling data and patient files.
  • Figure 8A illustrates a user interface for accessing an appointment schedule.
  • Figure 8B illustrates a user interface for transferring data to and from the user's site.
  • Figures 9A-C illustrate user interfaces for entering and displaying patient information.
  • Figure 9A illustrates a user interface at the beginning of a patient session.
  • Figure 9B illustrates a user interface for entering patient background.
  • Figure 9C illustrates the user interface of Figure 9B after patient background information has been entered.
  • Figure 10 illustrates an example of a patient questionnaire that is entered into the system.
  • Figure 1 1 illustrates a user interface at the beginning of a patient encounter.
  • Figure 12 illustrates a user interface displaying encounter components.
  • Figures 13A-M illustrate user interfaces within a submodule of the encounter.
  • Figure 13A illustrates a user interface opening the "history" component within the encounter.
  • Figure 13B illustrates a user interface for entering data within the "history of present illness” section.
  • Figure 13C illustrates the user interface in Figure 13B after data entry.
  • Figure 13D illustrates a user interface for entering data within the "past medical history" section.
  • Figure 13E illustrates the user interface in Figure 13D after data entry.
  • Figure 13F illustrates a user interface for entering data within the "past surgical history" section.
  • Figure 13G illustrates the user interface in Figure 13F after data entry.
  • Figure 13H illustrates a user interface for entering data within the "medication history" section.
  • Figure 131 illustrates the user interface in Figure 13H after data entry.
  • Figure 13J illustrates a user interface for entering data within the "social history" section.
  • Figure 13K illustrates a user interface for entering data within the "review of systems" section.
  • Figure 13L illustrates the user interface in Figure 13K after data entry.
  • Figure 13M illustrates the user interface after completing the data entry into the "History” submodule shown in the user interfaces 13A-13L.
  • Figure 14A illustrates a user interface at the beginning of the "Physical Exam” submodule within the encounter.
  • Figure 14B illustrates a user interface for entering data in the "motor exam” section.
  • Figure 15 illustrates the user interface for entering data in the "radiological findings" section of the patient encounter.
  • Figure 16A illustrates an example of an algorithm for determining possible diagnoses.
  • Figure 16B illustrates an example of the diagnosis identifying logic.
  • Figure 16C illustrates an example of the diagnosis selector process flow.
  • Figure 16D illustrates an example of the diagnosis profile comparison.
  • Figure 17 illustrates a user interface displaying possible diagnoses.
  • Figure 18 illustrates a user interface displaying a clinical pathway.
  • Figure 19 illustrates a user interface for determining the course of treatment.
  • Figure 20 illustrates an example of a document, "Patient Instructions Before A Procedure," generated by the system.
  • Figure 21 illustrates illustrate a user interface for viewing documents generated by the system.
  • Figure 22A and 22 B illustrate an example of the initial consult document that is generated from the data obtained from user interfaces in Figures 9B-C, 10, 13B-13L, 14A-B, and 15.
  • Figure 23 illustrates a user interface for finalizing documents produced by the system.
  • Figure 24 illustrates a user interface showing a subsequent patient session.
  • the present invention relates to a fully integrated, interactive, medical management system.
  • all or part of the system is maintained at a central location and a community of healthcare providers, patients and other parties access the system remotely, most typically via the Internet.
  • the maintenance of a central medical management system allows the system to be more readily updated with treatment, medication and insurer information and more easily accessed by all users.
  • This central updating of the system reduces the number of denied reimbursement requests due to a lag between changes in reimbursement requirements and practitioner response.
  • the system allows healthcare providers using the system to benefit from a higher percentage of reimbursed services and a substantially lower frequency of reimbursement denials.
  • the system may also track reimbursement outcomes including the rate of payment, days in accounts receivable, number of denied claims and percent reimbursement. This reimbursement data may be compared with diagnoses and treatment plans, documentation and coding. By monitoring billing outcomes, it is possible to detect changes in insurer reimbursement practices and modify the system's billing documentation to improve healthcare provider reimbursement outcomes.
  • This process of using information obtained from healthcare providers using the system is used throughout the system, for example, in regard to diagnoses, clinical pathways, outcome measures, and reimbursement.
  • use of the system by the community of healthcare providers provides valuable feedback data for continually improving the performance of the system.
  • the system By creating a community of system users, the system also serves as a conduit of information regarding new diagnoses and treatments, treatment outcome data, and changes in reimbursement procedures and requirements. Overall, healthcare providers using the system are able to generate more revenue and provide better pain management care to their patients.
  • Figure 1 illustrates a general information flow for features of the system. As illustrated, information is entered into the system by office personnel, patients, and/or healthcare providers. The information may include background patient information, insurer information, present illness history, past medical history, social history, family history, medications, allergies, physical examination, diagnostic studies and any other information which is either provided by the patient or garnered from a medical or diagnostic exam.
  • the information may include background patient information, insurer information, present illness history, past medical history, social history, family history, medications, allergies, physical examination, diagnostic studies and any other information which is either provided by the patient or garnered from a medical or diagnostic exam.
  • the information may be entered into the system by any mechanism known in the art including, but not limited to manual data entry (e.g. menu driven, word-processing), voice- recognition data entry, or scanning of forms.
  • a portion of the data to be entered into the system is entered via a personal data assistant (PDA) type device that is later hot-synced into the system.
  • PDA personal data assistant
  • the PDA may optionally have voice-recognition capabilities.
  • a portion of the data is entered into the system by scanning forms into the system.
  • the system can include user feedback which instructs the user when data is missing.
  • a feature of the present invention is that patients can enter data into the system by themselves when they are outside the healthcare provider's office by accessing the system over the Internet. This reduces the amount of time the patient has to spend in the waiting room and reduces the workload of the healthcare provider staff.
  • the system takes the information (histories, physical findings and diagnostic studies) and suggests possible diagnoses and treatment approaches for the different diagnoses.
  • the system may also request additional data to be obtained in order to help make diagnoses or decide on a treatment plan.
  • the system can also guide the user through a clinical pathway or explain outcome reports to the user.
  • the system can include a variety of applications to assist the healthcare provider including a complete medical thesaurus and a medical dictionary that translates medical terminology into lay terminology so that users may include healthcare providers and patients.
  • An example of a translation might be "hypertension: high blood pressure”.
  • the system can include information necessary for the diagnosis and treatment of diseases.
  • the system has stored onto it the information necessary to serve as a comprehensive medical textbook. This may include descriptions of symptoms, physical findings, diagnostic studies, diagnoses, treatment plans, and procedures. Other applications can include how-to guides for performing physical examinations, tests and procedures. Users may obtain the information within the system through a user interface. For example, selecting a field displaying the diagnosis, "spinal stenosis," results in information on the diagnosis and treatment of this condition.
  • the system can include a variety of applications that assist the healthcare provider in caring for the patient. These applications may include a database of information on various medications and their side effects.
  • the system may also include a database of clinical pathways where each clinical pathwa> is associated with a different diagnosis or group of diagnoses. Once one or more diagnoses are selected, the appropriate clinical pathway(s) are provided.
  • the system also contains a database of outcome measures, a description of those measures, and the parameters for measuring and reporting the outcomes.
  • return to work rate is an outcome measure that is defined as the ability to return to work. It is measured as the percent of patients returning to work in a defined time period. Outcomes are measured for quality of medical care, responsiveness to treatment and cost-effectiveness.
  • the system may also include an outcome database which may be used to monitor and report the effectiveness of various treatments for different diagnoses.
  • Data from nationally recognized outcome measures may be incorporated into the system to serve as a benchmark.
  • Data from the community of healthcare providers using the system can also be used to measure outcomes.
  • System administrators may use the data in the outcome database to modify and improve the performance of the system.
  • the system may also include templates for reporting the data collected in the database of outcome measures described above.
  • the system may also contain the logic for users and system administrators to generate outcome reports independent of pre-existing templates.
  • the system may also include a database of current billing requirements.
  • the system contains information regarding insurers and insurance requirements for obtaining reimbursement. This information may include needs for pre-certification, co-payments, referral patterns and payment schedules.
  • the system may also include current codes for coding diagnoses and procedures.
  • the system may also include logic to integrate an individual patient's information that is entered into the system with a database of current billing requirements to provide documentation needed for reimbursement and record keeping.
  • One piece of information requested by the system is the patient's insurer information.
  • Insurer information allows the system to generate documentation that may be used to meet the billing requirements of that patient's insurer.
  • the system identifies the patient's insurer as requiring evidence of documentation of "medical necessity" prior to authorizing a procedure.
  • the system may contain information regarding the definition of "medical necessity” for the patient's insurer.
  • the system then uses the patient's data to produce a letter of medical necessity that fulfills the insurer's requirements.
  • the system may also include logic for providing the healthcare provider with billing comments or suggestions, inform the healthcare provider of documentation requirements, and provide the healthcare provider with documentation suggestions. For example, the system can recognize that there is inadequate data to establish medical necessity. The system then informs the healthcare provider that medical necessity has not been established and provides suggestions to establish medical necessity based on the patient's insurer's requirements.
  • the system may also be used to track reimbursement outcomes including the rate of payment, days in accounts receivable, number of denied claims and percent reimbursement. This reimbursement data may be compared with diagnoses and treatment plans, documentation and coding. By monitoring billing outcomes, it is possible to detect changes in insurer reimbursement practices and modify the system's billing documentation to improve healthcare provider reimbursement outcomes. Monitoring of billing outcomes may be performed manually by users or system administrators. Alternatively, the system may include logic which monitors for changes in reimbursement outcomes and notifies users and/or system administrators of those changes in order to suggest that a change in insurer reimbursement practice has occurred.
  • the system is maintained on a central location and independently accessed remotely by a plurality of different users.
  • Various portions of the system may be stored at the user site. Access may be by a variety of connections, most preferably by the Internet or by phone lines.
  • the system may be continuously updated. This allows each of the plurality of users to have the most current medical information.
  • diagnoses and clinical pathways change these changes can be rapidly and effectively communicated to the community of users through the system.
  • the system may also include a security system that insures privacy of medical records.
  • Patient privacy is a key concern.
  • Users of the system require security access to enter the system. Users may be required to enter their security code at multiple points within the system, for example, to access patient files, to print documents and to electronically sign any document.
  • the system's security system can also prevent data from being transferred from one user to another without the permission of the patient.
  • Physician practices take many forms. For example, there may be an individual practitioner or a multi-specialty group. However, patients rarely see a single healthcare provider. Usually, patients have a primary care provider (PCP) who is the overseer of the patient's overall healthcare. PCPs refer patients for care provided by specialists or ancillary services such as physical therapy. Managed care describes the process of coordinating healthcare to provide the optimal healthcare while utilizing the fewest resources.
  • Figure 2 is an example of a sample multidisciplinary medical practice. As can be seen, multiple healthcare providers can typically treat each patient.
  • Several features of the present invention including a centralized database of patient information, and the Prescription Safety Module, serve to help coordinate multiple healthcare providers treating a single patient.
  • Patient data storage by the system provides several advantages in regard to coordinating treatment between multiple healthcare providers. For example, assuming that patient confidentiality issues are addressed, any healthcare provider treating a given patient may have access to that patient's database. This allows care to be coordinated between healthcare providers. Each healthcare provider is allowed to view all the data in the system but may only alter or edit their own data. If a patient is seen by multiple healthcare providers, the patient does not have to retell the same data (e.g. past medical history, past surgical history) to each of the healthcare providers.
  • data e.g. past medical history, past surgical history
  • the system may also function as an automated medical record where the system keeps track of when data is obtained and from whom the data is obtained.
  • the system thus creates a fully historical medical record. Data is obtained during each patient visit.
  • the system has already inco ⁇ orated data from the previous visit into the system.
  • the healthcare provider may add additional data into the system without having to restate the data from the last visit.
  • a patient's database may include an initial visit, a procedure, and a follow-up visit. At each visit, the appropriate fields are completed on the user interface and stored in the system.
  • the system allows each provider to see the entire patient record and also determine who entered what data.
  • the system may also incorporate a practice management database and processing system for controlling patient scheduling.
  • the patient scheduling database is linked to the billing database.
  • the system Prior to scheduling a visit, the system analyzes the insurance requirements for that patient. For example, the system includes logic for determining whether pre-certification from the referring physician is required prior to the patient's next appointment. Once a pre- certification is determined by the system to be necessary, a user interface of the system may display a field asking whether the healthcare provider wishes to submit a pre-certification request at that time. If the healthcare provider replies affirmatively, the system directs the healthcare provider to complete any information necessary for the system to submit a pre-certification request to the insurer.
  • the system is also designed to be used by patients. Because the system can be accessed by patients over the Internet, patients can obtain information about their diagnoses, treatment plan, and medications in the privacy of their homes. Further, the system can be used by healthcare providers to create information packets for the patient based on the patient's diagnoses, treatment plan and medication. In one embodiment, the system automatically creates a packet of patient information from information stored on the system based on data stored in the system regarding the diagnoses that have been made, the treatment plans that have been selected, and medications that has been prescribed. This information can be provided to the patient in paper form or electronically via the Internet or in an email message.
  • the system may be viewed as incorporating multiple databases that are arranged in submodules and modules. These modules may be vertically and horizontally stacked to form an exponential number of databases.
  • Users of the system access the system through a series of user interfaces.
  • Data entered into the system is incorporated into a series of databases located within modules.
  • Each patient's data is entered into the modules as an individual database.
  • Each patient's data may be accessed as an individual database consisting of the conglomerate of data from all modules within the system. This enables system users to obtain information regarding a single patient as a medical record.
  • the individual patient's data is also incorporated into a larger database represented by the system.
  • the databases within the modules may also be vertically stacked in order to compare large groups of patients with regard to each aspect of the system. For example, databases of symptoms, physical findings, and diagnoses can be compared across patients. This is a mechanism by which outcome data for a large population of patients can be achieved. a. MEDICAL MODULE
  • the Medical Module is comprised of a series of modules that contain the medical data within the system.
  • "Patient History” is an example of a medical module.
  • Other modules within the Medical Module can include Physical Exam, Diagnostic Studies, Diagnoses, and Treatment Plan.
  • Within each module is a group of submodules.
  • submodules within the "History” module may include medical history, surgical history, medications, allergies, and review of systems.
  • Each submodule can include a subset.
  • subsets within the "History of Present Illness" submodule may include onset of problem (symptoms), duration of symptoms, location of symptoms, and characteristics of symptoms.
  • User interfaces are used to display and record data.
  • the data is transferred into the system and placed in appropriate databases. For example, history data is entered into the History module.
  • the system is interactive and may be utilized during all points in a patient encounter.
  • Applications and information databases within the system interact with patient data.
  • the system prompts the user to ensure that data is entered correctly and completely.
  • the system includes logic for suggesting when additional data is needed or desirable in order to determine diagnoses and construct treatment plans.
  • Diagnoses are suggested by the system by analyzing pertinent positive and negative responses to questions regarding a patient's medical history, physical findings and results of laboratory and diagnostic studies.
  • the system contains a database of profiles for a series of possible diagnoses and logic for comparing patient data to these profiles. Diagnoses are suggested by the system when patient data sufficiently matches a diagnoses profile. For example, a patient cannot have a diagnosis of diabetic neuropathy without having diabetes. Similarly, women cannot have a diagnosis of prostate cancer since women do not have a prostate.
  • a diagnosis of lumbar radiculopathy radiating + pain + leg + electrical + burning + numb + tingling + decreased quadriceps femoris motor strength + MRI evidence of nerve root compression.
  • the system recognizes that a patient may have all of these points or the key features of radiating pain, decreased quadriceps strength and MRI evidence of nerve root compression.
  • the system interacts with the user through user interfaces to facilitate the search for matching diagnosis profiles.
  • the system has the ability to search for pertinent positive and negative responses as data is entered. If the system recognizes that there is insufficient data to match a patient profile to a diagnosis profile contained within the system, the system may prompt the healthcare provider to obtain certain additional data in order to confirm or rule out certain diagnoses.
  • the healthcare providers can query the system for potential diagnoses at multiple points along a patient encounter to help guide the healthcare provider to proper diagnoses.
  • the system provides the user with one or more diagnoses that best match the data provided to the system.
  • the user chooses diagnoses from a list of diagnoses or their own clinical impression. The user may override the system at any time and choose a diagnosis not generated by the system.
  • the system has a database of clinical pathways.
  • a clinical pathway is a comprehensive treatment algorithm.
  • Clinical pathways provide standardization of care by providing a suggested course of treatment for a diagnosis or set of diagnoses.
  • the clinical pathways within the system are based on the scientific literature and may also be based on outcome measures reflecting the relative effectiveness and risks associated with a particular clinical pathway.
  • Outcome measures are used by the system to provide a feedback loop for the clinical pathways within the system. More specifically, outcomes from following clinical pathways are monitored by the system. Based on these outcomes, the system may be modified to suggest clinical pathways which appear to be most effective based on the outcome measures. This process is described in the Outcome Measures module which is described herein.
  • the system may have a clinical pathway associated with different diagnoses and with different groups of diagnoses. Multiple alternative clinical pathways may also be associated with a particular diagnosis or group of diagnoses. When one or more diagnoses are chosen, the user is given a choice of viewing one or more clinical pathways for the one or more diagnoses selected.
  • the system may also contain a Prescription Safety Module.
  • the system is designed to accommodate a plurality of healthcare providers who are treating the same patient. One of the risks associated with a plurality of healthcare providers treating a single patient is the issuance of multiple conflicting prescriptions.
  • the system has logic which searches for medications prescribed to a patient.
  • the system updates its prescription database each time a healthcare provider indicates that a prescription has been given.
  • the system tracks and reports prescription medications prescribed to patients by users of the system.
  • the system may inform the healthcare provider of all medications regardless of which healthcare provider has provided the prescription. If a patient receives a prescription for the same drug by another healthcare provider, both healthcare providers are alerted.
  • the system may search its drug library for possible drug interactions and alert healthcare providers to possible drug interactions as illustrated in Figure 3.
  • the system may also provide information to healthcare providers and patients regarding medications.
  • Healthcare providers may utilize the prescription database to track patient compliance. For example, tracking refill requests may inform the healthcare provider that a patient is not taking a medication as prescribed.
  • the prescription database may also interact with patient data to determine drug effectiveness, incidence of side effects and other outcome measures. For example, the system has the ability to compare one or more medications with a diagnosis to determine which is most effective.
  • the Practice Management Module is composed of a series of modules containing nonclinical data. Examples of modules in the Practice Management Module include Demographic, Scheduling, Documentation, Billing and Outcome Measures. Each module can consist of submodules. Examples of submodules within the Billing module can include insurer, reimbursement, charges, and patient information.
  • the Demographic module contains data regarding patient information such as name, address, phone numbers, date of birth and sex.
  • the Demographics Module is accessible to the patient via the Internet or email so that the patient can introduce his or her patient information directly into the Demographics Module.
  • the Scheduling module contains data regarding the healthcare provider's schedule. It is used to schedule patient appointments.
  • the Scheduling module may interact with other modules to improve utilization. For example, data stored in the Scheduling module can be compared with data in the Medical module to determine average length of visit for a given medical problem.
  • the Scheduling module may interact with the Outcome Measures module to determine flow of patients. For example, by comparing scheduling to outcome measures, the system makes various correlations including whether there are fewer complications following procedures done in the morning than procedures performed in the afternoon.
  • the Scheduling Module also includes logic of analyzing data in the Demographic Module and notifying healthcare providers and patients when additional patient information is needed.
  • the Documentation module comprises a series of submodules which contain possible templates for documentation as well as logic for using data entered into the system to create documents from those templates. Examples of documents which the system can create from these templates include an initial visit medical record, follow-up visit medical record, letter to referring physician, letter of medical necessity and procedure note. As illustrated in Figure 4A, the system includes logic for searching for data in the system to complete the templates and generate documents. The system also has logic for determining what additional data is needed to complete the documentation and for notifying the user that the additional data is needed.
  • Figure 4B illustrates an example of a process flow used to obtain data from the multiple databases that is integrated into the templates to form a document.
  • Figure 4C illustrates an example of an initial visit template that has been created using data from a patient database.
  • the Billing module is composed of a series of submodules that can include patient information (insurer name, policy and group number), insurer information including requirements for pre-certification, co-payment, and reimbursement rates.
  • the system has information regarding insurers and requirements regarding reimbursement.
  • the information is preferably regularly updated for each insurer.
  • the system has logic for notifying the healthcare provider through a user interface of insurance requirements.
  • the system may search the Billing module for insurer information as illustrated in Figure 5A.
  • the system may search for insurer requirements by insurer.
  • the system has logic for alerting the healthcare provider of the need to comply with an insurer requirement, e.g. the need for a referral or pre-certification prior to the patient visit.
  • the system may locate the template needed and search the modules to obtain the data necessary to complete the required documentation to meet the insurer's requirements.
  • the system contains information regarding what particular documentation insurers require to show medical necessity and the information that needs to be provided to the insurer.
  • the system interactively prompts healthcare providers to complete the data necessary to demonstrate medical necessity as defined by that insurer. If the healthcare provider is unable to satisfy the documentation requirements, other options are given for documentation and/or procedure that may result in reimbursement or higher levels of reimbursement.
  • the Billing module is responsible for generating a bill based on several factors.
  • One factor is the level of service provided.
  • the system searches for key elements within the Medical module in order to determine the level of service that has been provided.
  • the system has logic for notifying the user of any suggestions or additional requirements that affect the level of service and hence the level of reimbursement.
  • the system has logic for searching for encounter and diagnosis codes that yield the highest reimbursement for the services rendered.
  • the system takes the diagnoses that have been selected and analyzes each diagnosis iteratively for whether patient data supports a more highly reimbursed diagnosis.
  • a patient with a diagnosis of lumbago low back pain
  • Lumbago which is a less specific diagnosis, may generate lower reimbursement than lumbar radiculopathy.
  • a bill is generated with the diagnosis code for the higher reimbursable diagnosis, lumbar radiculopathy.
  • the system may prompt the healthcare provider to consider lumber radiculopathy in view of its higher level of reimbursement.
  • the system may generate a bill for either a patient or third party payors.
  • the system can transmit the bill electronically and/or may produce printed versions.
  • the Billing module in addition to creating the bills, also functions as a monitoring system to track payments, rejected reimbursement requests, and bills which have not received a response after a predetermined period of time.
  • the Billing Module also tracks other reimbursement data such as days in accounts receivable, what diagnoses or documents have a higher rate of rejection or lowered reimbursement levels as well as changes in the way insurers are making reimbursements. All this is used by the system administrators to identify changes in reimbursement patterns.
  • the system may include logic which detects significant changes in frequencies of reimbursement rejections or other reimbursement behavior and notifies users and system administrators of such changes. This allows users and system administrators to continually monitor insurers and reimbursement for rules changes. By continuously monitoring insurer reimbursement practices, the system can be continuously updated to maintain the highest level of reimbursement and the lowest level of rejected reimbursement requests.
  • the system is also designed to serve as an interface between insurers and healthcare providers. Insurers may utilize the system to obtain the most effective services using known, quantifiable outcome measures; the best documentation of provided services; and the best utilization of resources.
  • the Outcome Measures module is comprised of a series of submodules for tracking outcome measures.
  • the system also has the capability for users to construct additional submodules to track outcomes not otherwise tracked by the user. System administrators can opt to add these outcome measures to the system. This is a further example of how system administrators are able to monitor how users use the system and improve the system based on that feedback.
  • the system may contain statistical programs that can analyze data to determine whether differences in outcome are statistically important. As illustrated in Figure 6A, the system utilizes data collected in its modules to measure outcomes. For example, a patient having an epidural steroid injection may have a clinical outcome measure of "response to epidural steroid injection.” The system can compare one treatment with another for a given variable. For example, epidural steroid injection versus epidural steroid injection in patients with lumbar radiculopathy (or men, or people over 65).
  • the system is able to access data from its databases to sort data in a variety of ways. Both the system administrators and the users can tap into the system's databases to analyze data stored in the system, for example, in order to create customized outcome measure reports.
  • the system may include logic for defining different patient populations and for searching its databases to compare one patient population with another. For example, the system may compare all of the user's patients, the user versus all other users, patient populations within a user's practice (lumbar radiculopathy versus low back pain), patient populations across multiple practices (all patients with a diagnosis of lumbar radiculopathy) and patients versus healthy controls.
  • the system is able to sort data by any variable and be compared to any variable.
  • the system also includes logic for comparing resource utilization as illustrated in Figure 6C. Examples include comparing the cost of one treatment versus another, and the number of visits required to treat a diagnosis. Billing comparisons are also available. For example, the average number of days in accounts receivable for one insurer versus another, the average reimbursement for one diagnosis code versus another, the number of rejected claims for a insurer versus another insurer, and more.
  • the system also includes logic for generating reports and suggesting the use of these reports to influence various aspects of their practice.
  • the system also includes logic for generating reports based on the outcome measures monitored.
  • the user may access outcome reports that the system offers or may request the system to generate an individualized report. Reports of outcome measures are used to provide quality assurance. These reports may also be utilized to demonstrate excellence of treatment. Outcome measures derived from the system may also be used to justify reimbursement from insurers.
  • the system integrates data obtained from the outcomes measures and the billing modules to make suggestions regarding contracting for services to the user.
  • the outcome information can be used to continuously modify the system's diagnosis logic, its clinical pathways, and its billing and reimbursement practices.
  • the system represents a large database of many user practices.
  • the Outcome Measures module provides a process for the continuous validation, updating and improvement of diagnosis profiles and clinical pathways.
  • Figure 6D illustrates an outcome analysis process flow that may be used. As illustrated, the process flow takes a diagnosis and analyzes whether one treatment versus a second treatment results in an improvement in a defined patient outcome. If two treatments are found by the system to be equivalent in outcome, the system can analyze other variables such as cost.
  • an improvement in a defined outcome measure is defined, the system may be modified to incorporate that improvement, for example, by modifying the clinical pathway for that diagnosis.
  • This process of using information obtained from users using the system is used throughout the system, for example, in regard to diagnoses, clinical pathways, outcome measures, and reimbursement.
  • Knowledge obtained from outside the system third party payors. medical studies) is also used to enhance the system's performance.
  • Figure 7 A illustrates a user interface that includes icon 12 that represents the system's software. Selecting the icon causes the system's software to become activated and causes a user interface for the system to become an active window on the screen.
  • Figure 7B illustrates the user interface for the system once the icon has been selected.
  • the first time the system is accessed during a session users are required to enter security information in window 14. Once this information is entered, the user selects the "submit" button 16. This may cause the system to log on. The system can verify the security information and access to the system is granted.
  • Figure 7C illustrates a user interface for displaying information that the system is reporting to the user.
  • window 18 informs the user of generated documents that need to be reviewed.
  • Selecting symbol 20 provides files of documents for review. Additional information may be accessed using the toolbar 22.
  • Figure 8 A illustrates a user interface that may be used to obtain today's schedule or schedule future patients.
  • Figure 8B illustrates a user interface for transferring patient files from one site to another.
  • a pull-down menu 24 accesses files that may include the patients for today, patients for a future day, or scheduling information.
  • Figure 9A illustrates the user interface for accessing patient demographic information. Selecting "new" (menu 26) produces a new patient information interface to enter the patient into the system. Choosing existing patient (menu 26) provides the user with the opportunity to enter demographic data to access the existing patient's demographic information.
  • Figure 9B illustrates the patient information screen to be completed by the user.
  • the user enters the requested data into the data fields.
  • a pull-down menu 28 allows the user to select the appropriate visit type.
  • Another pull-down menu 30 allows the user to select the gender of the patient.
  • the "Reason for Consult” menu 32 allows the user to select from a list of possible reasons or the user may enter a reason. Possible reasons may include evaluate and treat intractable pain, manage angina, or treat refractory seizures.
  • Under "primary insurer” menu 34 and "secondary insurer” menu 36 are lists of insurers. The system contains a directory of insurers and insurers' requirements. Once the data is entered, the user pushes the "submit" button 38.
  • Figure 9C illustrates the user interface that is produced after the data has been submitted.
  • the system identifies the patient as a new patient coming for an initial visit in system comment 40 (as compared to for a procedure).
  • the system highlights any missing data.
  • the system informs the user of any insurance requirements regarding pre-certification, documentation of medical necessity, co-payments and so on (system comment 42).
  • system comment 42 Once the user has reviewed the screen and any missing data is completed, the "submit" button 38 is pushed. If any required data fields are not completed, the system notifies the user and does not allow the user to proceed to the next step.
  • Data may be entered into the system by a number of mechanisms including transferring of data from one user of the system to another (provided they have patient authorization). Frequently, users may utilize patient questionnaires to obtain patient information prior to an encounter.
  • Figure 10 illustrates a sample patient questionnaire that may be entered into the system. Other examples of data that may be obtained include previous medical records, laboratory and other diagnostic studies. Data entered into the system appears in data fields in the appropriate submodule.
  • a feature of the present invention is the fact that at least a portion of the system is maintained remote from the healthcare provider and may be accessed via email or the Internet. As a result, it is possible for the patient to enter the patient demographic data and other needed data into the system remote from the office. For example, the patient may fill out an email version of an information form or may enter data over the Internet. This flexibility reduces clerical demands upon the healthcare provider and also makes it easier for the patient to provide the healthcare provider with necessary information.
  • the "patient" pulldown menu 44 on the toolbar is selected illustrated in Figure 1 1.
  • the healthcare provider may locate the patient from a list of today's patients or by searching for a piece of their demographic information.
  • a user interface When the healthcare provider accesses the patient's file, a user interface, illustrated in Figure 12, provides an outline of the visit type (window 46) and a summary statement is provided to inform the user of the purpose of the patient's visit (window 48). Each component within the visit represents a series of submodules. The healthcare provider may follow the format outlined in this interface or may access any portion in any order.
  • Figure 13A illustrates a user interface for accessing the "History” submodule.
  • Figure 13B illustrates a user interface of the section, "History of Present Illness.”
  • the user interface comprises a series of questions.
  • the data entered in the fields on the right represent information obtained prior to the patient visit.
  • a missing field is highlighted as illustrated by the dotted field 50.
  • the user reviews this information and conducts the patient interview.
  • the interface is completed as illustrated in Figure 13C.
  • Each question within the interface represents a list of possible answers as illustrated by the choices under "characteristics" (menu 52). Although some of the patient responses were obtained prior to the interview and shown in Figure 13B, note that additional responses have been added as displayed in Figure 13C- 54, 56, 58.
  • the user is able to review and edit each screen as it is completed.
  • the system includes logic for continuously analyzing the data inputted into the system. Incorporated into the sytstem are diagnosis profiles and logic for comparing the data entered to the diagnosis profiles in order to identify potential diagnoses.
  • the system may utilize all available data to generate a list of possible diagnoses based on the data currently entered into the system. As illustrated in Figure 13C, these diagnoses are suggested to the user in window 60. Accessing the FAQ button 62 allows the user to obtain information regarding any of the listed diagnoses. The user may also access information from "Help" on the toolbar 64.
  • the system also includes logic for distinguishing between potential diagnoses by taking available data and potential diagnoses and identifying to the user questions useful for confirming or dismissing potential diagnoses. For example, if a patient presents with symptoms consistent with diabetes, the system may direct the user to ask questions about possible interrelated organ systems and associated disease processes, e.g. cardiac symptoms, high blood pressure, and vision problems.
  • Figure 13D illustrates a user interface for obtaining data on the "Past Medical History.” Data obtained prior to the visit appears in the field and missing fields are identified (dotted field 50). If a particular area is important for establishing a diagnosis, the system alerts the user to this section.
  • Figure 13E illustrates a completed user interface for "Past Medical History.” Under each organ system is a menu 66 displaying a list of possible medical problems.
  • Figures 13F and 13G illustrate the user interface for entering data into the "Past Surgical History" section. Types of surgery are classified by organ system. Within the window 68 for each organ system is a list of possible surgeries. Data may be entered to indicate the year as seen in window 70 in which the surgical procedure took place.
  • Figures 13H and 131 illustrate the user interface for entering data in the "Medication History” section. Data is obtained regarding the medication 72, dose 74, response to the medication 76 and any side effects 78. The patient's responses are indicated under each section as indicated by field 80. Missing data is highlighted by dotted field 50. It is also possible to have partially missing data as seen in Figure 13H. Within the "past medications” section, it is indicated that the patient had taken two drugs but there is no dose, response or side effects noted. Figure 131 illustrates that each section represents a menu 82 that contains a list of possible answers. For example, under medications there is a list of drug types, e.g. anticonvulsant, antihypertensive, antiinflammatory. Within each of the drug types is a list of drugs.
  • drug types e.g. anticonvulsant, antihypertensive, antiinflammatory.
  • Figure 13J illustrates a user interface for data in the "Social History" section.
  • Each section represents a series of menus (example menu 84) with a list of possible responses. Completed fields are displayed for the user to view and edit.
  • Figures 13K and 13L illustrate a user interface for entering data in the "review of systems" section.
  • the “review of systems” is the part of the medical history during which the user may review organ systems not included during the "history of present illness” portion of the medical history. It is relevant to document both pertinent positive and negative responses.
  • the “review of systems” is often used to identify other symptoms that may be relevant to the diagnosis.
  • the “review of systems” is broken down by organ systems. Under each organ system (menu 86) is a list of symptoms pertinent to that section.
  • the fields completed in Figure 13K were indicated by the patient prior to the visit.
  • the system includes logic for suggesting areas within the "review of systems” for the user to focus upon. This is illustrated in Figure 13L system comment 88.
  • the user is able to provide either a positive or negative response (window 90) to each symptom within the "review of systems.” These responses are then shown to the user in the adjacent data field 92.
  • Figure 13M illustrates a user interface at the end of the "History" submodule.
  • the system has logic for reviewing each submodule and indicating any missing data. Missing data may indicate that the data may be mandatory for documentation requirements, necessary to rule in or rule out diagnoses, or affect the level of reimbursement.
  • the information regarding missing data is communicated to the user as seen in window 94. The user may elect not to complete missing data fields. While the system makes suggestions, it may be overriden by the user at any point.
  • Figure 13M also illustrates field 96 displaying billing comments provided by the system.
  • the "level of service provided” is based upon documentation. Based on the data entered into the system to this point, the system is able to determine a level of service provided. A field 96 notifies the user of the level of service provided.
  • the system includes logic for using the inputted data and insurer documentation requirements to identify additional documentation which would achieve a higher level of service, as seen in field 96. The user may select a field 98 to obtain help from the system in completing any additional documentation requirements.
  • Figure 13M illustrates a window 60 listing possible diagnoses based on the patient's data. At each step, the list is refined based on additional information. The user may access information regarding any of the listed diagnoses by selecting button 62. Reviewing the list of possible diagnoses guides the remainder of the patient encounter.
  • Figure 14A illustrates a user interface as the user selects the "Physical exam” submodule from the toolbar 100.
  • the user selects the the motor examination within the neurological examination from the menu 102.
  • Figure 14B illustrates a user interface for documenting the assessment of motor strength during a neurological examination.
  • Under each menu 104 is a list of the possible muscle groups to test and the nerves that innervate those muscles.
  • the system provides a system comment 106 that displays a description of how to test this muscle group. This feature may be hidden by the user.
  • adjacent to "left plantar flexion" is a box 108 indicating that muscle strength is scored on a scale of 0-5. The user simply chooses the appropriate score.
  • the system also provides a guide to the user to facilitate completing the exam. For example, the box 110 "Motor Strength 0-5 Scale" is included to guide the user in determining the appropriate score.
  • the system also includes logic for directing the user to aspects of the physical examination that are necessary for determining a diagnosis. The completed responses appear on the user interface so that the user may review and edit any aspect of the exam.
  • Figure 15 illustrates a user interface for reviewing radiological findings. Most of the data obtained for radiological and diagnostic studies should be available and entered into the system prior to the patient encounter. The user reviews the data and has full editing capabilities. As illustrated in Figure 15, the user may select a study by selecting the field in which it appears. For example, to add data to the MRI, the user selects the MRI field 112 and indicates spine, lumbar. The user is then is able to edit (add, delete, comment, change interpretation) this section. The system may also include logic for analyzing the data in the system and suggesting additional diagnostic studies that may be performed in order to confirm suspected diagnoses.
  • the system utilizes a database of diagnosis profiles and the patient data to suggest possible diagnoses. For each diagnosis in the system there is an associated diagnosis profile comprised of symptoms, physical findings, and diagnostic studies.
  • Figure 16 A illustrates an embodiment of a process by which the system can determine a list of possible diagnoses from the data.
  • the system has logic for taking the medical data in the system and searching through the database of diagnosis profiles in order to determine potential diagnoses based on the medical data. Once selected, these potential diagnoses are further analyzed with regard to how well the clinical data in the system matches the diagnosis profiles.
  • Figure 16B illustrates a logic tree structure by which diagnoses in the system may be divided. This allows the system to reduce the number of potential diagnoses that need to be analyzed. As illustrated, potential diagnoses are divided into male, female and sex independent diagnoses. Prostate cancer would be placed in the male diagnosis branch while ovarian cancer would be placed in the female diagnosis branch. Certain diagnoses are dependent on their being an underlying condition, such as diabetes as illustrated. By dividing the diagnoses in this manner, it is possible for the system to use the clinical data that is available in order to substantially reduce the number of diagnoses that need to be analyzed.
  • Figure 16C illustrates a diagnosis selector process flow that may be used. As noted at the top of the process flow, all diagnoses in the system may be analyzed. Alternatively, a subset of all diagnoses may first be selected, for example by the process illustrated in Figure 16B.
  • the process flow takes a set of diagnoses that are to be analyzed and compares the medical data in the system to each diagnosis in the set. Those diagnosis profiles which are sufficiently matched by the patient data are selected and reported to the user. The degree of similarity required for a diagnosis match can optionally be varied by the user.
  • Figure 16D illustrates a diagnosis profile comparison. Each selected diagnosis and the associated diagnosis profile is compared with the patient's data. Matches between the diagnosis profile and patient data are identified. Some identifying factors are definitive in determining the diagnosis. In other cases, the system has the ability to weight the likelihood of a correct diagnosis based on how many and which identifying features match.
  • Figure 17 illustrates a user interface that displays a list of possible diagnoses. Adjacent to the diagnosis is a number which indicates the degree of similarity between the diagnosis profile and the patient's data.
  • the user may select the diagnosis (window 1 14) to view the comparison of the diagnosis profile and patient data ( Figure 16C).
  • Figure 13C and 13M the user may query the system for information regarding any diagnosis.
  • the user may select "Diagnoses" as seen in menu 116.
  • the user may select button 118 to view clinical pathways for the treatment of those diagnoses.
  • the user may exercise the option to view clinical pathways for selected diagnoses at any point after a diagnosis is established.
  • a clinical pathway refers to a suggested course of treatment for a specific diagnosis.
  • the system has multiple clinical pathways and preferably at least one for each diagnosis or set of diagnoses. This is important because patients may have multiple diagnoses.
  • Figure 18 illustrates the clinical pathway for the diagnoses chosen by the user. The user reviews clinical pathways as a guide for treating diagnoses.
  • Figure 19 illustrates a user interface for establishing the treatment plan. The healthcare provider may select the treatments desired using the menus. As illustrated, the healthcare provider selects the menu 120 to begin the patient on new medications.
  • Under menu 120 is a list of medications similar to the list in Figure 131. If the healthcare provider is unfamilar with the dose, the healthcare provider may access information from the system regarding the recommended dose. In a similar fashion, selecting physical therapy may generate a prescription for physical therapy.
  • the healthcare provider is also given the choice of having the system generate the prescription for the medication by selecting button 122. Once selected, the system is able to print prescriptions or electronically communicate prescriptions to a pharmacy. Scheduling is done directly from the treatment plan. As illustrated in Figure 19, menu 124 indicates that the patient is to be scheduled for an "epidural steroid injection" at the next available appointment (menu 126). This information is communicated to the scheduling component.
  • the system includes logic for determining an available appointment time.
  • a number of documents may be generated using the system.
  • the system displays a system comment 128 informing the healthcare provider of the documents that are required and that is generated by the system.
  • the healthcare provider may choose not to generate any document by electing to remove that document.
  • the healthcare provider may elect to obtain other documents by accessing the "additional forms" menu 130.
  • the healthcare provider closes the patient file. The healthcare provider is asked if the changes are to be saved. If yes. the data is saved in the file. The data is inco ⁇ orated into the system's multiple databases.
  • Figure 20 illustrates an example of a document generated by the system to inform a patient of instructions for a procedure.
  • Documents may be standardized to reflect a healthcare provider's usual practice. An example of this is "Do not eat or drink anything for 6 hours before your procedure" (132). Documents also contain data obtained from the patient's database. For example, instructions regarding specific medications (134).
  • the system takes patient data from the multiple databases to form the required/requested pieces of documentation.
  • the system has a database of possible documentation templates. These templates are used as the basis for the document.
  • the healthcare provider also has the ability to dictate a document independent of the templates.
  • Figure 21 illustrates a user interface that displays a menu 136 with a list of documents for review.
  • the user interface displays a system comment 138 that informs the healthcare provider of any missing data or any suggestions regarding documentation and billing.
  • the healthcare provider selects the document for review from window 140. All documents may be edited by the healthcare provider.
  • Figure 22A and 22B illustrates a medical record document that may be generated by the system from the initial visit.
  • Figure 23 illustrates a user interface that illustrates the user's ability to finalize each document.
  • a menu 142 lists each of the documents.
  • the healthcare provider may select a button 144 to electronically sign it.
  • the healthcare provider may print the document without electronically signing it.
  • a system comment 146 reminds the healthcare provider that both the bill and the medical documentation (i.e. initial visit) must be finalized in order for the system to submit the bill. If the healthcare provider chooses the print option, the data used to complete the document is maintained within the system's database but the document is not. Copies of documents that are electronically signed are kept within the system.
  • Figure 24 illustrates a user interface that may be displayed by the system when the patient returns for a subsequent visit.
  • the system provides a system comment 148 that displays a summary of the data contained within the database for the healthcare provider's review.
  • Each type of patient encounter contains the necessary data fields to complete that visit. These data fields are similar to those in Figure 11.
  • the system may notify the healthcare provider of a change in data. For example, during the initial visit the patient complains severe pain. At the follow-up visit, the pain is improved.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Business, Economics & Management (AREA)
  • Bioethics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Pathology (AREA)
  • Instructional Devices (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

L'invention concerne un système de gestion médicale comprenant une base de données de profiles (figure 16A) de diagnostic, une logique servant à entrer des informations (figure 6) concernant le patient dans le système de gestion médicale, une logique servant à comparer les informations concernant le patient aux profiles (figure 16C) de diagnostic, et une logique servant à sélectionner au moins un diagnostic possible qui a un profil suffisamment similaire aux informations sur le patient entrées dans le système (figure 16C).
PCT/US2000/007773 1999-03-22 2000-03-22 Systeme de gestion en pratique medicale Ceased WO2000057264A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU40243/00A AU4024300A (en) 1999-03-22 2000-03-22 Medical practice management system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US12542899P 1999-03-22 1999-03-22
US60/125,428 1999-03-22
US40699299A 1999-09-28 1999-09-28
US09/406,992 1999-09-28

Publications (2)

Publication Number Publication Date
WO2000057264A1 true WO2000057264A1 (fr) 2000-09-28
WO2000057264A8 WO2000057264A8 (fr) 2001-03-08

Family

ID=26823575

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/007773 Ceased WO2000057264A1 (fr) 1999-03-22 2000-03-22 Systeme de gestion en pratique medicale

Country Status (2)

Country Link
AU (1) AU4024300A (fr)
WO (1) WO2000057264A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010057891A1 (fr) * 2008-11-19 2010-05-27 Compugroup Holding Ag Procédé mis en oeuvre par ordinateur pour l'aide au diagnostic médical
US7840421B2 (en) 2002-07-31 2010-11-23 Otto Carl Gerntholtz Infectious disease surveillance system
US9430616B2 (en) 2013-03-27 2016-08-30 International Business Machines Corporation Extracting clinical care pathways correlated with outcomes
US10365946B2 (en) 2013-03-27 2019-07-30 International Business Machines Corporation Clustering based process deviation detection

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4491725A (en) * 1982-09-29 1985-01-01 Pritchard Lawrence E Medical insurance verification and processing system
US4667292A (en) * 1984-02-16 1987-05-19 Iameter Incorporated Medical reimbursement computer system
US4858121A (en) * 1986-12-12 1989-08-15 Medical Payment Systems, Incorporated Medical payment system
US5070452A (en) * 1987-06-30 1991-12-03 Ngs American, Inc. Computerized medical insurance system including means to automatically update member eligibility files at pre-established intervals
US5235507A (en) * 1990-01-16 1993-08-10 P. B. Toau And Company, Ltd. Health insurance management system
US5253164A (en) * 1988-09-30 1993-10-12 Hpr, Inc. System and method for detecting fraudulent medical claims via examination of service codes
US5359509A (en) * 1991-10-31 1994-10-25 United Healthcare Corporation Health care payment adjudication and review system
US5915241A (en) * 1996-09-13 1999-06-22 Giannini; Jo Melinna Method and system encoding and processing alternative healthcare provider billing

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4491725A (en) * 1982-09-29 1985-01-01 Pritchard Lawrence E Medical insurance verification and processing system
US4667292A (en) * 1984-02-16 1987-05-19 Iameter Incorporated Medical reimbursement computer system
US4858121A (en) * 1986-12-12 1989-08-15 Medical Payment Systems, Incorporated Medical payment system
US5070452A (en) * 1987-06-30 1991-12-03 Ngs American, Inc. Computerized medical insurance system including means to automatically update member eligibility files at pre-established intervals
US5253164A (en) * 1988-09-30 1993-10-12 Hpr, Inc. System and method for detecting fraudulent medical claims via examination of service codes
US5235507A (en) * 1990-01-16 1993-08-10 P. B. Toau And Company, Ltd. Health insurance management system
US5359509A (en) * 1991-10-31 1994-10-25 United Healthcare Corporation Health care payment adjudication and review system
US5915241A (en) * 1996-09-13 1999-06-22 Giannini; Jo Melinna Method and system encoding and processing alternative healthcare provider billing

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7840421B2 (en) 2002-07-31 2010-11-23 Otto Carl Gerntholtz Infectious disease surveillance system
WO2010057891A1 (fr) * 2008-11-19 2010-05-27 Compugroup Holding Ag Procédé mis en oeuvre par ordinateur pour l'aide au diagnostic médical
EP2192510A1 (fr) * 2008-11-19 2010-06-02 CompuGroup Holding AG Procédé destiné au soutien du diagnostic médical
US8548827B2 (en) 2008-11-19 2013-10-01 CompuGroup Medical AG Computer-implemented method for medical diagnosis support
US9430616B2 (en) 2013-03-27 2016-08-30 International Business Machines Corporation Extracting clinical care pathways correlated with outcomes
US10181012B2 (en) 2013-03-27 2019-01-15 International Business Machines Corporation Extracting clinical care pathways correlated with outcomes
US10365946B2 (en) 2013-03-27 2019-07-30 International Business Machines Corporation Clustering based process deviation detection
US10365945B2 (en) 2013-03-27 2019-07-30 International Business Machines Corporation Clustering based process deviation detection

Also Published As

Publication number Publication date
AU4024300A (en) 2000-10-09
WO2000057264A8 (fr) 2001-03-08

Similar Documents

Publication Publication Date Title
US8010384B2 (en) Medical billing auditing method and system
US8924237B2 (en) Database for pre-screening potentially litigious patients
US8165897B2 (en) Medical decision system including interactive protocols and associated methods
US7194416B1 (en) Interactive creation and adjudication of health care insurance claims
US6915265B1 (en) Method and system for consolidating and distributing information
US8099302B2 (en) Method of increasing efficiency in a medical claim transaction, and computer program capable of executing same
US20110112848A1 (en) Medical decision system including question mapping and cross referencing system and associated methods
US20030074225A1 (en) Pharmaceutical information tracking system
EP2523136A2 (fr) Système et procédé pour fournir une gestion d'accès intégrée pour dialyse péritonéale et hémodialyse
US20040111293A1 (en) System and a method for tracking patients undergoing treatment and/or therapy for renal disease
US20070250352A1 (en) Fully Automated Health Plan Administrator
US20100114602A1 (en) Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information
WO2007089686A2 (fr) Procédé et appareil pour la génération d'une carte de pointage d'assurance de qualité
US20110112850A1 (en) Medical decision system including medical observation locking and associated methods
US12159708B2 (en) Healthcare occupational outcomes navigation engine
US20050065816A1 (en) Healthcare management information system
WO2000057264A1 (fr) Systeme de gestion en pratique medicale
Davis et al. Measuring outcomes in psychiatry: an inpatient model
Vang Analysis of Communication in the Electronic Medical Record: Communication of the Patient Story across the Continuum of Care
Wiederhold Expert Report on Health Care Systems
Larson A Multi-Level Assessment of Healthcare Facilities Readiness, Willingness, and Ability to Adopt and Sustain Telehealth Services
Matherlee From diagnosis to payment: the dynamics of coding systems for hospital, physician, and other health services
London The Impact of Healthcare Information Technology on Healthcare Outcomes

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: C1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

WR Later publication of a revised version of an international search report
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP