WO2018163265A1 - 保険金請求支援システムおよび保険金請求支援方法 - Google Patents

保険金請求支援システムおよび保険金請求支援方法 Download PDF

Info

Publication number
WO2018163265A1
WO2018163265A1 PCT/JP2017/008894 JP2017008894W WO2018163265A1 WO 2018163265 A1 WO2018163265 A1 WO 2018163265A1 JP 2017008894 W JP2017008894 W JP 2017008894W WO 2018163265 A1 WO2018163265 A1 WO 2018163265A1
Authority
WO
WIPO (PCT)
Prior art keywords
insurance
information
medical
medical information
predetermined
Prior art date
Application number
PCT/JP2017/008894
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/JP2017/008894 priority Critical patent/WO2018163265A1/ja
Priority to JP2019504156A priority patent/JP6805327B2/ja
Publication of WO2018163265A1 publication Critical patent/WO2018163265A1/ja

Links

Images

Classifications

    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance

Definitions

  • the present invention relates to an insurance claim support system and an insurance claim support method.
  • each contractor of the above-mentioned medical insurance accurately grasps the contents of the insurance contract. For this reason, even if an incident corresponding to an insurance payment reason occurs, the contractor is not even aware that this is the trigger for the insurance payment request, and the omission of the insurance payment can easily occur. Alternatively, even if the contractor is aware of the contents of the contract, there are cases in which various procedures such as contacting an insurance company are troublesome and neglected to make a payment request by one's own intention.
  • a step of receiving medical record information including information of a patient, medical institution information, and medical treatment / treatment content from a health insurance association server, and the received medical record information include A step of determining whether or not the medical insurance contract contents for the medical examinee is applicable, and when the determination is made, the procedure shifts to a procedure for payment of medical benefits based on the medical insurance contract.
  • a medical benefit payment service method (see Patent Document 1) characterized by the above has been proposed.
  • the information used to determine whether or not to make a payment request as described above varies depending on the circumstances of the contractors and the circumstances, or depending on the information management policy of the hospital or health insurance association.
  • various information including the above-described medical record information tends to be an enormous amount of data for the entire insured.
  • an object of the present invention is to provide a technology that can appropriately process information from various channels and support efficient and accurate claim payment.
  • the insurance claim support system of the present invention that solves the above-described problems is a communication device that communicates with one or more predetermined devices on a network, and medical information relating to an insured person of a predetermined insurance is received from the predetermined device and stored.
  • a process of storing in the apparatus and selecting the stored medical information having a predetermined attribute by a predetermined algorithm, and processing of the selected medical information by an insurance company with which the insurance contractor has an insurance contract And a processing unit that executes processing to be transmitted to the apparatus.
  • an information processing system including a communication device that communicates with one or more predetermined devices on a network receives medical information about an insured person of a predetermined insurance from the predetermined device.
  • An insurance company that the policyholder of the insurance contracts with the process of selecting a predetermined attribute of the stored medical care information with a predetermined algorithm, and storing the selected medical care information. And transmitting to the information processing apparatus.
  • FIG. 1 is a diagram showing a network configuration example including an insurance claim support system 100 of the present embodiment.
  • the insurance claim support system 100 shown in FIG. 1 is a computer system for appropriately supporting information from various channels to enable efficient and accurate support for claim payment.
  • the insurance claim support system 100 is connected to the network 10 and is capable of data communication with the user terminal 200, the insurance company system 300, the health insurance system 400, and the hospital system 500.
  • the user terminal 200 is a terminal of an insurance contractor who has contracted for a medical insurance of an insurance company (including various insurance concepts including death protection in the contract contents).
  • the user terminal 200 may be a smartphone, a tablet terminal having a communication function, a PC, or the like, but is not limited thereto.
  • the insurance company system 300 is a system operated by the above-described insurance company, and determines whether to approve an insurance claim for the medical information based on the medical information transmitted from the insurance claim support system 100 ( This is a device that returns the determination result to the insurance claim support system 100 (including the concept of acquiring the determination result by the person in charge).
  • the insurance company system 300 can be a server device, but is not limited thereto.
  • the health insurance system 400 is a system of a health insurance association to which the above-mentioned policyholders and insured persons belong, and is a computer system that provides medical information such as a receipt to the insurance claim support system 100.
  • the health insurance system 400 can be a server device, but is not limited thereto.
  • the hospital system 500 is a system of a medical institution where the insured person receives medical treatment, and is a computer system that provides medical claim information such as a receipt and an electronic medical record to the insurance claim support system 100.
  • a server device can be assumed as the hospital system 500, but is not limited thereto.
  • the hardware configuration of the insurance claim support system 100 is as follows.
  • the insurance claim support system 100 includes a storage device 101 composed of an appropriate nonvolatile storage element such as a hard disk drive, a memory 103 composed of a volatile storage element such as a RAM, and a program 102 held in the storage device 101.
  • a storage device 101 composed of an appropriate nonvolatile storage element such as a hard disk drive
  • a memory 103 composed of a volatile storage element such as a RAM
  • a program 102 held in the storage device 101 are connected to an arithmetic unit 104 such as a CPU that performs various determinations, computations and control processes, and is connected to the network 10 to perform overall control of the system itself, and the user terminal 200, the insurance company system 300, the health insurance system 400,
  • a communication device 105 that performs communication processing with other devices such as the hospital system 500.
  • the storage device 101 described above includes a filtering master table 125, a payment filter table 126, an exclusion filter table 127, a user master table 128, a contract content master table 129, an insured master table 130, and A medical history table 131 is stored. Details of these tables will be described later.
  • FIG. 3 shows an example of the filtering master table 125 in this embodiment.
  • the filtering master table 125 is a table that defines a filtering method for medical information for each insurance product of each insurance company.
  • This filtering method is an object that the insurance claim support system 100 transmits to the insurance company system 300 in order to obtain an approval decision for claim payment from medical information for a predetermined period stored in the storage device 101. It corresponds to the method of selecting.
  • the data structure consists of data such as an insurance company that sells the insurance product, a product name / special name of the insurance product, and a filter method, using the insurance product ID that uniquely identifies the insurance, that is, the insurance product as a key.
  • a collection of records as a specific example of the filter method, a white list method and a black list method are assumed.
  • the whitelist method is a method of selecting medical care information including information on injury or illness or medical practice corresponding to the insurance payment reason, by comparing with the insurance payment reason information prescribed by the insurance company for each insurance product. .
  • the detailed contents of this white list method are defined in a payment filter table 126 described later.
  • the blacklist method information on injury / illness / medical practice that does not correspond to the reason for payment of insurance claims is checked against information on injury / illness / medical practice that does not correspond to the reason for payment of insurance specified by insurance companies. This is a method for selecting medical information that is not included.
  • the detailed contents of this black list method are defined in the exclusion filter table 127.
  • FIG. 4A is a diagram showing a configuration example of the payment filter table 126 in the present embodiment.
  • This payment filter table 126 is a table that stores insurance payment reasons for insurance products for which the above-described white list method is prescribed.
  • the data structure is a collection of records consisting of data such as the insurance company that sells the insurance product, the product name / special name of the insurance product, and the reason for payment, using the insurance product ID that uniquely identifies the insurance product as a key. It is.
  • FIG. 4B is a diagram illustrating a configuration example of the exclusion filter table 127 in the present embodiment.
  • This exclusion filter table 127 is a table that stores insurance payment exclusion reasons for insurance products for which the above-described blacklist method is defined.
  • the data structure is a record consisting of data such as the insurance company that uniquely identifies the insurance product, the insurance company that sells the insurance product, the product name / special name of the insurance product, and the reason for exemption from payment. It is an aggregate.
  • FIG. 5A is a diagram showing a configuration example of the user master table 128 in the present embodiment.
  • This user master table 128 is a table storing information on policyholders.
  • the data structure is a collection of records composed of data such as a contractor name and a security number of the insurance product, with a policyholder ID uniquely identifying the policyholder, that is, a policyholder of the insurance product as a key.
  • a plurality of securities numbers can be included in one record.
  • FIG. 5B is a diagram showing a configuration example of the contract content master table 129 in the present embodiment.
  • the contract content master table 129 is a table that stores the contract content corresponding to the security number stored in the user master table 125 described above.
  • the data structure includes the insurance number stored in the above-described user master table 125 as a key, the insurance product ID of the insurance product, the insured ID that uniquely identifies the insured person, and the beneficiary of the insurance money.
  • This is a collection of records consisting of data such as.
  • FIG. 5C is a diagram showing a configuration example of the insured master table 130 in the present embodiment.
  • the insured person master table 130 is a table that stores information on the insured person whose ID is stored in the contract content master table 129 described above.
  • the data structure is a collection of records composed of data such as the insured person's name and health insurance card number using the insured person ID stored in the above-described contract content master table 129 as a key.
  • FIG. 6 is a diagram showing a configuration example of the medical history table 131 in the present embodiment.
  • the medical history table 131 is a table that stores medical information transmitted from each channel such as the user terminal 200, the health insurance system 400, and the hospital system 500.
  • the data structure is based on the health insurance card number of the insured included in the medical information, the name, the date and time when the insured received medical care, the detection category (the type of channel that received the medical information), the medical care From the data such as the name of the medical institution, the name of the injured subject, the medical treatment category (going to hospital / hospital), the amount paid for the medical treatment counter, the non-insurance medical treatment flag, the diagnosis unconfirmed flag, the filter processing flag, and the duplicate deletion flag Is a collection of records.
  • the non-insurance medical treatment flag is a flag to be given to medical information related to non-insurance medical treatment among the medical treatment information.
  • diagnosis unconfirmed flag corresponds to a flag to be given to the medical information related to the diagnosis content that has not been confirmed in the medical information.
  • the medical information to which the diagnosis unconfirmed flag is assigned is excluded from the transmission target to the insurance company system 300.
  • the filter processing flag stores all insurance products (information in the contract content master table 129) in which the insured person indicated by the medical information in the medical care information (the medical record history table record) is defined in the contract content. Is a flag given to those for which a payment request determination (FIG. 7A: s111), which will be described later, has been completed.
  • the duplicate deletion flag indicates that the same medical opportunity (that is, medical date and time, medical institution name, injury / illness name) of the same insured person (that is, the same health insurance card number) in the medical information (records of the medical history table). If there is a plurality of pieces of medical information relating to the same medical classification), that is, overlapping, it is given to the medical information other than the single medical information selected according to a predetermined priority among the plurality of overlapping medical information.
  • FIG. 7A is a diagram showing a flow example 1 of the insurance claim support method in the present embodiment.
  • the insurance claim support system 100 accepts, as a pre-process, registration of a payment reason for an insurance product from an appropriate information processing apparatus (hereinafter referred to as the insurance company system 300) such as the insurance company system 300 (s100). ).
  • the insurance company system 300 an appropriate information processing apparatus
  • the insurance company system 300 such as the insurance company system 300 (s100).
  • the insurance claim support system 100 should filter, for example, the medical information of the insured person of each insurance product. For example, an interface such as a screen for asking an insurance company is transmitted to the insurance company system 300 (s1001).
  • the above-mentioned interface is a screen that asks an insurance company whether it is a white list method or a black list method, for example.
  • the filtering method desired by the insurance company regarding medical information related to a certain insurance product is the white list method
  • the payment filter table 126 is required for the insurance product.
  • the exclusion filter table 127 is required for the insurance product.
  • the above-mentioned person in charge of the insurance company confirms the above-mentioned screen etc. in the insurance company system 300, and selects a filtering method to be applied regarding the medical information related to each insurance product of the company. At this time, the insurance company system 300 acquires the value of the selection and returns it to the insurance claim support system 100.
  • the insurance claim support system 100 receives the value of the filtering method described above from the insurance company system 300 (s1002), generates a record in which the value is linked to the insurance product and the insurance company, and stores it in the filtering master table 125. Store (s1003).
  • the insurance claim support system 100 acquires information on the filtering method indicated by the reply from the insurance company system 300 (s1004).
  • the insurance claim support system 100 accepts the insurance company system 300 to register the reason for payment of the insurance money.
  • a screen is transmitted and payment reason data is received from the insurance company system 300 (s1006).
  • the insurance claim support system 100 generates a record by associating the received payment reason data with the corresponding insurance product, and stores it in the payment filter table 126 (s1007).
  • the insurance claim support system 100 determines that the insurance company system 300 is to pay the insurance money.
  • the registration data for the reason data such as the name of the injured disease and the like, that is, the exclusion reason data is transmitted and the exclusion reason data is received from the insurance company system 300 (s1008).
  • the insurance claim support system 100 generates a record by associating the received exclusion reason data with the corresponding insurance product, and stores it in the exclusion filter table 127 (s1009).
  • the insurance claim support system 100 accepts user registration from a user who wants to receive insurance claim support, that is, an insurance contractor (s101).
  • the policyholder downloads and installs a predetermined application from the insurance claim support system 100 to the user terminal 200 at the time of the above user registration (of course, not limited to this form).
  • the policyholder enters information such as his / her name, contracted insurance company and insurance product, its security number, insured name, and health insurance card number on the interface of the app.
  • the application that has received the information input uploads the input information to the insurance claim support system 100 via the user terminal 200 and the network 10. Subsequently, the insurance claim support system 100 determines whether there is a problem such as a deficiency in the contents of the user registration received in s101 (s102).
  • an input omission of a predetermined item is specified, or it is found that the policy number input by the policyholder does not exist (inquiries to the insurance company system 300).
  • the insurance claim support system 100 notifies the user terminal 200 of the corresponding user that the user registration is not possible (s104), and the process is temporarily terminated.
  • the insurance claim support system 100 appropriately extracts the value of each item included in the contents of the user registration received in s101, and the user Each record of the master table 128, the contract content master table 129, and the insured master table 130 is generated and registered (s105).
  • the insurance claim support system 100 provides the medical information about the insured persons of the policyholders who have been registered as described above to the user terminal 200, the health insurance system 400, and the hospital system 500 corresponding to each channel.
  • the information is received from at least one of them and stored in the medical history table 131 of the storage device 101 (s106). There may be both cases where the policyholder and the insured are the same, and cases where the policyholder and the insured are different.
  • Medical information to be acquired and registered here includes medical expenses notifications delivered monthly from health insurance to each insurance policyholder, receipts linked to data from health insurance or payment funds, electronic medical records and receipts linked to data from medical institutions, For example, the receipt information obtained from the medical institution by the insured for each medical opportunity can be assumed.
  • receipt information a case where an insurance contractor who has obtained a receipt received by an insured at a medical institution obtains a manual input by operating the user terminal 200, or Both cases where the camera function of the user terminal 200 and an OCR application or the like are appropriately used to acquire a scanned image can be assumed.
  • the insurance claim support system 100 that has received the predetermined request from the user terminal 200 returns the input screens 1000 and 1010 illustrated in FIG. 8A or 8B to the user terminal 200 of the policyholder.
  • the policyholder performs an operation of inputting medical information on any of the input screens 1000 and 1010 while referring to the above-mentioned receipt issued from a medical institution such as a hospital.
  • a medical institution such as a hospital.
  • the insurance contractor uses the input screen 1000
  • the above receipt is taken by the camera of the user terminal 200
  • medical information is read by an appropriate OCR application.
  • the user terminal 200 acquires values such as the date and time of medical treatment and the name of the medical institution as medical information, and transmits them to the insurance claim support system 100.
  • the user terminal 200 acquires values such as the date and time of medical treatment, the medical treatment classification, and the name of the wound as medical information, and transmits this to the insurance claim support system 100.
  • the insurance claim support system 100 specifies medical information based on the medical cost notification, and displays a predetermined interface (screen 1020 in FIG. 8C) for receiving an input of the name of the sick / sickness regarding the medical information as a user terminal of the corresponding policyholder. 200 to receive information on the name of the wound. In this case, the insurance claim support system 100 sets the received information on the name of the disease in the above-described medical information column.
  • the data of the receipt, the electronic medical record, and the receipt computer contain detailed information, and measures for supplementing the deficient data are basically unnecessary.
  • a predetermined process is required when it includes a description of a wound or illness whose diagnosis has not been confirmed, such as a so-called “recept disease name” or “suspected disease name”.
  • the insurance claim support system 100 shall give a diagnosis unconfirmed flag “1” to the corresponding medical treatment information.
  • the medical information to which the diagnosis unconfirmed flag is assigned can be excluded from the transmission target to the insurance company system 300 in s111 to be described later, that is, can be excluded from the approval judgment of whether or not the insurance payment can be made.
  • the insurance claim support system 100 performs a pre-filtering process of selecting the predetermined attribute among the medical information stored in the medical history table 131 in step s106 (s107).
  • the insurance claim support system 100 in this case, as shown in the flow of FIG. 7C, among the records of the medical history table 131, that is, the medical information, the same insured person (the person with the same health insurance card number). ), There are multiple pieces of medical information related to the same medical opportunity (medical date and time, medical institution name, injury / illness name, and medical examination category). Is selected based on a predetermined priority order (s1071).
  • the value of “detection category” of medical information is “receipt”> “direct hospital” (electronic medical record data, etc.)> Manual (insurance policyholder manually input from user terminal 200)
  • the order can be assumed, but of course it is not limited to this.
  • the insurance claim support system 100 assigns a duplicate deletion flag “1” to items other than one piece of medical information in the medical history table 131 selected in s1071, that is, medical information not selected in s1071. (S1072).
  • the insurance claim support system 100 assigns a non-insurance medical treatment flag “1” to the medical care information (s1074).
  • the insurance claim support system 100 is selected from the above-described pre-filtering (s107), and is a medical insurance card from the medical information that is not assigned the duplicate deletion flag and is not assigned the diagnosis unconfirmed flag.
  • Each value of the number, the name of the disease, and the examination category is extracted (s108).
  • the insurance claim support system 100 specifies the insured person ID by collating the health insurance card number, for example, of the values obtained in s108 with the insured person master table 130, and uses the insured person ID as a key.
  • the insurance product ID is specified in the contract content master table 129 (s109).
  • the insurance product ID that can be specified here corresponds to the number of records in which the corresponding insured person ID is defined in the “insured person ID” column of the contract content master table 129, and there is one case or plural cases. is there.
  • the insurance claim support system 100 uses the filtering master table 125 as a key to filter out the corresponding insurance product using a predetermined one (eg, the first specified) among the one or more insurance product IDs specified in s109. Is specified (s110).
  • the insurance claim support system 100 acquires information on the payment reason or the exclusion reason from the payment filter table 126 or the exclusion filter table 127 based on the insurance product and the filter method specified in s110, and based on this information, Regarding medical information, it is determined whether or not a payment request (to an insurance company) can be made (s111).
  • the insurance claim support system 100 executes the above-described processes of s110 and s111 by the number of insurance product IDs identified by s109, that is, the number of insurance contracts applied to the insured (s112). : N-> s110-> s112-> s112: y), the filter processing flag is set in the medical history table 131 for the medical information for which the processing of s110 and s111 has been executed for all insurance contracts.
  • the insurance claim support system 100 in s111 collates each value obtained in s108 regarding the corresponding medical information with the information on the payment reason related to the corresponding insurance product in the payment filter table 126. Then, it is determined whether or not it corresponds to an injury or illness or medical practice corresponding to the payment reason.
  • the insurance claim support system 100 checks each value obtained in s108 regarding the corresponding medical information with the information on the exclusion reason regarding the corresponding insurance product in the exclusion filter table 127, and It is determined whether or not the medical information corresponds to the reason for exclusion.
  • the insurance claim support system 100 indicates that the relevant medical information cannot be a claim for insurance payment. Is returned to the user terminal 200 of the policyholder (s114), and the process is terminated.
  • the insurance claim support system 100 can claim the insurance money regarding the relevant medical information and actually makes the payment.
  • a notification as to whether or not is transmitted to the user terminal 200 of the policyholder (s115).
  • the insurance claim support system 100 when transmitting the notification at s115 described above, sends to at least one of the terminal of the insurance recipient or the insured person indicated by the record of the insurance contract in the contract content master table 129.
  • the notification may be transmitted.
  • the insurance claim support system 100 ends the process.
  • the insurance claim support system 100 sells the insurance product as a request for approval of the payment request including the medical information. It transmits to the insurance company system 300 of the insurance company that performs (s117).
  • a predetermined person or the like or a predetermined business system executes a determination process to determine whether or not the insurance payment can be made.
  • the determination result is returned from the insurance company system 300 to the insurance claim support system 100.
  • the insurance claim support system 100 receives from the insurance company system 300 the determination result of approval or non-approval of the claim payment based on the above-described medical information (s118).
  • the insurance claim support system 100 sends a rejection report (see screen 1040 in FIG. 10A) to the user terminal 200 of the corresponding policyholder. Distribute (s120), and the process ends.
  • the insurance claim support system 100 notifies that this confirmation procedure is necessary. Is transmitted to the user terminal 200 of the corresponding insurance policyholder (s121), and the process is once returned to S118.
  • the insurance claim support system 100 displays the result of the approval of the insurance payment (see the screen 1050 in FIG. 10B). It transmits to the user terminal 200 of the corresponding insurance policyholder (s122), and the process is terminated.
  • the policyholder does not need to make a declaration by the policyholder himself regarding the hospital visit / treatment of the insured subject to the contract, as well as proactive insurance payments and avoidance of cramping Is possible. Accordingly, omission of insurance claims is prevented appropriately. It also simplifies troublesome procedures related to payment requests such as “send a medical certificate and act as an insurance policyholder to an insurance company”. On the other hand, insurance companies can effectively reduce non-payment events. This is expected to provide an excellent customer experience for policyholders and increase the corporate value associated therewith. In addition, when making a payment request, an opportunity for the sales staff to contact the customer (the policyholder) is created.
  • the computing device sends a notification to the contractor's terminal that a claim for insurance payment is possible based on the selected medical information of the predetermined attribute.
  • the medical information may be transmitted to the information processing apparatus of the insurance company when the request for payment is received from the terminal.
  • the computing device identifies an insurance beneficiary or insured person based on the content information of the insurance contract held in advance in a storage device when the notification is transmitted.
  • the notification may be transmitted to at least one of the contractor, the insurance beneficiary, and the insured.
  • the arithmetic device selects the medical information with the predetermined attribute, the medical information regarding the same medical opportunity of the same insured person among the stored medical information.
  • one medical information may be selected from the plurality of medical information by a predetermined algorithm.
  • the arithmetic device uses the plurality of medical information based on a predetermined priority order between different types of medical information. One piece of medical information may be selected.
  • the arithmetic unit pays the stored insurance information with respect to the insurance. It is good also as what selects the medical treatment information which collates with the information on a reason, and contains the information of the sickness or medical treatment act corresponding to the said insurance payment reason.
  • the arithmetic unit pays the stored insurance information with respect to the insurance. It is good also as what checks against the information of the sickness or medical practice which does not correspond to a reason, and selects the medical information which does not include the information of the sickness or medical practice which does not correspond to the said insurance payment reason.
  • the arithmetic unit when there is medical information related to unconfirmed diagnostic contents in the received medical information, the arithmetic unit adds a diagnosis unconfirmed flag to the medical information. And it is good also as what further performs the process excluded from the transmission object to the information processing apparatus of the said insurance company.
  • medical information including a description about a wound or illness whose diagnosis has not yet been confirmed, such as a so-called “receipt disease name” or “suspected disease name” in the receipt, is identified and excluded from the transmission target to the insurance company, that is, insurance. It can be excluded from the judgment of approval of money payment.
  • the arithmetic device when there is medical information related to non-insurance medical care among the received medical information, the arithmetic device gives a non-insurance medical flag to the medical information, It is good also as what is transmitted to the information processing apparatus of the said insurance company.
  • the arithmetic device specifies a predetermined interface that identifies the received medical information that does not include the name of the sick and sick, and receives an input of the name of the sick and sick regarding the medical information. , Receiving information on the name of the wound and disease transmitted to the contractor's terminal, and adding the received information on the name of the disease and sickness to the medical information, and then subject to selection processing by the predetermined algorithm. It is good.
  • the arithmetic device transmits the medical care information to the information processing device of the insurance company
  • the calculation result of the approval / disapproval of the insurance claim based on the medical information is displayed. Further, a process of receiving from the information processing apparatus and transmitting the received determination result to the contractor's terminal may be further executed.
  • the information processing system sends a notification to the terminal of the contractor that the insurance claim can be claimed based on the selected medical information of the predetermined attribute.
  • the medical information may be transmitted to the information processing apparatus of the insurance company when the terminal receives the request for performing the payment request from the terminal.
  • the information processing system specifies an insurance beneficiary or an insured person based on content information of the insurance contract held in a storage device in advance when the notification is transmitted.
  • the notification may be transmitted to at least one of the contractor, the insurance beneficiary, and the insured.
  • the information processing system selects the medical information having the predetermined attribute, the medical information regarding the same medical opportunity of the same insured person is included in the stored medical information.
  • one piece of medical information may be selected from the plurality of pieces of medical information using a predetermined algorithm.
  • the information processing system selects the one piece of medical information
  • the information processing system selects 1 from the plurality of pieces of medical information based on a predetermined priority order between different types of medical information.
  • One piece of medical information may be selected.
  • the information processing system selects the medical information of the predetermined attribute
  • the stored medical information is used for the insurance payment reason that the insurance company provides for the insurance.
  • the medical information including information on the wound or illness or medical practice corresponding to the insurance payment reason may be selected.
  • the stored medical information is used for the insurance payment reason that the insurance company provides for the insurance. It is good also as collating with the information of the sickness and medical practice which does not correspond to, and selecting the medical information which does not contain the information of the sickness and medical practice which does not correspond to the said insurance payment reason.
  • a diagnostic unconfirmed flag is assigned to the medical information. Then, it is also possible to further execute a process of excluding from the transmission target to the information processing apparatus of the insurance company.
  • the information processing system when there is medical information related to non-insurance medical care among the medical information of the selected predetermined attribute, the information processing system adds an out-of-insurance medical flag to the medical information. Then, it may be transmitted to the information processing apparatus of the insurance company.
  • the information processing system identifies a received medical information that does not include the name of the sick and sick, and a predetermined interface that receives an input of the name of the sick and sick with respect to the medical information,
  • the information may be transmitted to the contractor's terminal to receive information on the name of the sick and sick, and the information on the name of the sick and sick may be added to the medical information, and may be selected by the predetermined algorithm.
  • the information processing system transmits the medical care information to the information processing device of the insurance company
  • a determination result of approval or non-approval of the insurance claim based on the medical information is obtained.
  • a process of receiving from the information processing apparatus and transmitting the received determination result to the contractor's terminal may be further executed.
  • Network 100 Insurance Claim Support System 101 Storage Device 102 Program 103 Memory 104 CPU (Calculation Device) 105 Communication Device 125 Filtering Master Table 126 Payment Filter Table 127 Exclusion Filter Table 128 User Master Table 129 Contract Content Master Table 130 Insured Person Master Table 131 Medical History Table 200 User Terminal 300 Insurance Company System 400 Health Insurance System 500 Hospital System

Abstract

【課題】種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援を可能とする。 【解決手段】保険金請求支援システム１００において、ネットワーク上の１または複数の所定装置と通信する通信装置１０５と、所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置１０１に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置３００に送信する処理と、を実行する演算装置１０４を含む構成とする。

Description

保険金請求支援システムおよび保険金請求支援方法
　本発明は、保険金請求支援システムおよび保険金請求支援方法に関する。
　年を追う毎に我が国の医療費は増大しており、将来的に公的保険制度の見直しも予想される。そうした状況下における各個人や団体は、民間の医療保険等を利用して、公的保険の対象外となる医療費を適宜にカバーする動きを強めている。
　一方、上述の医療保険等の各契約者は、当該保険の契約内容を正確に把握しているとは言い難い。そのため契約者は、保険金支払事由に該当するインシデントが発生しても、それが保険金支払請求の契機であるかすら意識せず、保険金の支払請求漏れが容易に起こりうる状態にある。或いは、その契約者が契約内容を認識していても、保険会社への連絡等の各種手続を面倒に感じ、自らの意思で支払請求を怠るケースも存在する。
　勿論、保険会社の側でも、保険金の支払漏れをなくす取り組みを進めているが、上述のインシデントの発生は契約者本人の申告によって認識しうるものであり、対策に限界がある。
　そこで、そうした問題に対処する従来技術として、例えば、健康保険組合のサーバから受診者情報、医療機関情報、診療・治療内容の情報を含む診療記録情報を受信するステップと、受信した診療記録情報が当該受診者を対象とする医療保険の契約内容と適合するか否かを判定するステップと、前記判定において適合すると判定されたとき、医療保険契約に基づく医療給付金支払いのための手続きに移行することを特徴とする医療給付金支払サービス方法（特許文献１参照）などが提案されている。
特開２００５－１００１６５号公報
　従来技術が示すように、診療記録情報に基づいて支払手続を適宜に進めることは有用である。ところが、保険金の支払請求の可否を判断しうる情報としては、診療記録情報の他にも様々な種類のものが存在する。例えば、健康保険組合から定期的に送付されてくる医療費通知、病院で作成されたレセプトや電子カルテ等のデータ、或いは、契約者或いは被保険者らが病院や薬局で受け取ったレシート、など複数ある。しかもこれらの情報は、その詳細さや所定項目の有無が、情報間で異なっているケースが多い上、提供時期も異なっている。
　従って、契約者らの都合や置かれた状況により、或いは、病院や健康保険組合等における情報管理ポリシーなどによって、上述した支払請求の可否判断に用いられる情報がまちまちになる。また、上述の診療記録情報も含めた各種情報は、被保険者全体では膨大なデータ量となりがちである。
　そのため、一人の被保険者の１回の受診行為に関してさえ複数の情報が集まりうる情報を、膨大な人数分収集し、それをそのまま支払請求の可否判断ロジックに提供するとすれば、全体として処理の速度や精度が大きく低下し、効率的で的確な支払請求の手続自体が困難となる恐れがある。
　そこで本発明の目的は、種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援を可能とする技術を提供することにある。
　上記課題を解決する本発明の保険金請求支援システムは、ネットワーク上の１または複数の所定装置と通信する通信装置と、所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置に送信する処理と、を実行する演算装置と、を含むことを特徴とする。
　また、本発明の保険金請求支援方法は、ネットワーク上の１または複数の所定装置と通信する通信装置を備えた情報処理システムが、所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置に送信する処理と、を実行することを特徴とする。
　本発明によれば、種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援が可能となる。
本実施形態における保険金請求支援システムを含むネットワーク構成図である。 本実施形態における保険金請求支援システムのハードウェア構成例を示す図である。 本実施形態におけるフィルタリングマスタテーブルの構成例を示す図である。 本実施形態における支払フィルタテーブルの構成例を示す図である。 本実施形態における除外フィルタテーブルの構成例を示す図である。 本実施形態におけるユーザマスタテーブルの構成例を示す図である。 本実施形態における契約内容マスタテーブルの構成例を示す図である。 本実施形態における被保険者マスタテーブルの構成例を示す図である。 本実施形態における診療履歴テーブルの構成例を示す図である。 本実施形態における保険金請求支援方法のフロー例１を示す図である。 本実施形態における保険金請求支援方法のフロー例２を示す図である。 本実施形態における保険金請求支援方法のフロー例３を示す図である。 本実施形態における画面例１を示す図である。 本実施形態における画面例２を示す図である。 本実施形態における画面例３を示す図である。 本実施形態における画面例４を示す図である。 本実施形態における画面例５を示す図である。 本実施形態における画面例６を示す図である。
－－－ネットワーク構成－－－
　以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態の保険金請求支援システム１００を含むネットワーク構成例を示す図である。図１に示す保険金請求支援システム１００は、種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援を可能とするためのコンピュータシステムである。
　こうした保険金請求支援システム１００はネットワーク１０に接続され、ユーザ端末２００、保険会社システム３００、健保システム４００、および、病院システム５００とデータ通信可能となっている。
　このうちユーザ端末２００は、保険会社の医療保険（死亡保障を契約内容に含む各種保険の概念含む）について契約している保険契約者の端末である。このユーザ端末２００としては、具体的には、スマートフォン、通信機能を備えたタブレット端末やＰＣ等を想定出来るが、これらに限定しない。
　また、保険会社システム３００は、上述の保険会社が運用するシステムであり、保険金請求支援システム１００から送信されてくる診療情報に基づき、当該診療情報に関する保険金支払請求を承認するか判断し（担当者による判断結果を取得する概念も含む）、その判断結果を保険金請求支援システム１００に返す装置である。この保険会社システム３００としては、具体的には、サーバ装置を想定出来るが、これに限定しない。
　また、健保システム４００は、上述の保険契約者や被保険者が所属する健康保険組合のシステムであり、レセプトなどの診療情報を保険金請求支援システム１００に提供するコンピュータシステムである。この健保システム４００としては、具体的には、サーバ装置を想定出来るが、これに限定しない。
　また、病院システム５００は、上述の被保険者が診療行為を受ける医療機関のシステムであり、レセプトや電子カルテ等の診療情報を保険金請求支援システム１００に提供するコンピュータシステムである。この病院システム５００としては、具体的には、サーバ装置を想定出来るが、これに限定しない。
－－－ハードウェア構成例－－－
　また、保険金請求支援システム１００のハードウェア構成は以下の如くとなる。保険金請求支援システム１００は、ハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行しシステム自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワーク１０と接続し、ユーザ端末２００、保険会社システム３００、健保システム４００、および病院システム５００といった他装置との通信処理を担う通信装置１０５を備える。
　なお、上述の記憶装置１０１には、プログラム２０２の他、フィルタリングマスタテーブル１２５、支払フィルタテーブル１２６、除外フィルタテーブル１２７、ユーザマスタテーブル１２８、契約内容マスタテーブル１２９、被保険者マスタテーブル１３０、および、診療履歴テーブル１３１が格納されている。これら各テーブルの詳細については後述する。
－－－データ構成例－－－
　続いて、本実施形態の保険金請求支援システム１００が用いるテーブル類について説明する。図３に、本実施形態におけるフィルタリングマスタテーブル１２５の一例を示す。　このフィルタリングマスタテーブル１２５は、各保険会社の保険商品ごとに、診療情報のフィルタリング方法を規定したテーブルである。このフィルタリング方法とは、保険金請求支援システム１００が、記憶装置１０１に蓄積している所定期間分の診療情報の中から、保険金支払請求の承認判断を求めるべく保険会社システム３００に送信する対象を選択する方法に該当する。
　そのデータ構造は、保険すなわち保険商品を一意に特定する保険商品ＩＤをキーとして、当該保険商品を販売している保険会社、当該保険商品の商品名・特約名、および、フィルタ方式といったデータから成るレコードの集合体である。このうち、フィルタ方式の具体例としては、ホワイトリスト方式とブラックリスト方式とを想定する。
　ホワイトリスト方式は、保険会社が各保険商品に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択する方式である。このホワイトリスト方式の詳細な内容は、後述する支払フィルタテーブル１２６にて規定されている。
　一方、ブラックリスト方式は、保険会社が各保険商品に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択する方式である。このブラックリスト方式の詳細な内容は、除外フィルタテーブル１２７にて規定されている。
　図４Ａは、本実施形態における支払フィルタテーブル１２６の構成例を示す図である。この支払フィルタテーブル１２６は、上述のホワイトリスト方式が規定された保険商品の保険金支払事由を格納したテーブルである。
　そのデータ構造は、保険商品を一意に特定する保険商品ＩＤをキーとして、当該保険商品を販売する保険会社、当該保険商品の商品名・特約名、および支払事由、といったデータから成るレコードの集合体である。
　図４Ｂは、本実施形態における除外フィルタテーブル１２７の構成例を示す図である。この除外フィルタテーブル１２７は、上述のブラックリスト方式が規定された保険商品の保険金の支払除外事由を格納したテーブルである。
　そのデータ構造は、保険商品を一意に特定する保険商品ＩＤをキーとして、当該保険商品を販売する保険会社、当該保険商品の商品名・特約名、および支払の除外事由、といったデータから成るレコードの集合体である。
　図５Ａは、本実施形態におけるユーザマスタテーブル１２８の構成例を示す図である。このユーザマスタテーブル１２８は、保険契約者の情報を格納したテーブルである。そのデータ構造は、保険契約者すなわち保険商品の契約者を一意に特定する契約者ＩＤをキーとして、契約者氏名、当該保険商品の証券番号といったデータから成るレコードの集合体である。なお、一人の保険契約者が複数の保険商品について契約を有する場合もあるため、１レコードにおいて複数の証券番号が含まれうる。
　図５Ｂは、本実施形態における契約内容マスタテーブル１２９の構成例を示す図である。この契約内容マスタテーブル１２９は、上述のユーザマスタテーブル１２５に格納されている証券番号に対応する契約内容を格納したテーブルである。
　そのデータ構造は、上述のユーザマスタテーブル１２５に格納されている証券番号をキーとして、該当保険商品の保険商品ＩＤ、被保険者を一意に特定する被保険者ＩＤ、および、保険金の受取人、といったデータから成るレコードの集合体である。
　図５Ｃは、本実施形態における被保険者マスタテーブル１３０の構成例を示す図である。この被保険者マスタテーブル１３０は、上述の契約内容マスタテーブル１２９にＩＤが格納されている被保険者に関する情報を格納したテーブルである。
　そのデータ構造は、上述の契約内容マスタテーブル１２９に格納されている被保険者ＩＤをキーとして、被保険者の氏名、および、健康保険証番号、といったデータから成るレコードの集合体である。
　図６は、本実施形態における診療履歴テーブル１３１の構成例を示す図である。この診療履歴テーブル１３１は、ユーザ端末２００，健保システム４００、および、病院システム５００といった各チャネルから送信されてきた診療情報を格納したテーブルである。
　そのデータ構造は、診療情報が含む、被保険者の健康保険証番号をキーに、氏名、当該被保険者が診療を受けた日時、検知区分（診療情報を受信したチャネルの種類）、診療を行った医療機関名、診療対象の傷病名、診療区分（通院／入院）、診療費の窓口支払額、保険外診療フラグ、診断未確定フラグ、フィルタ処理フラグ、および、重複削除フラグ、といったデータから成るレコードの集合体である。
　このうち、保険外診療フラグは、診療情報のうち、保険外診療に関する診療情報に付与するフラグである。
　また、診断未確定フラグは、診療情報のうち、確定していない診断内容に関する診療情報に付与するフラグに該当する。この診断未確定フラグが付与されている診療情報については、保険会社システム３００への送信対象から除外することとなる。
　また、フィルタ処理フラグは、診療情報（診療履歴テーブルのレコード）のうち、当該診療情報の示す被保険者が契約内容に規定された全ての保険商品（契約内容マスタテーブル１２９に情報が格納されている）に関して、後述する支払請求の可否判定（図７Ａ：ｓ１１１）が完了しているものに対し付与されるフラグである。
　一方、重複削除フラグは、診療情報（診療履歴テーブルのレコード）のうち、同一の被保険者（すなわち健康保険証番号が同一）の同一の診療機会（すなわち、診療日時、医療機関名、傷病名、および診療区分が同一）に関する診療情報が複数存在、すなわち重複している場合、重複している複数の診療情報のうち、所定の優先順位に従って選択した１つの診療情報以外の診療情報に付与される。
　上述の優先順位の例としては、検知区分が「レセプト」＞「病院直」（電子カルテデータ等）＞手動（保険契約者がユーザ端末２００から手動入力）、といった順を想定出来るが、勿論、これに限定しない。
－－－フロー例－－－
　以下、本実施形態における保険金請求支援方法の実際手順について図に基づき説明する。以下で説明する保険金請求支援方法に対応する各種動作は、保険金請求支援システム１００がメモリ１０３に読み出して実行するプログラムによって実現される。そして、これらのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
　図７Ａは、本実施形態における保険金請求支援方法のフロー例１を示す図である。まず、保険金請求支援システム１００は、事前処理として、保険会社システム３００など保険会社の適宜な情報処理装置（以降、保険会社システム３００とする）から、保険商品に関する支払事由の登録を受け付ける（ｓ１００）。
　なお、この支払事由の登録受付に際し、図7Ｂの詳細フローで示すように、保険金請求支援システム１００は、例えば、各保険商品の被保険者の診療情報をどのような方針でフィルタリングするべきか、について保険会社に問う画面等のインターフェイスを、例えば、保険会社システム３００に送信する（ｓ１００１）。
　上述のインターフェイスは、例えば、ホワイトリスト方式かブラックリスト方式かを保険会社に問う画面となる。保険会社が或る保険商品に係わる診療情報に関して希望するフィルタリングの方式が、ホワイトリスト方式の場合、当該保険商品に関して、支払フィルタテーブル１２６が必要となる。他方、保険会社が或る保険商品の診療情報に関して希望するフィルタリングの方式が、ブラックリスト方式の場合、当該保険商品に関して、除外フィルタテーブル１２７が必要となる。
　上述の保険会社の担当者等は、保険会社システム３００にて上述の画面等を確認し、自社の各保険商品に係わる診療情報に関して適用したいフィルタリングの方式を選択する。この時、保険会社システム３００は、当該選択の値を取得して保険金請求支援システム１００に返信する。
　保険金請求支援システム１００は、保険会社システム３００から上述のフィルタリングの方式の値を受信し（ｓ１００２）、これを、該当保険商品および保険会社と紐付けたレコードを生成し、フィルタリングマスタテーブル１２５に格納する（ｓ１００３）。
　次に、保険金請求支援システム１００は、保険会社システム３００からの返信が示すフィルタリングの方式に関する情報を取得する（ｓ１００４）。
　上述で得たフィルタリングの方式に関する情報が、ホワイトリスト方式を示すものであった場合（ｓ１００５：ｗ）、保険金請求支援システム１００は、保険会社システム３００に対し、保険金の支払事由の登録受付画面を送信し、当該保険会社システム３００から支払事由データを受信する（ｓ１００６）。保険金請求支援システム１００は、受信した支払事由データを、該当保険商品と紐付けてレコードを生成し、これを支払フィルタテーブル１２６に格納する（ｓ１００７）。
　他方、上述で得たフィルタリングの方式に関する情報が、ブラックリスト方式を示すものであった場合（ｓ１００５：ｂ）、保険金請求支援システム１００は、保険会社システム３００に対し、保険金の支払対象とならない傷病名等の事由データ、すなわち除外事由データの登録受付画面を送信し、当該保険会社システム３００から除外事由データを受信する（ｓ１００８）。保険金請求支援システム１００は、受信した除外事由データを、該当保険商品と紐付けてレコードを生成し、これを除外フィルタテーブル１２７に格納する（ｓ１００９）。
　ここで図７Ａのメインフローの説明に戻る。保険金請求支援システム１００は、上述のステップｓ１００に続いて、保険金の支払請求支援を受けたいユーザ、すなわち保険契約者からのユーザ登録を受け付ける（ｓ１０１）。
　この場合の保険契約者は、上述のユーザ登録に際して、保険金請求支援システム１００から所定アプリをユーザ端末２００にダウンロードおよびインストールしている（勿論、この形態に限定しない）。保険契約者は、このアプリのインターフェイス上で、自身の氏名、契約中の保険会社および保険商品、その証券番号、被保険者名、健康保険証番号といった情報を入力することとなる。情報入力を受けたアプリは、ユーザ端末２００およびネットワーク１０を介し、入力情報を保険金請求支援システム１００にアップロードする。　続いて、保険金請求支援システム１００は、ｓ１０１で受け付けたユーザ登録の内容について不備等の問題有無を判定する（ｓ１０２）。
　この判定の結果、例えば所定項目の入力漏れが特定されたり、或いは、保険契約者が入力した証券番号は存在しないものであることが（保険会社システム３００に問い合わせて）判明するといった結果となった場合（ｓ１０３：ｎ）、保険金請求支援システム１００は、ユーザ登録不可である旨を該当ユーザのユーザ端末２００に通知し（ｓ１０４）、一旦処理を終了する。
　他方、上述の判定の結果、問題が特定されなかった場合（ｓ１０３：ｙ）、保険金請求支援システム１００は、ｓ１０１で受け付けたユーザ登録の内容が含む各項目の値を適宜に抽出し、ユーザマスタテーブル１２８、契約内容マスタテーブル１２９、および被保険者マスタテーブル１３０の各レコードを生成し、登録する（ｓ１０５）。
　その後、保険金請求支援システム１００は、上述のユーザ登録がなされた保険契約者の被保険者に関して、その診療情報を、各チャネルに対応する、ユーザ端末２００、健保システム４００、および病院システム５００の少なくともいずれかから受信し、これを記憶装置１０１の診療履歴テーブル１３１に格納する（ｓ１０６）。なお、保険契約者と被保険者が同一である場合と、保険契約者と被保険者が異なる場合の両方ありうる。
　ここで取得して登録する診療情報としては、健保から保険契約者ごとに毎月配信される医療費通知、健保ないし支払基金からデータ連携されたレセプト、医療機関からデータ連携された電子カルテやレセコン、および、被保険者が診療機会ごとに医療機関から得たレシート情報、といったものが例として想定出来る。
　なお、上述の診療情報のうち、レシート情報に関しては、医療機関で被保険者が受け取ったレシートを得た保険契約者がユーザ端末２００を操作して手動入力してきたものを取得するケースか、或いは、ユーザ端末２００のカメラ機能およびＯＣＲアプリ等を適宜利用してスキャンしたものを取得するケースの両方が想定出来る。
　このように、保険契約者がユーザ端末２００を操作して診療情報を保険金請求支援システム１００に登録することを望む場合がある。その場合、ユーザ端末２００からの所定リクエストを受けた保険金請求支援システム１００は、図８Ａまたは図８Ｂに例示する入力画面１０００、１０１０を、当該保険契約者のユーザ端末２００に返す。
　保険契約者は、例えば病院等の医療機関から発行された上述のレシートを参考にしつつ、いずれかの入力画面１０００、１０１０において、診療情報の入力動作を行うことになる。当該保険契約者が入力画面１０００を利用する場合、上述のレシートをユーザ端末２００のカメラで撮影し、適宜なＯＣＲアプリによって、診療情報の読み取りを実行する。その結果、ユーザ端末２００は、診療日時、医療機関名、といった値を診療情報として取得し、これを保険金請求支援システム１００に送信することとなる。
　一方、上述の保険契約者が入力画面１０１０を利用する場合、上述のレシートを参照しつつ、診療情報の手入力あるいは選択動作を実行する。その結果、ユーザ端末２００は、診療日時、診療区分、傷病名、といった値を診療情報として取得し、これを保険金請求支援システム１００に送信することとなる。
　また、上述の診療情報のうち、医療費通知に関しては、健保システム４００からデータ連携を受けて、電子データとして取得出来るケースと、医療費通知の内容を閲覧した保険契約者がユーザ端末２００を操作して手動入力してきたものを取得するケースの両方が想定出来る。
　また、上述のように診療情報が医療費通知である場合、それには傷病名のデータが含まれていない。よって、保険金請求支援システム１００は、この医療費通知に基づく診療情報を特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイス（図８Ｃの画面１０２０）を、該当保険契約者のユーザ端末２００に送信して傷病名の情報入力を受け付ける。この場合の保険金請求支援システム１００は、当該受け付けた傷病名の情報を、上述の診療情報における傷病名欄に設定することとなる。
　一方、上述の診療情報のうちレセプトや電子カルテやレセコンのデータは、詳細な情報が含まれており、不足データを補う措置等は基本的に不要である。ただし、レセプトに関しては、いわゆる「レセプト病名」、「疑い病名」といった、診断が未確定の傷病等に関する記載を含む場合に所定の処理が必要となる。
　この場合、保険金請求支援システム１００は、該当診療情報に対して診断未確定フラグ「１」を付与するものとする。この診断未確定フラグが付与された診療情報は、後述するｓ１１１での保険会社システム３００への送信対象から除外、すなわち保険金支払可否の承認判断の対象外とすることができる。
　続いて、保険金請求支援システム１００は、ステップｓ１０６で診療履歴テーブル１３１に格納した診療情報のうち、所定属性のものを選択する事前フィルタリング処理を行う（ｓ１０７）。
　この場合の保険金請求支援システム１００は、このフィルタリング処理に際し、図７Ｃのフローのごとく、診療履歴テーブル１３１の各レコードすなわち診療情報のうち、同一の被保険者（同一の健康保険証番号の者）の同一の診療機会（診療日時、医療機関名、傷病名、診察区分が同一）に関する診療情報が複数存在する場合、当該複数の診療情報から１つの診療情報を、種類の異なる診療情報の間について予め定めた優先順位に基づき選択する（ｓ１０７１）。
　具体的な優先順位の例としては、診療情報の「検知区分」の値が「レセプト」＞「病院直」（電子カルテデータ等）＞手動（保険契約者がユーザ端末２００から手動入力）、といった順を想定出来るが、勿論、これに限定しない。
　保険金請求支援システム１００は、このｓ１０７１で選択した、診療履歴テーブル１３１の１つの診療情報以外のもの、すなわち、ｓ１０７１で選択されなかった診療情報に対して、重複削除フラグ「１」を付与する（ｓ１０７２）。
　また、保険金請求支援システム１００は、上述のｓ１０７１で選択した診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグ「１」を付与する（ｓ１０７４）。
　ここで図７Ａのフローの説明に戻る。保険金請求支援システム１００は、上述の事前フィルタリング（ｓ１０７）で選択され、重複削除フラグが付与されていない診療情報であり、かつ、診断未確定フラグが付与されていない診療情報から、健康保険証番号、傷病名、および、診察区分の各値を抽出する（ｓ１０８）。
　次に保険金請求支援システム１００は、ｓ１０８で得た値のうち、例えば健康保険証番号を、被保険者マスタテーブル１３０に照合して被保険者ＩＤを特定し、この被保険者ＩＤをキーに契約内容マスタテーブル１２９にて保険商品ＩＤを特定する（ｓ１０９）。なお、ここで特定出来る保険商品ＩＤは、該当被保険者ＩＤが契約内容マスタテーブル１２９の「被保険者ＩＤ」欄に規定されたレコード数に応じたものとなり、１つの場合も複数の場合もある。
　また、保険金請求支援システム１００は、ｓ１０９で特定した１または複数の保険商品ＩＤのうち所定の１つ（例：最初に特定したもの）をキーにフィルタリングマスタテーブル１２５で該当保険商品のフィルタ方式を特定する（ｓ１１０）。
　続いて、保険金請求支援システム１００は、ｓ１１０で特定した保険商品およびフィルタ方式に基づいて、支払フィルタテーブル１２６または除外フィルタテーブル１２７から支払事由または除外事由の情報を取得し、これに基づき、該当診療情報に関して、（保険会社に対する）支払請求の可否を判定する（ｓ１１１）。なお、保険金請求支援システム１００は、上述のｓ１１０およびｓ１１１の各処理を、ｓ１０９で特定できた保険商品ＩＤの数だけ、すなわち該当被保険者に適用される保険契約の数だけ実行し（ｓ１１２：ｎ→ｓ１１０→ｓ１１２→ｓ１１２：ｙ）、各保険契約の全てに関してｓ１１０、ｓ１１１の処理を実行済みとなった当該診療情報に関して、フィルタ処理フラグを診療履歴テーブル１３１に設定する。
　一方、ｓ１１１における保険金請求支援システム１００は、支払フィルタテーブル１２６を利用する場合、該当診療情報に関してｓ１０８で得ている各値を、支払フィルタテーブル１２６の該当保険商品に関する支払事由の情報に照合し、当該支払事由に該当する傷病ないし診療行為に対応しているか否か判定する。
　他方、保険金請求支援システム１００は、除外フィルタテーブル１２７を利用する場合、該当診療情報に関してｓ１０８で得ている各値を、除外フィルタテーブル１２７の該当保険商品に関する除外事由の情報に照合し、当該除外事由に該当する診療情報であるか否か判定する。
　上述のｓ１１１における判定の結果、該当診療情報は保険金の支払請求不可と判明した場合（ｓ１１３：ｎ）、保険金請求支援システム１００は、該当診療情報は保険金の支払請求対象となりえない旨を示す棄却レポートを、当該保険契約者のユーザ端末２００に返し（ｓ１１４）、処理を終了する。
　他方、該当診療情報は保険金の支払請求可能と判明した場合（ｓ１１３：ｙ）、保険金請求支援システム１００は、該当診療情報に関して保険金の支払請求が可能であり、実際に支払請求を行うか否かを問う通知（図９の画面１０３０参照）を、当該保険契約者のユーザ端末２００に宛てて送信する（ｓ１１５）。
　なお、保険金請求支援システム１００は、上述のｓ１１５での通知の送信に際し、契約内容マスタテーブル１２９にて該当保険契約のレコードが示す、保険金受取人または被保険者の少なくともいずれかの端末に該当通知を送信するとしてもよい。
　上述の通知の送信後、当該ユーザ端末２００から支払請求の実施不要との返信を受けた場合（ｓ１１６：ｎ）、保険金請求支援システム１００は処理を終了する。一方、当該ユーザ端末２００から支払請求の実施要との返信を受けた場合（ｓ１１６：ｙ）、保険金請求支援システム１００は、該当診療情報を含む支払請求の承認要求を、該当保険商品を販売する保険会社の保険会社システム３００に送信する（ｓ１１７）。
　保険会社では、保険会社システム３００で受けた上述の承認要求に関して、所定の担当者等或いは所定の業務システムが判定処理を実行し、保険金支払いの可否を判断することとなる。また、この判断結果は、保険会社システム３００から保険金請求支援システム１００に返信される。
　この場合、保険金請求支援システム１００は、上述の診療情報に基づく保険金支払請求の承認可否の判断結果を、保険会社システム３００から受信する（ｓ１１８）。
　この判断結果が、保険金の支払い不可を示すものである場合（ｓ１１９：ｎ１）、保険金請求支援システム１００は、棄却レポート（図１０Ａの画面１０４０参照）を該当保険契約者のユーザ端末２００に配信し（ｓ１２０）、処理を終了する。
　一方、上述の判断結果が、保険金支払いに別途確認手続が必要との回答を示すものである場合（ｓ１１９：ｎ２）、保険金請求支援システム１００は、この確認手続が必要である旨の通知を、上述の該当保険契約者のユーザ端末２００に送信し（ｓ１２１）、処理をＳ１１８に一旦戻す。
　他方、上述の判断結果が、保険金支払い可を示すものである場合（ｓ１１９：ｙ）、保険金請求支援システム１００は、保険金支払いが承認された結果（図１０Ｂの画面１０５０参照）を、該当保険契約者のユーザ端末２００に送信し（ｓ１２２）、処理を終了する。
　本実施形態によれば、保険契約者において、契約対象の被保険者の通院・治療行為に関する、保険契約者本人による申告を不要とすると共に、プロアクティブな保険金支払、貰いそびれの回避といったことが可能となる。従って、保険金の支払請求漏れが適宜に防止されることとなる。また、「診断書を送付する、保険会社に保険契約者自らアクションする」などの支払請求にかかる面倒な手続きが簡素化される。一方、保険会社において、保険金の不払い事象が効果的に低減される。このことは保険契約者への優良な顧客体験の提供とともに、それに伴う企業価値の向上が期待される。また支払請求にあたり、営業職員に顧客（保険契約者）との接触機会が創出される。
　すなわち、種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援が可能となる。
　本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記選択した所定属性の診療情報に基づき、保険金の支払請求が可能である旨の通知を、前記契約者の端末に宛てて送信し、当該端末より支払請求の実施要求を受けた場合、前記診療情報を前記保険会社の情報処理装置に送信するものである、としてもよい。
　これによれば、保険の契約者における実施意思に応じて、保険金の支払請求の手順を進めることが可能となり、意思に反した保険金支払請求を的確に回避できる。ひいては、種々のチャネルからの情報を適宜に処理し、より効率的で的確な保険金支払請求の支援が可能となる。
　また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記通知の送信に際し、予め記憶装置にて保持する前記保険契約の内容情報に基づき、保険金受取人または被保険者を特定し、前記契約者、前記保険金受取人、および前記被保険者の少なくともいずれかの端末に前記通知を送信するものである、としてもよい。
　これによれば、保険契約者だけでなく、被保険者ないし保険金受取人といった対象者にも、保険金支払請求の要否を確認出来る。これにより、これら各対象者らの意思に反した保険金支払請求を更に的確に回避できる。
　また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記所定属性の診療情報を選択するに際し、前記格納した診療情報のうち、同一の被保険者の同一の診療機会に関する診療情報が複数存在する場合、前記複数の診療情報から１つの診療情報を所定アルゴリズムで選択するものである、としてもよい。
　これによれば、一人の被保険者の、同一の診療機会に関する、医療費通知、電子カルテ、レセプト、保険契約者による手入力といった種々のチャネルからの診療情報が所定期間に格納された場合にも的確に対応し、保険会社に対して診療情報を重複送信する事態を回避出来る。
　また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記１つの診療情報を選択するに際し、種類の異なる診療情報の間について予め定めた優先順位に基づき、前記複数の診療情報から１つの診療情報を選択するものである、としてもよい。
　これによれば、一人の被保険者の、同一の診療機会に関して得られた、医療費通知、電子カルテ、レセプト、保険契約者による手入力といった種々のチャネルからの診療情報のうち、例えば、より詳細な診療情報が得られるレセプトを優先し、それ以外の診療情報を保険会社への送信対象外とすることが可能となる。ひいては、保険会社に対する診療情報の重複送信を的確かつ効率的に回避出来る。
　また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択するものである、としてもよい。
　これによれば、保険金支払事由に該当する傷病等に関する診療情報のみを特定し、これを保険会社に送信し、保険金支払可否の承認判断の対象とすることができる。
　また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択するものである、としてもよい。
　これによれば、数ある診療情報の中から、保険金支払事由に該当しない傷病等に関する診療情報を除外し、この除外後の診療情報のみを保険会社に送信し、保険金支払可否の承認判断の対象とすることができる。
　また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記受信した診療情報のうち、確定していない診断内容に関する診療情報が存在する場合、当該診療情報に診断未確定フラグを付与して、前記保険会社の情報処理装置への送信対象から除外する処理を更に実行するものである、としてもよい。
　これによれば、レセプトにおける、いわゆる「レセプト病名」、「疑い病名」といった、診断が未確定の傷病等に関する記載を含む診療情報を特定し、これを保険会社への送信対象から除外、すなわち保険金支払可否の承認判断の対象外とすることができる。
　また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記受信した診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグを付与して、前記保険会社の情報処理装置に送信するものである、としてもよい。
　これによれば、保険金の支払事由に該当する診療情報のうち、保険外診療に関する情報を含むものを特定し、これを保険会社に提供することが出来る。この場合、保険会社では、当該保険契約者が契約中の保険について、保険外診療に対する特約と保険金支払の規定を確認して、保険金支払請求の承認可否判断を迅速に行いやすくなる。
　また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記受信した診療情報のうち傷病名が含まれていないものを特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイスを、前記契約者の端末に送信して傷病名の情報入力を受け付け、当該受け付けた傷病名の情報を、前記診療情報に付加した上で、前記所定アルゴリズムによる選択処理の対象とするものである、としてもよい。
　これによれば、例えば、医療費通知など傷病名の情報が含まれない診療情報しか取得できない場合でもこれに対応し、この診療情報を保険会社への送信対象とするか否かの判断対象とできる。
　また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記診療情報を前記保険会社の情報処理装置に送信した後、当該診療情報に基づく保険金支払請求の承認可否の判断結果を、前記情報処理装置から受信し、当該受信した判断結果を、前記契約者の端末に送信する処理を更に実行するものである、としてもよい。
　これによれば、保険契約者等は、保険金の支払請求を要求した診療情報に関して、その承認判断の結果を確実に認識し、ひいては、以後の支払請求の実施要求の検討時に、無駄な実施要求を回避しやすくなる。このことは、より効率的で的確な保険金支払請求の処理につながる。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記選択した所定属性の診療情報に基づき、保険金の支払請求が可能である旨の通知を、前記契約者の端末に宛てて送信し、当該端末より支払請求の実施要求を受けた場合、前記診療情報を前記保険会社の情報処理装置に送信する、としてもよい。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記通知の送信に際し、予め記憶装置にて保持する前記保険契約の内容情報に基づき、保険金受取人または被保険者を特定し、前記契約者、前記保険金受取人、および前記被保険者の少なくともいずれかの端末に前記通知を送信する、としてもよい。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記所定属性の診療情報を選択するに際し、前記格納した診療情報のうち、同一の被保険者の同一の診療機会に関する診療情報が複数存在する場合、前記複数の診療情報から１つの診療情報を所定アルゴリズムで選択する、としてもよい。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記１つの診療情報を選択するに際し、種類の異なる診療情報の間について予め定めた優先順位に基づき、前記複数の診療情報から１つの診療情報を選択する、としてもよい。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択する、としてもよい。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択する、としてもよい。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記受信した診療情報のうち、確定していない診断内容に関する診療情報が存在する場合、当該診療情報に診断未確定フラグを付与して、前記保険会社の情報処理装置への送信対象から除外する処理を更に実行する、としてもよい。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記選択した所定属性の診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグを付与して、前記保険会社の情報処理装置に送信する、としてもよい。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記受信した診療情報のうち傷病名が含まれていないものを特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイスを、前記契約者の端末に送信して傷病名の情報入力を受け付け、当該受け付けた傷病名の情報を、前記診療情報に付加した上で、前記所定アルゴリズムによる選択処理の対象とする、としてもよい。
　本実施形態の保険金請求支援方法において、前記情報処理システムが、前記診療情報を前記保険会社の情報処理装置に送信した後、当該診療情報に基づく保険金支払請求の承認可否の判断結果を、前記情報処理装置から受信し、当該受信した判断結果を、前記契約者の端末に送信する処理を更に実行する、としてもよい。
１０　　ネットワーク
１００　保険金請求支援システム
１０１　記憶装置
１０２　プログラム
１０３　メモリ
１０４　ＣＰＵ（演算装置）
１０５　通信装置
１２５　フィルタリングマスタテーブル
１２６　支払フィルタテーブル
１２７　除外フィルタテーブル
１２８　ユーザマスタテーブル
１２９　契約内容マスタテーブル
１３０　被保険者マスタテーブル
１３１　診療履歴テーブル
２００　ユーザ端末
３００　保険会社システム
４００　健保システム
５００　病院システム

Claims (22)

  1. 　ネットワーク上の１または複数の所定装置と通信する通信装置と、
    　所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置に送信する処理と、を実行する演算装置と、
    　を含むことを特徴とする保険金請求支援システム。
  2. 　前記演算装置は、
    　前記選択した所定属性の診療情報に基づき、保険金の支払請求が可能である旨の通知を、前記契約者の端末に宛てて送信し、当該端末より支払請求の実施要求を受けた場合、前記診療情報を前記保険会社の情報処理装置に送信するものである、
    　ことを特徴とする請求項１に記載の保険金請求支援システム。
  3. 　前記演算装置は、
    　前記通知の送信に際し、予め記憶装置にて保持する前記保険契約の内容情報に基づき、保険金受取人または被保険者を特定し、前記契約者、前記保険金受取人、および前記被保険者の少なくともいずれかの端末に前記通知を送信するものである、
    　ことを特徴とする請求項２に記載の保険金請求支援システム。
  4. 　前記演算装置は、
    　前記所定属性の診療情報を選択するに際し、前記格納した診療情報のうち、同一の被保険者の同一の診療機会に関する診療情報が複数存在する場合、前記複数の診療情報から１つの診療情報を所定アルゴリズムで選択するものである、
    　ことを特徴とする請求項１に記載の保険金請求支援システム。
  5. 　前記演算装置は、
    　前記１つの診療情報を選択するに際し、種類の異なる診療情報の間について予め定めた優先順位に基づき、前記複数の診療情報から１つの診療情報を選択するものである、
    　ことを特徴とする請求項４に記載の保険金請求支援システム。
  6. 　前記演算装置は、
    　前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択するものである、
    　ことを特徴とする請求項１に記載の保険金請求支援システム。
  7. 　前記演算装置は、
    　前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択するものである、
    　ことを特徴とする請求項１に記載の保険金請求支援システム。
  8. 　前記演算装置は、
    　前記受信した診療情報のうち、確定していない診断内容に関する診療情報が存在する場合、当該診療情報に診断未確定フラグを付与して、前記保険会社の情報処理装置への送信対象から除外する処理を更に実行するものである、
    　ことを特徴とする請求項１に記載の保険金請求支援システム。
  9. 　前記演算装置は、
    　前記受信した診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグを付与して、前記保険会社の情報処理装置に送信するものである、
    　ことを特徴とする請求項１に記載の保険金請求支援システム。
  10. 　前記演算装置は、
    　前記受信した診療情報のうち傷病名が含まれていないものを特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイスを、前記契約者の端末に送信して傷病名の情報入力を受け付け、当該受け付けた傷病名の情報を、前記診療情報に付加した上で、前記所定アルゴリズムによる選択処理の対象とするものである、
    　ことを特徴とする請求項１に記載の保険金請求支援システム。
  11. 　前記演算装置は、
    　前記診療情報を前記保険会社の情報処理装置に送信した後、当該診療情報に基づく保険金支払請求の承認可否の判断結果を、前記情報処理装置から受信し、当該受信した判断結果を、前記契約者の端末に送信する処理を更に実行するものである、
    　ことを特徴とする請求項１に記載の保険金請求支援システム。
  12. 　ネットワーク上の１または複数の所定装置と通信する通信装置を備えた情報処理システムが、
    　所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、
    　前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置に送信する処理と、
    　を実行することを特徴とする保険金請求支援方法。
  13. 　前記情報処理システムが、
    　前記選択した所定属性の診療情報に基づき、保険金の支払請求が可能である旨の通知を、前記契約者の端末に宛てて送信し、当該端末より支払請求の実施要求を受けた場合、前記診療情報を前記保険会社の情報処理装置に送信する、
    　ことを特徴とする請求項１２に記載の保険金請求支援方法。
  14. 　前記情報処理システムが、
    　前記通知の送信に際し、予め記憶装置にて保持する前記保険契約の内容情報に基づき、保険金受取人または被保険者を特定し、前記契約者、前記保険金受取人、および前記被保険者の少なくともいずれかの端末に前記通知を送信する、
    　ことを特徴とする請求項１３に記載の保険金請求支援方法。
  15. 　前記情報処理システムが、
    　前記所定属性の診療情報を選択するに際し、前記格納した診療情報のうち、同一の被保険者の同一の診療機会に関する診療情報が複数存在する場合、前記複数の診療情報から１つの診療情報を所定アルゴリズムで選択する、
    　ことを特徴とする請求項１２に記載の保険金請求支援方法。
  16. 　前記情報処理システムが、
    　前記１つの診療情報を選択するに際し、種類の異なる診療情報の間について予め定めた優先順位に基づき、前記複数の診療情報から１つの診療情報を選択する、
    　ことを特徴とする請求項１５に記載の保険金請求支援方法。
  17. 　前記情報処理システムが、
    　前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択する、
    　ことを特徴とする請求項１２に記載の保険金請求支援方法。
  18. 　前記情報処理システムが、
    　前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択する、
    　ことを特徴とする請求項１２に記載の保険金請求支援方法。
  19. 　前記情報処理システムが、
    　前記受信した診療情報のうち、確定していない診断内容に関する診療情報が存在する場合、当該診療情報に診断未確定フラグを付与して、前記保険会社の情報処理装置への送信対象から除外する処理を更に実行する、
    　ことを特徴とする請求項１２に記載の保険金請求支援方法。
  20. 　前記情報処理システムが、
    　前記選択した所定属性の診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグを付与して、前記保険会社の情報処理装置に送信する、
    　ことを特徴とする請求項１２に記載の保険金請求支援方法。
  21. 　前記情報処理システムが、
    　前記受信した診療情報のうち傷病名が含まれていないものを特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイスを、前記契約者の端末に送信して傷病名の情報入力を受け付け、当該受け付けた傷病名の情報を、前記診療情報に付加した上で、前記所定アルゴリズムによる選択処理の対象とする、
    　ことを特徴とする請求項１２に記載の保険金請求支援方法。
  22. 　前記情報処理システムが、
    　前記診療情報を前記保険会社の情報処理装置に送信した後、当該診療情報に基づく保険金支払請求の承認可否の判断結果を、前記情報処理装置から受信し、当該受信した判断結果を、前記契約者の端末に送信する処理を更に実行する、
    　ことを特徴とする請求項１２に記載の保険金請求支援方法。
PCT/JP2017/008894 2017-03-07 2017-03-07 保険金請求支援システムおよび保険金請求支援方法 WO2018163265A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2017/008894 WO2018163265A1 (ja) 2017-03-07 2017-03-07 保険金請求支援システムおよび保険金請求支援方法
JP2019504156A JP6805327B2 (ja) 2017-03-07 2017-03-07 保険金請求支援システムおよび保険金請求支援方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/008894 WO2018163265A1 (ja) 2017-03-07 2017-03-07 保険金請求支援システムおよび保険金請求支援方法

Publications (1)

Publication Number Publication Date
WO2018163265A1 true WO2018163265A1 (ja) 2018-09-13

Family

ID=63449036

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/008894 WO2018163265A1 (ja) 2017-03-07 2017-03-07 保険金請求支援システムおよび保険金請求支援方法

Country Status (2)

Country Link
JP (1) JP6805327B2 (ja)
WO (1) WO2018163265A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020100989A1 (ja) * 2018-11-15 2020-05-22 株式会社日本総険 保険販売方法及び保険販売プログラム
JP2021026738A (ja) * 2019-08-09 2021-02-22 株式会社アジャスト 保険金支払支援システム、プログラム及び記録媒体
JP2021189758A (ja) * 2020-05-29 2021-12-13 株式会社アドバンスクリエイト 保険管理装置、端末プログラム及び保険管理プログラム
JP2022540251A (ja) * 2019-07-11 2022-09-14 レモンヘルスケア クラウド基盤の実損医療費保険金請求システム及び方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002056188A (ja) * 2000-08-10 2002-02-20 Olympus Optical Co Ltd 生命保険の処理システム及び生命保険の処理方法
JP2002109042A (ja) * 2000-09-29 2002-04-12 Sanyo Electric Co Ltd 医療給付金手続きサービス方法
JP2005100165A (ja) * 2003-09-25 2005-04-14 Hitachi Software Eng Co Ltd 医療給付金支払サービス方法
JP2008152595A (ja) * 2006-12-19 2008-07-03 Hitachi Software Eng Co Ltd 保険金請求事務代行システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002056188A (ja) * 2000-08-10 2002-02-20 Olympus Optical Co Ltd 生命保険の処理システム及び生命保険の処理方法
JP2002109042A (ja) * 2000-09-29 2002-04-12 Sanyo Electric Co Ltd 医療給付金手続きサービス方法
JP2005100165A (ja) * 2003-09-25 2005-04-14 Hitachi Software Eng Co Ltd 医療給付金支払サービス方法
JP2008152595A (ja) * 2006-12-19 2008-07-03 Hitachi Software Eng Co Ltd 保険金請求事務代行システム

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020100989A1 (ja) * 2018-11-15 2020-05-22 株式会社日本総険 保険販売方法及び保険販売プログラム
JP2020095295A (ja) * 2018-11-15 2020-06-18 株式会社日本総険 保険販売方法及び保険販売プログラム
JP2022540251A (ja) * 2019-07-11 2022-09-14 レモンヘルスケア クラウド基盤の実損医療費保険金請求システム及び方法
JP7409716B2 (ja) 2019-07-11 2024-01-09 レモンヘルスケア クラウド基盤の実損医療費保険金請求システム及び方法
JP2021026738A (ja) * 2019-08-09 2021-02-22 株式会社アジャスト 保険金支払支援システム、プログラム及び記録媒体
JP7085167B2 (ja) 2019-08-09 2022-06-16 株式会社アジャスト 保険金支払支援システム、プログラム及び記録媒体
JP2021189758A (ja) * 2020-05-29 2021-12-13 株式会社アドバンスクリエイト 保険管理装置、端末プログラム及び保険管理プログラム
JP7232794B2 (ja) 2020-05-29 2023-03-03 株式会社アドバンスクリエイト 保険管理装置、端末プログラム及び保険管理プログラム

Also Published As

Publication number Publication date
JPWO2018163265A1 (ja) 2019-11-14
JP6805327B2 (ja) 2020-12-23

Similar Documents

Publication Publication Date Title
US20170330298A1 (en) Systems and Methods for Reducing Medical Claims Fraud
US8099295B2 (en) Prescription creation and adjudication method
JP6830719B1 (ja) 高信頼データ取引システム、および高信頼データ取引方法
WO2018163265A1 (ja) 保険金請求支援システムおよび保険金請求支援方法
US20090019552A1 (en) Healthcare Medical Information Management System
US20050209893A1 (en) System and method for identifying and servicing medically uninsured persons
US20090076855A1 (en) Apparatus, method and system for web-based health care marketplace portal
US20150278462A1 (en) Hipaa compliant data collection and fraud prediction system and method
US11210671B2 (en) User controlled event record system
US20170103230A1 (en) Methods and systems for secure document management
JP2001297153A (ja) 個人医療情報の共有化方法及び個人医療情報のデータベース端末
JP6911478B2 (ja) 情報提供プログラム、情報提供方法及び情報提供装置
US20150052058A1 (en) Auction for medical image diagnostic services
KR20110112495A (ko) 의료용 자료의 의료분석 시스템
KR101703538B1 (ko) 보험증권 분석 및 보험금 청구 방법
JP7120811B2 (ja) プログラム及び処理端末
JP2008152595A (ja) 保険金請求事務代行システム
KR20170111812A (ko) 보험청구 시스템과, 키오스크 및 보험금 지급 방법
US20130197923A1 (en) Systems and methods for preventing fraud
JP2023073525A (ja) 情報管理システムの制御方法、および情報管理システム
JP7254855B2 (ja) 情報管理システムの制御方法、および情報管理システム
JP2020106882A (ja) 保険設計支援システム及び保険設計支援方法
JP2009116612A (ja) 保険金請求処理支援システム
JP6832428B1 (ja) 保険金・給付金支払処理システム
JP2022055946A (ja) 支払対象外可能性判定装置、支払対象外可能性判定システム、および支払対象外可能性判定方法

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: 17899781

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019504156

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17899781

Country of ref document: EP

Kind code of ref document: A1