WO2015162716A1 - 業務支援システム、業務支援方法及び業務支援プログラム - Google Patents

業務支援システム、業務支援方法及び業務支援プログラム Download PDF

Info

Publication number
WO2015162716A1
WO2015162716A1 PCT/JP2014/061384 JP2014061384W WO2015162716A1 WO 2015162716 A1 WO2015162716 A1 WO 2015162716A1 JP 2014061384 W JP2014061384 W JP 2014061384W WO 2015162716 A1 WO2015162716 A1 WO 2015162716A1
Authority
WO
WIPO (PCT)
Prior art keywords
patient
code
verification
likelihood
receipt
Prior art date
Application number
PCT/JP2014/061384
Other languages
English (en)
French (fr)
Inventor
淳平 佐藤
俊太郎 由井
島田　和之
Original Assignee
株式会社日立製作所
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 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2014/061384 priority Critical patent/WO2015162716A1/ja
Publication of WO2015162716A1 publication Critical patent/WO2015162716A1/ja

Links

Images

Classifications

    • 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
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • 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 a system, a method, and a program for assisting a medical worker in making a judgment related to medical work.
  • Patent Document 1 states that “a doctor in charge at the time of admission inputs temporary diagnosis group classification data from the data input / output control unit. This represents a medical resource of treatment, examination, and medicine that is put into the patient during the hospitalization period. The medical resource data is input via the data input / output unit.When the discharge approval is given by the doctor in charge, the optimal diagnosis group classification selection unit inputs it during the hospitalization period while referring to the medical resource-diagnosis group classification database.
  • All the collected medical resource data is classified and aggregated for each diagnosis group classification to identify the optimal diagnosis group classification where the most medical resources are actually invested, and the diagnosis group classification verification unit It is verified whether or not the diagnostic group classification and the optimal diagnostic group classification in which the most medical resources are actually invested are in agreement (see summary).
  • Patent Document 1 JP 2010-157128 A
  • the comprehensive payment system in Japan has introduced a DPC system called DPC (Diagnosis Procedure Combination) code that determines the amount of comprehensive payment per day of hospitalization based on a 14-digit number DPC code that combines the name of the wound and medical treatment.
  • DPC Diagnosis Procedure Combination
  • the Ministry of Health, Labor and Welfare has defined that the most suitable DPC code for each patient is “the DPC code to which the name of the disease or disease to which the most cost of treatment belongs” belongs.
  • Hospitals that have introduced the DPC system should prepare a medical fee description statement (hereinafter referred to as “receipt”) containing the DPC code, and submit it to a screening payment organization such as the Social Insurance Medical Fee Payment Fund or the National Health Insurance Association Federation. To claim medical fees.
  • Patent Document 1 As a system for supporting the receipt verification work, a system for extracting receipt verification candidates using a correspondence table in which medical practice performed for each DPC code is defined has been proposed (see Patent Document 1).
  • the system described in Patent Document 1 first sums up the insurance points corresponding to the medical practice defined for each DPC code of the correspondence table based on the medical practice described in the subject receipt, The DPC code having the highest sum, that is, the DPC code having the highest medical cost is calculated as the optimum DPC code.
  • a receipt in which the DPC code written in the receipt does not match the calculated optimum DPC code is extracted as a receipt verification candidate.
  • the correct DPC code cannot be determined for a patient who has taken into consideration the cost of medical care and has performed only a medical practice commonly performed for a plurality of DPC codes. There was a problem that it was difficult to determine the necessity of verification.
  • the present invention includes a storage unit that stores receipt data, and a likelihood calculation unit that calculates a likelihood of association between the patient and the diagnostic code based on the receipt data.
  • a reception verification candidate extraction unit for extracting verification candidate receipt data based on the likelihood, wherein the reception data includes a patient, a diagnosis code of the patient, and the patient
  • the likelihood calculation unit includes information for associating the performed medical practice with the cost of the medical practice, and the likelihood calculating unit includes the cost of each medical practice performed on the patient and the diagnostic code of each medical practice.
  • the receipt verification candidate extraction unit calculates the likelihood of each diagnosis code, and if the calculated diagnosis code with the maximum likelihood is different from the diagnosis code of the patient, the receipt data of the patient is a verification candidate. And information indicating that the patient's receipt data is a verification candidate is output.
  • a correct diagnostic code even for a patient who has performed a medical practice that is performed in common with a plurality of diagnostic codes (for example, DPC codes) in consideration of medical costs.
  • the necessity of receipt verification can be judged.
  • FIG. 1 is a block diagram showing a configuration of a receipt verification work support system 100 according to the first embodiment of the present invention.
  • Example 1 shown in FIG. 1 is a first example of a usage pattern in which a receipt verification work support system to which the present invention is applied is installed in a hospital.
  • the receipt verification work support system 100 includes a control unit 101, an input unit 102, an output unit 103, a memory 104, a communication unit 105, a display screen generation unit 106, an execution probability calculation unit 108, a likelihood calculation unit 109, a receipt.
  • the verification candidate extraction unit 111, the execution probability database 114, and the receipt analysis database 115 are configured.
  • a receipt information database 130 in which the receipt data after examination request in the hospital and the receipt data for examination request in the hospital are stored, and the receipt validation work.
  • the input / output terminal 150 for the medical department the doctor's input / output terminal 160 for confirming the contents of the receipt which is highly necessary for the receipt verification, and the like.
  • the control unit 101 controls the overall operation of the receipt verification work support system 100.
  • the control unit 101 may be a processor that executes a program stored in the memory 104.
  • the input unit 102 provides a function of accepting input of information to the receipt verification work support system 100.
  • the input unit 102 may include a keyboard and a pointing device (for example, a mouse).
  • the output unit 103 provides a function of outputting information from the receipt verification work support system 100.
  • the output unit 103 may include a display device that displays text, images, and the like.
  • the memory 104 is a storage device that stores various data necessary for processing executed by the receipt verification work support system 100.
  • the communication unit 105 is a network interface that is connected to the network 120 and communicates with the receipt information database 130, the medical department input / output terminal 150, the doctor input / output terminal 160, and the like.
  • the execution probability database 114 and the receipt analysis database 115 are stored in a storage device in the receipt verification work support system 100.
  • the execution probability database 114 and the receipt analysis database 115 are stored in a storage device (not shown) such as a hard disk drive included in the receipt verification work support system 100, and at least a part of them is stored in the memory 104 as necessary. It may be copied.
  • at least a part of the receipt data acquired from the receipt information database 130 is also stored in the memory 104 as necessary.
  • the display screen generation unit 106 provides a function of creating a screen to be displayed on the medical department input / output terminal 150 and the doctor input / output terminal 160.
  • the execution probability calculation unit 108 acquires the receipt data after the examination request stored in the receipt information database 130 via the network 120, and the probability that each medical practice is implemented in each diagnosis code from the receipt data after the examination request. A function of calculating an execution probability and storing it in the execution probability database 114 is provided.
  • the diagnostic code is a code representing a diagnostic group classification and a diagnostic group, for example, a DRG code in the United States, a DPC code in Japan, and the like.
  • the likelihood calculating unit 109 acquires the examination request object receipt data stored in the receipt information database 130 and the execution probability stored in the execution probability database 114 via the network 120, and the examination request object Provides a function to calculate the likelihood that each diagnosis code represents the likelihood corresponding to the patient based on the cost, the number of times and the execution probability of each medical practice described in the receipt data, and store it in the receipt analysis database 115 To do.
  • the receipt verification candidate extraction unit 111 acquires the likelihood corresponding to each diagnosis code of each patient stored in the receipt analysis database 115, calculates the diagnosis code with the highest likelihood as the maximum likelihood code, and receives the receipt analysis database The function to store in 115 is provided.
  • the receipt verification candidate extraction unit 111 performs diagnosis of each patient described in the maximum likelihood code of each patient stored in the reception analysis database 115 and the receipt data to be examined stored in the reception information database 130.
  • the patient is extracted as a receipt verification candidate, and the patient information of the reception verification candidate, the likelihood of the maximum likelihood code, and the likelihood of the diagnostic code are extracted. And a total analysis cost are stored in a receipt analysis database.
  • the functions of the display screen generation unit 106, the execution probability calculation unit 108, the likelihood calculation unit 109, and the receipt verification candidate extraction unit 111 may be realized by hardware such as a dedicated logic circuit, respectively. It may be realized by executing a program stored in 104.
  • the control unit 101 the processing executed by the above-described units in the following description is actually performed by the control unit 101 according to instructions described in a program stored in the memory 104. Executed.
  • the likelihood corresponding to each diagnosis code is calculated using the cost of the medical practice, the number of executions, and the execution probability, and the diagnosis code with the highest likelihood is calculated as the maximum likelihood code. It is possible to estimate the diagnostic code with the input.
  • the likelihood of the maximum likelihood code and the likelihood of the diagnostic code can be compared, and the difference between the maximum likelihood code and the diagnostic code can be grasped. It becomes possible.
  • FIG. 2 is an explanatory diagram showing a data structure of the receipt data table 400 constituting the receipt information database 130 according to the first embodiment of this invention.
  • the receipt data table 400 (FIG. 2) is a table for storing information on a receipt after an examination request and a receipt to be examined, and is basically registered by the medical department in charge of the receipt requesting work.
  • the table includes a patient ID field 401, a hospitalization date field 402, a discharge date field 403, a diagnosis code field 404, a medical practice field 405, a medical cost field 406, a number of actions field 407, an implementation date field 408, An examination requested fragment field 409 and an examination requested object fragment field 410 are included.
  • the patient ID field 401 stores a patient ID which is an identifier for identifying a patient.
  • the hospitalization date field 402 stores the date on which the patient started hospitalization.
  • the discharge date field 403 stores the date on which the patient was discharged. Since there are patients who repeat a plurality of hospital discharges, it is possible to designate one hospitalization data by combining the patient ID field 401 and the hospitalization date field 402 or the patient ID field 401 and the hospital discharge date field 403. It becomes possible.
  • the diagnostic code field 404 stores a diagnostic code corresponding to one hospitalization of each patient.
  • a DRG code is stored in the diagnostic code field 404 in the DRG / PPS in the United States
  • a DPC code is stored in the DPC system in Japan.
  • the medical practice field 405 stores the name of the medical practice performed on each patient.
  • the medical cost field 406 stores a medical cost required when each medical service stored in the medical service field 405 is performed once.
  • the action number field 407 stores the number of times the medical action stored in the medical action field 405 has been performed.
  • the implementation date field 408 stores the date on which the medical practice stored in the medical practice field 405 was implemented.
  • the examination requested fragment field 409 stores a flag indicating whether each record belongs to the receipt after examination requested.
  • the examination request target fragment field 410 stores a flag indicating whether each record belongs to the examination request target receipt.
  • the flags of both the examination requested fragment field 409 and the examination requested fragment field 410 do not have a value at the same time, and only one of the flags has a value.
  • the examination requested fragment field 409 of the record has no value in the initial state (for example, the value is “0”), and the examination requested fragment field 410 Has a value in the initial state (for example, the value is “1”).
  • the examination request is made for a record in which the examination request target fragment field 410 has a value.
  • the examination requested fragment field 409 is updated to have a value
  • the examination request target fragment field 410 is updated to have no value.
  • the diagnostic code stored in the diagnostic code field 404 of each record is described as the diagnostic code of the patient identified by the patient ID of the record, but the examination request target fragment field 410 has a value.
  • the diagnostic code stored in the diagnostic code field 404 of the record may be described as the current diagnostic code of the patient.
  • This system refers to the value of the examination requested fragment field 409 or the examination requested fragment field 410, so that only the records belonging to the receipt after the examination request or only the data belonging to the examination requested receipt are obtained. Each can be extracted.
  • receipt data after examination request and the receipt request examination data are stored in the receipt data table 400 having the examination requested fragment field 409 and the examination request fragment field 410, instead of storing these fields. Each may be stored in a separate dedicated table.
  • FIG. 3 is an explanatory diagram showing a data structure of an execution probability table 500 constituting the execution probability database 114 according to the first embodiment of the present invention.
  • the execution probability table 500 (FIG. 3) is a table that stores the probability that each medical practice will be performed on the patient of each diagnostic code. The correspondence between each diagnostic code and the patient is specified based on the receipt data table 400. One record of the execution probability table 500 stores the probability that one medical practice will be performed on the patient of each diagnostic code.
  • the table includes a medical practice field 501 and a limited number of diagnostic code fields 502.
  • the medical practice field 501 stores the name of the medical practice.
  • the diagnosis code field 502 is a probability that the medical practice stored in the medical practice field 501 in the same record is performed for a patient having a diagnostic code (for example, diagnostic codes 1 to 3) of each field name of the diagnostic code field 502. Is stored. This probability is calculated by the execution probability calculation unit 108 (see FIG. 7 and the like) as will be described later.
  • the receipt analysis database 115 stores information necessary for extracting receipt verification candidates and information necessary for screen generation in the display screen generation unit 106.
  • the receipt analysis database 115 includes an expected cost table 900, a likelihood table 1000, and a receipt verification table 1400.
  • FIG. 5, and FIG. 6 are explanatory diagrams showing the data structures of the expected cost table 900, the likelihood table 1000, and the receipt verification table 1400, respectively, constituting the receipt analysis database 115 according to the first embodiment of the present invention.
  • the expected cost table 900 (FIG. 4) stores an expected cost representing the degree of possibility that the medical cost of each medical practice performed on each patient is input to each diagnostic code.
  • the expected cost is calculated by the likelihood calculating unit 109 as described later (see FIG. 10 and the like). It includes a medical practice field 901 and a finite number of diagnostic code fields 902.
  • the medical practice field 901 stores the name of the medical practice performed on each patient.
  • diagnosis code field 902 the expected cost of the medical practice stored in the medical practice field 901 in the same record in each diagnostic code is stored.
  • FIG. 4 shows an example of an expected cost table 900 that stores the expected cost calculated for the patient whose patient ID is ## 1.
  • the expected cost for medical practice A is 800 for diagnostic code 1, 300 for diagnostic code 2, 160 for diagnostic code 3, and the expected cost for medical practice B is 0 for diagnostic code 1 and diagnostic code 2 160 and 80 in the diagnosis code 3 are shown.
  • the likelihood calculating unit 109 creates a similar expected cost table 900 for each patient.
  • the likelihood table 1000 (FIG. 5) stores the likelihood calculated by the likelihood calculating unit 109 and indicating the likelihood that each diagnosis code corresponds to each patient.
  • the table includes a patient ID field 1001 and a finite number of diagnostic code fields 1002.
  • the patient ID field 1001 stores a patient ID that is an identifier for identifying a patient.
  • the diagnosis code field 1002 stores a likelihood representing the likelihood that each patient corresponds to each diagnosis code. For example, the value of the diagnostic code field 1002 corresponding to “diagnostic code 1” of the record corresponding to the patient ID “## 1” is identified by the patient ID “## 1”. This means that the likelihood that the patient corresponds to “diagnosis code 1” is “5000”.
  • the patient whose patient ID is ## 1 has a DPC code 1 likelihood of 5000, a DPC code 2 likelihood of 2800, a DPC code 3 likelihood of 1200, and a patient ID of #
  • the likelihood of DPC code 1 is 760
  • the likelihood of DPC code 2 is 3900
  • the likelihood of DPC code 3 is 9400.
  • the receipt verification table 1400 (FIG. 6) is a table that stores detailed information calculated by the receipt verification candidate extraction unit 111 for determining whether or not the receipt verification is necessary.
  • the table includes a patient ID field 1401, a diagnostic code field 1402, a diagnostic code likelihood field 1403, a maximum likelihood code field 1404, a maximum likelihood code likelihood field 1405, a receipt verification fragment field 1406, and a total medical cost field 1407. Is done.
  • the patient ID field 1401 stores a patient ID that is an identifier for identifying a patient.
  • the diagnosis code field 1402 stores the current diagnosis code of the patient corresponding to the patient ID stored in the patient ID field 1401 in the same record. This diagnostic code is read from the diagnostic code field 404 of the receipt data table 400 corresponding to the patient ID.
  • the diagnostic code likelihood field 1403 stores the likelihood of the diagnostic code stored in the diagnostic code field 1402 in the same record. This likelihood is calculated by the likelihood calculating unit 109.
  • the maximum likelihood code likelihood field 1405 stores the diagnosis code having the highest likelihood in the patient corresponding to the patient ID stored in the patient ID field 1401 in the same record. This diagnostic code is extracted by the receipt verification candidate extraction unit 111.
  • the maximum likelihood code likelihood field stores the likelihood of the maximum likelihood code calculated by the receipt verification candidate extraction unit 111.
  • the receipt verification fragment field 1406 stores a flag indicating the necessity of reception verification.
  • the total medical cost field 1407 stores the total medical cost which is the sum of the medical costs of all the medical care activities of the patient corresponding to the patient ID stored in the patient ID field 1401 in the same record.
  • the receipt verification work support system 100 can extract only the information of the patient that requires the receipt verification. By extracting only patient information that requires receipt verification, the receipt verification work support system 100 can present only patients that require receipt verification.
  • the execution probability is a probability that each medical practice is executed in each diagnosis code.
  • the execution probability calculation unit 108 can execute the execution probability calculation process at an arbitrary time.
  • the execution probability calculation process may be started when the medical department instructs the start of the process using the input / output terminal 150, may be started once a month, or may be a date and time designated by the medical department. It may be started automatically or at the same time when the medical department starts the system.
  • FIG. 7 is a flowchart showing an example of the execution probability calculation process executed by the execution probability calculation unit 108 according to the first embodiment of the present invention.
  • the execution probability calculation unit 108 refers to the receipt data table 400 stored in the receipt information database 130 via the network 120, and data that has a value in the examination requested fragment field 409 (that is, the examination request is received). Only the obtained data) is acquired (S201). Next, the execution probability calculation unit 108 calculates the average number of executions that is the average number of times each medical practice is performed for each hospitalization in each diagnosis code (S202).
  • FIG. 8 is a flowchart illustrating an example of processing in which the execution probability calculation unit 108 according to the first embodiment of the present invention calculates the average number of executions.
  • the execution probability calculation unit 108 selects one diagnostic code for calculating the average number of executions from the diagnostic code field 404 of the data acquired in S201 (S301).
  • the execution probability calculation unit 108 calculates the total number of patients by counting the number of patient IDs of the records in which the diagnosis code selected in S301 is stored in the diagnosis code field 404 (S302).
  • the execution probability calculation unit 108 selects one medical practice for calculating the average number of implementations from the medical practice field 405 of the data acquired in S201 (S303).
  • the execution probability calculation unit 108 calculates the number of actions of the record in which the diagnosis code selected in S301 is stored in the diagnosis code field 404 and the medical action selected in S303 is stored in the medical action field 405.
  • the total number of executions is calculated by counting (S304).
  • the execution probability calculation unit 108 divides the total number of executions calculated in S304 by the total number of patients calculated in S302, thereby obtaining the average number of executions of the medical practice selected in S303 in the diagnosis code selected in S301. Calculate (S305).
  • the implementation probability calculation unit 108 checks whether or not there is an unselected medical practice (S306), and if there is an unselected medical practice, executes the processing after S303 for the unselected medical practice. To do. If there is no unselected medical practice, the execution probability calculation unit 108 executes the next step.
  • the execution probability calculation unit 108 checks whether or not an unselected diagnostic code exists (S307). If there is an unselected diagnostic code, the processing after S301 is performed on the unselected diagnostic code. Execute. If there is no unselected diagnostic code, the execution probability calculation unit 108 ends the calculation process of the average number of executions.
  • the execution probability calculation unit 108 selects one medical practice for calculating the implementation probability from the medical practice field 405 of the data acquired in S201 (S203).
  • the execution probability calculation unit 108 calculates the total sum of the average number of executions in each diagnosis code of the medical practice selected in S203 (S204).
  • the execution probability calculation unit 108 selects one diagnostic code for calculating the execution probability from the diagnostic code field 404 of the data acquired in S201 (S205).
  • the execution probability calculation unit 108 divides the average number of times of the medical practice selected in S203 in the diagnostic code selected in S205 by the sum of the average number of times calculated in S204, thereby selecting the diagnostic code selected in S205.
  • the execution probability of the medical practice selected in S203 is calculated (S206).
  • the execution probability calculation unit 108 stores the execution probability of the medical practice selected in S203 in the diagnosis code selected in S205 calculated in S206 in the execution probability table 500 (S207).
  • the execution probability calculation unit 108 checks whether or not there is an unselected diagnostic code (S208). If there is an unselected diagnostic code, the processing after S205 is performed on the unselected diagnostic code. Execute. If there is no unselected diagnostic code, the execution probability calculation unit 108 executes the next step.
  • the execution probability calculation unit 108 checks whether there is an unselected medical practice, and if there is an unselected medical practice, executes the processing after S203 for the unselected medical practice. When there is no unselected medical practice, the execution probability calculation unit 108 executes the next step (S209). Next, the execution probability calculation unit 108 registers the execution probability table 500 in the execution probability database 114 (S210). Through the above processing, the execution probability of each medical practice in each diagnostic code is calculated.
  • the execution probability can be accurately calculated based on the data that has passed the request for examination. . Further, by calculating the execution probability from the receipt data after the request for examination accumulated in the hospital, it is possible to calculate the execution probability according to the medical performance of each hospital.
  • Likelihood is the likelihood that each diagnostic code corresponds to a patient.
  • the likelihood calculation process is started when the medical department performs a process start operation using the input / output terminal 150.
  • FIG. 9 is a flowchart illustrating an example of likelihood calculation processing executed by the likelihood calculation unit 109 according to the first embodiment of this invention.
  • the likelihood calculating unit 109 acquires the receipt data table 400 stored in the receipt information database 130 via the network 120 (S601). Next, the likelihood calculating unit 109 extracts only data having a value in the examination request target fragment field 410 (that is, data that has not been requested yet) from the acquired receipt data table 400 (S602). ). In this process, the data extracted in S602 is hereinafter referred to as analysis target data.
  • the likelihood calculating unit 109 acquires the execution probability table 500 stored in the execution probability database 114 (S603).
  • the likelihood calculating unit 109 selects a patient ID of any patient from the patient ID field 401 of the analysis target data (S604).
  • the likelihood calculating unit 109 refers to the hospitalization date field 402 of the patient selected in S604, and determines whether the stored hospitalization date is before the execution month of the process (S605). ).
  • the likelihood calculating unit 109 executes S606, and subsequently executes S607.
  • the likelihood calculating unit 109 executes S607 without executing S606.
  • the likelihood calculating unit 109 calculates the hospitalization date in which the hospitalization date stored in the hospitalization date field 402 is referred to in S605 in the patient selected in S604 from the receipt data table 400 acquired in S601. Extract all data with the same value as the day. Then, the likelihood calculating unit 109 adds the extracted data to the analysis target data extracted in S602. If duplicate data exists in the analysis target data, the likelihood calculating unit 109 deletes one of the duplicate data (S606).
  • the likelihood calculating unit 109 uses the analysis target data to calculate an expected cost that represents the probability that the medical cost of each medical practice is input to each diagnostic code (S607).
  • FIG. 10 is a flowchart illustrating an example of processing in which the likelihood calculating unit 109 according to the first embodiment of the present invention calculates an expected cost.
  • the likelihood calculating unit 109 selects one diagnostic code from the diagnostic code field 404 of the analysis target data (S801).
  • the likelihood calculating unit 109 selects one medical practice from the medical practice field 405 of the analysis target data (S802).
  • the likelihood calculation unit 109 adds the values in the diagnosis cost field 406 of the record in which the diagnosis code selected in S802 is stored in the diagnosis code field 404 in the patient selected in S604, and the selection is made in S802.
  • the total medical cost of the performed medical practice is calculated (S803).
  • the likelihood calculating unit 109 extracts the implementation probability of the medical practice selected in S802 in the diagnostic code selected in S801 from the implementation probability table 500, and calculates the extracted implementation probability and the total medical cost calculated in S803. By multiplying, the expected cost is calculated (S804).
  • the likelihood calculating unit 109 associates the patient ID of the patient selected in S604 with the medical practice selected in S802 and the expected cost calculated in S804, and stores it in the expected cost table 900 (S805).
  • the likelihood calculating unit 109 checks whether or not there is an unselected medical practice (S806), and if there is an unselected medical practice, the processing after S802 is performed on the unselected medical practice. Execute. When there is no unselected medical practice, the likelihood calculating unit 109 executes the next step.
  • the likelihood calculating unit 109 checks whether or not there is an unselected diagnostic code (S807). If there is an unselected diagnostic code, the processing after S801 is performed on the unselected diagnostic code. Execute. When there is no unselected diagnostic code, the likelihood calculating unit 109 executes the next step.
  • the likelihood calculating unit 109 registers the expected cost table 900 in the receipt analysis database 115, and ends the expected cost calculation process (S808).
  • the likelihood calculating unit 109 continues to hold the expected cost table 900 until the likelihood calculating process ends. With the above processing, the expected cost of each medical practice in each diagnostic code is calculated.
  • the likelihood calculating unit 109 selects one diagnostic code from the diagnostic code field 404 of the analysis target data (S608).
  • the likelihood calculating unit 109 selects all the expected costs of each medical practice stored in the diagnostic code field 902 corresponding to the diagnostic code selected in S608 in the expected cost table 900, thereby selecting in S608.
  • the likelihood corresponding to the diagnosed code is calculated. (S609).
  • the likelihood calculating unit 109 associates the likelihood calculated in S609 with the patient ID of the patient selected in S604 and the diagnosis code selected in S608 and stores the likelihood in the likelihood table 1000 (S610).
  • the likelihood calculating unit 109 checks whether or not there is an unselected diagnostic code (S611), and if there is an unselected diagnostic code, the processing after S608 is performed on the unselected diagnostic code. Execute. When there is no unselected diagnostic code, the likelihood calculating unit 109 executes the next step.
  • the likelihood calculating unit 109 checks whether or not an unselected patient ID exists (S612), and if there is an unselected patient ID, performs the processing from S604 onward for the unselected patient ID. Execute. When there is no unselected patient ID, the likelihood calculating unit 109 executes the next step.
  • the likelihood calculating unit 109 registers the likelihood table 1000 in the receipt analysis database 115 (613). Through the above processing, the likelihood that each patient corresponds to each diagnosis code is calculated.
  • the receipt verification candidate is a patient who may not have an appropriate diagnosis code because the diagnosis code already assigned to the patient does not match the diagnosis code having the highest likelihood. This process is automatically started after the likelihood calculation unit 109 calculates the likelihood corresponding to each diagnosis code of the patient, the medical department performs a process start operation using the input / output terminal 150, etc. Processing begins.
  • FIG. 11 is a flowchart showing an example of the receipt verification candidate extraction process executed by the receipt verification candidate extraction unit 111 according to the first embodiment of the present invention.
  • the receipt verification candidate extraction unit 111 acquires the likelihood table 1000 from the receipt analysis database 115 (S1301).
  • the receipt verification candidate extraction unit 111 selects one patient ID from the patient ID field 1401 of the likelihood table 1000. (S1302).
  • the receipt verification candidate extraction unit 111 sets the diagnosis code name of the diagnosis code field 1102 having the maximum likelihood as the maximum likelihood code in the patient ID selected in S1302, and the diagnosis code field 1102 having the maximum likelihood. Are extracted as the likelihood of the maximum likelihood code, respectively (S1303).
  • diagnosis code name “diagnostic code 3” in the diagnostic code field 1102 having the maximum likelihood of “9400” is the maximum likelihood code
  • likelihood “9400” is the likelihood of the maximum likelihood code.
  • the receipt verification candidate extraction unit 111 records in the receipt data table 400 in which the patient ID selected in S1302 is stored in the patient ID field 401 and the value is stored in the examination request target fragment field 410
  • the diagnostic code stored in the diagnostic code field 404 is acquired (S1304).
  • the receipt verification candidate extraction unit 111 associates the patient ID selected in S1302, the diagnostic code acquired in S1304 and the likelihood thereof, the maximum likelihood code extracted in S1303 and the likelihood thereof, respectively, and a receipt verification table 1400. (S1305).
  • the receipt verification candidate extraction unit 111 verifies whether or not the maximum likelihood code and the diagnosis code stored in association with each other in S1305 match (S1306), and the maximum likelihood code and the diagnosis code do not match Executes S1307 and subsequently executes S1308. On the other hand, if the maximum likelihood code matches the diagnostic code, the receipt verification candidate extraction unit 111 executes S1307 without executing S1307.
  • the receipt verification candidate extraction unit 111 stores a value of 1 in the reception verification fragment field 1406 of the reception verification table 1400 in association with the patient ID selected in S1302.
  • the receipt verification candidate extraction unit 111 sets the medical cost stored in the medical cost field 406 of all records of the receipt data table 400 in which the patient ID selected in S1302 is stored in the patient ID field 401.
  • the total medical cost is calculated by counting.
  • the receipt verification candidate extraction unit 111 stores the calculated total medical cost value in the total medical cost field 1407 of the reception verification table 1400 in association with the patient ID selected in S1302 (S1309).
  • the receipt verification candidate extraction unit 111 checks whether or not an unselected patient ID exists (S1310), and if there is an unselected patient ID, the processes after S1302 are performed for the unselected patient ID. Execute. If there is no unselected patient ID, the receipt verification candidate extraction unit 111 executes the next step.
  • the reception verification candidate extraction unit 111 registers the reception verification table 1400 in the reception analysis database 115 (S1311). Through the above processing, the receipt verification candidate extraction unit 111 extracts a receipt verification candidate.
  • the receipt verification candidates extracted as described above constitute a display screen for displaying the receipt verification candidates in the display screen generation unit 106, and the display screen is displayed on the input / output terminal 150.
  • FIG. 12 is an explanatory diagram of a screen example 1600 that the conventional receipt verification work support system presents to the input / output terminal 150 based on the correspondence table.
  • the conventional receipt verification work support system calculates and holds the diagnosis cost of each diagnosis code without calculating the likelihood of each diagnosis code.
  • the conventional receipt verification work support system refers to a record having a value in the examination requested fragment field 409 among the records of the receipt data table 400, and determines a diagnosis code corresponding to each medical practice.
  • it is determined that the medical practice stored in the medical practice field 405 of any record corresponds to the diagnostic code stored in the diagnostic code field 404 of the record.
  • One medical practice may correspond to a plurality of diagnostic codes.
  • the conventional receipt verification work support system refers to the patient ID field 401, the diagnosis code field 404, the medical practice field 405, and the medical cost field 406 of the record in which the examination request fragment field 410 has a value.
  • the total value of the medical costs of the medical practice corresponding to the current diagnostic code of the patient is calculated as the diagnostic cost of the diagnostic code.
  • the conventional reception verification service support system calculates the total cost of medical treatment costs corresponding to diagnostic codes other than the current diagnostic code for each patient as the medical cost of each medical behavior, and calculates the current diagnostic cost.
  • the medical costs calculated for each of the code and the other diagnostic codes are compared, and the diagnostic code corresponding to the largest value among them is extracted as the optimal diagnostic code for the patient.
  • the conventional reception verification service support system calculates and holds the same total medical cost as that stored in the total medical cost field 1407 of the reception verification table 1400.
  • the conventional reception verification service support system includes, for example, a patient ID field 1401, a diagnostic code field 1402, and a total medical cost field 1407, and a diagnostic code likelihood field 1403, a maximum likelihood code field 1404, and a maximum likelihood code likelihood field.
  • the diagnostic cost field (not shown) of the diagnostic code that does not include 1405 and stores the diagnostic cost of the current diagnostic code of each patient calculated as described above, and the optimal diagnostic code field (not shown) that stores the optimal diagnostic code
  • a receipt verification table (not shown) including a diagnosis cost field (not shown) of the optimum diagnosis code for storing the diagnosis cost of the optimum diagnosis code.
  • the values stored in these fields are displayed in the corresponding fields of the screen example 1600 as will be described later.
  • Screen example 1600 includes a receipt verification candidate list display unit 1601, a medical practice list display unit 1602, and a confirmation request button 1603.
  • the receipt verification candidate list display unit 1601 includes a doctor submission check button 16011, a medical practice list display button 16012, a patient ID field 16013, a diagnostic code field 16014, a diagnostic cost medical cost field 16015, an optimal diagnostic code field 16016, and an optimal diagnosis. It includes a medical cost cost field 16017 for a code and a total medical cost field 16018.
  • the receipt verification candidate list display unit 1601 displays only the patients of the reception verification candidates that are determined to be required to be verified by the method using the correspondence table.
  • the doctor check button 16011 is selected when pressed by the screen operator (for example, an operation such as a mouse click, and so on).
  • the medical treatment list display button 16012 is selected when pressed by the screen operator.
  • the medical practice list display button 16012 is pressed by the screen operator, the medical practice list of the patient corresponding to the pressed medical practice list display button 16012 is displayed on the medical practice list display unit 1602.
  • the patient ID field 16013 displays a patient ID that is an identifier for identifying a patient.
  • the diagnosis code field 16014 displays the current diagnosis code of the patient identified by the value of the patient ID field 16013.
  • the diagnosis cost field 16015 of the diagnosis code displays the diagnosis cost input to the diagnosis code in the diagnosis code field 16014.
  • the medical cost displayed in the medical cost field 16015 of the diagnosis code of each record is the medical cost of the medical service corresponding to the diagnostic code of the record in the medical service performed on the patient identified by the patient ID of each record. Is the sum of
  • the optimal diagnosis code field 16016 displays the diagnosis code having the maximum value of the medical treatment cost of the medical treatment as the optimal diagnosis code in the patient identified by each patient ID.
  • the optimal diagnostic code medical cost field 16017 displays the optimal diagnostic code medical cost.
  • the total medical cost field 16018 displays the total medical cost, which is a value obtained by summing up the medical costs of all the medical activities performed on each patient.
  • the total medical cost is calculated in the same manner as that stored in the total medical cost field 1407 of the receipt verification table 1400 according to the first embodiment of this invention.
  • the medical practice list display unit 1602 includes a medical practice field 16021, a correspondence field 16022 with a diagnostic code, and a correspondence field 16023 with an optimum diagnostic code.
  • the medical practice list display unit 1602 displays a list of medical practices performed on the patient of the record corresponding to the pressed medical practice list display button 16012.
  • the receipt verification work support system transmits the receipt information of the patient whose submission check button 16011 to the doctor is selected at the time of pressing as a confirmation request receipt to the doctor.
  • the value of the diagnosis code field 16014 of the record in which the value of the patient ID field 16013 is ## 2 is “diagnosis code 2”, and the value of the diagnosis cost field 16015 of the diagnosis code is “22,000”. is there.
  • the optimum diagnosis code field 16016 of the record two values of “diagnosis code 2” that is the same as the current diagnosis code of the patient and “diagnosis code 3” that is different from the diagnosis code are stored.
  • the value of the diagnosis cost field 16017 of the optimum diagnosis code corresponding to each diagnosis code is “22,000”, which is the same as the diagnosis cost field 16015 of the diagnosis code.
  • the medical practice list display unit 1602 displays a list of medical practice performed on the patient whose patient ID is ## 2.
  • the medical practice A, the medical practice C, and the medical practice D which are the medical practice performed on the patient, are respectively set in the correspondence field 16023 with the optimum diagnostic code and the correspondence field 16022 with the diagnostic code. Is described. Therefore, all the medical practices performed on the patient whose patient ID is ## 2 are all the current diagnostic code of the patient (diagnostic code 2 in the above example) and an optimal diagnostic code different from that (in the above example, This is a medical practice performed in common for both diagnosis codes 3).
  • the operator of this system cannot determine which of the diagnostic code described in the diagnostic code field 16014 and the diagnostic code described in the optimal diagnostic code field 16016 is the optimal diagnostic code. In the example of FIG. 12, it cannot be determined which of the diagnostic code 2 and the diagnostic code 3 is the optimal diagnostic code for the patient with the patient ID ## 2. Based on the above, the operator of this system determines the necessity of receipt verification in the case of a patient who has only undergone medical practice that is performed in common with both the current diagnosis code and the optimal diagnosis code of a patient. There was a problem that it was not possible.
  • FIG. 13 is an explanatory diagram of a screen example 1500 that is presented to the input / output terminal 150 by the receipt verification business support system 100 according to the first embodiment of this invention.
  • Screen example 1500 includes a receipt verification candidate list display unit 1501, a medical practice list display unit 1502, and a confirmation request button 1503.
  • the receipt verification candidate list display unit 1501 includes a doctor submission check button 15011, a medical practice list display button 15012, a patient ID field 15013, a diagnostic code field 15014, a diagnostic code likelihood field 15015, a maximum likelihood code field 15016, and a maximum likelihood code.
  • a likelihood field 15017 and a total medical cost field 15018 are included.
  • the receipt verification candidate list display unit 1501 displays only information related to patients whose “1” is stored in the reception verification fragment field 1406 of the reception verification table 1400.
  • the “Submit to Doctor” check button 15011 is selected when pressed by the screen operator (that is, the user of the receipt verification work support system 100).
  • the medical practice list display button 15012 is selected when pressed by the screen operator.
  • the medical practice list display button 15012 is pressed by the screen operator, the medical practice list of the patient corresponding to the pressed medical practice list display button 15012 is displayed on the medical practice list display unit 1502.
  • the patient ID field 15013 displays a patient ID that is an identifier for identifying a patient.
  • the diagnosis code field 15014 displays the current diagnosis code of the patient identified by the value of the patient ID field 15013 in the receipt verification table 1400, that is, the value of the diagnosis code field 1402 corresponding to the patient.
  • the diagnostic code likelihood field 15015 displays the value of the diagnostic code likelihood field 1403 of the patient in the receipt verification table 1400.
  • the maximum likelihood code field 15016 displays the value of the maximum likelihood code field 1404 of the patient in the receipt verification table 1400.
  • the maximum likelihood code likelihood field 15017 displays the value of the maximum likelihood code likelihood field 1405 of the patient in the receipt verification table 1400.
  • the total medical cost field 15018 displays the total medical cost, which is the total value of the medical costs of all the medical practices performed on the patient, stored in the total medical cost field 1407 of the receipt verification table 1400.
  • the medical practice list display unit 1502 includes a medical practice field 15021, an expected cost field 15022 in the diagnostic code, and an expected cost field 15023 in the maximum likelihood code.
  • the medical practice list display unit 1502 displays a list of medical practices performed on the patient of the record corresponding to the pressed medical practice list display button 15012.
  • the medical practice performed on the patient is read from the record having a value in the examination request target fragment field 410 of the receipt data table 400.
  • the receipt verification work support system 100 transmits, as a confirmation request receipt to the doctor, the patient's receipt information for which the submission check button 15011 to the doctor is currently selected. .
  • the value of the diagnosis code likelihood field 15015 of the patient whose patient ID field 15013 is ## 2 is 3,900 and the value of the maximum likelihood code likelihood field 15017. Is shown to be 9,400.
  • the medical practice list display unit 1502 displays a list of medical practice performed on the patient whose patient ID is ## 2.
  • the expected cost field 15023 in the maximum likelihood code and the expected cost field 15023 in the diagnostic code for the clinical practice A, the medical practice C, and the medical practice D which are the medical practices performed on the patient, are respectively displayed. Is described.
  • the medical practice A, the medical practice C, and the medical practice D are all performed in accordance with both the diagnostic code in the diagnostic code field 15014 and the diagnostic code in the maximum likelihood code field 15016.
  • the value of the expected cost field 15023 in the maximum likelihood code is shown higher than the value of the expected cost field 15022. Therefore, all the medical practices performed on the patient whose patient ID is ## 2 are medical practices that have a high probability of being performed in the diagnostic code of the maximum likelihood code field 15016. This is a medical practice with a high expected cost of the medical costs input.
  • the system operator refers to the value of the expected cost field 15022 in the diagnostic code of each medical practice displayed on the medical practice list display unit 1502 and the value of the expected cost field 15023 in the maximum likelihood code. It is possible to grasp the expected cost that the medical treatment cost of the action is input to both diagnostic codes.
  • the operator of this system understands the expected cost, which is the expected value of the amount of each diagnostic action that has been input to both diagnostic codes, thereby causing a difference in likelihood between the diagnostic codes. It becomes possible to grasp.
  • the system operator can easily determine the necessity of receipt verification by grasping the medical practice that causes the difference in likelihood between the two diagnostic codes.
  • the execution probability is calculated based on the receipt data having a value in the examination requested fragment field 409 (that is, the receipt data that is not the candidate for verification candidate extraction). This is because it is possible to determine that an appropriate diagnosis code has been given since the receipt data having a value in the examination requested fragment field 409 has already passed examination. As a result, the execution probability is calculated based on the actual medical treatment at each hospital, so it is possible to accurately determine the possibility that the diagnostic code of each patient is not appropriate based on the actual medical treatment trends that were performed at each hospital in the past. It becomes possible to judge.
  • the receipt verification work support system 100 obtains a verification candidate by obtaining a standard execution probability from, for example, another hospital or a public institution, and calculating the likelihood based on the standard execution probability. It can also be extracted.
  • Example 2 of the present invention will be described. Except for the differences described below, each part of the receipt verification work support system 1700 of the second embodiment has the same function as each part denoted by the same reference numeral in the first embodiment shown in FIGS. Therefore, those descriptions are omitted.
  • FIG. 14 is a block diagram illustrating a configuration of the receipt verification work support system 1700 according to the second embodiment of this invention.
  • Example 2 shown in FIG. 14 is a second example of a usage pattern in which a receipt verification work support system to which the present invention is applied is installed in a hospital.
  • the receipt verification service support system 1700 illustrated in FIG. 14 stores the comprehensive volume difference calculation unit 112, the receipt verification priority calculation unit 113, and various master tables in the receipt verification service support system 100 according to the first embodiment illustrated in FIG.
  • the knowledge database 116 and the alignment control unit 117 are added.
  • the comprehensive volume difference calculation unit 112 uses the receipt data stored in the receipt information database 130 to be examined and the comprehensive compensation master table registered in the knowledge database to calculate the medical compensation amount (hereinafter referred to as comprehensive compensation) in the comprehensive payment method. And a function for calculating a medical fee amount (hereinafter referred to as a volume reward) in the volume payment method.
  • the amount of medical remuneration paid to the hospital in the volume payment method is the sum of the medical costs of all the medical practices performed during the hospitalization period of each patient. Therefore, the volume remuneration is equal to the sum of the medical costs of all the medical practices performed during the hospitalization period of each patient.
  • the receipt verification priority calculation unit 113 provides a function of calculating a receipt verification priority, which is an index indicating the priority of verification of a receipt verification candidate.
  • the alignment control unit 117 provides a function of aligning the receipt verification candidates displayed on the screen created by the display screen generation unit 106 based on the alignment criterion.
  • the functions of the comprehensive volume difference calculation unit 112, the receipt verification priority calculation unit 113, and the alignment control unit 117 may be realized by hardware such as a dedicated logic circuit, or the control unit 101 is stored in the memory 104. It may be realized by executing a program.
  • the processing executed by the above-described units in the following description is actually performed by the control unit 101 according to instructions described in a program stored in the memory 104. Executed.
  • the knowledge database 116 is stored in a storage device in the receipt verification work support system 1700.
  • the knowledge database 116 may be stored in a storage device (not shown) such as a hard disk drive included in the receipt verification work support system 1700, and at least a part of them may be copied to the memory 104 as necessary.
  • the receipt analysis database 115 includes a comprehensive volume table 2000 and a receipt verification priority table 2200 in addition to the expected cost table 900, the likelihood table 1000, and the receipt verification table 1400 similar to those in the first embodiment.
  • FIG. 15 and FIG. 16 are explanatory diagrams showing the data structures of the comprehensive volume table 2000 and the receipt verification priority table 2200 constituting the receipt analysis database 115 according to the second embodiment of the present invention, respectively.
  • the comprehensive volume table 2000 (FIG. 15) stores the comprehensive volume difference calculated by the comprehensive volume difference calculation unit 112, which is the difference between the comprehensive reward, the volume reward, and the comprehensive reward and the volume reward for each patient.
  • the table includes a patient ID field 2001, a comprehensive reward field 2002, a volume reward field 2003, and a comprehensive volume difference field 2004.
  • the patient ID field 2001 stores a patient ID that is an identifier for identifying a patient.
  • the comprehensive reward field 2002 stores the comprehensive reward of the patient identified by each patient ID.
  • the volume reward field 2003 stores the volume reward of the patient identified by each patient ID.
  • the comprehensive volume difference field 2004 stores the difference between the comprehensive reward and the volume reward of the patient identified by each patient ID.
  • the reception verification priority table 2200 (FIG. 16) stores the reception verification priority of each patient calculated by the reception verification priority calculation unit 113 and the comprehensive volume difference calculated by the comprehensive volume difference calculation unit 112.
  • the table includes a patient ID field 2201, a receipt verification priority field 2202, and a comprehensive volume difference field 2203.
  • the patient ID field 2201 stores a patient ID that is an identifier for identifying a patient.
  • the reception verification priority field 2202 stores the reception verification priority of each patient calculated by the reception verification priority calculation unit 113.
  • the comprehensive volume difference field 2203 stores the comprehensive volume difference calculated by the comprehensive volume difference calculation unit 112.
  • the knowledge database 116 includes a comprehensive reward master table 1900.
  • FIG. 17 is an explanatory diagram showing a data structure of the comprehensive reward master table 1900 constituting the knowledge database 116 according to the second embodiment of the present invention.
  • the comprehensive compensation master table 1900 (FIG. 17) stores the comprehensive compensation amount per day or per hospitalization in the comprehensive payment method. Depending on the form of operation of the comprehensive payment method, the amount of comprehensive payment per day may be set in stages depending on the length of hospitalization. In this embodiment, an example of the comprehensive reward master table 1900 when the comprehensive reward amount per day is set in three stages according to the hospitalization period is shown.
  • the comprehensive compensation master table 1900 includes a diagnosis code field 1901, a hospitalization period 1 field 1902, a daily comprehensive compensation field 1903 in the hospitalization period 1, a hospitalization period 2 field 1904, a comprehensive compensation field 1905 per day in the hospitalization period 2, and a hospitalization period. 3 field 1906, and a comprehensive remuneration field 1907 per day in hospitalization period 3.
  • the diagnostic code field 1901 stores a diagnostic code.
  • the hospitalization period 1 field 1902 stores the hospitalization period corresponding to the first stage of each diagnosis code.
  • the comprehensive compensation field 1903 per day in the hospitalization period 1 stores the comprehensive compensation per day corresponding to the hospitalization period in the hospitalization period 1 field 1902 of each diagnosis code.
  • the hospitalization period 2 field 1904 stores the hospitalization period corresponding to the second stage of each diagnosis code.
  • the comprehensive compensation field 1905 per day in the hospitalization period 2 stores the comprehensive compensation per day corresponding to the hospitalization period in the hospitalization period 2 field 1904 of each diagnosis code.
  • the hospitalization period 3 field 1906 stores the hospitalization period corresponding to the third stage of each diagnosis code.
  • the comprehensive compensation field 1907 per day in the hospitalization period 3 stores the comprehensive compensation per day corresponding to the hospitalization period in the hospitalization period 3 field 1906 of each diagnosis code.
  • the comprehensive volume difference is the difference between the comprehensive reward and the volume reward. This process is started at the same time as the likelihood calculation process in the likelihood calculation unit 109 is completed.
  • FIG. 18 is a flowchart illustrating an example of the comprehensive volume difference calculation process executed by the comprehensive volume difference calculation unit 112 according to the second embodiment of the present invention.
  • the comprehensive volume difference calculation unit 112 acquires the receipt data table 400 stored in the receipt information database 130 via the network 120 (S1801).
  • the comprehensive volume difference calculation unit 112 acquires the comprehensive reward master table 1900 stored in the knowledge database 116 via the network 120 (S1802).
  • the comprehensive volume difference calculation unit 112 selects a patient by selecting one patient ID in the patient ID field 401 in the record in which the examination requested fragment field 409 has a value in the receipt data table 400. (S1803).
  • the comprehensive volume difference calculation unit 112 calculates a comprehensive reward (S1804).
  • FIGS. 19A and 19B are flowcharts showing an example of processing in which the comprehensive volume difference calculation unit 112 according to the second embodiment of the present invention calculates a comprehensive reward.
  • the comprehensive volume difference calculation unit 112 sets the comprehensive reward to 0 (S4001).
  • the comprehensive volume difference calculation unit 112 acquires the diagnosis code of the patient with the patient ID selected in S1803 from the receipt data table 400 (S4002).
  • the comprehensive volume difference calculation unit 112 calculates the hospitalization days of the patient with the patient ID selected in S1803 from the hospitalization date field 402 and the discharge date field 403 of the receipt data table 400 (S4003).
  • the comprehensive volume difference calculation unit 112 refers to the upper limit days of the hospitalization period 1 of the diagnosis code acquired in S4002 from the hospitalization period 1 field 1902 of the comprehensive reward master table 1900, and the hospitalization days calculated in S4003 It is determined whether it is equal to or less than the upper limit number of days of period 1 (S4004).
  • the comprehensive volume difference calculation unit 112 executes S4005.
  • the comprehensive volume difference calculation unit 112 executes S4006.
  • the comprehensive volume difference calculation unit 112 substitutes the product of the medical fee for the hospitalization period 1 of the diagnosis code acquired in S4002 and the number of days of hospitalization calculated in S4003 for the comprehensive fee, and ends the comprehensive fee calculation process.
  • the comprehensive volume difference calculation unit 112 substitutes the product of the medical fee for the hospitalization period 1 of the diagnostic code acquired in S4002 and the number of days of the hospitalization period 1 of the diagnostic code acquired in S4002 for the comprehensive reward.
  • the comprehensive volume difference calculation unit 112 refers to the upper limit days of the hospitalization period 2 of the diagnosis code acquired in S4002 from the hospitalization period 2 field 1904 of the comprehensive reward master table 1900, and the hospitalization days calculated in S4003 It is determined whether it is equal to or less than the upper limit number of days in period 2 (S4007).
  • the comprehensive volume difference calculation unit 112 executes S4008.
  • the comprehensive volume difference calculation unit 112 executes S4009.
  • the comprehensive volume difference calculation unit 112 adds the product of the medical fee for the hospitalization period 2 of the diagnostic code acquired in S4002 and the number of days of hospitalization calculated in S4003 to the comprehensive fee, and ends the calculation process of the comprehensive fee.
  • the comprehensive volume difference calculation unit 112 adds the product of the medical fee for the hospitalization period 2 of the diagnostic code acquired in S4002 and the number of days of the hospitalization period 2 of the diagnostic code acquired in S4002 to the comprehensive reward.
  • the comprehensive volume difference calculation unit 112 refers to the upper limit days of the hospitalization period 3 of the diagnosis code acquired in S4002 from the hospitalization period 3 field 1906 of the comprehensive reward master table 1900, and the hospitalization days calculated in S4003 It is determined whether it is equal to or less than the upper limit number of days in period 3 (S4010).
  • the comprehensive volume difference calculation unit 112 executes S4011. If the hospitalization days calculated in S4003 are not less than or equal to the upper limit days of the hospitalization period 3, the comprehensive volume difference calculation unit 112 executes S4012.
  • the comprehensive volume difference calculation unit 112 adds the product of the medical fee for the hospitalization period 3 of the diagnosis code acquired in S4002 and the number of days of hospitalization calculated in S4003 to the comprehensive fee, and ends the comprehensive fee calculation processing.
  • the comprehensive volume difference calculation unit 112 adds the product of the medical fee for the hospitalization period 3 of the diagnostic code acquired in S4002 and the number of days of the hospitalization period 3 for the diagnostic code acquired in S4002 to the comprehensive reward, The calculation process ends.
  • the comprehensive volume difference calculation unit 112 calculates the volume reward by counting the medical costs of all the medical practices performed during the hospitalization period of the patient with the patient ID selected in S1803 from the medical cost field 406 ( S1805).
  • the comprehensive volume difference calculation unit 112 calculates the difference between the comprehensive reward calculated in S1804 and the volume reward calculated in S1805 as a comprehensive volume difference (S1806).
  • the comprehensive volume difference calculation unit 112 stores the calculated comprehensive reward, the volume reward, and the comprehensive volume difference in the comprehensive volume table 2000 in association with the patient ID (S1807).
  • the comprehensive volume difference calculation unit 112 checks whether or not an unselected patient ID exists (S1808), and if there is an unselected patient ID, the processes after S1803 are performed on the unselected patient ID. Execute. If there is no unselected patient ID, the receipt verification candidate extraction unit 111 executes the next step.
  • the comprehensive volume difference calculation unit 112 registers the comprehensive volume table 2000 in the receipt analysis database 115 (S1809). Through the above processing, the comprehensive volume difference calculation unit 112 calculates the comprehensive reward, the volume reward, and the comprehensive volume difference.
  • the receipt verification priority is an index representing the priority of verification of a receipt verification candidate.
  • the receipt verification priority is calculated by multiplying the ratio of the likelihood of the maximum likelihood code to the total medical cost and the comprehensive volume difference. The greater the value of the receipt verification priority in the present embodiment, the smaller the comprehensive reward is compared to the volume reward, and the more likely the diagnostic code is erroneous.
  • the receipt verification priority may be calculated using a hospital-specific standard such as a standardized likelihood for each DPC and a comprehensive volume difference.
  • This process is started when the comprehensive volume difference calculation process in the comprehensive volume difference calculation unit 112 is completed.
  • FIG. 20 is a flowchart illustrating an example of the receipt verification priority calculation process executed by the receipt verification priority calculation unit 113 according to the second embodiment of this invention.
  • the receipt verification priority calculation unit 113 acquires the receipt verification table 1400 from the receipt analysis database 115 (S2101).
  • the receipt verification priority calculation unit 113 acquires the comprehensive volume table 2000 from the receipt analysis database 115 (S2102).
  • the receipt verification priority calculation unit 113 selects one patient by selecting one patient ID from the patient ID field 1401 of the record having the value in the reception verification fragment field 1406 in the reception verification table 1400 (S2103). ).
  • the receipt verification priority calculation unit 113 divides the value of the maximum likelihood code likelihood field 1405 of the patient with the patient ID selected in S2103 in the reception verification table by the value of the total medical cost field 1407 of the patient.
  • the maximum likelihood medical cost ratio is calculated (S2104).
  • the receipt verification priority calculation process is executed for a patient whose current diagnosis code and maximum likelihood code do not match. Therefore, the magnitude of the maximum likelihood medical cost ratio calculated here represents a high possibility that the current diagnostic code is not optimal.
  • the receipt verification priority calculation unit 113 multiplies the maximum likelihood medical cost ratio calculated in S2103 by the value of the comprehensive volume difference field 2004 of the patient with the patient ID selected in S2103 in the comprehensive volume table 2000.
  • the receipt verification priority is calculated (S2105). Therefore, the receipt verification priority increases as the current diagnosis code is more likely to be non-optimal, and the difference between the comprehensive reward and the volume reward (more specifically, the value obtained by subtracting the volume reward from the comprehensive reward) increases. It gets bigger.
  • the reception verification priority calculation unit 113 stores the comprehensive volume difference and the reception verification priority calculated in S2104 in the reception verification priority table 2200 in association with the patient ID selected in S2103 (S2106). ).
  • the receipt verification priority calculation unit 113 checks whether or not an unselected patient ID exists (S2107), and if there is an unselected patient ID, the processes after S2103 are performed on the unselected patient ID. Execute. If there is no unselected patient ID, the receipt verification priority calculation unit 113 executes the next step.
  • the reception verification priority calculation unit 113 registers the reception verification priority table 2200 in the reception analysis database 115 (S2108). Through the above processing, the receipt verification priority calculation unit 113 calculates the receipt verification priority.
  • the display screen generation unit 106 configures a display screen for displaying the comprehensive reward, the volume reward, the comprehensive volume difference, and the receipt verification priority calculated as described above together with the receipt verification candidates shown in the first embodiment.
  • the configured display screen is displayed by the input / output terminal 150.
  • FIG. 21 is an explanatory diagram of a screen example 2300 presented to the input / output terminal 150 by the receipt verification work support system 1700 according to the second embodiment of the present invention.
  • Screen example 2300 includes a receipt verification candidate list display unit 1501, a medical practice list display unit 1502, a confirmation request button 1503, and an alignment reference setting unit 1504.
  • the receipt verification candidate list display unit 1501 includes a doctor submission check button 15011, a medical practice list display button 15012, a patient ID field 15013, a diagnostic code field 15014, a diagnostic code likelihood field 15015, a maximum likelihood code field 15016, and a maximum likelihood code. It includes a likelihood field 15017, a total medical cost field 15018, a comprehensive volume difference field 15019, and a receipt verification priority field 150111.
  • the receipt verification candidate list display unit 1501 displays only information related to patients whose values exist in the reception verification fragment field 1406 of the reception verification table 1400 (for example, “1” is stored).
  • Doctor submission check button 15011 medical practice list display button 15012, patient ID field 15013, diagnostic code field 15014, diagnostic code likelihood field 15015, maximum likelihood code field 15016, maximum likelihood code likelihood field 15017, and total medical cost field
  • Reference numerals 15018 are the same as those denoted by the same reference numerals in FIG.
  • the comprehensive volume difference field 15019 provides a function of displaying the value of the comprehensive volume difference of the patient with the patient ID in the receipt verification priority table 2200.
  • the reception verification priority field 150111 provides a function of displaying the value of the reception verification priority of the patient with the patient ID in the reception verification priority table 2200.
  • the medical practice list display unit 1502 and the confirmation request button 1503 are the same as the parts with the same reference numerals in FIG.
  • the alignment reference setting unit 1504 includes an alignment setting button 15041, an alignment reference object item radio button 15042, and an alignment reference object order radio button 15043.
  • the alignment setting button 15041 is selected by being pressed by the screen operator. When the selection is made, the alignment reference set by the alignment reference target item radio button 15042 and the alignment reference target order radio button 15043 is displayed. A function of transmitting to the alignment control unit 117 via the screen generation unit 106 is provided.
  • a unique alignment reference target item is selected from a plurality of alignment reference target items, and the selected alignment reference target item is used as a selection criterion. Provide the function to set.
  • the receipt verification priority and the comprehensive volume difference are displayed as the alignment reference target items, and either one of them is selected by operating the alignment reference target item radio button 15042.
  • a unique alignment reference target order is selected from a plurality of alignment reference target orders, and the selected alignment reference target order is used as a selection reference. Provide the function to set.
  • ascending order and descending order are displayed as the alignment reference target order, and one of them is selected by operating the alignment reference target order radio button 15043.
  • FIG. 22 is a sequence diagram related to the alignment process executed by the receipt verification work support system 1700 according to the second embodiment of the present invention.
  • the input / output terminal 150 is operated by the alignment reference object item radio button 15042 and the alignment reference object order radio button 15043.
  • the set selection criterion is transmitted to the display screen generation unit 106 (S2401).
  • the display screen generation unit 106 transmits the alignment criteria transmitted from the input / output terminal 150, and the receipt verification candidate data whose value exists in the reception verification fragment field 1406 in the reception verification table 1400 constituting the display screen. Is transmitted to the alignment control unit 117 (S2402).
  • the alignment control unit 117 creates a list of receipt verification candidates that are aligned based on the alignment criterion, and transmits the list to the display screen generation unit 106 (S2403).
  • the display screen generation unit 106 configures a screen as shown in the receipt verification candidate list display unit 1501 of FIG. 21 based on the list transmitted from the alignment control unit 117 and displays it on the input / output terminal 150 ( S2404). Thereby, the patient's receipt data for which a high receipt verification priority is calculated is displayed preferentially (for example, at the top of the list).
  • the screen operator can preferentially verify a receipt verification candidate that is highly interested. For example, by selecting the receipt verification priority with the alignment reference target item radio button 15042 and selecting the descending order with the alignment reference target order radio button 15043, the receipt verification candidates are in descending order of the negative value and the absolute value of the reception verification priority. Are aligned. Patients with negative and high absolute value of receipt verification priority are likely to have incorrect diagnostic codes, and can be easily increased by changing to the correct diagnostic code. It is a high candidate for receipt verification. Therefore, the screen operator preferentially verifies the receipt verification candidates that are likely to have an incorrect diagnostic code and that can easily increase the medical fee by changing to the correct diagnostic code. Things will be possible.
  • the method for calculating the receipt verification priority as described above is an example, and the receipt verification priority calculated by various methods can be used according to the purpose of the receipt verification. For example, if you want to preferentially verify the receipt data of a patient who is likely to have an incorrect diagnosis code regardless of the possibility that the medical fee will increase, use the maximum likelihood medical cost ratio as the receipt verification priority. May be. Or, if you want to preferentially verify the patient's receipt data that is likely to increase the medical fee regardless of the possibility that the diagnosis code is wrong, you can use the comprehensive volume difference as the receipt verification priority. Good.
  • each part of the receipt verification business support system 2500 according to the third embodiment has the same functions as those denoted by the same reference numerals as those according to the first or second embodiment. Is omitted.
  • FIG. 23 is a block diagram showing a configuration of the receipt verification work support system 2500 according to the third embodiment of the present invention.
  • the receipt verification business support system 2500 of the third embodiment shown in FIG. 23 is installed in an institution that examines a receipt submitted from a hospital such as an examination payment institution that is a receipt examination organization designated by the country and pays a medical fee.
  • the receipt verification work support system 2500 includes a control unit 101, an input unit 102, an output unit 103, a memory 104, a communication unit 105, a display screen generation unit 106, an execution probability calculation unit 108, a likelihood calculation unit 109, and a receipt verification candidate extraction unit.
  • 111 an execution probability database 114, a receipt analysis database 115, a knowledge database 116, and an alignment control unit 117.
  • the receipt verification work support system 2500 is connected via the network 120 to an input / output terminal 170 that performs a receipt examination work, a receipt examination system 180, a submitted receipt information database 190, and the like.
  • the submission receipt information database 190 stores information on receipts submitted from at least one hospital.
  • the submission receipt information database 190 includes a submission receipt data table 4100.
  • FIG. 24 is an explanatory diagram showing a data structure of a submission receipt data table 4100 constituting the submission receipt information database 190 according to the third embodiment of the present invention.
  • the submission receipt data table 4100 (FIG. 24) is a table for storing the examination request receipt data and the examination requested receipt data submitted by each hospital, and is basically automatically registered by the receipt examination system 180. Is done.
  • the table includes a patient ID field 4101, a hospitalization date field 4102, a discharge date field 4103, a diagnosis code field 4104, a medical practice field 4105, a medical cost field 4106, a number of actions field 4107, an implementation date field 4108, An examination requested fragment field 4109, an examination requested object fragment field 4110, and a hospital code field 4111 are configured.
  • the patient ID field 4101 to examination request fragment field 4110 may be the same as the patient ID field 401 to examination request fragment field 410 of the receipt data table 400 (FIG. 2), respectively. The description is omitted.
  • the hospital code field 4111 stores a hospital code that is an identifier for identifying a hospital that has submitted a report.
  • This system can extract only the receipt data submitted from a specific hospital by referring to the hospital code field 4111.
  • This system extracts only the records belonging to the post-examination request and only the data belonging to the examination-requested receipt by referring to the value of the examination-requested fragment field 4109 or the examination-requested fragment field 4110. It is possible to do.
  • the examination requested fragment field 4109 basically has no value when submitted from each hospital (for example, the value is 0), and after the examination of the receipt is completed, the receipt examination system 180 sets the value (for example, 1). ) Is entered.
  • the examination request fragment field 4110 is basically input with a value (for example, 1) by the receipt examination system 180 when submitted from each hospital, and after the receipt examination is completed, the value is entered by the receipt examination system 180. Deleted (for example, the value is updated to 0).
  • receipt data after examination request and the receipt request examination data are not stored in one submission receipt data table 4100 having examination requested fragment field 4109 and examination request fragment field 4110, but instead of these fields. May be stored in separate tables that do not have
  • the display screen generation unit 106 of the present embodiment displays a display screen for displaying the comprehensive reward, the volume reward, the comprehensive volume difference, and the receipt verification priority shown in the second embodiment together with the receipt verification candidates shown in the first embodiment. Constitute.
  • the configured display screen is displayed by the input / output terminal 170.
  • FIG. 25 is an explanatory diagram of a screen example 2600 presented by the receipt verification business support system 2500 according to the third embodiment of the present invention on the input / output terminal 170.
  • the screen example 2600 (FIG. 25) includes a receipt verification candidate list display unit 1501, a medical practice list display unit 1502, an alignment criterion setting unit 1504, and a return request button 1505. Returning means that the reviewing organization returns the receipt that the reviewing organization has determined to require correction to the submitting hospital.
  • the receipt verification candidate list display unit 1501 includes a hospital return check button 150112, a medical practice list display button 15012, a patient ID field 15013, a diagnostic code field 15014, a diagnostic code likelihood field 15015, a maximum likelihood code field 15016, and a maximum likelihood code. It includes a likelihood field 15017, a total medical cost field 15018, a comprehensive volume difference field 15019, and a receipt verification priority field 150111.
  • the receipt verification candidate list display unit 1501 displays only information related to patients whose values exist in the examination request target fragment field 4110 of the submission receipt data table 4100.
  • the return to hospital check button 150112 is selected when pressed by the screen operator.
  • Medical treatment list display button 15012 patient ID field 15013, diagnostic code field 15014, diagnostic code likelihood field 15015, maximum likelihood code field 15016, maximum likelihood code likelihood field 15017, total medical cost field 15018, comprehensive volume difference field 15019 and
  • the receipt verification priority field 150111 is the same as the part denoted by the same reference numeral in FIG.
  • the medical practice list display unit 1502 is the same as that shown in FIG.
  • the reception verification service support system 2500 receives the receipt information of the patient whose return check button 150112 to the hospital is currently selected as a return request reception to the hospital. Transmit to system 180.
  • the alignment reference setting unit 1504 is the same as that shown in FIG.
  • this system is used for the purpose of extracting a receipt in which an inappropriate DPC code is written in a receipt submitted from each hospital and a medical fee more than the appropriate amount is requested. Therefore, it is necessary for the examination organization to preferentially verify the receipt verification candidates having a positive comprehensive difference value and a large absolute value and a high likelihood of the maximum likelihood code.
  • the “receipt verification priority” is set using the alignment reference object item radio button 15042 and the alignment reference object order radio button 15043 in the alignment reference setting unit 1504.
  • each part of the receipt verification work support system 2700 according to the fourth embodiment has the same function as each part denoted by the same reference numeral in the first, second, or third embodiment. These descriptions are omitted.
  • FIG. 26 is a block diagram illustrating a configuration of a receipt verification work support system 2700 according to the fourth embodiment of the present invention.
  • the receipt verification work support system 2700 of Example 3 shown in FIG. 26 is installed in a hospital.
  • the receipt verification work support system 2700 is configured by adding a code control unit 118 to the receipt verification work support system 1700 shown in FIG.
  • the code control unit 118 is characterized in that the code for calculating the execution probability and likelihood is changed from a diagnostic code to a higher-order code of the diagnostic code.
  • the diagnostic code is a DPC code
  • the upper code of the DPC code is a disease code
  • the upper code of the disease code is a main diagnostic group code.
  • the diagnostic code is a DRG code
  • the upper code of the DRG code is an MDC (Major Diagnostic Category) code.
  • the diagnostic code is an HRG code
  • the upper code of the HRG code is a group code of two alphabetic characters called Sub-chapter
  • the upper code is a group code of one alphabetic character called Chapter.
  • the Japanese DPC system is taken as an example.
  • the present invention is not limited to the DPC system, but can be applied to diagnostic codes and higher-order codes in all comprehensive payment systems.
  • diagnostic code when Examples 1 to 3 are applied to the Japanese DPC system, the “diagnostic code” described in Examples 1 to 3 may be any of a DPC code, a disease code, and a main diagnostic group code.
  • a disease code is a code in which a plurality of DPC codes are grouped by disease, and corresponds to the upper 6 digits of the DPC code.
  • the main diagnosis group code is a code in which a plurality of disease codes are collected, and corresponds to the upper two digits of the DPC code.
  • FIG. 27 is an explanatory diagram of the code master 2800 constituting the knowledge database 116 according to the fourth embodiment of the present invention.
  • the code master 2800 is a table including a main diagnosis group code field 2801, a disease code field 2802, and a DPC code field 2803, for example, as shown in FIG.
  • the DPC code field 2803 stores the DPC code
  • the disease code field 2802 stores the disease code corresponding to each DPC code
  • the main diagnosis group code field 2801 stores the main diagnosis group code corresponding to each disease code.
  • DPC code 1 and DPC code 2 correspond to disease code 1
  • DPC code 3-4 corresponds to disease code 2
  • DPC code 5 corresponds to disease code 3.
  • the disease code 1 and the disease code 2 correspond to the main diagnosis group code 1
  • the disease code 3 corresponds to the main diagnosis group code 2.
  • the execution probability calculation unit 108 calculates the execution probability so that the disease code or the main diagnosis group code It is possible to calculate the execution probability in.
  • the code control unit 118 changes the DPC code to a disease code or a main diagnosis group code so that the likelihood calculation unit 109 calculates the likelihood and the maximum likelihood code calculation unit 110 calculates the maximum likelihood code. Alternatively, it can be carried out for the main diagnostic group code.
  • the DPC coding mistake in the unit of the disease code or the main diagnosis group code can be applied to the DPC code in which there are few or no corresponding patients in the DPC data storage database 140. It is possible to make a determination.
  • FIG. 28 is an explanatory diagram of a screen example 2900 presented to the input / output terminal 150 by the receipt verification work support system 2700 according to the fourth embodiment of the present invention.
  • the screen example 2900 includes a code reference setting unit 1506 in addition to the same parts as the screen example 2300 shown in FIG.
  • the code reference setting unit 1506 includes a plurality of radio buttons for selecting a code reference and a code setting button. 28 shows an example in which this embodiment is applied to the Japanese DPC system, the code reference setting unit 1506 in FIG. 28 has three radio buttons corresponding to the DPC code, disease code, and diagnostic group classification code, respectively. Is displayed.
  • FIG. 29 is a sequence diagram relating to a process in which the receipt verification work support system 2700 according to the fourth embodiment of the present invention extracts a receipt verification candidate based on a selected code.
  • the screen operator When displaying the receipt verification candidate based on the disease code or the main diagnosis group code, the screen operator operates the input / output terminal 150 to select the radio button of the code reference setting unit 1506 shown in FIG. A code reference is selected and a code setting button 15061 is pressed.
  • the input / output terminal 150 transmits the selected code reference to the code control unit 118 via the display screen generation unit 106 (S3001, S3002).
  • the code control unit 118 calculates a maximum likelihood code based on the selected code standard, and acquires, as a receipt verification candidate, patient receipt data for which the calculated maximum likelihood code is different from the current code of the receipt information.
  • the code control unit 118 converts the DPC code of the receipt data into a disease code based on the code master 2800, and performs the execution probability calculation unit 108 and the likelihood calculation unit 109.
  • the execution probability, likelihood, and the like may be calculated by the same method as in Examples 1 to 3 based on the disease code.
  • the main diagnosis group code is selected as the code reference
  • the DPC code of the receipt data is converted into the main diagnosis group code, and the execution probability and likelihood are calculated based on the DPC code.
  • the code control unit 118 transmits information such as the maximum likelihood code based on the calculated likelihood to the receipt verification candidate extraction unit 111 (S3003).
  • the receipt verification candidate extraction unit 111 extracts a receipt verification candidate by the same method as in the first to third embodiments, and transmits the result to the code control unit 118 (S3004).
  • the code control unit 118 transmits the acquired receipt verification candidate, its maximum likelihood code, and the code of the receipt information to the display screen generation unit 106 (S3005). Based on the received receipt verification candidate, its maximum likelihood code, and the code of the receipt information, the display screen generation unit 106 configures a screen as shown in FIG. 28 and presents it to the input / output terminal 150 (S3006).
  • FIG. 28 shows an example in which a disease code is selected as a code criterion.
  • the disease code 2 is calculated in the diagnostic code field 15014
  • the likelihood of the disease code 2 is stored in the diagnostic code likelihood field 15015
  • the maximum likelihood disease code calculated from the receipt data of the disease code 2 is stored in the maximum likelihood code field 15016.
  • the likelihood of the disease code 3 is displayed in the maximum likelihood code likelihood field 15017, respectively.
  • the current diagnosis code of the patient identified by the patient ID ## 5 is the DPC code 3, but the diagnosis code is the DPC code 3 in the receipt data of the examination request of the hospital where the patient is hospitalized. If some data is not included, it cannot be determined whether or not the patient's receipt data should be a verification candidate based on the DPC code. Further, even if the receipt data for which examination has been requested includes data whose diagnostic code is DPC code 3, if the amount is small, a highly reliable determination cannot be made.
  • both the DPC code 3 and the DPC code 4 correspond to the same disease code 2. Even if different DPC codes are given, it is considered that the tendency of medical practice performed on patients who are given the same disease code (i.e. having the same injury or illness) is similar. Similarly, the similarity in clinical practice between patients given the same primary diagnostic group code is considered higher than the similarity between patients given different primary diagnostic group codes.
  • the receipt data for which examination is requested sufficiently includes, for example, data whose diagnostic code is DPC code 4, the maximum likelihood code and the like are calculated for disease code 2 including DPC code 3 and DPC code 4.
  • the maximum likelihood code and the like are calculated for disease code 2 including DPC code 3 and DPC code 4.
  • Example 4 when there are few corresponding patients or there are DPC codes for which there are no corresponding patients, it is possible to determine a DPC coding error in units of disease codes and main diagnosis group codes. By making changes, it becomes possible to support receipt verification.
  • this invention is not limited to the Example mentioned above, Various modifications are included.
  • the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described.
  • a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment.
  • each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor.
  • Information such as programs, tables, and files that realize each function is a memory, hard disk drive, storage device such as SSD (Solid State Drive), or computer-readable non-transitory data such as an IC card, SD card, or DVD. It can be stored in a storage medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Biomedical Technology (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Data Mining & Analysis (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Databases & Information Systems (AREA)
  • Pathology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

　レセプトデータを保持する記憶部と、尤度算出部と、レセプト検証候補抽出部と、を有する業務支援システムであって、前記レセプトデータは、患者と、前記患者の診断コードと、前記患者に実施された診療行為と、前記診療行為のコストと、を対応付ける情報を含み、前記尤度算出部は、前記患者に実施された各診療行為のコストと、前記各診療行為の前記診断コードごとの実施確率と、に基づいて、前記各診療行為の前記診断コードごとの期待コストを算出し、前記各診断コードに対応する全ての前記診療行為の前記期待コストの合計値を前記各診断コードの尤度として算出し、前記レセプト検証候補抽出部は、前記算出された尤度が最大となる診断コードと、前記患者の診断コードとが異なる場合、前記患者のレセプトデータが検証候補であると判定し、前記患者のレセプトデータが検証候補であることを示す情報を出力する。

Description

業務支援システム、業務支援方法及び業務支援プログラム
　本発明は、医療従事者による医療関連業務上の判断を支援するシステム、方法及びプログラムに関する。
　本技術分野の背景技術として、特開２０１０－１５７１２８号公報（特許文献１）がある。特許文献１には、「データ入出力制御部から入院時の担当医師が仮診断群分類データを入力する。患者に対して入院期間中に投入されてゆく治療、検査、薬剤の医療資源を表わす医療資源データをデータ入出力部を介して入力してゆく。担当医師から退院承認が出ると、最適診断群分類選定部は、医療資源－診断群分類データベースを参照しつつ、入院期間中に入力されたすべての医療資源データを診断群分類ごとに分類・集計して実際に最も多くの医療資源が投入された最適診断群分類を特定し、診断群分類検証部は、入院時に入力された仮診断群分類と、実際に最も多くの医療資源が投入された最適診断群分類とが一致しているか否かを検証する。」と記載されている（要約参照）。
　特許文献１：特開２０１０－１５７１２８号公報
　近年、増え続ける医療費の抑制の為、医療の質向上と効率化が世界的に求められている。このような背景のもと、医療行為の実績に基づいて診療報酬を支払う出来高払いに変わり、傷病名と診療行為の組み合わせに応じて一定の診療報酬を支払う包括支払い方式が注目されている。米国における包括支払い方式では、ＤＲＧ（Diagnosis Related Group：診断別関連群）と呼ばれる診断群分類に基づき、１入院当りの支払い額が決定されるＤＲＧ/ＰＰＳ（Diagnosis Related Group and the prospective payment system : 診断関連群による包括定額支払方式）が導入されている。英国における包括支払い方式では、ＨＲＧ（Healthcare Resource Group）と呼ばれる診断群ごとに設定された価格に基づき、支払い額が決定されるＰｂＲ（Payment by Results：実績払い方式）が導入されている。日本における包括支払い方式では、ＤＰＣ（Diagnosis Procedure Combination）コードと呼ばれる傷病名と診療行為を組み合わせた１４桁の番号ＤＰＣコードに基づき、入院１日当たりの包括支払い額が決定されるＤＰＣ制度が導入されている。このＤＰＣ制度において厚生労働省は、各患者に最適なＤＰＣコードとは「最も診療コストを投入した傷病名が属するＤＰＣコードである」と定義している。ＤＰＣ制度を導入している病院は、ＤＰＣコードを記載した診療報酬明細書（以下、レセプト）を作成し、社会保険診療報酬支払基金又は国民健康保険団体連合会などの審査支払機関に提出することで診療報酬の請求を行う。もし、レセプトに記載されたＤＰＣコードが適切でない場合、病院は適正な診療報酬を受け取る事が出来ない。そのため、病院経営において、レセプトに記載されたＤＰＣコードが適切であるかを検証し、適切なＤＰＣコードを付与するレセプト検証作業は重要となっている。
　レセプト検証作業を支援するシステムとして、ＤＰＣコード毎に実施される診療行為が定義された対応表を用いてレセプト検証候補を抽出するシステムが提案されている（特許文献１参照）。特許文献１に記載されたシステムは、まず、対象のレセプトに記載された診療行為をもとに、対応表のＤＰＣコード毎に定義された診療行為に対応する保険点数を合計し、保険点数の合計が最も高いＤＰＣコード、即ち最も診療コストの高いＤＰＣコードを最適ＤＰＣコードとして算出する。次に、レセプトに記載されているＤＰＣコードと算出した最適ＤＰＣコードとが一致しないレセプトを、レセプト検証候補として抽出する。
　このように、特許文献１に記載されたシステムでは、対応表と診療コストから算出した最適ＤＰＣコードを用いる事で検証が必要なレセプトが抽出される。しかし、対応表を用いたシステムでは、複数のＤＰＣコードに共通して実施される診療行為のみを行っている患者の場合、保険点数の合計が同値になってしまう。そのため、このような患者は、最適ＤＰＣコードを正しく算出する事が出来ないため、レセプト検証の必要性を判断することが困難であった。
　以上のように、従来の技術では、診療コストを考慮し、かつ、複数のＤＰＣコードに共通して実施される診療行為のみを行った患者について、正しいＤＰＣコードを判定する事ができず、レセプト検証の必要性を判断することが困難であるという課題があった。
　上記の課題を解決するために、本発明は、レセプトデータを保持する記憶部と、前記レセプトデータに基づいて、前記患者と前記診断コードとの対応付けの尤度を算出する尤度算出部と、前記尤度に基づいて、検証候補のレセプトデータを抽出するレセプト検証候補抽出部と、を有する業務支援システムであって、前記レセプトデータは、患者と、前記患者の診断コードと、前記患者に実施された診療行為と、前記診療行為のコストと、を対応付ける情報を含み、前記尤度算出部は、前記患者に実施された各診療行為のコストと、前記各診療行為の前記診断コードごとの実施確率と、に基づいて、前記各診療行為の前記診断コードごとの期待コストを算出し、前記各診断コードに対応する全ての前記診療行為の前記期待コストの合計値を前記各診断コードの尤度として算出し、前記レセプト検証候補抽出部は、前記算出された尤度が最大となる診断コードと、前記患者の診断コードとが異なる場合、前記患者のレセプトデータが検証候補であると判定し、前記患者のレセプトデータが検証候補であることを示す情報を出力することを特徴とする。
　本発明の一実施形態によれば、診療コストを考慮し、かつ、複数の診断コード（例えばＤＰＣコード）に共通して実施される診療行為のみを行った患者についても正しい診断コードを判定できるため、レセプト検証の必要性を判断する事ができる。
　上記以外の課題、構成および効果は、以下の実施形態の説明によって明らかにされる。
本発明の実施例１のレセプト検証業務支援システムの構成を示すブロック図である。 本発明の実施例１のレセプト情報データベースを構成するレセプトデータテーブルのデータ構造を示す説明図である。 本発明の実施例１の実施確率データベースを構成する実施確率テーブルのデータ構造を示す説明図である。 本発明の実施例１のレセプト分析データベースを構成する期待コストテーブルのデータ構造を示す説明図である。 本発明の実施例１のレセプト分析データベースを構成する尤度テーブルのデータ構造を示す説明図である。 本発明の実施例１のレセプト分析データベースを構成するレセプト検証テーブルのデータ構造を示す説明図である。 本発明の実施例１の実施確率算出部が実行する実施確率算出処理の例を示すフローチャートである。 本発明の実施例１の実施確率算出部が平均実施回数を算出する処理の例を示すフローチャートである。 本発明の実施例１の尤度算出部が実行する尤度算出処理の例を示すフローチャートである。 本発明の実施例１の尤度算出部が期待コストを算出する処理の例を示すフローチャートである。 本発明の実施例１のレセプト検証候補抽出部が実行するレセプト検証候補抽出処理の例を示すフローチャートである。 従来のレセプト検証業務支援システムが対応表に基づいて入出力端末に提示する画面例の説明図である。 本発明の実施例１のレセプト検証業務支援システムが入出力端末に提示する画面例の説明図である。 本発明の実施例２のレセプト検証業務支援システムの構成を示すブロック図である。 本発明の実施例２のレセプト分析データベースを構成する包括出来高テーブルのデータ構造を示す説明図である。 本発明の実施例２のレセプト分析データベースを構成するレセプト検証優先度テーブルのデータ構造を示す説明図である。 本発明の実施例２の知識データベースを構成する包括報酬マスタテーブルのデータ構造を示す説明図である。 本発明の実施例２の包括出来高差算出部が実行する包括出来高差算出処理の例を示すフローチャートである。 本発明の実施例２の包括出来高差算出部が包括報酬を算出する処理の例を示すフローチャートである。 本発明の実施例２の包括出来高差算出部が包括報酬を算出する処理の例を示すフローチャートである。 本発明の実施例２のレセプト検証優先度算出部が実行するレセプト検証優先度算出処理の例を示すフローチャートである。 本発明の実施例２のレセプト検証業務支援システムが入出力端末に提示する画面例の説明図である。 本発明の実施例２のレセプト検証業務支援システムが実行する整列処理に関するシークエンス図である。 本発明の実施例３のレセプト検証業務支援システムの構成を示すブロック図である。 本発明の実施例３の提出レセプト情報データベースを構成する提出レセプトデータテーブル４１００のデータ構造を示す説明図である。 本発明の実施例３のレセプト検証業務支援システムが入出力端末に提示する画面例の説明図である。 本発明の実施例４のレセプト検証業務支援システムの構成を示すブロック図である。 本発明の実施例４の知識データベースを構成するコードマスタの説明図である。 本発明の実施例４のレセプト検証業務支援システムが入出力端末に提示する画面例の説明図である。 本発明の実施例４のレセプト検証業務支援システムが、選択したコードを基準としたレセプト検証候補を抽出する処理に関するシークエンス図である。
　以下、図面に基づいて、本発明の実施の形態を説明する。なお、本発明の実施形態は、後述する形態例に限定されるものではなく、その技術思想の範囲において、種々の変形が可能である。
　≪構成≫
　＜システム構成の説明１＞
　図１は、本発明の実施例１のレセプト検証業務支援システム１００の構成を示すブロック図である。
　図１に示す実施例１は、本発明が適用されるレセプト検証業務支援システムを病院内に設置する使用形態の第１の例である。実施例１のレセプト検証業務支援システム１００は、制御部１０１、入力部１０２、出力部１０３、メモリ１０４、通信部１０５、表示画面生成部１０６、実施確率算出部１０８、尤度算出部１０９、レセプト検証候補抽出部１１１、実施確率データベース１１４、及びレセプト分析データベース１１５によって構成される。図１に示すレセプト検証業務支援システム１００は、ネットワーク１２０を介して、病院内の審査請求後のレセプトデータと病院内の審査請求対象のレセプトデータが格納されているレセプト情報データベース１３０、レセプト検証業務を実施する医事課用の入出力端末１５０、及びレセプト検証の必要性が高いレセプトの内容確認を行う医師用の入出力端末１６０等と接続される。
　制御部１０１は、レセプト検証業務支援システム１００全体の動作を制御する。制御部１０１は、例えば、メモリ１０４に格納されたプログラムを実行するプロセッサであってもよい。
　入力部１０２は、レセプト検証業務支援システム１００への情報の入力を受け付ける機能を提供する。例えば、入力部１０２は、キーボード及びポインティングデバイス（例えばマウス）等を含んでもよい。
　出力部１０３は、レセプト検証業務支援システム１００からの情報を出力する機能を提供する。例えば、出力部１０３は、テキスト及び画像等を表示する表示装置を含んでもよい。
　メモリ１０４は、レセプト検証業務支援システム１００が実行する処理のために必要な種々のデータを格納する記憶装置である。
　通信部１０５は、ネットワーク１２０に接続され、レセプト情報データベース１３０、医事課用の入出力端末１５０及び医師用の入出力端末１６０等と通信するネットワークインタフェースである。
　実施確率データベース１１４及びレセプト分析データベース１１５は、レセプト検証業務支援システム１００内の記憶装置に格納される。例えば、実施確率データベース１１４及びレセプト分析データベース１１５は、レセプト検証業務支援システム１００に含まれるハードディスクドライブのような記憶装置（図示省略）に格納され、それらの少なくとも一部が必要に応じてメモリ１０４にコピーされてもよい。同様に、レセプト情報データベース１３０から取得されたレセプトデータもその少なくとも一部が必要に応じてメモリ１０４に格納される。
　表示画面生成部１０６は、医事課用の入出力端末１５０と医師用の入出力端末１６０に表示する画面を作成する機能を提供する。
　実施確率算出部１０８は、ネットワーク１２０を介してレセプト情報データベース１３０に格納されている審査請求後のレセプトデータを取得し、審査請求後のレセプトデータから各診療行為が各診断コードにおいて実施される確率である実施確率を算出し、実施確率データベース１１４に格納する機能を提供する。診断コードとは、診断群分類および診断群を表すコード等であり、例えば米国におけるＤＲＧコード及び日本におけるＤＰＣコード等がこれに該当する。
　尤度算出部１０９は、ネットワーク１２０を介して、レセプト情報データベース１３０に格納されている審査請求対象のレセプトデータと、実施確率データベース１１４に格納されている実施確率とを取得し、審査請求対象のレセプトデータに記載されている各診療行為のコスト、実施回数および実施確率に基づいて各診断コードが患者に対応する尤もらしさを表した尤度を算出し、レセプト分析データベース１１５に格納する機能を提供する。
　レセプト検証候補抽出部１１１は、レセプト分析データベース１１５に格納されている各患者の各診断コードに対応する尤度を取得し、最も尤度が高い診断コードを最尤コードとして算出し、レセプト分析データベース１１５に格納する機能を提供する。
　さらに、レセプト検証候補抽出部１１１は、レセプト分析データベース１１５に格納された各患者の最尤コードと、レセプト情報データベース１３０に格納されている審査請求対象のレセプトデータに記載されている各患者の診断コードとを取得し、最尤コードとレセプトに記載されている診断コードとが一致しない患者をレセプト検証候補として抽出し、レセプト検証候補の患者情報と最尤コードの尤度と診断コードの尤度と合計診療コストとを関連付けてレセプト分析データベースに格納する機能を提供する。
　表示画面生成部１０６、実施確率算出部１０８、尤度算出部１０９およびレセプト検証候補抽出部１１１の機能は、それぞれ専用の論理回路等のハードウェアによって実現されてもよいし、制御部１０１がメモリ１０４に格納されたプログラムを実行することによって実現されてもよい。上記の各部の機能が制御部１０１によって実現される場合、以下の説明において上記の各部が実行する処理は、実際には、メモリ１０４に格納されたプログラムに記述された命令に従って、制御部１０１によって実行される。
　＜効果＞
　このように、診療行為のコストと実施回数と実施確率を用いて各診断コードに対応する尤度を算出し、最も尤度が最も高い診断コードを最尤コードとして算出する事で、最も診療コストを投入した診断コードを推定する事が可能となる。
　最尤コードと診断コードが一致しない患者をレセプト検証候補として格納する事で、最も診療コストが投入されたと考えられる診断コードが付与されていない患者のみを参照する事が可能となる。
　レセプト検証候補の患者情報と最尤コードの尤度と診断コードの尤度とを関連付けて格納する事によって、レセプト検証候補の最尤コードの尤度と診断コードの尤度と合計診療コストを同時に参照する事が可能となる。
　最尤コードの尤度と診断コードの尤度を同時に参照する事によって、最尤コードの尤度と診断コードの尤度が比較可能となり、最尤コードと診断コードとの乖離を把握する事が可能となる。
　＜データベースのテーブル構造＞
　＜レセプト情報データベース＞
　以下、レセプト情報データベース１３０を構成するテーブル構造を説明する。図２は、本発明の実施例１のレセプト情報データベース１３０を構成するレセプトデータテーブル４００のデータ構造を示す説明図である。
　＜レセプトデータテーブル４００＞
　レセプトデータテーブル４００（図２）は、審査請求後のレセプトの情報と審査請求対象のレセプトとを格納するテーブルであり、基本的にレセプト請求業務を担当する医事課が登録する。当該テーブルは、患者ＩＤフィールド４０１、入院年月日フィールド４０２、退院年月日フィールド４０３、診断コードフィールド４０４、診療行為フィールド４０５、診療コストフィールド４０６、行為回数フィールド４０７、実施年月日フィールド４０８、審査請求済みフラグメントフィールド４０９、および審査請求対象フラグメントフィールド４１０を含んで構成される。
　ここで、患者ＩＤフィールド４０１は、患者を識別する識別子である患者ＩＤを格納する。入院年月日フィールド４０２は、患者が入院を開始した年月日を格納する。退院年月日フィールド４０３は、患者が退院した年月日を格納する。複数の入退院を繰り返す患者が存在する為、患者ＩＤフィールド４０１と入院年月日フィールド４０２、または、患者ＩＤフィールド４０１と退院年月日フィールド４０３を組み合わせることによって、１入院のデータを指定する事が可能となる。
　診断コードフィールド４０４は、各患者の１入院に対応する診断コードを格納する。例えば、米国におけるＤＲＧ/ＰＰＳではＤＲＧコード、日本におけるＤＰＣ制度ではＤＰＣコード等のコードが診断コードフィールド４０４に格納される。
　診療行為フィールド４０５は、各患者に実施された診療行為の名称を格納する。
　診療コストフィールド４０６は、診療行為フィールド４０５に格納された各診療行為が１回実施される際に掛かる診療コストを格納する。
　行為回数フィールド４０７は、診療行為フィールド４０５に格納された診療行為が実施された回数を格納する。
　実施年月日フィールド４０８は、診療行為フィールド４０５に格納された診療行為が実施された年月日を格納する。
　審査請求済みフラグメントフィールド４０９は、各レコードが審査請求後のレセプトに属するかどうかを示すフラグを格納する。
　審査請求対象フラグメントフィールド４１０は、各レコードが審査請求対象のレセプトに属するかどうかを示すフラグを格納する。審査請求済みフラグメントフィールド４０９と審査請求対象フラグメントフィールド４１０の両方のフラグが同時に値を持つ事はなく、どちらか一方のフラグのみが値を持つ。
　例えば、レセプトデータテーブル４００に新たなレコードが追加された場合、そのレコードの審査請求済みフラグメントフィールド４０９は初期状態において値を持たず（例えば値が「０」であり）、審査請求対象フラグメントフィールド４１０は初期状態において値を持っている（例えば値が「１」である）。審査請求は、審査請求対象フラグメントフィールド４１０が値を持っているレコードを対象として行われる。そのレコードのデータについて審査請求が行われると、審査請求済みフラグメントフィールド４０９が値を持ち、審査請求対象フラグメントフィールド４１０が値を持たないように更新される。
　審査請求対象フラグメントフィールド４１０が値を持っているレコードの審査請求をするときに、必要に応じてレセプト検証が行われる。その結果、いずれかの患者に対応する診断コードが訂正された場合には、その訂正が診断コードフィールド４０４に反映される。したがって、審査請求対象フラグメントフィールド４１０が値を持っているレコードの診断コードは適切でない可能性があるが、審査請求済みフラグメントフィールド４０９が値を持っているレコードの診断コードは適切なものとして扱われる。以下の説明において、各レコードの診断コードフィールド４０４に格納された診断コードを、当該レコードの患者ＩＤによって識別される患者の診断コードと記載するが、審査請求対象フラグメントフィールド４１０が値を持っているレコードの診断コードフィールド４０４に格納された診断コードを、特に、当該患者の現時点の診断コードと記載する場合がある。
　本システムは、審査請求済みフラグメントフィールド４０９、または、審査請求対象フラグメントフィールド４１０の値を参照する事で、審査請求後のレセプトに属するレコードのみ、または、審査請求対象のレセプトに属するデータのみを、それぞれ抽出する事が可能となる。
　なお、審査請求後のレセプトのデータと審査請求対象のレセプトのデータは、審査請求済みフラグメントフィールド４０９および審査請求対象フラグメントフィールド４１０を有する一つのレセプトデータテーブル４００に格納する代わりに、それらのフィールドを有しない別々の専用のテーブルにそれぞれ格納しても良い。
　＜実施確率データベース＞
　以下、実施確率データベース１１４を構成するテーブル構造を説明する。
　図３は、本発明の実施例１の実施確率データベース１１４を構成する実施確率テーブル５００のデータ構造を示す説明図である。
　＜実施確率テーブル＞
　実施確率テーブル５００（図３）は、各診療行為が各診断コードの患者に対して実施される確率を格納するテーブルである。各診断コードと患者との対応はレセプトデータテーブル４００に基づいて特定される。実施確率テーブル５００の一つのレコードに、一つの診療行為が各診断コードの患者に対して実施される確率が格納される。当該テーブルは、診療行為フィールド５０１、および有限個の診断コードフィールド５０２を含んで構成される。
　診療行為フィールド５０１は診療行為の名称を格納する。
　診断コードフィールド５０２は、同一レコード内の診療行為フィールド５０１に格納された診療行為が、診断コードフィールド５０２の各フィールド名の診断コード（例えば診断コード１～３）の患者に対して実施される確率を格納する。この確率は、後述するように、実施確率算出部１０８によって算出される（図７等参照）。
　＜レセプト分析データベース＞
　以下、レセプト分析データベース１１５を構成するテーブル構造を説明する。レセプト分析データベース１１５は、レセプト検証候補の抽出に必要な情報と、表示画面生成部１０６における画面の生成に必要な情報を格納する。レセプト分析データベース１１５は、期待コストテーブル９００、尤度テーブル１０００、およびレセプト検証テーブル１４００から構成されている。
　図４、図５および図６は、それぞれ、本発明の実施例１のレセプト分析データベース１１５を構成する期待コストテーブル９００、尤度テーブル１０００およびレセプト検証テーブル１４００のデータ構造を示す説明図である。
　＜期待コストテーブル＞
　期待コストテーブル９００（図４）は、各患者に実施された各診療行為の診療コストが、各診断コードに投入された可能性の程度を表す期待コストを格納する。この期待コストは、後述するように、尤度算出部１０９によって算出される（図１０等参照）。診療行為フィールド９０１、および有限個の診断コードフィールド９０２を含んで構成される。
　診療行為フィールド９０１は、各患者に実施された診療行為の名称を格納する。
　診断コードフィールド９０２には、各診断コードにおける、同一レコード内の診療行為フィールド９０１に格納された診療行為の期待コストを格納する。
　図４には、患者ＩＤが＃＃＃１の患者について計算された期待コストを格納する期待コストテーブル９００の例を示す。この例では、診療行為Ａの期待コストは、診断コード１で８００、診断コード２で３００、診断コード３で１６０をそれぞれ示し、診療行為Ｂの期待コストは、診断コード１で０、診断コード２で１６０、診断コード３で８０をそれぞれ示す事が表されている。尤度算出部１０９は、各患者について同様の期待コストテーブル９００を作成する。
　＜尤度テーブル＞
　尤度テーブル１０００（図５）は、尤度算出部１０９によって算出された、各診断コードが各患者に対応する尤もらしさを表す尤度を格納する。当該テーブルは患者ＩＤフィールド１００１、および有限個の診断コードフィールド１００２を含んで構成される。
　患者ＩＤフィールド１００１は、患者を識別する識別子である患者ＩＤを格納する。
　診断コードフィールド１００２は、各患者が各診断コードに対応する尤もらしさを表す尤度を格納する。例えば、患者ＩＤ「＃＃＃１」に対応するレコードの「診断コード１」に対応する診断コードフィールド１００２の値が「５０００」であることは、患者ＩＤ「＃＃＃１」によって識別される患者が「診断コード１」に対応する尤度が「５０００」であることを意味する。
　図５の例では、患者ＩＤが＃＃＃１の患者は、ＤＰＣコード１の尤度が５０００、ＤＰＣコード２の尤度が２８００、ＤＰＣコード３の尤度が１２００であり、患者ＩＤが＃＃＃２の患者は、ＤＰＣコード１の尤度が７６０、ＤＰＣコード２の尤度が３９００、ＤＰＣコード３の尤度が９４００である事が表されている。
　＜レセプト検証テーブル＞
　レセプト検証テーブル１４００（図６）は、レセプト検証候補抽出部１１１によって算出された、レセプト検証が必要であるか判断するための詳細な情報を格納するテーブルである。当該テーブルは、患者ＩＤフィールド１４０１、診断コードフィールド１４０２、診断コード尤度フィールド１４０３、最尤コードフィールド１４０４、最尤コード尤度フィールド１４０５、レセプト検証フラグメントフィールド１４０６および総診療コストフィールド１４０７を含んで構成される。
　患者ＩＤフィールド１４０１は、患者を識別する識別子である患者ＩＤを格納する。
　診断コードフィールド１４０２は、同一レコード内の患者ＩＤフィールド１４０１に格納された患者ＩＤが対応する患者の現時点の診断コードを格納する。この診断コードは、当該患者ＩＤに対応するレセプトデータテーブル４００の診断コードフィールド４０４から読み出される。
　診断コード尤度フィールド１４０３は、同一レコード内の診断コードフィールド１４０２に格納された診断コードの尤度を格納する。この尤度は、尤度算出部１０９によって算出される。
　最尤コード尤度フィールド１４０５は、同一レコード内の患者ＩＤフィールド１４０１に格納された患者ＩＤが対応する患者において、最も尤度の高い診断コードを格納する。この診断コードは、レセプト検証候補抽出部１１１によって抽出される。
　最尤コード尤度フィールドは、レセプト検証候補抽出部１１１によって算出された最尤コードの尤度を格納する。
　レセプト検証フラグメントフィールド１４０６は、レセプト検証の必要性の有無を示すフラグを格納する。
　総診療コストフィールド１４０７は、同一レコード内の患者ＩＤフィールド１４０１に格納された患者ＩＤが対応する患者の全診療行為の診療コストの合計である総診療コストを格納する。
　このように、レセプト検証の必要性の有無を表すフラグを有する事で、レセプト検証業務支援システム１００は、レセプト検証が必要な患者の情報のみを抽出する事が可能となる。レセプト検証が必要な患者の情報のみを抽出する事で、レセプト検証業務支援システム１００は、レセプト検証が必要な患者のみを提示する事が可能となる。
　＜処理部＞
　＜実施確率算出フロー＞
　次に、実施確率算出部１０８が実行する実施確率算出処理について述べる。実施確率とは、各診療行為が各診断コードにおいて実施される確率である。実施確率算出部１０８は、実施確率算出処理を任意の時点で実行することができる。例えば、実施確率算出処理は、医事課が入出力端末１５０を用いて処理の開始を指示したときに開始されてもよいし、１ヶ月に一度開始されてもよいし、医事課が指定した日時に自動的に開始されてもよいし、医事課がシステムを起動したと同時に開始されてもよい。
　図７は、本発明の実施例１の実施確率算出部１０８が実行する実施確率算出処理の例を示すフローチャートである。
　まず始めに、実施確率算出部１０８は、ネットワーク１２０を介してレセプト情報データベース１３０に格納されているレセプトデータテーブル４００を参照し、審査請求済みフラグメントフィールド４０９に値が存在するデータ（すなわち審査請求が行われたデータ）のみを取得する（Ｓ２０１）。次に、実施確率算出部１０８は、各診断コードにおいて各診療行為が１入院毎に実施される平均回数である平均実施回数を算出する（Ｓ２０２）。
　図８は、本発明の実施例１の実施確率算出部１０８が平均実施回数を算出する処理の例を示すフローチャートである。
　まず始めに、実施確率算出部１０８は、Ｓ２０１で取得したデータの診断コードフィールド４０４から、平均実施回数を算出する診断コードを一つ選択する（Ｓ３０１）。次に、実施確率算出部１０８は、Ｓ３０１で選択した診断コードが診断コードフィールド４０４に格納されているレコードの患者ＩＤ数を集計することで、合計患者数を算出する（Ｓ３０２）。
　次に、実施確率算出部１０８は、Ｓ２０１で取得したデータの診療行為フィールド４０５から、平均実施回数を算出する診療行為を一つ選択する（Ｓ３０３）。次に、実施確率算出部１０８は、診断コードフィールド４０４にＳ３０１で選択した診断コードが格納されており、かつ、Ｓ３０３で選択した診療行為が診療行為フィールド４０５に格納されているレコードの行為回数を集計することで、合計実施回数を算出する（Ｓ３０４）。次に、実施確率算出部１０８は、Ｓ３０４で算出した合計実施回数を、Ｓ３０２で算出した合計患者数で割る事で、Ｓ３０１で選択した診断コードにおける、Ｓ３０３で選択した診療行為の平均実施回数を算出する（Ｓ３０５）。
　次に、実施確率算出部１０８は、未選択の診療行為が存在すかどうかを確認し（Ｓ３０６）、未選択の診療行為が存在する場合には、未選択の診療行為についてＳ３０３以降の処理を実行する。未選択の診療行為が存在しない場合には、実施確率算出部１０８は次のステップを実行する。
　次に、実施確率算出部１０８は、未選択の診断コードが存在するかどうかを確認し（Ｓ３０７）、未選択の診断コードが存在する場合には、未選択の診断コードについてＳ３０１以降の処理を実行する。未選択の診断コードが存在しない場合には、実施確率算出部１０８は平均実施回数の算出処理を終了する。
　次に、実施確率算出部１０８は、Ｓ２０１で取得したデータの診療行為フィールド４０５から、実施確率を算出する診療行為を一つ選択する（Ｓ２０３）。次に、実施確率算出部１０８は、Ｓ２０３で選択した診療行為の各診断コードにおける平均実施回数の総和を算出する（Ｓ２０４）。
　次に、実施確率算出部１０８は、Ｓ２０１で取得したデータの診断コードフィールド４０４から、実施確率を算出する診断コードを一つ選択する（Ｓ２０５）。次に、実施確率算出部１０８は、Ｓ２０５で選択した診断コードにおける、Ｓ２０３で選択した診療行為の平均実施回数を、Ｓ２０４で算出した平均実施回数の総和で割る事で、Ｓ２０５で選択した診断コードにおける、Ｓ２０３で選択した診療行為の実施確率を算出する（Ｓ２０６）。次に、実施確率算出部１０８は、Ｓ２０６で算出した、Ｓ２０５で選択した診断コードにおけるＳ２０３で選択した診療行為の実施確率を、実施確率テーブル５００へ格納する（Ｓ２０７）。
　次に、実施確率算出部１０８は、未選択の診断コードが存在するかどうかを確認し（Ｓ２０８）、未選択の診断コードが存在する場合には、未選択の診断コードについてＳ２０５以降の処理を実行する。未選択の診断コードが存在しない場合には、実施確率算出部１０８は次のステップを実行する。
　次に、実施確率算出部１０８は、未選択の診療行為が存在するかどうかを確認し、未選択の診療行為が存在する場合には、未選択の診療行為についてＳ２０３以降の処理を実行する。未選択の診療行為が存在しない場合には、実施確率算出部１０８は、次のステップを実行する（Ｓ２０９）。次に、実施確率算出部１０８は、実施確率テーブル５００を実施確率データベース１１４へ登録する（Ｓ２１０）。以上の処理によって、各診断コードにおける各診療行為の実施確率が算出される。
　このように、審査請求が完了したレセプトである審査請求後のレセプトデータのみを用いて実施確率を算出する事によって、審査請求が通ったデータを根拠として、精度良く実施確率を算出する事が出来る。また、病院内に蓄積された審査請求後のレセプトデータから実施確率を算出する事で、各病院の医療実績に則した実施確率を算出することができる。
　＜尤度算出処理フロー＞
　次に、尤度算出部１０９における尤度算出処理について述べる。尤度とは、各診断コードが患者に対応する尤もらしさである。例えば、医事課が入出力端末１５０を用いて処理開始操作を行う事を契機として、尤度算出処理が開始される。
　図９は、本発明の実施例１の尤度算出部１０９が実行する尤度算出処理の例を示すフローチャートである。
　まず始めに、尤度算出部１０９は、ネットワーク１２０を介して、レセプト情報データベース１３０に格納されているレセプトデータテーブル４００を取得する（Ｓ６０１）。次に、尤度算出部１０９は、取得したレセプトデータテーブル４００の中から、審査請求対象フラグメントフィールド４１０に値が存在するデータ（すなわち、まだ審査請求がされていないデータ）のみを抽出する（Ｓ６０２）。本処理において、Ｓ６０２で抽出したデータを、以後、分析対象データと呼ぶ。
　次に、尤度算出部１０９は、実施確率データベース１１４に格納されている実施確率テーブル５００を取得する（Ｓ６０３）。次に、尤度算出部１０９は、分析対象データの患者ＩＤフィールド４０１からいずれかの患者の患者ＩＤを選択する（Ｓ６０４）。次に、尤度算出部１０９は、Ｓ６０４で選択した患者の入院年月日フィールド４０２を参照し、格納されている入院年月日が処理の実行月以前であるか否かを判定する（Ｓ６０５）。入院年月日フィールド４０２に格納されている入院年月日が処理の実行月以前である場合には、尤度算出部１０９は、Ｓ６０６を実行し、続いてＳ６０７を実行する。一方、入院年月日フィールド４０２に格納されている入院年月日が、処理の実行月以前でない場合は、尤度算出部１０９は、Ｓ６０６を実行せずに、Ｓ６０７を実行する。
　次に、尤度算出部１０９は、Ｓ６０１で取得したレセプトデータテーブル４００から、Ｓ６０４で選択した患者において、入院年月日フィールド４０２に格納されている入院年月日がＳ６０５で参照した入院年月日と同じ値であるデータを全て抽出する。そして、尤度算出部１０９は、抽出したデータを、Ｓ６０２で抽出した分析対象データに追加する。分析対象データ内に重複するデータが存在する場合には、尤度算出部１０９は、重複するデータの一方を削除する（Ｓ６０６）。
　次に、尤度算出部１０９は、分析対象データを用いて、各診療行為の診療コストが各診断コードに投入された確率を表す期待コストを算出する（Ｓ６０７）。
　図１０は、本発明の実施例１の尤度算出部１０９が期待コストを算出する処理の例を示すフローチャートである。
　まず始めに、尤度算出部１０９は、分析対象データの診断コードフィールド４０４から診断コードを一つ選択する（Ｓ８０１）。
　次に、尤度算出部１０９は、分析対象データの診療行為フィールド４０５から診療行為を一つ選択する（Ｓ８０２）。
　次に、尤度算出部１０９は、Ｓ６０４で選択した患者において、診断コードフィールド４０４にＳ８０２で選択した診断コードが格納されているレコードの診療コストフィールド４０６の値を集計することで、Ｓ８０２で選択した診療行為の合計診療コストを算出する（Ｓ８０３）。
　次に、尤度算出部１０９は、実施確率テーブル５００から、Ｓ８０１で選択した診断コードにおけるＳ８０２で選択した診療行為の実施確率を抽出し、抽出した実施確率とＳ８０３で算出した合計診療コストとを掛け合わせる事で、期待コストを算出する（Ｓ８０４）。
　次に、尤度算出部１０９は、Ｓ６０４で選択した患者の患者ＩＤとＳ８０２で選択した診療行為とＳ８０４で算出した期待コストとを紐付けて、期待コストテーブル９００に格納する（Ｓ８０５）。
　次に、尤度算出部１０９は、未選択の診療行為が存在するかどうかを確認し（Ｓ８０６）、未選択の診療行為が存在する場合には、未選択の診療行為についてＳ８０２以降の処理を実行する。未選択の診療行為が存在しない場合には、尤度算出部１０９は、次のステップを実行する。
　次に、尤度算出部１０９は、未選択の診断コードが存在するかどうかを確認し（Ｓ８０７）、未選択の診断コードが存在する場合には、未選択の診断コードについてＳ８０１以降の処理を実行する。未選択の診断コードが存在しない場合には、尤度算出部１０９は次のステップを実行する。
　次に、尤度算出部１０９は、期待コストテーブル９００をレセプト分析データベース１１５へ登録し、期待コストの算出処理を終了する（Ｓ８０８）。尤度算出部１０９は、尤度算出処理が終了するまで、期待コストテーブル９００を保持し続ける。以上の処理によって、各診断コードにおける各診療行為の期待コストが算出される。
　次に、尤度算出部１０９は、尤度算出部１０９は、分析対象データの診断コードフィールド４０４から診断コードを一つ選択する（Ｓ６０８）。
　次に、尤度算出部１０９は、期待コストテーブル９００において、Ｓ６０８で選択した診断コードが対応する診断コードフィールド９０２に格納されている各診療行為の期待コストを全て集計する事で、Ｓ６０８で選択した診断コードに対応する尤度を算出する。（Ｓ６０９）。
　次に、尤度算出部１０９は、Ｓ６０９で算出した尤度を、Ｓ６０４で選択した患者の患者ＩＤおよびＳ６０８で選択した診断コードと紐付けて、尤度テーブル１０００に格納する（Ｓ６１０）。
　次に、尤度算出部１０９は、未選択の診断コードが存在するかどうかを確認し（Ｓ６１１）、未選択の診断コードが存在する場合には、未選択の診断コードについてＳ６０８以降の処理を実行する。未選択の診断コードが存在しない場合には、尤度算出部１０９は次のステップを実行する。
　次に、尤度算出部１０９は、未選択の患者ＩＤが存在するかどうかを確認し（Ｓ６１２）、未選択の患者ＩＤが存在する場合には、未選択の患者ＩＤについてＳ６０４以降の処理を実行する。未選択の患者ＩＤが存在しない場合には、尤度算出部１０９は次のステップを実行する。
　次に、尤度算出部１０９は、尤度テーブル１０００をレセプト分析データベース１１５へ登録する（６１３）。以上の処理によって、各患者が各診断コードに対応する尤度が算出される。
　このように、各診療行為の診療コストと各診療行為が各診療コードで実施される確率との積の総和を計算する事で、各診断コードに投入された総診療コストを推定する事が可能となる。
　＜レセプト検証候補抽出処理フロー＞
　次に、レセプト検証候補抽出部１１１における、レセプト検証候補抽出処理について述べる。レセプト検証候補とは、患者に既に付与されている診断コードと、算出した尤度が最も高い診断コードとが一致しない為に、適切な診断コードが付与されていない可能性がある患者である。本処理は、尤度算出部１０９による各患者の各診断コードに対応する尤度の算出後に、自動的に開始される、医事課が入出力端末１５０を用いて処理開始操作を行う、等により処理が開始される。
　図１１は、本発明の実施例１のレセプト検証候補抽出部１１１が実行するレセプト検証候補抽出処理の例を示すフローチャートである。
　まず始めに、レセプト検証候補抽出部１１１は、レセプト分析データベース１１５から尤度テーブル１０００を取得する（Ｓ１３０１）。
　次に、レセプト検証候補抽出部１１１は、尤度テーブル１０００の患者ＩＤフィールド１４０１から患者ＩＤを一つ選択する。（Ｓ１３０２）。
　次に、レセプト検証候補抽出部１１１は、Ｓ１３０２にて選択した患者ＩＤにおいて、尤度が最大である診断コードフィールド１１０２の診断コード名を最尤コードとして、尤度が最大である診断コードフィールド１１０２の値を最尤コードの尤度として、それぞれ抽出する（Ｓ１３０３）。例えば、図５の例において、診断コードフィールド１１０２が診断コード名「診断コード１」、「診断コード２」および「診断コード３」に対応する三つしかなく、患者ＩＤとして「＃＃＃２」が選択された場合、尤度が最大の「９４００」である診断コードフィールド１１０２の診断コード名「診断コード３」が最尤コードとして、その尤度「９４００」が最尤コードの尤度として、それぞれ抽出される。
　次に、レセプト検証候補抽出部１１１は、レセプトデータテーブル４００において、Ｓ１３０２で選択した患者ＩＤが患者ＩＤフィールド４０１に格納されており、かつ、審査請求対象フラグメントフィールド４１０に値が格納されているレコードの、診断コードフィールド４０４に格納されている診断コードを取得する（Ｓ１３０４）。
　次に、レセプト検証候補抽出部１１１は、Ｓ１３０２で選択した患者ＩＤとＳ１３０４で取得した診断コードとその尤度、Ｓ１３０３で抽出した最尤コードとその尤度を、それぞれ紐付けてレセプト検証テーブル１４００へ格納する（Ｓ１３０５）。
　次に、レセプト検証候補抽出部１１１は、Ｓ１３０５で互いに紐付けて格納された最尤コードと診断コードとが一致するかどうかを検証し（Ｓ１３０６）、最尤コードと診断コードとが一致しない場合は、Ｓ１３０７を実行し、続いてＳ１３０８を実行する。一方、最尤コードと診断コードとが一致する場合は、レセプト検証候補抽出部１１１は、Ｓ１３０７を実行せずにＳ１３０７を実行する。
　Ｓ１３０７において、レセプト検証候補抽出部１１１は、レセプト検証テーブル１４００のレセプト検証フラグメントフィールド１４０６に、Ｓ１３０２で選択した患者ＩＤと紐付けて１の値を格納する。
　Ｓ１３０８において、レセプト検証候補抽出部１１１は、Ｓ１３０２にて選択した患者ＩＤが患者ＩＤフィールド４０１に格納されているレセプトデータテーブル４００の全てのレコードの、診療コストフィールド４０６に格納されている診療コストを集計することで、総診療コストを算出する。
　次に、レセプト検証候補抽出部１１１は、算出した総診療コストの値を、レセプト検証テーブル１４００の総診療コストフィールド１４０７に、Ｓ１３０２で選択した患者ＩＤと紐付けて格納する（Ｓ１３０９）。
　次に、レセプト検証候補抽出部１１１は、未選択の患者ＩＤが存在するかどうかを確認し（Ｓ１３１０）、未選択の患者ＩＤが存在する場合には、未選択の患者ＩＤについてＳ１３０２以降の処理を実行する。未選択の患者ＩＤが存在しない場合には、レセプト検証候補抽出部１１１は次のステップを実行する。
　次に、レセプト検証候補抽出部１１１は、レセプト検証テーブル１４００をレセプト分析データベース１１５へ登録する（Ｓ１３１１）。以上の処理によって、レセプト検証候補抽出部１１１は、レセプト検証候補を抽出する。
　複数の診療コードに共通して実施される診療行為でも、各診断コードで実施される確率は異なる。各診断コードの尤度は、複数の診療コードに共通して実施される診療行為のみが実施された患者についても、異なる尤度となる。本システムは、尤度を用いてレセプト検証候補を抽出する事で、複数の診療コードに共通して実施される診療行為のみが実施された患者についても、レセプト検証の必要性を判断する事を可能とする。
　＜画面構成１＞
　上述のように抽出したレセプト検証候補は、表示画面生成部１０６にてレセプト検証候補を表示するための表示画面を構成し、表示画面は入出力端末１５０にて表示される。
　ここで、入出力端末１５０にて表示する表示画面について述べる。
　まず始めに、従来例として、特許文献１の対応表を用いた方式における表示画面について述べる。
　図１２は、従来のレセプト検証業務支援システムが対応表に基づいて入出力端末１５０に提示する画面例１６００の説明図である。
　従来のレセプト検証業務支援システムは、各診断コードの尤度を算出せずに、各診断コードの診療コストを算出して保持する。具体的には、従来のレセプト検証業務支援システムは、レセプトデータテーブル４００のレコードのうち、審査請求済みフラグメントフィールド４０９が値を持つレコードを参照し、各診療行為が対応する診断コードを判定する。ここで、いずれかのレコードの診療行為フィールド４０５に格納された診療行為は、そのレコードの診断コードフィールド４０４に格納された診断コードに対応すると判定される。一つの診療行為が複数の診断コードに対応する場合がある。
　そして、従来のレセプト検証業務支援システムは、審査請求対象フラグメントフィールド４１０が値を持つレコードの患者ＩＤフィールド４０１、診断コードフィールド４０４、診療行為フィールド４０５及び診療コストフィールド４０６を参照し、患者ごとに、その患者の現時点の診断コードに対応する診療行為の診療コストの合計値を診断コードの診療コストとして算出する。さらに、従来のレセプト検証業務支援システムは、患者ごとに、現時点の診断コード以外の診断コードに対応する診療行為の診療コストの合計値を、それぞれの診療行為の診療コストとして算出し、現時点の診断コード及びそれ以外の診断コードのそれぞれについて算出された診療コストを比較し、それらのうち最も大きい値に対応する診断コードを、当該患者の最適診断コードとして抽出する。
　さらに、従来のレセプト検証業務支援システムは、レセプト検証テーブル１４００の総診療コストフィールド１４０７に格納されるものと同様の総診療コストを算出して保持する。
　すなわち、従来のレセプト検証業務支援システムは、例えば、患者ＩＤフィールド１４０１、診断コードフィールド１４０２及び総診療コストフィールド１４０７を含み、診断コード尤度フィールド１４０３、最尤コードフィールド１４０４及び最尤コード尤度フィールド１４０５を含まず、代わりに上記のように計算された各患者の現時点の診断コードの診療コストを格納する診断コードの診療コストフィールド（図示省略）、最適診断コードを格納する最適診断コードフィールド（図示省略）、及び、最適診断コードの診療コストを格納する最適診断コードの診療コストフィールド（図示省略）を含む、レセプト検証テーブル（図示省略）を保持してもよい。これらのフィールドに格納された値が、後述するように、画面例１６００の対応するフィールドに表示される。
　画面例１６００（図１２）は、レセプト検証候補一覧表示部１６０１、診療行為一覧表示部１６０２、および確認依頼ボタン１６０３を含んで構成される。
　レセプト検証候補一覧表示部１６０１は、医師への提出チェックボタン１６０１１、診療行為一覧表示ボタン１６０１２、患者ＩＤフィールド１６０１３、診断コードフィールド１６０１４、診断コードの診療コストフィールド１６０１５、最適診断コードフィールド１６０１６、最適診断コードの診療コストフィールド１６０１７、および総診療コストフィールド１６０１８を含んで構成される。
　レセプト検証候補一覧表示部１６０１は、対応表を用いた方式によってレセプトの検証が必要であると判断されたレセプト検証候補の患者のみを表示する。
　医師への提出チェックボタン１６０１１は、画面操作者によって押下（例えばマウスクリック等の操作、以下同様）された時に選択状態となる。
　診療行為一覧表示ボタン１６０１２は、画面操作者によって押下された時に選択状態となる。診療行為一覧表示ボタン１６０１２が画面操作者によって押下された時に、押下された診療行為一覧表示ボタン１６０１２が該当するレコードの患者の診療行為一覧が診療行為一覧表示部１６０２に表示される。
　患者ＩＤフィールド１６０１３は患者を識別する識別子である患者ＩＤを表示する。
　診断コードフィールド１６０１４は、患者ＩＤフィールド１６０１３の値によって識別される患者の現時点の診断コードを表示する。
　診断コードの診療コストフィールド１６０１５は、診断コードフィールド１６０１４の診断コードに投入された診療コストを表示する。各レコードの診断コードの診療コストフィールド１６０１５に表示される診療コストは、各当該レコードの患者ＩＤによって識別される患者に実施された診療行為において、当該レコードの診断コードと対応する診療行為の診療コストを合計した値である。
　最適診断コードフィールド１６０１６は、各患者ＩＤによって識別される患者において、診療行為の診療コストの値が最大となった診断コードを、最適診断コードとして表示する。
　最適診断コードの診療コストフィールド１６０１７は、最適診断コードの診療コストを表示する。
　総診療コストフィールド１６０１８は、各患者に実施された全ての診療行為の診療コストを合計した値である総診療コストを表示する。この総診療コストは、本発明の実施例１のレセプト検証テーブル１４００の総診療コストフィールド１４０７に格納されたものと同様に計算される。
　診療行為一覧表示部１６０２は、診療行為フィールド１６０２１、診断コードとの対応フィールド１６０２２、および最適診断コードとの対応フィールド１６０２３を含んで構成される。
　診療行為一覧表示部１６０２は、押下された診療行為一覧表示ボタン１６０１２が該当するレコードの患者に対して実施された診療行為の一覧を表示する。
　確認依頼ボタン１６０３が押下されると、レセプト検証業務支援システムは、押下時に医師への提出チェックボタン１６０１１が選択状態となっている患者のレセプト情報を、医師への確認依頼レセプトとして送信する。
　図１２に示した具体例について説明する。この例において、患者ＩＤフィールド１６０１３の値が＃＃＃２であるレコードの診断コードフィールド１６０１４の値は「診断コード２」であり、診断コードの診療コストフィールド１６０１５の値は「２２，０００」である。一方、当該レコードの最適診断コードフィールド１６０１６には、当該患者の現時点の診断コードと同一の「診断コード２」、及び、それとは異なる「診断コード３」の二つの値が格納されている。そして、それぞれの診断コードに対応する最適診断コードの診療コストフィールド１６０１７の値は、いずれも、診断コードの診療コストフィールド１６０１５と同じ「２２，０００」である。
　診療行為一覧表示部１６０２には患者ＩＤが＃＃＃２の患者に実施された診療行為一覧が表示されている。この中で、当該患者に実施された診療行為である診療行為Ａ、診療行為Ｃ、診療行為Ｄにはそれぞれ、診断コードとの対応フィールド１６０２２との最適診断コードとの対応フィールド１６０２３に、「あり」が記載されている。そのため、患者ＩＤが＃＃＃２である患者に実施された診療行為は全て、当該患者の現時点の診断コード（上記の例では診断コード２）と、それとは異なる最適診断コード（上記の例では診断コード３）の両方に共通して実施される診療行為である。
　現時点の診断コードと最適診断コードが異なっていても、それらの両方に共通して実施される診療行為のみが実施された患者に関しては、診断コードの診療コストフィールド１６０１５の値と、最適診断コードの診療コストフィールド１６０１７の値が、同値となる。そのため、本システムの操作者は、診断コードフィールド１６０１４に記載された診断コードと、最適診断コードフィールド１６０１６に記載された診断コードのどちらが最適な診断コードであるか判断が出来ない。図１２の例では、診断コード２及び診断コード３のどちらが、患者ＩＤが＃＃＃２の患者に最適な診断コードであるか判断が出来ない。以上のことから、本システムの操作者は、ある患者の現時点の診断コードと最適診断コードの両方に共通して実施される診療行為のみが実施された患者の場合、レセプト検証の必要性を判断出来ないという課題があった。
　＜画面例構成２＞
　次に、本発明を用いた方式における表示画面について述べる。
　図１３は、本発明の実施例１のレセプト検証業務支援システム１００が入出力端末１５０に提示する画面例１５００の説明図である。
　画面例１５００（図１３）は、レセプト検証候補一覧表示部１５０１、診療行為一覧表示部１５０２、および確認依頼ボタン１５０３を含んで構成される。
　レセプト検証候補一覧表示部１５０１は、医師への提出チェックボタン１５０１１、診療行為一覧表示ボタン１５０１２、患者ＩＤフィールド１５０１３、診断コードフィールド１５０１４、診断コード尤度フィールド１５０１５、最尤コードフィールド１５０１６、最尤コード尤度フィールド１５０１７、および総診療コストフィールド１５０１８を含んで構成される。
　レセプト検証候補一覧表示部１５０１は、レセプト検証テーブル１４００のレセプト検証フラグメントフィールド１４０６に「１」が格納されている患者に関する情報のみを表示する。
　医師への提出チェックボタン１５０１１は、画面操作者（すなわちレセプト検証業務支援システム１００のユーザ）によって押下された時に選択状態となる。
　診療行為一覧表示ボタン１５０１２は、画面操作者によって押下された時に選択状態となる。診療行為一覧表示ボタン１５０１２が画面操作者によって押下された時に、押下された診療行為一覧表示ボタン１５０１２が該当するレコードの患者の診療行為一覧が診療行為一覧表示部１５０２に表示される。
　患者ＩＤフィールド１５０１３は、患者を識別する識別子である患者ＩＤを表示する。
　診断コードフィールド１５０１４は、レセプト検証テーブル１４００における、患者ＩＤフィールド１５０１３の値によって識別される患者の現時点の診断コード、すなわち、当該患者に対応する診断コードフィールド１４０２の値を表示する。
　診断コード尤度フィールド１５０１５は、レセプト検証テーブル１４００における、当該患者の診断コード尤度フィールド１４０３の値を表示する。
　最尤コードフィールド１５０１６は、レセプト検証テーブル１４００における、当該患者の最尤コードフィールド１４０４の値を表示する。
　最尤コード尤度フィールド１５０１７は、レセプト検証テーブル１４００における、当該患者の最尤コード尤度フィールド１４０５の値を表示する。
　総診療コストフィールド１５０１８は、レセプト検証テーブル１４００の総診療コストフィールド１４０７に格納された、当該患者に実施された全ての診療行為の診療コストを合計した値である総診療コストを表示する。
　診療行為一覧表示部１５０２は、診療行為フィールド１５０２１、診断コードにおける期待コストフィールド１５０２２、および最尤コードにおける期待コストフィールド１５０２３を含んで構成される。
　診療行為一覧表示部１５０２は、押下された診療行為一覧表示ボタン１５０１２が該当するレコードの患者に実施された診療行為の一覧を表示する。ここで、当該患者に実施された診療行為は、レセプトデータテーブル４００の、審査請求対象フラグメントフィールド４１０が値を持つレコードから読み取られる。
　確認依頼ボタン１５０３が押下されると、レセプト検証業務支援システム１００は、その時点で医師への提出チェックボタン１５０１１が選択状態となっている患者のレセプト情報を、医師への確認依頼レセプトとして送信する。
　図１３の画面例１５００のレセプト検証候補一覧表示部１５０１では、患者ＩＤフィールド１５０１３が＃＃＃２の患者の診断コード尤度フィールド１５０１５の値が３,９００、最尤コード尤度フィールド１５０１７の値が９,４００であると示される。
　ここで、診療行為一覧表示部１５０２には、患者ＩＤが＃＃＃２の患者に実施された診療行為一覧が表示されている。この中で、当該患者に実施された診療行為である診療行為Ａ、診療行為Ｃおよび診療行為Ｄについて、診断コードにおける期待コストフィールド１５０２２との最尤コードにおける期待コストフィールド１５０２３に、それぞれの期待コストが記載されている。診療行為Ａ、診療行為Ｃおよび診療行為Ｄはいずれも、診断コードフィールド１５０１４の診断コードと最尤コードフィールド１５０１６の診断コードのいずれにも対応して実施される診療行為であるが、診断コードにおける期待コストフィールド１５０２２の値よりも、最尤コードにおける期待コストフィールド１５０２３の値が高く示されている。そのため、患者ＩＤが＃＃＃２である患者に実施された診療行為は全て、最尤コードフィールド１５０１６の診断コードにおいて実施される確率が高い診療行為であり、最尤コードフィールド１５０１６の診断コードに対して投入された診療コストの期待コストが高い診療行為である。
　診断コードフィールド１５０１４の診断コードと最尤コードフィールド１５０１６の診断コードの両方に共通して実施される診療行為のみが実施された患者であっても、各診療行為が各診断コードにおいて実施される確率が異なる為、各診断コードの尤度は異なる。そのため、本システムの操作者は、診断コードフィールド１５０１４の診断コードと最尤コードフィールド１５０１６の診断コードのどちらが最適な診断コードであるか判断する事が可能である。
　さらに、本システム操作者は、診療行為一覧表示部１５０２に表示される各診療行為の診断コードにおける期待コストフィールド１５０２２の値と最尤コードにおける期待コストフィールド１５０２３の値を参照する事で、各診療行為の診療コストが両診断コードに投入された期待コストを把握する事が可能となる。本システム操作者は、各診療行為の診療コストが両診断コードに投入された量の期待値である期待コストを把握する事で、両診断コードの尤度の差を生じさせる原因となる診療行為を把握する事が可能となる。本システム操作者は、両診断コードの尤度の差を生じさせる原因となる診療行為を把握する事で、レセプト検証の必要性を容易に判断する事が可能となる。
　なお、上記のとおり、実施例１では、審査請求済みフラグメントフィールド４０９が値を持っているレセプトデータ（すなわち検証候補の抽出対象でないレセプトデータ）に基づいて、実施確率が計算される。これは、審査請求済みフラグメントフィールド４０９が値を持っているレセプトデータがすでに審査を通っていることから、適切な診断コードを与えられていると判断できるためである。これによって、各病院の診療の実績に基づいて実施確率が計算されるため、各病院で過去に実施された実際の診療の傾向に基づいて、各患者の診断コードが適切でない可能性を精度よく判定することが可能になる。
　しかし、例えば病院の規模、専門性または開設時期等によっては、各診断コードに対応する十分な数の審査済みのレセプトデータが存在しない場合がある。このような場合には、レセプト検証業務支援システム１００は、例えば他の病院または公的機関等から標準的な実施確率を入手して、それに基づいて尤度等を算出することによって、検証候補を抽出することもできる。
　次に、本発明の実施例２を説明する。以下に説明する相違点を除き、実施例２のレセプト検証業務支援システム１７００の各部は、図１～図１３に示された実施例１の同一の符号を付された各部と同一の機能を有するため、それらの説明は省略する。
　＜システム構成の説明２＞
　図１４は、本発明の実施例２のレセプト検証業務支援システム１７００の構成を示すブロック図である。
　図１４に示す実施例２は、本発明が適用されるレセプト検証業務支援システムを病院内に設置する使用形態の第２の例である。図１４に示すレセプト検証業務支援システム１７００は、図１に示した実施例１のレセプト検証業務支援システム１００に、包括出来高差算出部１１２、レセプト検証優先度算出部１１３、各種マスタテーブルが格納されている知識データベース１１６、および整列制御部１１７を加えたシステムである。
　包括出来高差算出部１１２は、レセプト情報データベース１３０に格納されている審査請求対象のレセプトデータと知識データベースに登録された包括報酬マスタテーブルを用いて、包括支払い方式における医療報酬額（以下、包括報酬と呼ぶ）と、出来高支払い方式における医療報酬額（以下、出来高報酬と呼ぶ）とを算出する機能を提供する。出来高支払い方式において病院に支払われる医療報酬額は、各患者の入院期間中に実施された全診療行為の診療コストの総和である。そのため、出来高報酬は、各患者の入院期間中に実施された全診療行為の診療コストの総和と等しい。
　レセプト検証優先度算出部１１３は、レセプト検証候補の検証の優先度を表す指標であるレセプト検証優先度を算出する機能を提供する。
　整列制御部１１７は、表示画面生成部１０６において作成する画面において表示するレセプト検証候補を、整列基準に基づき整列する機能を提供する。
　包括出来高差算出部１１２、レセプト検証優先度算出部１１３および整列制御部１１７の機能は、それぞれ専用の論理回路等のハードウェアによって実現されてもよいし、制御部１０１がメモリ１０４に格納されたプログラムを実行することによって実現されてもよい。上記の各部の機能が制御部１０１によって実現される場合、以下の説明において上記の各部が実行する処理は、実際には、メモリ１０４に格納されたプログラムに記述された命令に従って、制御部１０１によって実行される。
　知識データベース１１６は、レセプト検証業務支援システム１７００内の記憶装置に格納される。例えば、知識データベース１１６は、レセプト検証業務支援システム１７００に含まれるハードディスクドライブのような記憶装置（図示省略）に格納され、それらの少なくとも一部が必要に応じてメモリ１０４にコピーされてもよい。
　＜データベースのテーブル構造＞
　＜レセプト分析データベース＞
　以下、上記レセプト分析データベース１１５を構成するテーブル構造を説明する。レセプト分析データベース１１５は、実施例１と同様の期待コストテーブル９００、尤度テーブル１０００およびレセプト検証テーブル１４００に加え、包括出来高テーブル２０００およびレセプト検証優先度テーブル２２００から構成される。
　図１５および図１６は、それぞれ、本発明の実施例２のレセプト分析データベース１１５を構成する包括出来高テーブル２０００およびレセプト検証優先度テーブル２２００のデータ構造を示す説明図である。
　＜包括出来高テーブル２０００＞
　包括出来高テーブル２０００（図１５）は、包括出来高差算出部１１２が算出した、各患者の包括報酬、出来高報酬、包括報酬と出来高報酬との差である包括出来高差を格納する。当該テーブルは患者ＩＤフィールド２００１、包括報酬フィールド２００２、出来高報酬フィールド２００３、および包括出来高差フィールド２００４を含んで構成される。
　患者ＩＤフィールド２００１は、患者を識別する識別子である患者ＩＤを格納する。
　包括報酬フィールド２００２は、各患者ＩＤによって識別される患者の包括報酬を格納する。
　出来高報酬フィールド２００３は、各患者ＩＤによって識別される患者の出来高報酬を格納する。
　包括出来高差フィールド２００４は、各患者ＩＤによって識別される患者の包括報酬と出来高報酬の差を格納する。
　＜レセプト検証優先度テーブル２２００＞
　レセプト検証優先度テーブル２２００（図１６）は、レセプト検証優先度算出部１１３が算出した、各患者のレセプト検証優先度と、包括出来高差算出部１１２が算出した包括出来高差と、を格納する。当該テーブルは患者ＩＤフィールド２２０１、レセプト検証優先度フィールド２２０２、および包括出来高差フィールド２２０３を含んで構成される。
　患者ＩＤフィールド２２０１は、患者を識別する識別子である患者ＩＤを格納する。
　レセプト検証優先度フィールド２２０２は、レセプト検証優先度算出部１１３が算出した各患者のレセプト検証優先度を格納する。
　包括出来高差フィールド２２０３は、包括出来高差算出部１１２が算出した包括出来高差を格納する。
　＜知識データベース１１６＞
　以下、知識データベース１１６を構成するテーブル構造を説明する。知識データベース１１６は、包括報酬マスタテーブル１９００から構成される。
　図１７は、本発明の実施例２の知識データベース１１６を構成する包括報酬マスタテーブル１９００のデータ構造を示す説明図である。
　包括報酬マスタテーブル１９００（図１７）は、包括支払い方式における１日当たり、または、１入院当たりの包括報酬額を格納する。包括支払い方式の運用形態によっては、入院期間に応じて１日当たりの包括報酬額は段階的に設定されている場合がある。本実施例では、入院期間に応じて１日当たりの包括報酬額が３段階で設定されている場合における、包括報酬マスタテーブル１９００の例を示す。
　包括報酬マスタテーブル１９００は、診断コードフィールド１９０１、入院期間１フィールド１９０２、入院期間１における１日当たりの包括報酬フィールド１９０３、入院期間２フィールド１９０４、入院期間２における１日当たりの包括報酬フィールド１９０５、入院期間３フィールド１９０６、および入院期間３における１日当たりの包括報酬フィールド１９０７を含んで構成される。
　診断コードフィールド１９０１は、診断コードを格納する。
　入院期間１フィールド１９０２は、各診断コードの第１段階に対応する入院期間を格納する。
　入院期間１における１日当たりの包括報酬フィールド１９０３は、各診断コードの、入院期間１フィールド１９０２の入院期間に対応する１日当たりの包括報酬を格納する。
　入院期間２フィールド１９０４は、各診断コードの第２段階に対応する入院期間を格納する。
　入院期間２における１日当たりの包括報酬フィールド１９０５は、各診断コードの、入院期間２フィールド１９０４の入院期間に対応する１日当たりの包括報酬を格納する。
　入院期間３フィールド１９０６は、各診断コードの第３段階に対応する入院期間を格納する。
　入院期間３における１日当たりの包括報酬フィールド１９０７は、各診断コードの、入院期間３フィールド１９０６の入院期間に対応する１日当たりの包括報酬を格納する。
　＜処理部＞
　＜包括出来高差算出処理フロー＞
　次に、包括出来高差算出部１１２が実行する、包括出来高差算出処理について述べる。包括出来高差とは、包括報酬と出来高報酬の差である。本処理は、上記尤度算出部１０９における尤度算出処理が終了したと同時に開始される。
　図１８は、本発明の実施例２の包括出来高差算出部１１２が実行する包括出来高差算出処理の例を示すフローチャートである。
　まず始めに、包括出来高差算出部１１２は、ネットワーク１２０を介して、レセプト情報データベース１３０に格納されているレセプトデータテーブル４００を取得する（Ｓ１８０１）。
　次に、包括出来高差算出部１１２は、ネットワーク１２０を介して、知識データベース１１６に格納されている包括報酬マスタテーブル１９００を取得する（Ｓ１８０２）。
　次に、包括出来高差算出部１１２は、レセプトデータテーブル４００において、審査請求済みフラグメントフィールド４０９が値を持つレコードにおける患者ＩＤフィールド４０１の患者ＩＤを一つ選択する事で患者を選択する。（Ｓ１８０３）。
　次に、包括出来高差算出部１１２は、包括報酬を算出する（Ｓ１８０４）。
　図１９Ａおよび図１９Ｂは、本発明の実施例２の包括出来高差算出部１１２が包括報酬を算出する処理の例を示すフローチャートである。
　まず始めに、包括出来高差算出部１１２は、包括報酬に０を設定する（Ｓ４００１）。
　次に、包括出来高差算出部１１２は、レセプトデータテーブル４００から、Ｓ１８０３で選択した患者ＩＤの患者の診断コードを取得する（Ｓ４００２）。
　次に、包括出来高差算出部１１２は、レセプトデータテーブル４００の入院年月日フィールド４０２と退院年月日フィールド４０３から、Ｓ１８０３で選択した患者ＩＤの患者の入院日数を算出する（Ｓ４００３）。
　次に、包括出来高差算出部１１２は、包括報酬マスタテーブル１９００の入院期間１フィールド１９０２から、Ｓ４００２で取得した診断コードの入院期間１の上限日数を参照し、Ｓ４００３で算出した入院日数が、入院期間１の上限日数以下であるか否かを判定する（Ｓ４００４）。Ｓ４００３で算出した入院日数が、入院期間１の上限日数以下であった場合、包括出来高差算出部１１２は、Ｓ４００５を実行する。Ｓ４００３で算出した入院日数が、入院期間１の上限日数以下でない場合、包括出来高差算出部１１２は、Ｓ４００６を実行する。
　Ｓ４００５において、包括出来高差算出部１１２は、Ｓ４００２で取得した診断コードの入院期間１の診療報酬とＳ４００３で算出した入院日数の積を包括報酬に代入し、包括報酬の算出処理を終了する。
　Ｓ４００６において、包括出来高差算出部１１２は、Ｓ４００２で取得した診断コードの入院期間１の診療報酬とＳ４００２で取得した診断コードの入院期間１の日数の積を包括報酬に代入する。
　次に、包括出来高差算出部１１２は、包括報酬マスタテーブル１９００の入院期間２フィールド１９０４から、Ｓ４００２で取得した診断コードの入院期間２の上限日数を参照し、Ｓ４００３で算出した入院日数が、入院期間２の上限日数以下であるか否かを判定する（Ｓ４００７）。Ｓ４００３で算出した入院日数が、入院期間２の上限日数以下であった場合、包括出来高差算出部１１２は、Ｓ４００８を実行する。Ｓ４００３で算出した入院日数が、入院期間２の上限日数以下でない場合、包括出来高差算出部１１２は、Ｓ４００９を実行する。
　Ｓ４００８において、包括出来高差算出部１１２は、Ｓ４００２で取得した診断コードの入院期間２の診療報酬とＳ４００３で算出した入院日数の積を包括報酬に加算し、包括報酬の算出処理を終了する。
　Ｓ４００６において、包括出来高差算出部１１２は、Ｓ４００２で取得した診断コードの入院期間２の診療報酬とＳ４００２で取得した診断コードの入院期間２の日数の積を包括報酬に加算する。
　次に、包括出来高差算出部１１２は、包括報酬マスタテーブル１９００の入院期間３フィールド１９０６から、Ｓ４００２で取得した診断コードの入院期間３の上限日数を参照し、Ｓ４００３で算出した入院日数が、入院期間３の上限日数以下であるか否かを判定する（Ｓ４０１０）。Ｓ４００３で算出した入院日数が、入院期間３の上限日数以下であった場合、包括出来高差算出部１１２は、Ｓ４０１１を実行する。Ｓ４００３で算出した入院日数が、入院期間３の上限日数以下でない場合、包括出来高差算出部１１２は、Ｓ４０１２を実行する。
　Ｓ４０１１において、包括出来高差算出部１１２は、Ｓ４００２で取得した診断コードの入院期間３の診療報酬とＳ４００３で算出した入院日数の積を包括報酬に加算し、包括報酬の算出処理を終了する。
　Ｓ４０１２において、包括出来高差算出部１１２は、Ｓ４００２で取得した診断コードの入院期間３の診療報酬と前記Ｓ４００２で取得した診断コードの入院期間３の日数の積を包括報酬に加算し、包括報酬の算出処理を終了する。
　次に、包括出来高差算出部１１２は、Ｓ１８０３で選択した患者ＩＤの患者の入院期間中に実施された全診療行為の診療コストを診療コストフィールド４０６から集計することで、出来高報酬を算出する（Ｓ１８０５）。
　次に、包括出来高差算出部１１２は、Ｓ１８０４で算出した包括報酬とＳ１８０５で算出した出来高報酬との差を、包括出来高差として算出する（Ｓ１８０６）。
　次に、包括出来高差算出部１１２は、算出した包括報酬、出来高報酬、および包括出来高差をそれぞれ患者ＩＤと対応付けて包括出来高テーブル２０００へ格納する（Ｓ１８０７）。
　次に、包括出来高差算出部１１２は、未選択の患者ＩＤが存在するかどうかを確認し（Ｓ１８０８）、未選択の患者ＩＤが存在する場合には未選択の患者ＩＤについてＳ１８０３以降の処理を実行する。未選択の患者ＩＤが存在しない場合には、レセプト検証候補抽出部１１１は次のステップを実行する。
　次に、包括出来高差算出部１１２は、包括出来高テーブル２０００をレセプト分析データベース１１５へ登録する（Ｓ１８０９）。以上の処理によって、包括出来高差算出部１１２は、包括報酬、出来高報酬および包括出来高差を算出する。
　＜レセプト検出優先度算出処理フロー＞
　次に、レセプト検証優先度算出部１１３が実行するレセプト検証優先度算出処理について述べる。レセプト検証優先度とは、レセプト検証候補の検証の優先度を表す指標である。本実施例では、総診療コストに対する最尤コードの尤度の割合と包括出来高差とを掛け合わせる事でレセプト検証優先度を算出する。本実施例におけるレセプト検証優先度の値が大きいほど出来高報酬に比べて包括報酬が小さく、かつ、診断コードが誤りである可能性が高くなる。なお、レセプト検証優先度は、ＤＰＣ毎に標準化した尤度と包括出来高差より算出する等、病院独自に定めた基準を用いて算出してもよい。
　本処理は、上記包括出来高差算出部１１２における包括出来高差算出処理が終了したときに開始される。
　図２０は、本発明の実施例２のレセプト検証優先度算出部１１３が実行するレセプト検証優先度算出処理の例を示すフローチャートである。
　まず始めに、レセプト検証優先度算出部１１３は、レセプト分析データベース１１５から、レセプト検証テーブル１４００を取得する（Ｓ２１０１）。
　次に、レセプト検証優先度算出部１１３は、レセプト分析データベース１１５から、包括出来高テーブル２０００を取得する（Ｓ２１０２）。
　次に、レセプト検証優先度算出部１１３は、レセプト検証テーブル１４００においてレセプト検証フラグメントフィールド１４０６が値を持つレコードの患者ＩＤフィールド１４０１から患者ＩＤを一つ選択することで患者を一つ選択する（Ｓ２１０３）。
　次に、レセプト検証優先度算出部１１３は、レセプト検証テーブルにおけるＳ２１０３で選択した患者ＩＤの患者の最尤コード尤度フィールド１４０５の値を、当該患者の総診療コストフィールド１４０７の値で割ることで、最尤診療コスト比を算出する（Ｓ２１０４）。なお、Ｓ２１０３の選択の結果、レセプト検証優先度算出処理は、現時点の診断コードと最尤コードとが一致しない患者を対象として実行される。したがって、ここで計算される最尤診療コスト比の大きさは、現時点の診断コードが最適でない可能性の高さを表している。
　次に、レセプト検証優先度算出部１１３は、Ｓ２１０３で算出した最尤診療コスト比と、包括出来高テーブル２０００におけるＳ２１０３で選択した患者ＩＤの患者の包括出来高差フィールド２００４の値と、を掛け合わせる事でレセプト検証優先度を算出する（Ｓ２１０５）。したがって、レセプト検証優先度は、現時点の診断コードが最適でない可能性が高いほど大きくなり、また、包括報酬と出来高報酬の差額（より詳細には、包括報酬から出来高報酬を減算した値）が大きいほど大きくなる。
　次に、レセプト検証優先度算出部１１３は、Ｓ２１０３で選択した患者ＩＤと対応付けて、包括出来高差、および、Ｓ２１０４で算出したレセプト検証優先度をそれぞれレセプト検証優先度テーブル２２００へ格納する（Ｓ２１０６）。
　次に、レセプト検証優先度算出部１１３は、未選択の患者ＩＤが存在するかどうかを確認し（Ｓ２１０７）、未選択の患者ＩＤが存在する場合には未選択の患者ＩＤについてＳ２１０３以降の処理を実行する。未選択の患者ＩＤが存在しない場合には、レセプト検証優先度算出部１１３は次のステップを実行する。
　次に、レセプト検証優先度算出部１１３は、レセプト検証優先度テーブル２２００をレセプト分析データベース１１５へ登録する（Ｓ２１０８）。以上の処理によって、レセプト検証優先度算出部１１３は、レセプト検証優先度を算出する。
　＜画面構成３＞
　表示画面生成部１０６は、上述のように算出した包括報酬、出来高報酬、包括出来高差およびレセプト検証優先度を、実施例１に示したレセプト検証候補と共に表示するための表示画面を構成する。構成された表示画面は入出力端末１５０によって表示される。
　ここで、本実施例において入出力端末１５０が表示する表示画面について述べる。
　図２１は、本発明の実施例２のレセプト検証業務支援システム１７００が入出力端末１５０に提示する画面例２３００の説明図である。
　画面例２３００（図２１）は、レセプト検証候補一覧表示部１５０１、診療行為一覧表示部１５０２、確認依頼ボタン１５０３、および整列基準設定部１５０４を含んで構成される。
　レセプト検証候補一覧表示部１５０１は、医師への提出チェックボタン１５０１１、診療行為一覧表示ボタン１５０１２、患者ＩＤフィールド１５０１３、診断コードフィールド１５０１４、診断コード尤度フィールド１５０１５、最尤コードフィールド１５０１６、最尤コード尤度フィールド１５０１７、総診療コストフィールド１５０１８、包括出来高差フィールド１５０１９、およびレセプト検証優先度フィールド１５０１１１を含んで構成される。
　レセプト検証候補一覧表示部１５０１は、レセプト検証テーブル１４００のレセプト検証フラグメントフィールド１４０６に値が存在する（例えば「１」が格納されている）患者に関する情報のみを表示する。
　医師への提出チェックボタン１５０１１、診療行為一覧表示ボタン１５０１２、患者ＩＤフィールド１５０１３、診断コードフィールド１５０１４、診断コード尤度フィールド１５０１５、最尤コードフィールド１５０１６、最尤コード尤度フィールド１５０１７および総診療コストフィールド１５０１８は、それぞれ、図１３の同じ参照符号が付された部分と同様であるため、説明を省略する。
　包括出来高差フィールド１５０１９は、レセプト検証優先度テーブル２２００における、患者ＩＤの患者の包括出来高差の値を表示する機能を提供する。
　レセプト検証優先度フィールド１５０１１１は、レセプト検証優先度テーブル２２００における、患者ＩＤの患者のレセプト検証優先度の値を表示する機能を提供する。
　診療行為一覧表示部１５０２及び確認依頼ボタン１５０３は、それぞれ、図１３の同じ参照符号が付された部分と同様であるため、説明を省略する。
　整列基準設定部１５０４は、整列設定ボタン１５０４１、整列基準対象項目ラジオボタン１５０４２、および整列基準対象順序ラジオボタン１５０４３を含んで構成される。
　整列設定ボタン１５０４１は、画面操作者によって押下される事で選択状態となり、選択状態となった時に、整列基準対象項目ラジオボタン１５０４２と整列基準対象順序ラジオボタン１５０４３によって設定された整列基準を、表示画面生成部１０６を介して整列制御部１１７に送信する機能を提供する。
　整列基準対象項目ラジオボタン１５０４２は、画面操作者によって押下される事で、複数の整列基準対象項目から一意の整列基準対象項目が選択状態となり、選択状態となった整列基準対象項目を選択基準として設定する機能を提供する。図２１の例では、整列基準対象項目としてレセプト検証優先度及び包括出来高差が表示され、それらのいずれか一方が整列基準対象項目ラジオボタン１５０４２の操作によって選択される。
　整列基準対象順序ラジオボタン１５０４３は、画面操作者によって押下される事で、複数の整列基準対象順序から一意の整列基準対象順序が選択状態となり、選択状態となった整列基準対象順序を選択基準として設定する機能を提供する。図２１の例では、整列基準対象順序として昇順及び降順が表示され、それらのいずれか一方が整列基準対象順序ラジオボタン１５０４３の操作によって選択される。
　次に、画面操作者が整列設定ボタン１５０４１を押下した時に、レセプト検証業務支援システム１７００によって実行される整列処理について述べる。
　図２２は、本発明の実施例２のレセプト検証業務支援システム１７００が実行する整列処理に関するシークエンス図である。
　まず、画面操作者が入出力端末１５０上に表示された整列基準設定部１５０４の整列設定ボタン１５０４１を押下すると、入出力端末１５０は整列基準対象項目ラジオボタン１５０４２と整列基準対象順序ラジオボタン１５０４３によって設定された選択基準を表示画面生成部１０６に送信する（Ｓ２４０１）。
　次に、表示画面生成部１０６は、入出力端末１５０から送信された整列基準と、表示画面を構成していたレセプト検証テーブル１４００においてレセプト検証フラグメントフィールド１４０６に値が存在するレセプト検証候補のデータとを整列制御部１１７に送信する（Ｓ２４０２）。
　次に、整列制御部１１７は、整列基準を基に整列したレセプト検証候補のリストを作成し、表示画面生成部１０６に送信する（Ｓ２４０３）。
　次に、表示画面生成部１０６は、整列制御部１１７から送信されたリストを基に、図２１のレセプト検証候補一覧表示部１５０１に示すような画面を構成し、入出力端末１５０に表示する（Ｓ２４０４）。これによって、高いレセプト検証優先度が算出された患者のレセプトデータが優先的に（例えばリストの上位に）表示される。
　このように、整列制御部１１７を備えることで、ユーザの関心の高い項目の値の順にレセプト検証候補に関する情報を並び変えて表示する事が可能となる。その為、画面操作者は、関心の高いレセプト検証候補を優先的に検証する事ができる。例えば、整列基準対象項目ラジオボタン１５０４２においてレセプト検証優先度を選択し、整列基準対象順序ラジオボタン１５０４３において降順を選択する事で、レセプト検証優先度の値が負かつ絶対値の大きい順にレセプト検証候補が整列される。レセプト検証優先度の値が負かつ絶対値の大きい患者は、診断コードが誤りである可能性が高く、かつ、正しい診断コードに変更する事で容易に診療報酬を増加する事が出来る可能性が高いレセプト検証候補である。そのため、画面操作者は診断コードが誤りである可能性が高く、かつ、正しい診断コードに変更する事で容易に診療報酬を増加する事が出来る可能性が高いレセプト検証候補を優先的に検証する事が可能となる。
　以上のことからレセプト検証優先度を用いたレセプト検証候補の整列をおこなうことで、効率的なレセプト検証業務を実施することが可能となる。
　なお、上記のようなレセプト検証優先度の算出方法は一例であり、レセプト検証の目的等に応じて、種々の方法で算出されたレセプト検証優先度を使用することができる。例えば、診療報酬が増加する可能性にかかわらず、診断コードが誤りである可能性が高い患者のレセプトデータを優先的に検証したい場合には、最尤診療コスト比をレセプト検証優先度として使用してもよい。あるいは、診断コードが誤りである可能性にかかわらず、診療報酬が増加する可能性が高い患者のレセプトデータを優先的に検証したい場合には、包括出来高差をレセプト検証優先度として使用してもよい。
　次に、本発明の実施例３を説明する。以下に説明する相違点を除き、実施例３のレセプト検証業務支援システム２５００の各部は、実施例１または実施例２の同一の符号を付された各部と同一の機能を有するため、それらの説明は省略する。
　図２３は、本発明の実施例３のレセプト検証業務支援システム２５００の構成を示すブロック図である。
　図２３に示す実施例３のレセプト検証業務支援システム２５００は、国が指定するレセプト審査機関である審査支払機関等の病院から提出されたレセプトを審査し診療報酬の支払いを行う機関に設置される。レセプト検証業務支援システム２５００は、制御部１０１、入力部１０２、出力部１０３、メモリ１０４、通信部１０５、表示画面生成部１０６、実施確率算出部１０８、尤度算出部１０９、レセプト検証候補抽出部１１１、実施確率データベース１１４、レセプト分析データベース１１５、知識データベース１１６、および整列制御部１１７によって構成される。レセプト検証業務支援システム２５００は、ネットワーク１２０を介して、レセプト審査業務を実施する入出力端末１７０、レセプト審査システム１８０、および提出レセプト情報データベース１９０等と接続される。提出レセプト情報データベース１９０は、少なくとも１つ以上の病院から提出されたレセプトの情報を蓄積する。
　＜提出レセプト情報データベース１９０＞
　以下、提出レセプト情報データベース１９０を構成するテーブル構造を説明する。提出レセプト情報データベース１９０は、提出レセプトデータテーブル４１００を含んで構成される。
　図２４は、本発明の実施例３の提出レセプト情報データベース１９０を構成する提出レセプトデータテーブル４１００のデータ構造を示す説明図である。
　提出レセプトデータテーブル４１００（図２４）は、各病院から提出された、審査請求対象のレセプトデータと審査請求済みのレセプトデータを格納するテーブルであり、基本的にレセプト審査システム１８０によって自動的に登録される。
　当該テーブルは、患者ＩＤフィールド４１０１、入院年月日フィールド４１０２、退院年月日フィールド４１０３、診断コードフィールド４１０４、診療行為フィールド４１０５、診療コストフィールド４１０６、行為回数フィールド４１０７、実施年月日フィールド４１０８、審査請求済みフラグメントフィールド４１０９、審査請求対象フラグメントフィールド４１１０、および病院コードフィールド４１１１を含んで構成される。これらのフィールドのうち、患者ＩＤフィールド４１０１～審査請求対象フラグメントフィールド４１１０は、それぞれ、レセプトデータテーブル４００（図２）の患者ＩＤフィールド４０１～審査請求対象フラグメントフィールド４１０と同様のものであってよいため、説明を省略する。
　病院コードフィールド４１１１は、提出されたレポートの提出元病院を識別する識別子である病院コードを格納する。
　本システムは、病院コードフィールド４１１１を参照する事で、特定の病院から提出されたレセプトのデータのみを抽出することが可能である。
　本システムは、審査請求済みフラグメントフィールド４１０９、または、審査請求対象フラグメントフィールド４１１０の値を参照する事で、審査請求後のレセプトに属するレコードのみ、審査請求対象のレセプトに属するデータのみを、それぞれ抽出する事が可能である。
　審査請求済みフラグメントフィールド４１０９は、基本的に各病院から提出された際には値を持たず（例えば値が０であり）、レセプトの審査が終了した後に、レセプト審査システム１８０によって値（例えば１）が入力される。また、審査請求対象フラグメントフィールド４１１０は、基本的に各病院から提出された際にレセプト審査システム１８０によって値（例えば１）が入力され、レセプトの審査が終了した後に、レセプト審査システム１８０によって値が削除される（例えば値が０に更新される）。
　なお、審査請求後のレセプトのデータと審査請求対象のレセプトのデータは、審査請求済みフラグメントフィールド４１０９および審査請求対象フラグメントフィールド４１１０を有する一つの提出レセプトデータテーブル４１００に格納する代わりに、それらのフィールドを有しない別々のテーブルにそれぞれ格納しても良い。
　本実施例の表示画面生成部１０６は、実施例２に示した包括報酬、出来高報酬、包括出来高差およびレセプト検証優先度を、実施例１に示したレセプト検証候補と共に表示するための表示画面を構成する。構成された表示画面は入出力端末１７０によって表示される。
　ここで、本実施例において入出力端末１７０が表示する表示画面について述べる。
　図２５は、本発明の実施例３のレセプト検証業務支援システム２５００が入出力端末１７０に提示する画面例２６００の説明図である。
　画面例２６００（図２５）は、レセプト検証候補一覧表示部１５０１、診療行為一覧表示部１５０２、整列基準設定部１５０４、および返戻依頼ボタン１５０５を含んで構成される。返戻とは、審査機関によって修正が必要だと判断されたレセプトを審査機関が提出元の病院に差し戻す事である。
　レセプト検証候補一覧表示部１５０１は、病院への返戻チェックボタン１５０１１２、診療行為一覧表示ボタン１５０１２、患者ＩＤフィールド１５０１３、診断コードフィールド１５０１４、診断コード尤度フィールド１５０１５、最尤コードフィールド１５０１６、最尤コード尤度フィールド１５０１７、総診療コストフィールド１５０１８、包括出来高差フィールド１５０１９、およびレセプト検証優先度フィールド１５０１１１を含んで構成される。
　レセプト検証候補一覧表示部１５０１は、提出レセプトデータテーブル４１００の審査請求対象フラグメントフィールド４１１０に値が存在する患者に関する情報のみを表示する。
　病院への返戻チェックボタン１５０１１２は、画面操作者によって押下された時に選択状態となる。
　診療行為一覧表示ボタン１５０１２、患者ＩＤフィールド１５０１３、診断コードフィールド１５０１４、診断コード尤度フィールド１５０１５、最尤コードフィールド１５０１６、最尤コード尤度フィールド１５０１７、総診療コストフィールド１５０１８、包括出来高差フィールド１５０１９およびレセプト検証優先度フィールド１５０１１１は、それぞれ、図２１の同じ参照符号が付された部分と同様であるため、説明を省略する。
　診療行為一覧表示部１５０２は、図２１に示したものと同様であるため、説明を省略する。
　返戻依頼ボタン１５０５が押下されると、レセプト検証業務支援システム２５００は、その時点で病院への返戻チェックボタン１５０１１２が選択状態となっている患者のレセプト情報を、病院への返戻依頼レセプトとしてレセプト審査システム１８０へ送信する。
　整列基準設定部１５０４は、図２１に示したものと同様であるため、説明を省略する。
　審査機関において、本システムは、各病院から提出されるレセプトの中に、適切でないＤＰＣコードが記載され、適正額以上の診療報酬が請求されているレセプトの抽出を目的に使用される。そのため、審査機関は包括出来高差の値が正かつ絶対値が大きく、最尤コードの尤度が高いレセプト検証候補を優先的に検証する必要がある。
　図２５に示した、入出力端末１７０が表示する画面例中の、整列基準設定部１５０４にある整列基準対象項目ラジオボタン１５０４２および整列基準対象順序ラジオボタン１５０４３を用いて、それぞれ「レセプト検証優先度」および「昇順」を整列基準として選択することによって、包括出来高差の値が正かつ絶対値が大きく、最尤コードの尤度が高いレセプトを上位に整列することが可能である。そのため、審査機関は本システムを用いる事で、包括出来高差の値が正かつ絶対値が大きく、最尤コードの尤度が高いレセプトを優先的に検証する事が可能となる。
　このように、レセプト検証優先度によるレセプトの整列を行うことで、審査機関における関心が高いレセプト検証候補を効率的に審査することが可能となる。
　以上のことから、レセプト検証優先度を用いたレセプト検証候補の整列を行うことで、審査機関においても効率的なレセプトの審査を実施することが可能となる。
　次に、本発明の実施例４を説明する。以下に説明する相違点を除き、実施例４のレセプト検証業務支援システム２７００の各部は、実施例１、実施例２または実施例３の同一の符号を付された各部と同一の機能を有するため、それらの説明は省略する。
　図２６は、本発明の実施例４のレセプト検証業務支援システム２７００の構成を示すブロック図である。
　図２６に示す実施例３のレセプト検証業務支援システム２７００は、病院内に設置される。レセプト検証業務支援システム２７００は、図１４に示したレセプト検証業務支援システム１７００に、コード制御部１１８を追加することによって構成される。特に、コード制御部１１８において、実施確率および尤度の算出を行うコードを診断コードから、診断コードの上位コードに変更することを特徴とする。
　例えば日本のＤＰＣ制度においては、診断コードはＤＰＣコードであり、ＤＰＣコードの上位コードは疾患コードであり、疾患コードの上位コードは主要診断群コードである。米国のＤＲＧ/ＰＰＳにおいては、診断コードはＤＲＧコードであり、ＤＲＧコードの上位コードはＭＤＣ（Major Diagnostic Category）コードである。英国のＰｂＲにおいては、診断コードはＨＲＧコードであり、ＨＲＧコードの上位コードはＳｕｂ－ｃｈａｐｔｅｒと呼ばれるアルファベット２文字のグループコードであり、その上位コードはＣｈａｐｔｅｒと呼ばれるアルファベット１文字のグループコードである。本実施例では日本のＤＰＣ制度を例として取り上げるが、ＤＰＣ制度に限らず、全ての包括支払い制度における診断コードとその上位コードに適用が可能である。
　なお、上記の診断コードおよびその上位コードは、いずれも、広義の診断コードとして扱うことができる。例えば実施例１～３を日本のＤＰＣ制度に適用する場合、実施例１～３に記載された「診断コード」は、ＤＰＣコード、疾患コードまたは主要診断群コードのいずれであってもよい。
　ＤＰＣ制度において、疾患コードとは複数のＤＰＣコードを疾患別に纏めたコードであり、ＤＰＣコードの上位６桁に相当する。主要診断群コードとは複数の疾患コードを纏めたコードであり、ＤＰＣコードの上位２桁に相当する。知識データベース１１６に予め記録したコードマスタ２８００を使用し、診断コードであるＤＰＣコードと、その上位の診断コードである疾患コードおよび主要診断群コードとの対応付けを行うことで、コードの変更が可能となる。
　図２７は、本発明の実施例４の知識データベース１１６を構成するコードマスタ２８００の説明図である。
　コードマスタ２８００は、例えば図２７に示すように、主要診断群コードフィールド２８０１、疾患コードフィールド２８０２およびＤＰＣコードフィールド２８０３を含んで構成されるテーブルである。ＤＰＣコードフィールド２８０３にはＤＰＣコードが、疾患コードフィールド２８０２には各ＤＰＣコードが対応する疾患コードが、主要診断群コードフィールド２８０１には各疾患コードが対応する主要診断群コードが、それぞれ格納されている。本実施例では、ＤＰＣコード１およびＤＰＣコード２が疾患コード１に対応し、ＤＰＣコード３－４が疾患コード２に対応し、ＤＰＣコード５が疾患コード３に対応する。また、疾患コード１および疾患コード２が主要診断群コード１に対応し、疾患コード３が主要診断群コード２に対応する。コード制御部１１８が、コードマスタ２８００に基づいてレセプトのＤＰＣコードを疾患コード、主要診断群コードに変更した後、実施確率算出部１０８が実施確率を算出する事で、疾患コードまたは主要診断群コードにおける実施確率の算出が可能となる。同様にコード制御部１１８がＤＰＣコードを疾患コードまたは主要診断群コードに変更する事で、尤度算出部１０９による尤度の算出および最尤コード算出部１１０による最尤コードの算出を、疾患コードまたは主要診断群コードについて実施する事が可能となる。
　このように疾患コード、主要診断群コードを用いる事で、ＤＰＣデータ蓄積データベース１４０において該当する患者が少ない、または該当する存在しないＤＰＣコードについても、疾患コードまたは主要診断群コード単位でのＤＰＣコーディングミスの判定をすることが可能となる。
　ここでコード制御部１１８による、入出力端末１５０に提示するレセプト検証候補を制御する仕組みについて述べる。
　図２８は、本発明の実施例４のレセプト検証業務支援システム２７００が入出力端末１５０に提示する画面例２９００の説明図である。
　画面例２９００は、図２１に示した画面例２３００と同様の部分に加えて、コード基準設定部１５０６を含む。コード基準設定部１５０６は、コード基準を選択するための複数のラジオボタンと、コード設定ボタンと、を含む。図２８は本実施例が日本のＤＰＣ制度に適用される例を示しているため、図２８のコード基準設定部１５０６は、それぞれＤＰＣコード、疾患コードおよび診断群分類コードに対応する三つのラジオボタンが表示される。
　また、図２９は、本発明の実施例４のレセプト検証業務支援システム２７００が、選択したコードを基準としたレセプト検証候補を抽出する処理に関するシークエンス図である。
　疾患コードや主要診断群コードを基準としたレセプト検証候補を表示する時は、画面操作者は、入出力端末１５０を操作して図２８に示すコード基準設定部１５０６のラジオボタンを選択することでコード基準を選択し、コード設定ボタン１５０６１を押下する。入出力端末１５０は、選択されたコード基準を、表示画面生成部１０６を介してコード制御部１１８に送信する（Ｓ３００１、Ｓ３００２）。コード制御部１１８は、選択されたコード基準において、最尤コードを算出し、算出した最尤コードとレセプト情報の現時点のコードが異なる患者のレセプトデータをレセプト検証候補として取得する。
　ここで、例えばコード基準として疾患コードが選択された場合、コード制御部１１８は、コードマスタ２８００に基づいてレセプトデータのＤＰＣコードを疾患コードに変換し、実施確率算出部１０８および尤度算出部１０９が、疾患コードに基づいて、実施例１～３と同様の方法で、実施確率および尤度等を算出してもよい。コード基準として主要診断群コードが選択された場合は、レセプトデータのＤＰＣコードが主要診断群コードに変換され、それに基づいて実施確率および尤度等が算出される。コード制御部１１８は、算出された尤度に基づく最尤コード等の情報をレセプト検証候補抽出部１１１に送信する（Ｓ３００３）。レセプト検証候補抽出部１１１は、実施例１～３と同様の方法でレセプト検証候補を抽出してその結果をコード制御部１１８に送信する（Ｓ３００４）。
　コード制御部１１８は、取得したレセプト検証候補とその最尤コード、レセプト情報のコードを表示画面生成部１０６に送信する（Ｓ３００５）。表示画面生成部１０６は送信されたレセプト検証候補とその最尤コード、レセプト情報のコードを基に、図２８に示すような画面を構成し、入出力端末１５０に提示する（Ｓ３００６）。
　図２８には、コード基準として疾患コードが選択された例を示す。この例では、診断コードフィールド１５０１４に疾患コード２が、診断コード尤度フィールド１５０１５に疾患コード２の尤度が、最尤コードフィールド１５０１６に、疾患コード２のレセプトデータから算出された最尤疾患コードである疾患コード３が、最尤コード尤度フィールド１５０１７に疾患コード３の尤度が、それぞれ表示される。
　このようにコード制御部１１８を備えることで、入出力端末１５０に提示するレセプト検証候補を、任意のコードを基準としたレセプト検証候補に変更することが可能となる。
　例えば、患者ＩＤ＃＃＃５で識別される患者の現時点の診断コードがＤＰＣコード３であるが、当該患者が入院している病院の、審査請求済みのレセプトデータに診断コードがＤＰＣコード３であるデータが含まれていない場合、ＤＰＣコードに基づいて当該患者のレセプトデータを検証候補とすべきか否かを判定することができない。また、審査請求済みのレセプトデータに診断コードがＤＰＣコード３であるデータが含まれていたとしても、その量が少なければ、信頼性の高い判定をすることができない。
　図２７の例では、ＤＰＣコード３およびＤＰＣコード４がいずれも同一の疾患コード２に対応する。異なるＤＰＣコードが与えられていても、同一の疾患コードが与えられた（すなわち同一の傷病を持つ）患者に実施される診療行為の傾向は類似すると考えられる。同様に、同一の主要診断群コードが与えられた患者間の診療行為の類似性は、異なる主要診断群コードが与えられた患者間の類似性より高いと考えられる。
　このため、審査請求済みのレセプトデータに例えば診断コードがＤＰＣコード４であるデータが十分に含まれていた場合には、ＤＰＣコード３およびＤＰＣコード４を含む疾患コード２について最尤コード等を算出し、それでも十分でない場合には主要診断群コードについて同様の算出をすることによって、信頼性の高いレセプト検証候補を抽出することが可能となる。
　以上のことから、実施例４によれば、該当する患者が少ない、または該当する患者が存在しないＤＰＣコードが存在する場合には、疾患コード、主要診断群コード単位でのＤＰＣコーディングミスの判定に変更することで、レセプト検証を支援することが可能となる。
　なお、本発明は上述した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
　また、図面には、実施例を説明するために必要と考えられる制御線及び情報線を示しており、必ずしも、本発明が適用された実際の製品に含まれる全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

Claims (15)

  1. 　レセプトデータを保持する記憶部と、前記レセプトデータに基づいて、前記患者と前記診断コードとの対応付けの尤度を算出する尤度算出部と、前記尤度に基づいて、検証候補のレセプトデータを抽出するレセプト検証候補抽出部と、を有する業務支援システムであって、
    　前記レセプトデータは、患者と、前記患者の診断コードと、前記患者に実施された診療行為と、前記診療行為のコストと、を対応付ける情報を含み、
    　前記尤度算出部は、
    　前記患者に実施された各診療行為のコストと、前記各診療行為の前記診断コードごとの実施確率と、に基づいて、前記各診療行為の前記診断コードごとの期待コストを算出し、
    　前記各診断コードに対応する全ての前記診療行為の前記期待コストの合計値を前記各診断コードの尤度として算出し、
    　前記レセプト検証候補抽出部は、
    　前記算出された尤度が最大となる診断コードと、前記患者の診断コードとが異なる場合、前記患者のレセプトデータが検証候補であると判定し、
    　前記患者のレセプトデータが検証候補であることを示す情報を出力することを特徴とする業務支援システム。
  2. 　請求項１に記載の業務支援システムであって、
    　前記記憶部は、検証候補の抽出対象でないレセプトデータをさらに保持し、
    　前記検証候補の抽出対象でないレセプトデータは、複数の患者と、前記各患者の診断コードと、前記各患者に実施された一つ以上の診療行為と、前記各患者への前記各診療行為の実施回数と、を対応付ける情報を含み、
    　前記業務支援システムは、前記検証候補の抽出対象でないレセプトデータに基づいて、前記診断コードごとおよび前記患者ごとの前記各診療行為の平均実施回数を算出し、前記各診断コードに対応する全ての前記診療行為の前記平均実施回数の合計に対する、前記各診断コードに対応する前記各診療行為の前記平均実施回数の割合を、前記各診療行為の前記診断コードごとの実施確率として算出する実施確率算出部をさらに有することを特徴とする業務支援システム。
  3. 　請求項１に記載の業務支援システムであって、
    　前記記憶部は、
    　複数の患者に関する前記レセプトデータを保持し、
    　前記診断コードごとの包括報酬額の情報を含む包括報酬データをさらに保持し、
    　前記尤度算出部は、前記レセプトデータおよび前記実施確率に基づいて、前記各患者の前記診断コードごとの尤度を算出し、
    　前記レセプト検証候補抽出部は、前記レセプトデータおよび前記尤度に基づいて、前記各患者のレセプトデータが検証候補であるか否かを判定し、
    　前記業務支援システムは、
    　前記包括報酬データから取得される前記各患者の診断コードの包括報酬額と、前記レセプトデータに含まれる前記各患者に実施された診療行為のコストから算出される前記各患者の出来高報酬額と、の差額である包括出来高差を算出する包括出来高差算出部と、
    　前記各患者の包括出来高差と、前記各患者に関して計算された複数の前記診断コードの尤度の最大値と、の少なくとも一方に基づいて、検証候補であると判定された複数の患者のレセプトデータの検証優先度を算出する検証優先度算出部と、
    　前記検証優先度が高いレセプトデータを優先的に出力する整列制御部と、さらに有することを特徴とする業務支援システム。
  4. 　請求項３に記載の業務支援システムであって、
    　前記検証優先度算出部は、前記各患者の包括出来高差が大きいほど前記検証優先度が大きくなり、かつ、前記各患者の診療コストの合計値に対する前記尤度の最大値の割合が大きいほど前記検証優先度が大きくなるように、前記検証優先度を算出することを特徴とする業務支援システム。
  5. 　請求項１に記載の業務支援システムであって、
    　前記記憶部は、下位の前記診断コードと、複数の前記下位の診断コードを包含する上位の診断コードと、を対応付ける診断コード情報をさらに保持し、
    　前記尤度算出部は、前記下位の診断コードまたは前記上位の診断コードのうち選択された一方について前記尤度を算出することを特徴とする業務支援システム。
  6. 　記憶部と、前記記憶部に接続される制御部と、を有する業務支援システムが実行する業務支援方法であって、
    　前記記憶部は、患者と、前記患者の診断コードと、前記患者に実施された診療行為と、前記診療行為のコストと、を対応付ける情報を含むレセプトデータを保持し、
    　前記業務支援方法は、
    　前記制御部が、前記患者に実施された各診療行為のコストと、前記各診療行為の前記診断コードごとの実施確率と、に基づいて、前記各診療行為の前記診断コードごとの期待コストを算出し、前記各診断コードに対応する全ての前記診療行為の前記期待コストの合計値を前記各診断コードの尤度として算出する尤度算出手順と、
    　前記制御部が、前記算出された尤度が最大となる診断コードと、前記患者の診断コードとが異なる場合、前記患者のレセプトデータが検証候補であると判定し、前記患者のレセプトデータが検証候補であることを示す情報を出力するレセプト検証候補抽出手順と、を含むことを特徴とする業務支援方法。
  7. 　請求項６に記載の業務支援方法であって、
    　前記記憶部は、検証候補の抽出対象でないレセプトデータをさらに保持し、
    　前記検証候補の抽出対象でないレセプトデータは、複数の患者と、前記各患者の診断コードと、前記各患者に実施された一つ以上の診療行為と、前記各患者への前記各診療行為の実施回数と、を対応付ける情報を含み、
    　前記業務支援方法は、前記検証候補の抽出対象でないレセプトデータに基づいて、前記診断コードごとおよび前記患者ごとの前記各診療行為の平均実施回数を算出し、前記各診断コードに対応する全ての前記診療行為の前記平均実施回数の合計に対する、前記各診断コードに対応する前記各診療行為の前記平均実施回数の割合を、前記各診療行為の前記診断コードごとの実施確率として算出する実施確率算出手順をさらに含むことを特徴とする業務支援方法。
  8. 　請求項６に記載の業務支援方法であって、
    　前記記憶部は、
    　複数の患者に関する前記レセプトデータを保持し、
    　前記診断コードごとの包括報酬額の情報を含む包括報酬データをさらに保持し、
    　前記尤度算出手順において、前記制御部は、前記レセプトデータおよび前記実施確率に基づいて、前記各患者の前記診断コードごとの尤度を算出し、
    　前記レセプト検証候補抽出手順において、前記制御部は、前記レセプトデータおよび前記尤度に基づいて、前記各患者のレセプトデータが検証候補であるか否かを判定し、
    　前記業務支援方法は、
    　前記制御部が、前記包括報酬データから取得される前記各患者の診断コードの包括報酬額と、前記レセプトデータに含まれる前記各患者に実施された診療行為のコストから算出される前記各患者の出来高報酬額と、の差額である包括出来高差を算出する包括出来高差算出手順と、
    　前記制御部が、前記各患者の包括出来高差と、前記各患者に関して計算された複数の前記診断コードの尤度の最大値と、の少なくとも一方に基づいて、検証候補であると判定された複数の患者のレセプトデータの検証優先度を算出する検証優先度算出手順と、
    　前記制御部が、前記検証優先度が高いレセプトデータを優先的に出力する整列制御手順と、さらに含むことを特徴とする業務支援方法。
  9. 　請求項８に記載の業務支援方法であって、
    　前記検証優先度算出手順において、前記制御部は、前記各患者の包括出来高差が大きいほど前記検証優先度が大きくなり、かつ、前記各患者の診療コストの合計値に対する前記尤度の最大値の割合が大きいほど前記検証優先度が大きくなるように、前記検証優先度を算出することを特徴とする業務支援方法。
  10. 　請求項６に記載の業務支援方法であって、
    　前記記憶部は、下位の前記診断コードと、複数の前記下位の診断コードを包含する上位の診断コードと、を対応付ける診断コード情報をさらに保持し、
    　前記尤度算出手順において、前記制御部は、前記下位の診断コードまたは前記上位の診断コードのうち選択された一方について前記尤度を算出することを特徴とする業務支援方法。
  11. 　記憶部と、前記記憶部に接続されるプロセッサと、を有する業務支援システムのための業務支援プログラムであって、
    　前記記憶部は、患者と、前記患者の診断コードと、前記患者に実施された診療行為と、前記診療行為のコストと、を対応付ける情報を含むレセプトデータを保持し、
    　前記業務支援プログラムは、
    　前記患者に実施された各診療行為のコストと、前記各診療行為の前記診断コードごとの実施確率と、に基づいて、前記各診療行為の前記診断コードごとの期待コストを算出し、前記各診断コードに対応する全ての前記診療行為の前記期待コストの合計値を前記各診断コードの尤度として算出する尤度算出手順と、
    　前記算出された尤度が最大となる診断コードと、前記患者の診断コードとが異なる場合、前記患者のレセプトデータが検証候補であると判定し、前記患者のレセプトデータが検証候補であることを示す情報を出力するレセプト検証候補抽出手順と、を前記プロセッサに実行させることを特徴とする業務支援プログラム。
  12. 　請求項１１に記載の業務支援プログラムであって、
    　前記記憶部は、検証候補の抽出対象でないレセプトデータをさらに保持し、
    　前記検証候補の抽出対象でないレセプトデータは、複数の患者と、前記各患者の診断コードと、前記各患者に実施された一つ以上の診療行為と、前記各患者への前記各診療行為の実施回数と、を対応付ける情報を含み、
    　前記業務支援プログラムは、前記検証候補の抽出対象でないレセプトデータに基づいて、前記診断コードごとおよび前記患者ごとの前記各診療行為の平均実施回数を算出し、前記各診断コードに対応する全ての前記診療行為の前記平均実施回数の合計に対する、前記各診断コードに対応する前記各診療行為の前記平均実施回数の割合を、前記各診療行為の前記診断コードごとの実施確率として算出する実施確率算出手順をさらに前記プロセッサに実行させることを特徴とする業務支援プログラム。
  13. 　請求項１１に記載の業務支援プログラムであって、
    　前記記憶部は、
    　複数の患者に関する前記レセプトデータを保持し、
    　前記診断コードごとの包括報酬額の情報を含む包括報酬データをさらに保持し、
    　前記尤度算出手順は、前記レセプトデータおよび前記実施確率に基づいて、前記各患者の前記診断コードごとの尤度を算出する手順を含み、
    　前記レセプト検証候補抽出手順は、前記レセプトデータおよび前記尤度に基づいて、前記各患者のレセプトデータが検証候補であるか否かを判定する手順を含み、
    　前記業務支援プログラムは、
    　前記包括報酬データから取得される前記各患者の診断コードの包括報酬額と、前記レセプトデータに含まれる前記各患者に実施された診療行為のコストから算出される前記各患者の出来高報酬額と、の差額である包括出来高差を算出する包括出来高差算出手順と、
    　前記各患者の包括出来高差と、前記各患者に関して計算された複数の前記診断コードの尤度の最大値と、の少なくとも一方に基づいて、検証候補であると判定された複数の患者のレセプトデータの検証優先度を算出する検証優先度算出手順と、
    　前記検証優先度が高いレセプトデータを優先的に出力する整列制御手順と、さらに前記プロセッサに実行させることを特徴とする業務支援プログラム。
  14. 　請求項１３に記載の業務支援プログラムであって、
    　前記検証優先度算出手順は、前記各患者の包括出来高差が大きいほど前記検証優先度が大きくなり、かつ、前記各患者の診療コストの合計値に対する前記尤度の最大値の割合が大きいほど前記検証優先度が大きくなるように、前記検証優先度を算出する手順を含むことを特徴とする業務支援プログラム。
  15. 　請求項１１に記載の業務支援プログラムであって、
    　前記記憶部は、下位の前記診断コードと、複数の前記下位の診断コードを包含する上位の診断コードと、を対応付ける診断コード情報をさらに保持し、
    　前記尤度算出手順は、前記下位の診断コードまたは前記上位の診断コードのうち選択された一方について前記尤度を算出する手順を含むことを特徴とする業務支援プログラム。
PCT/JP2014/061384 2014-04-23 2014-04-23 業務支援システム、業務支援方法及び業務支援プログラム WO2015162716A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/061384 WO2015162716A1 (ja) 2014-04-23 2014-04-23 業務支援システム、業務支援方法及び業務支援プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/061384 WO2015162716A1 (ja) 2014-04-23 2014-04-23 業務支援システム、業務支援方法及び業務支援プログラム

Publications (1)

Publication Number Publication Date
WO2015162716A1 true WO2015162716A1 (ja) 2015-10-29

Family

ID=54331906

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/061384 WO2015162716A1 (ja) 2014-04-23 2014-04-23 業務支援システム、業務支援方法及び業務支援プログラム

Country Status (1)

Country Link
WO (1) WO2015162716A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017102848A (ja) * 2015-12-04 2017-06-08 東芝メディカルシステムズ株式会社 医事会計システムおよび医事会計プログラム
JP2021089541A (ja) * 2019-12-03 2021-06-10 Ｃｇｉメディカル株式会社 診断群分類推定システム、診断群分類推定プログラム、及び診断群分類推定方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010157128A (ja) * 2008-12-27 2010-07-15 Nichii Gakkan Co 診断群分類検証システム、診断群分類検証プログラムおよび診断群分類検証方法
JP2011210142A (ja) * 2010-03-30 2011-10-20 Secom Co Ltd 医療情報処理装置およびプログラム
JP2013120422A (ja) * 2011-12-06 2013-06-17 Hokkaido Univ 医療費解析システム
JP2014021680A (ja) * 2012-07-17 2014-02-03 Reasonwhy Inc レセプト分析装置及びレセプト分析プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010157128A (ja) * 2008-12-27 2010-07-15 Nichii Gakkan Co 診断群分類検証システム、診断群分類検証プログラムおよび診断群分類検証方法
JP2011210142A (ja) * 2010-03-30 2011-10-20 Secom Co Ltd 医療情報処理装置およびプログラム
JP2013120422A (ja) * 2011-12-06 2013-06-17 Hokkaido Univ 医療費解析システム
JP2014021680A (ja) * 2012-07-17 2014-02-03 Reasonwhy Inc レセプト分析装置及びレセプト分析プログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017102848A (ja) * 2015-12-04 2017-06-08 東芝メディカルシステムズ株式会社 医事会計システムおよび医事会計プログラム
JP2021089541A (ja) * 2019-12-03 2021-06-10 Ｃｇｉメディカル株式会社 診断群分類推定システム、診断群分類推定プログラム、及び診断群分類推定方法
JP7372668B2 (ja) 2019-12-03 2023-11-01 Ｃｇｉメディカル株式会社 診断群分類推定システム、診断群分類推定プログラム、及び診断群分類推定方法

Similar Documents

Publication Publication Date Title
AU2016270515B2 (en) Product customization based on user contributions
US11615637B1 (en) Document data capture
US20140201045A1 (en) Determining local tax structures in an accounting application through user contribution
US8332287B2 (en) Methods and apparatus for automated deposit reconciliation
Zechmeister-Koss et al. Appropriate Evidence Sources for Populating Decision Analytic Models within Health Technology Assessment (HTA) A Systematic Review of HTA Manuals and Health Economic Guidelines
WO2015162716A1 (ja) 業務支援システム、業務支援方法及び業務支援プログラム
US20200151804A1 (en) Systems and methods for electronically accepting and transmitting purchase order on an online platform
JP6285284B2 (ja) 意見活用支援装置、及び意見活用支援方法
US20130035963A1 (en) System and method for financial transactions between insurance service provider and medical service provider
KR102206001B1 (ko) 사용자 행위에 기반한 전자서적 추천 장치 및 방법
JP4925269B2 (ja) レセプト債権管理システム
JP4774308B2 (ja) 減価償却費算出プログラムおよび減価償却費算出方法
JP2019008453A (ja) データの仲介システムおよび仲介方法
JP2017151627A (ja) 帳票データ化システム、帳票データ化装置、帳票データ化方法および帳票データ化装置の制御プログラム
CN112699872A (zh) 表单审核处理方法及装置、电子设备和存储介质
US20100293004A1 (en) Payer estimation and identification methods and apparatus
JP5899189B2 (ja) 利用情報管理装置、利用情報管理方法および利用情報管理プログラム
US20230197213A1 (en) Medical information management system, clinical information acquisition server, medical information management method, and non-transitory recording medium storing a program
JP2020086681A (ja) 情報処理方法、プログラムおよび情報処理装置
JP2019159608A (ja) 検索装置及び検索方法
US20230352154A1 (en) Methods and systems for managing healthcare workflows
Chakrabarti et al. Conceptualizing monetary benchmarks for health investments toward poverty reduction in low-and lower middle-income countries
JP2011209769A (ja) 会計支援装置、会計支援プログラムおよび会計支援方法
US20210217527A1 (en) Systems and methods for providing accurate patient data corresponding with progression milestones for providing treatment options and outcome tracking
US20200294170A1 (en) Information setting apparatus and information setting method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14890135

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14890135

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP