JP2019185403A - Patient matching method and device in receipt information/specific medical examination information database - Google Patents

Abstract

To provide a patient matching method and a device for improving efficiency and accuracy of computer-assisted name identification in receipt information database for NDB.SOLUTION: A device collates the data in a receipt information database having a first hash value based on an insurer number and a second hash value based on a name, and performs computer-assisted name identification. The device first extracts the first hash value, the second hash value, and a medical treatment date by separately using a receipt other than a dispensing receipt, and the dispensing receipt, and concatenates, based on a match between the first hash value and the second hash value over a plurality of months, a receipt, and generates an intermediate table for identifying a same patient. The device next integrates the intermediate table of the same patient along time series medical treatment date and generates a correspondence table of the first hash value in the same patient. The device then generates, when a plurality of types of first hash values exist in the correspondence table, a computer-assisted name identification table in which the first hash value is replaced with a unique first hash value.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a technique for identifying patients by collating the receipt data and specific medical examination data in an information database (NDB) such as a receipt information / specific medical examination.

  Information database (NDB) such as receipt information / specific medical examinations, such as electronic receipt data transmitted from hospitals etc. to examination paying institutions and insurers, and specific medical examinations held by insurers etc. It is a database that stores and constructs data through anonymization processing, and is a comprehensive data on insurance practice in Japan that employs the universal health insurance system. NDB is the world's largest health-related database, with approximately 12,884 million (as of the end of March 2017) received data from April 2009 to December 2016. Yes, it is expected that various clinical research and policy research can be strongly promoted by utilizing this effectively.

  However, the current situation is limited to partial utilization by disease, region, etc., and it is hard to say that the results have been sufficiently improved. The main reason for this is that, along with the huge size of the NDB, the structure of the receipt set for requesting medical fees is not suitable for use for research purposes. Among them, “name identification” described later is a big problem.

  Since each medical institution charges a medical fee every month for each patient, the receipt data is transmitted to one patient in units of medical institutions and monthly. Patients often visit for multiple months or visit multiple medical institutions in the same month, so if you do not perform “name collation” to connect multiple receipts from the same patient, Cannot be analyzed. Therefore, “ID1” and “ID2” are prepared in the NDB as anonymous variables for personal association that enable name identification. ID1 is an alphanumeric string hashed using a hash function to protect personal information from insurer number, insured person's identification code / number, date of birth, gender, ID2 is name, date of birth, Similarly, it is an alphanumeric string hashed using a hash function from gender.

  Here, the hash function is to generate a fixed-length pseudorandom number (hash value) from given data, and it is extremely difficult to generate the same hash value from different data. Further, since the original data cannot be reproduced from the generated value (hash value), it is useful for anonymizing data. However, since a hash value is generated based on personal information such as the insurer number, symbol / number, date of birth, gender, and name, simply generating one hash value changes the personal information such as the insurer number and name. If there is, it becomes difficult to join. Therefore, in NDB, two hash values “ID1” and “ID2” are prepared and have a structure that collates based on these hash values.

  However, even in the same patient, the insurer changes due to employment, job change, etc., and the name notation changes due to fluctuations in medical institutions (for example, “Watanabe” and “Watanabe”) and marriage / divorce etc., ID1, ID2 Both have been found to be easily changeable. Table 1 below is a table summarizing cases where the IDs are the same regardless of different persons.

As shown in Table 1 above, when the ID is the same regardless of another person, when ID1 and ID2 are the same, when ID1 is different but ID2 is the same, and when ID1 is the same and ID2 is different There are cases.
First, the case where ID1 and ID2 are the same is a case where the same ID1 and ID2 are generated between different persons (X1). The case where ID1 is different but ID2 is the same is when the same ID2 is generated between different persons (Y1) or when the same family name and same date of birth are the same gender (Y2). is there. The case where ID1 is the same and ID2 is different is the case where the same ID1 is generated between different persons (Z1), or the case of multiple births (such as twins) of the same sex / date of birth (Z2). . In addition, according to the 2014 population dynamics survey, there were 10,000 cases of total complications per year.
Unlike Table 1, Table 2 below summarizes the cases where the IDs do not match despite the same person.

As shown in Table 2 above, when the ID does not match despite the same person, ID1 changes but ID2 is unchanged, ID1 is unchanged but ID2 changes, and ID1 and ID2 also change Can be considered.
First, in the case where ID1 changes but ID2 remains unchanged, the employment is lost due to employment / change of job (A1-1), turnover (A1-2), retirement age (A1-3), employment / change of job (A1-4) ), Insurance change due to marriage / divorce of dependents (A2-1), insurance change due to dependent changes due to adoption (A2-2), change of dependents (A2-3), change of residence for National Health Insurance members Cases such as (A3), joining a senior citizen system (A4), or a patient (A5) whose insurance card number has been leaked are considered. If ID1 is unchanged but ID2 changes, the changed name by adoptive child (B1), the changed name by marriage / divorce (B2-1), the changed name by the dependent's marriage / divorce (B2-2), the name change (B3) ), Typographical error (in Japanese) (B4) or name change (B5) due to nationality acquisition.

  Next, as a case where both ID1 and ID2 change, the case where the above-mentioned “A” and “B” are multiplied can be considered. For example, when leaving a company / name changed due to marriage (A1-2 * B2-1), finding a job / name changed due to divorce (A1-1 * B2-1), or adopting a changed name / insurer (A2-2 * B1) Can be considered. Besides the case where “A” and “B” are multiplied, the case of sex change (C3) can be considered.

  In the case where the ID does not match despite the same person, for example, a person whose ID1 has changed due to employment / change of job (A1-1), turnover (A1-2) or retirement age (A1-3) According to the Ministry of Labor's “2014 Survey on Employment Trends,” it is known that there are approximately 7.13 million people per year. About 8 million people who fall out of support due to employment, job change, etc. (A1-4) per year, and according to the Ministry of Internal Affairs and Communications Statistics Bureau population estimate, ID1 changes due to joining the elderly system (A4) It is known that there are about 1,220,000 people. Moreover, according to the Ministry of Justice family register statistics as of 2014, the number of marriages per year is about 650,000, so it can be inferred that the number of renames has been changed. Thus, it can be seen that there are a large number of cases where the ID does not match despite the same person.

For this reason, there is a possibility of recognizing a visit by one patient as a visit of two different patients before and after employment, job change, etc., and estimating the number of patients using NDB and per patient Estimated values are considered to contain large errors. In order to solve this problem, it is necessary to give the NDB a personal ID that remains unchanged throughout the lifetime, but discussions have just begun. Even if the introduction of the invariant ID is realized, the current ID1 and ID2 must be used for past data.
In addition, there exists a motion which provides ID3 as a motion which improves patient matching of NDB. However, ID3 improves the above-mentioned notation fluctuation (difference in full-width half-width, whether or not 0 is given to the head) in ID1 of specific medical checkup, and improves patient matching of data of specific medical checkup and receipt data. It is an improvement. Therefore, even if ID3 is used, the need for name identification remains unchanged.

A health management system that can collate medical checkup data with receipt data is known (see Patent Document 1).
This includes a medical examination database, a receipt database, an association means, a medical examination data fetching means, a receipt data fetching means, a first concatenated key acquisition means, a medical examination data adding means, a second This is a system comprising a concatenated key obtaining unit and a receipt data adding unit. According to this, when medical examination data is taken in from the outside, a connection key is obtained from the receipt database based on the associated personal information, and the medical examination data acquired by giving the connection key is examined. If you add to the database and receive receipt data from the outside, on the other hand, obtain a concatenated key from the medical examination database based on the associated personal information, and accept the received receipt data with the concatenated key. Additional registration in the database is possible. As a result, the medical examination data and the receipt data can be matched.
However, the health management system disclosed in Patent Document 1 does not solve the problem that the anonymous variable for personal association easily changes due to job hunting, job change, name fluctuation, or the like.

JP 2009-271743 A

  In view of such circumstances, an object of the present invention is to provide a patient matching method and apparatus that improve the efficiency and accuracy of name identification in a receipt information database such as NDB.

In order to solve the above problems, the patient matching method of the present invention is a method for matching a receipt information database having at least two search keys, a first hash value based on an insurer number and a second hash value based on a name. Then, the following steps 1) to 4) are provided, and the data in the database are collated to identify patients.
1) At least a first hash value, a second hash value, and a medical date are extracted using a receipt other than the dispensing receipt, and the first hash value and the second hash value over a plurality of months of the medical date Based on at least one of the matches, the receipts are concatenated to generate a first name identification intermediate table for the same patient.
2) Using the dispensing receipt, extract at least the first hash value, the second hash value, and the medical date, and at least one of the first hash value and the second hash value over a plurality of months of the medical date Based on the match, the receipts are connected to generate a second name identification intermediate table for the same patient.
3) The first name identification intermediate table and the second name identification intermediate table of the same patient are integrated along the time series of the medical treatment date, and the correspondence table of the first hash value in the same patient is generated.
4) If multiple types of first hash values exist in the correspondence table, a name identification table is generated by replacing the multiple types of first hash values with unique first hash values.

In the step 1), it is preferable to extract an outcome category other than the first hash value, the second hash value, and the medical date, and it is preferable to extract “death outcome” as the outcome category. The reason for using dispensing receipts separately from other receipts is that in outpatients, dispensing is often done at an out-of-hospital pharmacy based on a prescription issued by a doctor, and there is a pair receipt for out-of-hospital and dispensing This is because, when batch processing is performed, patient linking information becomes many-to-many and genuine matching becomes difficult.
In addition, it is also possible to process together, without dividing a dispensing receipt and other receptors. In such a case, the processing including the dispensing receipt is performed in the step 1), and the step 2) is omitted. In this case, in the step 3), the first name identification intermediate table and the second name identification intermediate table are not integrated, and the first patient in the same patient is based only on the first name identification intermediate table. A hash value correspondence table is generated.

In the first and second name identification intermediate table generating steps 1) and 2), specifically, the following steps 5) and 6) are performed.
5) If both the first hash value and the second hash value match, concatenate as a receipt for the same patient and result from the first receipt occurrence month to the last receipt occurrence month or from the first receipt occurrence month Up to the month in which the death outcome is shown in the category, it is linked as a single reception group.
6) If only one of the first hash value and the second hash value matches in each of the receipt groups, the first hash value indicates the connection candidate of the reception group whose connection target is the last receipt occurrence month. Satisfies at least one of coincidence, closest in time series, non-overlapping periods except the same year and month, or the first receipt occurrence month of the same first or second hash value candidate is not the same The first receipt month is linked to the receipt group to be consolidated.
Here, the term “recept group” is used to mean not only a group in which two or more receptors are linked, but also one receptor that is not linked to other receptors.

For the second hash value, the same hash name, the same birth date, and the same sex patient will have the same ID for the second hash value, but the first hash value is preferentially linked. This is because, except for the same-sex twins and the like who are in the same support, the frequency with which the same person has the same ID is relatively low. The reason why the ones closest in time series are preferentially connected is that the ones near in time series are more likely to be the same person.
The reason why the periods that do not overlap except for the same year and month are connected is because there is a high possibility that they are not the same person when the periods overlap. Also, the reason for excluding the same year and month is that there are a plurality of different first or second hash values for the same person in the month in which a reason such as employment or marriage occurs.

In addition, the lost qualification receipt is checked by the insurer via the examination / payment institution and a re-examination request is made. Therefore, the new and old first hash values can coexist for about three months. Therefore, when connecting a receipt based on the match of the second hash value, not only the same month but also the previous month and the month before the last receipt may overlap. Even in such a case, the receipt group having the first receipt occurrence month after the last receipt occurrence month is the same person as the receipt group having the first receipt occurrence month in the previous month or the month before the last receipt occurrence month. Since it is considered that the possibility is high, it is preferable to perform connection in the order of the previous month and the month after the last month after the last receipt occurrence month.
If the first receipt generation month of the same first or second hash value candidate is not the same, if the first receipt generation month is the same, which receptor group should be connected? This is because judgment is difficult.

  In the above 6), when only one of the first hash value and the second hash value matches in each of the reception groups, the connection candidate of the reception group whose connection target is the last reception month is the first Satisfies all the cases where the hash values match, the closest in time series, the periods do not overlap except for the same year and month, and the first receipt occurrence month of the same first or second hash value candidate is not the same It is more preferable to connect with the receiving group.

  Moreover, it is preferable not to connect with the other receipt group which has the first receipt generation | occurrence | production month more than three months from the last month in the receipt group in which a death outcome is shown. Even in the case of a receptor group that shows a death outcome, there is a receptor that should be linked immediately after the patient's death, but if it exceeds 3 months, it is considered unnecessary to link it. .

Further, it may be connected to a reception group in which at least one of the location of the medical institution, the start date of medical treatment, the name of the sickness, and the age group of the patient in the reception information match. For example, even if the hash value is the same, it is appropriate to consider a patient who visited a distant place with a completely different disease name as a different person, and even if it has a different hash value, This is because there is an increased possibility that patients with matching disease names are the same person.
Here, the term “match” does not require exact matching but may include approximate information. For example, the coincidence of medical institution locations may be the same municipality, or may be more widely the same prefecture. In addition, it can be determined that the names match even when the names of wounds are different in expression but are substantially the same disease.

  The patient matching program of the present invention is a program that causes a computer to execute each step in the above-described patient matching method.

The patient matching device of the present invention is a device for matching a receipt information database having at least two search keys of a first hash value based on an insurer number and a second hash value based on a name. To d) and collate the data in the database to identify patients.
a) Input a receipt other than the dispensing receipt, extract at least the first hash value, the second hash value, and the medical date, and the first hash value and the second hash value over a plurality of months of the medical date First name identification intermediate table generation means for determining at least one of the matches and connecting the receipts of the same patient based on the determination to generate a first name identification intermediate table.
b) Input a dispensing receipt, extract at least the first hash value, the second hash value, and the medical date, and at least one of the first hash value and the second hash value over a plurality of months of the medical date A second name identification intermediate table generation unit that generates a second name identification intermediate table by determining a match between the same patients and connecting the receipts of the same patient based on the determination.
c) Correspondence table generation that integrates the first name identification intermediate table and the second name identification intermediate table of the same patient according to the time series of the medical treatment date and generates the correspondence table of the first hash value in the same patient. means.
d) Name collation table generating means for generating a name collation table in which plural types of first hash values are replaced with unique first hash values when there are plural types of first hash values in the correspondence table.

  According to the present invention, there is an effect that the efficiency and accuracy of name identification in a receipt information database such as NDB can be improved. In addition to this, not only “the number of prescriptions for a certain drug” but also “the number of patients taking the drug” and “the overall picture of medical practices that those patients are receiving” are clinically meaningful. There is an effect that it can be totaled.

Flow chart of patient matching method of Example 1 First name identification intermediate table generation flow chart Graph when ID1 and ID2 are the same Graph showing the priority of ID1 and ID2 linking Flow chart for linking ID groups with a common ID group Graph showing the relationship between the last receipt occurrence month and the first receipt occurrence month in pegging Graph showing the case where the first receipt month is the same Graph showing the priority of pegging when the first receipt month is different Graph showing the first month of receipt exceeding 3 months from death outcome Flow chart for linking ID groups with common ID groups Graph when the first receipt occurrence month exists in the month before ID1 Graph when the first receipt occurrence month exists two months before the year when ID1 was interrupted Second name identification intermediate table generation flowchart Integration flow diagram of intermediate table for name identification Chart showing examples of circular references Name identification table generation flow chart Comparison graph of name identification accuracy of ID0 and ID1 Explanatory drawing of patient matching device

  Hereinafter, an example of an embodiment of the present invention will be described in detail with reference to the drawings. The scope of the present invention is not limited to the following examples and illustrated examples, and many changes and modifications can be made.

In this embodiment, the entire 12 months of medical inpatient reception, non-medical inpatient receipt, DPC receptor, and dispensing receipt for April 2013 to March 2014 are targeted. DPC is a comprehensive payment system for inpatient medical expenses per day based on the diagnostic group classification introduced in 2003. Among the receipts that occur during hospitalization of DPCs, the receipt related to comprehensive payment is the DPC receipt. Become. Therefore, an inpatient receipt not related to the comprehensive payment becomes a medical inpatient receipt. By using these receipt data, changes in ID and the like over a plurality of months will be observed, and the patient matching method created using the medical treatment date and outcome category in addition to ID1 and ID2 will be described.
In outpatients, dispensing is often performed at an out-of-hospital pharmacy based on a prescription issued by a doctor. Receipts often occur outside the hospital and in pairs. Therefore, when batch processing is performed, patient association information becomes many-to-many and genuine matching becomes difficult. Therefore, in this embodiment, a first name identification intermediate table using a DPC and a medical department (in-patient / out-of-hospital) receipt and a second name identification intermediate table using a dispensing receipt are generated separately, and the two are combined. It is a mechanism to complete name identification.
Unlike the present embodiment, data such as a specific medical examination may be used to generate the first name identification intermediate table.

  FIG. 1 shows a flowchart of the patient matching method of the first embodiment. As shown in FIG. 1, first, a first name identification intermediate table is generated using a medical inpatient receipt, a non-medical inpatient receipt, and a DPC receptor (step S01). Next, a second name identification intermediate table is generated using the dispensing receipt (step S02). The first name identification intermediate table and the second name identification intermediate table are integrated (step S03). Finally, a name identification table is generated (step S04).

(About the first name identification intermediate table generation)
FIG. 2 shows a first name identification intermediate table generation flowchart. Although FIG. 1 shows the overall flow of name identification table generation, FIG. 2 will be described below focusing on individual receipts. As shown in FIG. 2, in the first name identification intermediate table generation, ID1, ID2, medical treatment date, and outcome category are extracted from the medical inpatient receipt, the non-medical inpatient receipt, and the DPC receipt (step S11). The DPC receptor refers to a general hospitalization receipt for DPC hospitalization, a DPC reception for DPC hospitalization, and a DPC reception for generalization of DPC hospitalization. Also, death information is extracted for the outcome category shown in step S11. As will be described later, when the death result is indicated in the receipt data, only the receipt data within three months from that month is linked, and the receipt data exceeding 3 months is not linked.

  Based on the extracted data, first, patients having the same ID1 and ID2 are made the same person over a plurality of months (step S12). FIG. 3 shows a graph when ID1 and ID2 are the same. As shown in FIG. 3, the reception group A groups receptions having a common ID 1 of “130” and ID 2 of “479”. In the receipt group A, ID1 and ID2 are common for April, June, and October to December 2015, but one group is included, including the month when the examination did not take place. The first receipt occurrence month and the last receipt occurrence month in the group linked in this way are compared with other receipt groups.

The comparison between the reception groups is performed with priority given to ID1 out of ID1 and ID2. FIG. 4 is a graph showing the priority order of linking ID1 and ID2. As shown in FIG. 4, the ID 1 of the receipt group B is “130” and is common to the receipt group A. The ID 2 of the receipt group B is “479”, which is the same as the reception group C. As for the year and month, the first receipt of Receipt Group A is February 2016, the first receipt of Receipt Group C is December 2015, and the last Receipt of Receipt Group B is the receipt month. It can be said that the reception group C is closer to October 2015.
However, ID1 is given priority when it can be linked to both ID1 and ID2. In ID2, the same name, same date of birth, and same-sex patient will have the same ID in ID2, but in ID1, the frequency with which another person has the same ID is relatively high except for the same-sex twins who are in the same support. Because there are few.
Therefore, when there is a receive group having a common ID1 (step S13), the receive groups having a common ID1 are associated with each other (step S14). Thereafter, it is determined whether there is a reception group having a common ID2 (step S15). If there is a reception group having a common ID2, the reception groups having a common ID2 are linked (step S15). S16).

(About linking of receipt groups that share ID1)
FIG. 5 shows a flow chart for associating receipt groups having a common ID1. As shown in FIG. 5, first, a subsequent receipt group whose first receipt occurrence month is the same month or later as the last receipt occurrence month of the previous receipt group is extracted (step S21). FIG. 6 is a graph showing the relationship between the last receipt occurrence month and the first receipt occurrence month in pegging. As shown in FIG. 6, ID1 of the receipt group A and ID1 of the receipt group B are both “130” and are common. And since the last receipt occurrence month of the receipt group A is October of 2015 and the first receipt occurrence month of the receipt group B is October of 2015, the reception group B, which is the later receipt group, The first receipt occurrence month is the same month as the last receipt occurrence month of the reception group A, which is the previous receipt group, and can be linked. On the other hand, for example, when the first receipt occurrence month of the receipt group B is September 2015, the above condition is not satisfied and the linking is not performed.

Next, a determination is made as to whether there are a plurality of extracted reception groups (step S22). If only one reception group exists, the reception group is selected (step S23). On the other hand, when there are a plurality of extracted reception groups, it is determined whether the first reception occurrence months of the subsequent reception groups are different (step S24).
Here, when the first receipt generation months of the subsequent receipt groups are the same, no association is made (step S28). FIG. 7 is a graph showing a case where the first receipt occurrence month is the same. As shown in FIG. 7, the IDs 1 of the receipt groups A, B, and C are all “130” and are common. However, the first receipt occurrence months of the receipt groups B and C with respect to the final receipt occurrence month of the receipt group A are both January 2016, and it can be said that the first receipt occurrence month is the same. Therefore, the receipt group A is not associated with either B or C.

  In step S24 of FIG. 5, when the first receipt generation months of the subsequent reception groups are different, the subsequent reception group having the first reception generation month closest to the final reception generation month of the previous reception group is selected. (Step S25). FIG. 8 is a graph showing the priority order of linking when the first receipt occurrence month is different. As shown in FIG. 8, the IDs 1 of the receipt groups A, B, and C are all “260” and are common. However, the first month of receipt of receipt group B is May 2015 and the first month of receipt of receipt group C is January 2016, compared to March 2015, the last month of receipt of receipt group A. ing. In such a case, the receipt group A is linked to the receipt group B having the first receipt occurrence month closer to the last receipt occurrence month of the receipt group A in March 2015.

Even if the later receptor group is selected in step S23 and step S25 of FIG. 5, if the death outcome is indicated in the outcome category of the earlier receptor group, the last month of receipt of the earlier receptor group The subsequent receipt group (step S26) having the first receipt generation month exceeding 3 months is not linked (step S28).
On the other hand, if the death category is not indicated in the outcome category of the previous receptor group, or if the death outcome is indicated, but the selected receptor group is the final receptor of the previous receptor group When it has the first receipt occurrence month within 3 months from the occurrence month, it is linked (step S27).
FIG. 9 is a graph showing the case of having the first receipt month exceeding 3 months from the death outcome. As shown in FIG. 9, the IDs 1 of the receipt groups A and B are both “863”. However, in the receipt group A, although not shown, the death outcome is shown in the receipt in October 2015, which is the last receipt month. And the first receipt occurrence month of the receipt group B is February 2016, and has exceeded three months from the last receipt occurrence month of the receipt group A which is the receipt group in which the death outcome was shown. Therefore, the receipt groups A and B are not linked.

(About linking of receipt groups that share ID2)
As shown in FIG. 2, after ID1 is linked (step S14), if there is a receipt group having the same ID2 before and after the break for ID1 (step S15), the link is performed (step S16). ).
The association between the receipts having the same ID2 is performed by an algorithm that takes into account the existence of a loss of qualification. The reason is that the old and new ID1 can coexist for about three months because the insured person checks the receipt of the lost qualification through the examination and payment institution and makes a re-examination request. Specific processing will be described with reference to FIG.

FIG. 10 shows a flow chart for associating receipt groups having a common ID2. As shown in FIG. 10, first, among the receipt groups having a common ID2 after the date when ID1 is interrupted, the one closest to the date when ID1 is interrupted is searched (step S301).
When the reception group after the year when ID1 is interrupted is not detected by the search in step S301 (step S302), the group having the common ID2 is searched for in the month before the year when ID1 is interrupted (step S302). S303). FIG. 11 is a graph in the case where the first receipt occurrence month exists in the month before the year when ID1 was interrupted. As shown in FIG. 11, the ID 2 of the reception group A and the reception group B is “479” and is common. And the first receipt occurrence month of the receipt group B is the month before the last receipt occurrence month of the receipt group A. Therefore, in the case shown in FIG. 11, the receipt group A and the receipt group B can be linked.

  If the receipt group having the common ID2 is not detected in the month before the year when ID1 is interrupted by the search in step S303 (step S304), the ID2 is common in the month two months before the year when ID1 is interrupted. A receipt group is searched (step S305). FIG. 12 is a graph in the case where the first receipt occurrence month exists in the month two months before the year and month when ID1 was interrupted. As shown in FIG. 12, the ID 2 of the receipt group A and the receipt group B are both “479” and are common. Then, the first receipt occurrence month of the receipt group B is two months before the final receipt occurrence month of the receipt group A. Therefore, in the case as shown in FIG. 12, the receipt group A and the receipt group B can be linked.

Even in the case where a reception group close to the year and month when ID1 is interrupted is detected in step S302 above, it is a subsequent reception group having the first reception generation month that exceeds three months from the death outcome of the previous reception group. If there is any (step S307), no association is made (step S310).
On the other hand, if it is not a subsequent receipt group having the first receipt occurrence month exceeding 3 months from the death outcome of the previous receipt group, or has a common ID2 in either step S304 or step S306 If a receipt group is detected, a determination is made as to whether or not a plurality of receipt groups having the same initial receipt month have been detected (step S308). Here, when a plurality of receipt groups having the same first receipt month are detected, no association is made (step S311). On the other hand, when a plurality of receipt groups having the same first receipt month are not detected, a receipt group close to the year and month when ID1 is interrupted is linked (step S309).

(About the second name identification intermediate table generation)
Generation of the second name identification intermediate table shown in FIG. 1 (step S02) will be described with reference to FIG. FIG. 13 shows a second name identification intermediate table generation flowchart. As shown in FIG. 13, first, ID1, ID2, and medical date are extracted from the dispensing receipt (step S41). Next, the receipts having the same ID1 are grouped as those of the same person (step S42). When there is a reception group having a common ID2 (step S43), it is linked to a reception group having a common ID2 (step S44).
Note that the linking in step S44 is performed by the same method as in the case of linking the receipt groups having the same ID2 in the first name identification intermediate table generation shown in FIG.

(About the integration of the first name identification intermediate table and the second name identification intermediate table)
As shown in FIG. 1, the first name identification intermediate table generated in step S01 and the second name identification intermediate table generated in step S02 are integrated in step S03.
FIG. 14 shows an integration flowchart of the name identification intermediate table. As shown in FIG. 14, the first name identification intermediate table and the second name identification intermediate table are integrated to generate a one-to-one correspondence table of ID1s that are actually the same person (step S51). Table 3 below shows a one-to-one correspondence table for the first ID 1 and the first ID 1. Here, “first-out ID1” refers to ID1 that appears first regardless of medical department, DPC, or dispensing, and “follow-up ID1” refers to ID1 that appears second or later.

The first-out ID1 and the later-out ID1 shown in Table 3 are considered to be the same person because they are different in alphanumeric characters but have the same ID2. In Table 3, this is not a problem, but when the first ID 1 and the last ID 1 are displayed, the circular reference becomes a problem.
FIG. 15 is a graph showing an example of circular reference. As shown in FIG. 15, the ID 1 of the reception group A is “135”, and the ID 1 of the reception group B is “512”. Therefore, the ID 1 is different, but the IDs 2 of the reception group A and the reception group B are both. “479” is common. However, since both the reception group A and the reception group B are reception groups consisting of only one reception with a medical treatment date of only April 2015, when creating a one-to-one correspondence table, the reception group A first. As the outgoing ID 1, the receiving group B can be the subsequent ID 1, and conversely, the receiving group B can be the preceding ID 1 and the receiving group A can be the subsequent ID 1. If both are input, a circular reference that refers to each other at the time of integration occurs, so this inconvenience needs to be avoided.
Therefore, when a circular reference occurs (step S52), one of the correspondence sets is deleted (step S53).

(About name identification table generation)
FIG. 16 shows a name identification table generation flowchart. As shown in FIG. 16, the above-described one-to-one correspondence table is used to replace the later ID 1 with the first ID 1 (step S61). Thereby, a plurality of IDs 1 of the same person are integrated into one type. Since the replaced ID1 may be a subsequent ID1 in another corresponding set, in this case, the ID1 is further replaced with the previous ID1. As described above, if all the replacements are not completed (step S62), the later ID1 is replaced with the first ID1 again (step S61). This operation is repeated until the later ID1 is exhausted. All replacement is completed, and finally the remaining ID1 is set as a new name identification variable “ID0” (step S63).
In the present embodiment, the previous ID 1 is used for ID0, but the later ID1 may be used for ID0.

  This will be specifically described in Table 3 above. First, the succeeding ID 1 is replaced with the preceding ID 1 from the new receipt group c in time series. In the receipt group c in which the first ID 1 is “78 wmdjfg” and the last ID 1 is “Ajdke783”, the last ID 1 “Ajdke783” is replaced with the first ID “78 wmdjfg”. The subsequent ID1 “Ajdke783” before the replacement of the receipt group c is the same as the previous ID1 “Ajdke783” of the receipt group b. Since “Ajdke783” is replaced with “78wmdjfg”, when the succeeding ID 1 “ue8k22ue” of the receipt group b is replaced with the preceding ID 1 “Ajdke783”, it is replaced with “78wmdjfg”. Similarly, the subsequent ID 1 “ue8k22ue” before the replacement of the receipt group b is the same as the previous ID 1 “ue8k22ue” of the receipt group a. When replacing with "78", it is replaced with "78wmdjfg". The process is repeated until there is no later ID1, and all the replacement is completed, and finally the remaining ID1 becomes “78wmdjfg”. Table 4 below shows a name identification table that has been generated.

  As shown in Table 4 above, ID 0 “78wmdjfg” is set for all of the receipt groups (a to c). In this embodiment, the generation of the name identification table is completed by the third update, but there are cases where a larger number of replacements are actually performed. In addition, the ID0 includes those in which the original ID1 remains as it is because it has not been subjected to name identification in a single visit or the like.

Regarding the first ID1 and the last ID1 in the receipt group, even if it is a first-to-last relationship (old ... first; new ... after) in time sequence from the oldest to the newer, It may be a chronological relationship (new ... first; old ... after) along the time series toward the older one.
In addition, the order of naming the plurality of reception groups is not particularly limited. For example, reception may be performed from a reception group including old receptions in time series, or reception including new receptions. You may process from a group.

(Validity of ID0)
FIG. 17 is a comparison graph of the identification accuracy of ID0 and ID1, and specifically, identification of ID0 for patients (DPC, medical admission, non-medical admission, dispensing) for the year 2013 The results for each sex age group compared to the number of name-identified patients by conventional ID1 and the estimated population in October 2013 are shown. Note that (1) shows the results for men and (2) shows the results for women. As shown in FIGS. 17 (1) and (2), the number of patients by gender age group by ID0 is lower than the number of patients by ID1 for both men and women, and the additional name identification rate (same person with ID0 grouping compared to ID1 grouping) The rate of additional successful identification) was 6.2% for men and 7.1% for women. The number of patients named by ID1 greatly exceeded the estimated population at 0-9 years, 75-79 years, 90 years and older, 85-89 years for men, and 25-29 years for women. On the other hand, the number of patients named by ID0 greatly exceeded the estimated population at the age of 85 and over for males and 90 and over for females, but in other sex age classes, it was generally within the estimated population.

FIG. 18 shows an explanatory diagram of the patient matching apparatus. As shown in FIG. 18, the computer 3 includes a patient matching device 4 and a communication unit 45. The computer 3 and the server 5 are connected to each other by a communication means 45 via a network 6 in a wired or wireless manner. The server 5 is provided with an NDB.
The patient matching apparatus 4 is provided with first name identification intermediate table generation means 41, second name identification intermediate table generation means 42, correspondence table generation means 43, and name identification table generation means 44.

When operating the patient matching apparatus 4, the computer 4 receives data from the server 5 using the communication means 45. The computer 4 uses the received data to generate a first name identification intermediate table by the first name identification intermediate table generation means 41. Next, the second name identification intermediate table generation means 42 generates a second name identification intermediate table. The generated table is integrated by the correspondence table generating means 43. A name identification table is generated by the name identification table generation unit 44 based on the integrated table.
The completed name identification table is transmitted to the server via the network 6 by the communication means 45. Thereby, the NDB in the server 5 can be used as a database with improved name identification accuracy.
Since the NDB in the server 5 is updated with new information every day, the operation of the patient matching device 4 as described above is desirably performed not only once but periodically. By frequently operating the patient matching apparatus 4, it is possible to make a database with improved name identification accuracy.

  The present invention is useful as a tool for supporting effective utilization of receipt information data and the like.

DESCRIPTION OF SYMBOLS 3 Computer 4 Patient matching apparatus 5 Server 6 Network 41 1st name identification intermediate table generation means 42 2nd name identification intermediate table generation means 43 Correspondence table generation means 44 Name identification table generation means 45 Communication means

Claims (7)

A method of matching a receipt information database having at least two search keys, a first hash value based on an insurer number and a second hash value based on a name,
1) At least a first hash value, a second hash value, and a medical date are extracted using a receipt other than the dispensing receipt, and the first hash value and the second hash value over a plurality of months of the medical date Concatenating the receipts based on at least any match to generate a first name identification intermediate table for the same patient;
2) Using the dispensing receipt, extract at least the first hash value, the second hash value, and the medical date, and at least one of the first hash value and the second hash value over a plurality of months of the medical date Concatenating the receipts based on the match and generating a second name identification intermediate table for the same patient;
3) integrating a first name identification intermediate table and a second name identification intermediate table of the same patient along a time series of medical treatment dates, and generating a first hash value correspondence table for the same patient;
4) When there are a plurality of types of first hash values in the correspondence table, a step of generating a name collation table in which the plurality of types of first hash values are replaced with unique first hash values;
A patient collation method comprising: collating data in the database and collating patients. In the first and second name identification intermediate table generation steps,
If both the first hash value and the second hash value match, they are linked as a receipt for the same patient, and from the first receipt occurrence month to the last receipt occurrence month, or from the first receipt occurrence month to the outcome category Concatenating as a single reception group until the month in which the death outcome is indicated,
When only one of the first hash value and the second hash value is matched in each of the receive groups, the first hash value matches the candidate for concatenation of the receive group whose connection target is the last receipt occurrence month, The first satisfying at least one of the closest in time series, the period does not overlap except for the same month, or the first receipt generation month of the same first or second hash value candidate is not the same Linking a receipt month with a receipt group to be consolidated;
The patient matching method according to claim 1, further comprising: In the first and second name identification intermediate table generation steps,
If both the first hash value and the second hash value match, they are linked as a receipt for the same patient, and from the first receipt occurrence month to the last receipt occurrence month, or from the first receipt occurrence month to the outcome category Concatenating as a single reception group until the month in which the death outcome is indicated,
When only one of the first hash value and the second hash value is matched in each of the receive groups, the first hash value matches the candidate for concatenation of the receive group whose connection target is the last receipt occurrence month, Linked to a receipt group that satisfies all of the following conditions: the closest in time series, except for the same year and month, the periods do not overlap, and the first receipt generation month of the same first or second hash value candidate is not the same Step to do,
The patient matching method according to claim 1, further comprising:   4. The patient matching method according to claim 2 or 3, wherein a receipt group showing a death outcome is not connected to another receipt group having an initial month of receipt that exceeds three months from the last month. .   5. The method according to claim 2, wherein at least one of a medical institution location, a medical treatment start date, a medical treatment name, and / or a patient age group in the receipt information is connected. Patient matching method.   A patient matching program for causing a computer to execute each step in the patient matching method according to claim 1. An apparatus for matching a receipt information database having at least two search keys of a first hash value based on an insurer number and a second hash value based on a name,
1) Enter a receipt other than the dispensing receipt, extract at least the first hash value, the second hash value, and the medical date, and the first hash value and the second hash value over a plurality of months of the medical date A first name identification intermediate table generating means for determining at least one of the matches, connecting the receipts of the same patient based on the determination, and generating a first name identification intermediate table;
2) Input a dispensing receipt, extract at least the first hash value, the second hash value, and the medical date, and at least one of the first hash value and the second hash value over a plurality of months of the medical date A second name identification intermediate table generating unit that generates a second name identification intermediate table by connecting the same patient's receipts based on the determination,
3) Correspondence table generation that integrates the first name identification intermediate table and the second name identification intermediate table of the same patient according to the time series of the medical treatment date and generates the first hash value correspondence table for the same patient. Means,
4) When there are a plurality of types of first hash values in the correspondence table, a name identification table generating unit that generates a name identification table in which the plurality of types of first hash values are replaced with unique first hash values;
A patient collating apparatus characterized by collating data in the database and identifying patients.