JP2018081632A - Service support system, service support method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To present conceivable causes, factors, risk factors, and items to be paid attention of an occurred matter from a multifaceted point of view.SOLUTION: A service support system 210 includes: a cause database 460 for storing a data group with which each cause for each event related to occurrence of a case is associated for each kind of the case; a reception unit 314 for receiving an input containing a kind of the occurred case and an occurrence state of the case; a matching unit 316 for matching the received occurrence state with a data group corresponding to the kind of the received case stored in the cause database; and an output unit 317 for outputting the cause obtained as a result of matching in the matching unit.SELECTED DRAWING: Figure 4

Description

  The present invention relates to a service support system, a service support method, and a program.

  In nursing homes and medical facilities, various accidents can occur for elderly people residing there. The causes, factors, risk factors, matters to be noted for preventing the accident, and the like vary depending on the type and occurrence of the accident. In addition, in order to identify various causes of accidents, appropriate knowledge and experience are required. Also, a lot of time and effort may be spent analyzing the accident and planning future responses and preventive measures.

  Patent Document 1 discloses a technique for extracting assistance target items that match a combination pattern of assessment items selected by a user when generating a care plan.

Japanese Patent No. 3889189

  No technology has been proposed for presenting the cause, factors, risk factors, matters to be noted of the incident, etc. to the staff. The cause of the occurrence of the case varies depending on the type of the case and the state of occurrence, and cannot be identified uniformly. Rather, there is a risk that some kind of assumptions will cause the staff to overlook the real cause that they are not aware of.

  SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to provide a service support system, a service support method, and a program capable of presenting possible causes, factors, risk factors, considerations, and the like of a case that has occurred from various viewpoints. And

  A service support system according to an aspect of the present invention includes a cause database that stores, for each event type, a data group that associates each cause with respect to each event related to the occurrence of the event, the type of the event that has occurred, and the occurrence status of the event A receiving unit that accepts an input including: a matching unit that matches a received occurrence situation and a data group corresponding to a type of received case stored in the cause database, and obtains a matching result in the matching unit And an output unit for outputting the cause.

  A service support method according to an aspect of the present invention includes a step of receiving an input including a type of a case that has occurred and a state of occurrence of the case, the received occurrence state, and each cause for each event related to the occurrence of the case. Store the associated data group for each case type Matching the data group corresponding to the accepted case type among the data groups stored in the cause database, and the cause obtained as a result of the matching Outputting.

  A program according to an aspect of the present invention includes a step of accepting an input including a type of a case that has occurred and a state of occurrence of the case in the computer, each cause for each event related to the occurrence of the case that has been accepted, and the occurrence of the case A step of matching a data group corresponding to an accepted case type in a data group stored in a cause database, and a cause obtained as a result of the matching Are executed.

  According to the present invention, it is possible to present the cause, factor, risk factor, considerations, and the like of a case that has occurred from various viewpoints.

It is a figure which shows typically an example of the factor of the fall accident which occurs in a care facility. It is a figure which shows an example of a utilization form. It is a block diagram which shows the example of the structure of a service assistance system, and the structure of a user terminal. It is a figure which shows the example of a detailed structure of a database part and a matching part. It is a figure which shows an example of the preparation screen of the accident report of a fall accident. It is a figure which shows the generation area record group corresponding to an input area and an input area. It is a figure which shows the generation area record group corresponding to an input area and an input area. It is a figure which shows the example of the input record regarding an external factor. It is a figure which shows the example of the input record regarding an internal factor. It is a figure which shows the example of a cause record typically. It is a schematic diagram for demonstrating a matching process. It is a figure for demonstrating vertical matching and intersection matching. It is a figure which shows an example of a matching result screen. It is a figure which shows the example of an analysis result screen. It is a flowchart which shows an example of the control method of a user terminal. It is a flowchart which shows an example of the service support method in a service support system. It is a flowchart which shows an example of a matching process. It is a flowchart which shows an example of the detailed process of a matching process. It is a flowchart which shows an example of the process according to a predetermined rule.

[Explanation of terms]
Terms used in this embodiment will be described.

  “Staff”: Facility manager / manager, care manager (planner in charge), service provider, care staff / home helper, nursing staff, functional training instructor, life counselor, life support staff, reception clerk, etc. A person who performs work related to facilities.

  “User”: A person who uses the system described in this embodiment. A specific example is a facility staff.

  “Service recipient”: a person who receives a service provided by a facility or business operator. It does not necessarily have to be in the facility, including those who receive some services outpatiently. In the following embodiment, the service recipient will be described by taking a resident who enters a care facility as an example. The service recipient may be a person who is not in the facility, such as a person who receives services such as outpatient care or home care, and in the embodiment described below, both may be mixed. Good.

  A preferred embodiment of the present invention will be described with reference to the accompanying drawings. In addition, in each figure, what attached | subjected the same code | symbol has the same or similar structure.

[Explanation of accident factors]
FIG. 1 is a diagram schematically illustrating an example of the cause of an accident that occurs in a care facility. FIG. 1 shows an example in which there are various factors that cause a fall accident. For example, if a factor causing a fall accident is roughly divided into two, it can be divided into an internal factor and an external factor.

  Internal factors are factors attributable to the resident, and in a fall accident, various factors related to the resident, such as the physical / physiological factors of the resident, illness / illness / symptoms, drugs taken, etc. It is a factor. For example, as shown in FIG. 1, it can be further classified into physical / physiological factors, disease / disease / symptom factors, and drug factors. For example, as an example of physical / physiological factors, determine whether you are elderly, have a history of falls, have a sense of sensation or lack of exercise, have insomnia, constipation, poor physical condition, etc. This may be due to a decrease in power or other circumstances. Diseases / disorders / symptoms include cardiovascular diseases / disorders / symptoms such as high blood pressure, cranial nervous system diseases / disorders / symptoms, psychogenic diseases / disorders / symptoms, fractures, muscle weakness Such as a decrease in motor function. Examples of drug factors include the type of drug being taken and the number of drugs being taken. For example, side effects of drugs can cause wobbling and fall accidents.

  External factors are factors other than the resident, such as the building structure of the facility, the environment of the room, the clothes and footwear worn by the resident, equipment used such as canes and wheelchairs, Factors that include facility staff skills, knowledge, experience, assistance methods and relationships, information sharing and various training related matters. For example, as shown in FIG. 1, it can be classified into environmental factors and home / staff factors. Examples of environmental factors include the surrounding environment and the personal environment. For example, the surrounding environment such as when there is a step in the hallway or a slippery floor, equipment used such as using a cane, footwear such as wearing slippers, etc. It is done. Home / staff factors include, for example, staff assistance methods, information sharing within the home, well-known methods, assessment plans, staff management, and the like. In addition, the example of the factor mentioned above is only an example, and is not restricted to this.

  In this way, even if the fall accident is simply taken as an example, various factors are included as the cause of the accident. In addition, a fall accident may occur due to a combination of these factors. Furthermore, as the type of accident, not only a fall accident, but also an aspiration / suffocation accident, a drug accident, etc. may occur. These accident factors include various factors that are separate from those of the fall accident. As described above, in various accidents that can occur in residents of a nursing facility, various factors often occur in a complex manner. In addition, lack of staff knowledge and experience and organizational follow-up may result in inadequate analysis, resulting in inadequate response and preventive measures. .

  Therefore, in the present embodiment, various causes, factors, risk factors, and the like that may occur for each accident type are systematized and databased. For example, a database is created so that the data has the same hierarchical structure. Then, when the accident occurred, the user was made to input information related to the situation of the accident (including the situation of the accident detection; the same applies hereinafter), and the input information was systematized (for example, structured, hierarchized). The information stored in the database is matched according to a predetermined rule. And a score is given to a cause candidate based on the result of matching. As a result, for example, cause candidates with high scores are displayed on the user terminal. In this way, analysis of the cause of the accident is supported.

[Overall configuration]
FIG. 2 is a diagram illustrating an example of a usage pattern in the present embodiment. The service support system 210 can be configured as a server device and is connected to a plurality of user terminals 220a and 220b. Although two user terminals are shown in FIG. 2, the number of user terminals may be an arbitrary number. A plurality of user terminals are collectively referred to as a user terminal 220. The user terminal 220 and the service support system 210 are connected to each other through a network such as the Internet and a local area network (LAN).

  The user terminal 220 is an information processing terminal used by the staff at a care facility. In this embodiment, the user includes a staff of a care facility. The user can confirm information necessary for providing the service with reference to information displayed on the user terminal 220.

  The service support system 210 is an information processing apparatus such as a server that records data relating to a provided service. The user terminal 220 can display information on the user terminal 220 based on the data transmitted from the service support system 210. Further, the service support system 210 manages users by, for example, a login method, and can transmit data corresponding to the user of the user terminal 220 to the user terminal 220.

  FIG. 3 is a block diagram illustrating an example of the configuration of the service support system 210 and the configuration of the user terminal 220 according to the present embodiment.

[User terminal configuration]
The user terminal 220 includes an input unit 320, a communication unit 321, a display unit 323, a display control unit 324, a storage unit 325, and a storage control unit 326. The user terminal 220 can be various information processing terminals such as a tablet terminal, a smartphone, and a personal computer.

  An operation instruction from the user is input to the input unit 320.

  The communication unit 321 transmits and receives various data to and from the communication unit 311 of the service support system 210. That is, the communication unit 321 functions as a reception unit and a transmission unit.

  The display unit 323 displays various screens including an accident report creation screen described later. For example, the display unit 323 can be a liquid crystal display, an organic EL (electroluminescence) display, or the like.

  The display control unit 324 controls information displayed on the display unit 323.

  The storage unit 325 stores various data. For example, the storage unit 325 stores data used for creating an accident report. The storage unit 325 may be various storage media such as an HDD (Hard Disc Drive) and a flash memory.

  The storage control unit 326 writes various data to the storage unit 325 and reads various data from the storage unit 325.

  The user terminal 220 can include a CPU (Central Processing Unit), a RAM (Random Access Memory), and a flash memory or HDD (not shown). The flash memory or the HDD may be the same as or different from the storage unit 325 described above. The program stored in the flash memory or HDD is temporarily read into the RAM, and the CPU executes the program read into the RAM, so that the CPU functions as each unit of the user terminal 220 shown in FIG. can do. Here, a configuration realized using software will be described as an example. However, the configuration may be any of hardware, firmware, and software. FIG. 3 is only an example of the configuration, and the user terminal 220 may include other configurations. Further, not all the configurations described in FIG. 3 are indispensable requirements.

[Server configuration]
Next, the configuration of the service support system 210 will be described. The service support system 210 includes a communication unit 311, a storage control unit 312, a storage unit 313, a reception unit 314, a database 315, a matching unit 316, and an output unit 317.

  The communication unit 311 transmits and receives data to and from the user terminal 220 through a network interface such as the Internet and a LAN. That is, the communication unit 311 functions as a transmission unit and a reception unit.

  The storage control unit 312 writes various data to the storage unit 313 and reads various data from the storage unit 313.

  The storage unit 313 stores various data. For example, the storage unit 313 stores data on schedules and results of services that the tenant receives. The storage unit 313 may be various storage media such as an HDD (Hard Disc Drive) and a flash memory.

  The accepting unit 314 accepts input of various types of information including the type of a case (for example, an accident) that has occurred and the state of occurrence of the case (for example, an accident). For example, the reception unit 314 can receive an input of information transmitted from the user terminal 220 received by the communication unit 311. In the following, an accident will be described as an example of a case.

  For example, the database 315 stores, for each type of incident (accident), a data group in which each event related to the occurrence (including discovery; the same applies hereinafter) related to the occurrence of the incident (accident) is organized (for example, structured and hierarchized). Store. Examples of accident types include falls accidents, aspiration / suffocation accidents, and drug accidents. In other words, in this case, a data group that associates each cause for each event of a fall accident, a data group that associates each cause for each event of an aspiration / suffocation accident, and a data group that associates each cause for each event of a drug accident And store. Here, three types of accidents will be described as examples, but the present invention is not limited to this. For convenience of explanation, the storage unit 313 and the database 315 are described separately, but a configuration in which both are shared may be used.

  The matching unit 316 matches the occurrence status received by the receiving unit 314 with a data group stored in the database 315 and corresponding to the received case (accident) type. Details will be described later.

  The output unit 317 outputs cause information obtained as a result of the matching in the matching unit 316. For example, the output unit 317 can transmit cause information to the user terminal 220 via the communication unit 311.

  The service support system 210 can include a CPU, RAM, and flash memory or HDD (not shown). The flash memory or HDD may be the same as or different from the storage unit 313 described above. The program stored in the flash memory or the HDD is temporarily read into the RAM, and the CPU executes the program read into the RAM, so that the CPU functions as each part of the service support system 210 shown in FIG. Can function. Here, a configuration realized using software will be described as an example. However, the configuration may be any of hardware, firmware, and software.

  At least a part of each part of the service support system 210 may be realized by distributed processing by a plurality of information processing apparatuses. Further, the service support system 210 may execute processing according to a program downloaded from a cloud server or the like (not shown). FIG. 3 is merely an example of the configuration, and the service support system 210 may include other configurations. Further, not all the configurations described in FIG. 3 are indispensable requirements.

  FIG. 4 is a diagram illustrating an example of a detailed configuration of the database 315 and the matching unit 316. In the present embodiment, the database 315 includes an occurrence situation database 450 and a cause database 460. The occurrence situation database 450 has a database for each type of accident. In the example of FIG. 4, the occurrence situation database 450 includes a fall accident occurrence situation database 451, an aspiration / suffocation accident occurrence situation database 452, and a drug accident occurrence situation database 453. Like the occurrence database 450, the cause database 460 has a database for each type of accident. In the example of FIG. 4, the cause database 460 includes a fall accident cause database 461, an aspiration / suffocation cause database 462, and a drug accident cause database 463. The common cause may be shared as the accident common cause database 465.

  The occurrence status database 450 and the cause database 460 store data groups obtained by systematizing (structuring and hierarchizing) each event related to the occurrence of an accident for each type of accident. The occurrence state database 450 and the cause database 460 each store a data group including a plurality of structured (structured and layered) records. In the present embodiment, a record stored in the occurrence status database 450 is referred to as an “occurrence status record”. A record stored in the cause database 460 is referred to as a “cause record”. In the present embodiment, the cause record includes a data structure common to the occurrence status record. For example, the item of the Nth item (N is a natural number) of a certain occurrence status record and the item of the Nth item of the cause record are structured to store data of the same type of item. That is, it is assumed that the same kind of events related to the occurrence of the accident are stored in the Nth item of the occurrence status record and the cause record. In the present embodiment, an item having an N value of “1” is treated as an item having the highest hierarchy, and an item having a lower hierarchy as the value of N increases.

  In addition to the data structure common to the occurrence status record, the cause record is associated with data indicating various factors of the occurrence of the accident such as “a viewpoint to be pressed and a candidate for the cause”. That is, the cause database 460 stores a data group in which each cause for each event related to the occurrence of an accident is associated. Details of the occurrence status record and the cause record will be described later.

  The matching unit 316 includes a keyword extraction unit 401, an input record acquisition unit 402, a matching rule holding unit 403, a matching method determination unit 404, a matching process execution unit 405, and a matching result output unit 406.

  The keyword extraction unit 401 extracts a keyword used for searching the database based on the information regarding the occurrence situation that received the input. For example, an accident report creation screen 500 displayed on the display unit 323 of the user terminal 220 as shown in FIG. 5 (described later) includes an input area for inputting a situation when an accident occurs. The keyword extraction unit 401 can extract keywords based on information input to the input area. For example, in the case of a fall accident, “room” is input as a keyword of “discovery / occurrence place”, and “bed” is input as more detailed information. In this case, the keyword extraction unit 401 extracts “room” and “bed” as keywords. Further, the input sentence may be decomposed into words or idioms using a method such as natural language analysis or software, and one or a plurality of keywords may be generated.

  The input record acquisition unit 402 selects from the occurrence situation database 450 a database corresponding to the type of accident that has been received by the reception unit 314. For example, when the type of accident for which the input has been accepted is “fall accident”, the input record acquisition unit 402 selects the fall accident occurrence situation database 451. Then, the input record acquisition unit 402 searches the selected fall accident occurrence situation database 451 using the keywords extracted by the keyword extraction unit 401, and acquires an occurrence situation record including all keywords as an input record. . The acquired input record is used in matching processing with the cause record stored in the cause database 460. The input record is sent to the matching method determination unit 404.

  The matching rule holding unit 403 holds matching rules. In the present embodiment, the matching process is performed by comparing corresponding items (N-th terms) of the input record and the cause record. As described above, the matching process for comparing the N-th terms is referred to as “lateral matching” in the present embodiment. In this embodiment, an example in which matching processing is basically performed using this horizontal matching will be described. However, another matching method is performed on an input record including a specific item (or a specific keyword). Sometimes. Details will be described later.

  The matching method determination unit 404 determines the matching method of the input record with reference to the matching rules held in the matching rule holding unit 403.

  The matching process execution unit 405 performs the matching process using the input record on the cause database 460 corresponding to the accident type according to the matching method determined by the matching method determination unit 404. As described above, when the accident type is a fall accident, the matching process execution unit 405 executes a matching process on the fall accident cause database 461. For example, the matching process execution unit 405 determines whether the keyword included in the Nth item of the input record to be processed matches the keyword included in the Nth item of the cause record to be processed. If they match, the score corresponding to the weight associated with the Nth item is added to the score accumulated in the cause record to be processed. Such matching processing (lateral matching processing) is performed on all cause records of the candidate for processing in the fall accident cause database 461. Further, the above matching process is performed while changing the input record to be processed. Since the score which matched is accumulated and added, the score of a cause record with high coincidence with an input record becomes high as a result.

  The matching result output unit 406 outputs the result of the matching process performed by the matching process execution unit 405. As a result of the matching process performed by the matching process execution unit 405, the score of each cause record is calculated. The matching result output unit 406 can output a cause record for which a score exceeding a predetermined threshold is calculated as a result of the matching process. Alternatively, the matching result output unit 406 outputs, as a matching result, data indicating various factors of the occurrence of an accident such as “a viewpoint to be pressed and a candidate for cause” associated with the cause record, not the cause record itself. May be.

  Next, details of the matching process will be described with specific examples.

  FIG. 5 is a diagram illustrating an example of an accident report creation screen 500 for a fall accident displayed on the display unit 323 of the user terminal 220. An accident report is a report that describes the contents, response status, cause analysis, future response, and preventive measures, etc., when an accident occurs (or when an accident is found). The user (care facility staff) of the user terminal 220 inputs necessary items according to the creation screen 500. In addition, items already input on another screen (not shown) may be reflected on the creation screen 500.

  The input area 501 is an area in which the user of the user terminal 220 inputs the date and time when the fall accident was discovered and the date and time when the fall accident occurred. The input area 502 is an area in which the user of the user terminal 220 inputs a situation where a fall accident is found and a situation where a fall accident has occurred. The input area 503 is an area where the user of the user terminal 220 inputs a place where a fall accident is found and a place where the fall accident has occurred. The input area 504 is an area where the user of the user terminal 220 inputs a discoverer who has found a fall accident. The creation screen 500 illustrated in FIG. 5 illustrates a part of the input area. For example, a screen for inputting another input area is displayed on the display unit 323 by scrolling the screen.

  FIG. 6 shows the occurrence status record groups 610 and 620 in the occurrence status database 450 including the input areas 601, 602, and 603 displayed on the creation screen 500 of FIG. 5 by scrolling or in another screen, and events corresponding to these input areas. , 630. The occurrence status record groups 610, 620, and 630 are records related to external factors. As described with reference to FIG. 1, categories are classified among external factors. In the example of FIG. 6, a category of “discovery / occurrence location”, a category of “obstacle”, and a category of “personal” An example exists.

  The data structure of the occurrence status record stored in the occurrence status database 450 will be described taking the occurrence status record group 610 as an example. The occurrence status record has a hierarchical structure as described above. In the example of FIG. 6, the highest hierarchy is displayed as “Lv1”, and the number of levels increases as “Lv2” and “Lv3” as the hierarchy is lowered. Since FIG. 6 is a record related to “external factor” as described in FIG. 1, “external” data is included in the item of the highest hierarchy. Further, since the record group 610 is a record group of the category “discovery / occurrence place”, the item of the “Lv2” layer includes the data of “place”. Subsequent hierarchical items include records including items that can be input in the input area 601. As shown in FIG. 6, the occurrence status record sets more detailed (specific) contents as it goes from the highest hierarchy to the lower hierarchy.

  In the input area 601, a plurality of items that can be checked by check boxes are listed as candidates for the discovery / occurrence location. In this example, “Living room” is checked. In addition, the “room” further includes a radio button so that a detailed location in the room can be specified. In this example, “toilet” is selected. Information input by the input unit 320 in such an input area 601 displayed on the display unit 323 of the user terminal 220 is transmitted from the user terminal 220 to the service support system 210.

  In the service support system 210, the keyword extraction unit 401 extracts keywords based on information transmitted from the user terminal 220. In this example, “room, toilet” is extracted as a keyword based on the transmitted data as a keyword of the category “discovery / occurrence location”. And the input record acquisition part 402 acquires the occurrence situation record corresponding to the keyword from the fall accident occurrence situation database 451 as an input record. That is, in the example of FIG. 6, the record 611 is acquired in the record group 610 as an input record of the category “discovery / occurrence place”.

  Similarly, a corresponding input record is acquired from the “obstacle” category record group 620 according to the item input in the input area 602, and the “personal” category category is acquired according to the item input in the input area 603. A corresponding input record is acquired from the record group 630.

  That is, in the example of FIG. 6, the occurrence record 611, 621, 622, 631, 632, 633 is acquired as an input record by the input record acquisition unit 402 according to the items input in the input areas 601, 602, 603. It will be. These input records are used for matching processing as will be described later.

  FIG. 7 shows input areas 701 and 703 displayed on the creation screen 500 in FIG. 5 by scrolling or in another screen, input areas 501 included in the creation screen in FIG. 5, and occurrence status database 450 corresponding to these input areas. The record group 710 of FIG. The record group 710 is a record group related to internal factors. Among the internal factors, the categories are classified into “action at the time of accident”, “unusual appearance”, “disease / disease / symptom”, and “drug”. The example of FIG. 7 shows an example of the occurrence status record of the category “action at the time of accident”.

  The record group 710 includes records corresponding to items that can be input in the input area 701, similarly to the content described in the external factor of FIG. 6, and the keyword extraction unit 401 is transmitted from the user terminal 220. Keywords are extracted based on the information. And the input record acquisition part 402 acquires the occurrence situation record corresponding to the keyword from the fall accident occurrence situation database 451 as an input record. That is, in the example of FIG. 7, records 711, 712, and 713 are acquired in the record group 710 of the category “action at the time of accident”.

  In the case of an internal factor as shown in FIG. 7, in addition to information input in the input area of the corresponding category, information input in other input areas is used as a keyword of a predetermined item of the record. Can be used. For example, in the input area 501, since the discovery date and time when the accident was discovered and the occurrence date and time when the accident occurred are input, the keyword extraction unit 401 selects the keyword in the time zone based on the input date and time. Extract. For example, as shown in a table 721, a table is prepared in which a value input in advance as an accident report discovery / occurrence date / time is associated with a time zone. The keyword extraction unit 401 refers to the table 721 and determines, for example, whether the time zone is “early morning”, “daytime”, “nighttime”, or “midnight”. Then, as shown in the record group 730, the input record acquisition unit 402 acquires a record group 730 including the keyword (“night” in this example) in the “Lv6” hierarchy of the record group 710 as an input record. That is, by diverting a value already input in another input area, it is possible to save the trouble of re-input, and even if there is an input omission, the input record acquisition unit 402 uses an appropriate record as an input record. Can be acquired.

  Similarly, the input area 703 is an input area other than the input area corresponding to the category of “action at the time of accident”, and indicates an area for selecting an accident occurrence situation. The table 722 is a table in which values input to the input area 703 are associated with corresponding keywords. Based on the value input in the input area 703 and the table 722, the keyword extraction unit 401 determines whether “helping”, “not helping”, or “NULL” that contains nothing. . Then, as shown in the record group 730, the input record acquisition unit 402 acquires a record group including the keyword (in this example, “in-service” in the hierarchy) of the record group 710 as an input record.

  As described above, the matching rule holding unit 403 holds table information for referring to values input in other input areas, and various types of information indicating input destinations for inputting keywords obtained by reference. The keyword extraction unit 401 and the input record acquisition unit 402 can perform processing with reference to the matching rule held in the matching rule holding unit 403.

  Similarly, the input record acquisition unit 402 also acquires input records of “different from usual”, “disease / disease / symptom”, and “drug” which are other categories.

  FIG. 8 is a diagram illustrating an example of an input record related to an external factor acquired by the input record acquisition unit 402. In accordance with the processing described with reference to FIG. 6, the input records of each category are acquired. The matching process execution unit 405 performs a process of matching each input record of each category obtained in this way with each cause record stored in the cause database 460. Note that, as described in FIG. 7, items that are treated as external factors, such as the items 801 and 802, are set as keywords of specific items of the internal factors, and items handled in a certain category , Sometimes used in other categories.

  FIG. 9 is a diagram illustrating an example of an input record related to an internal factor acquired by the input record acquisition unit 402. In accordance with the processing described with reference to FIG. 7, the input records for each category are acquired. The item 951 includes the keywords of the items 801 and 802 in FIG. In the examples so far, values have been defined in advance in the input area by radio buttons, check boxes, etc., and the defined values (keywords) are used as they are. However, the present invention is not limited to this. . For example, as shown in an item 960, it is assumed that there is an item “I am tired after bathing” in the input area options. In this case, for example, the keyword extraction unit 401 can set “bathing” as indicated by an item 955 as a keyword and can also set “bathing fatigue” as indicated by an item 956. The keyword extraction unit 401 may extract such keywords according to the rules held in the matching rule holding unit 403, for example.

  Further, although the description has been given taking as an example a mode in which options are included in advance in the input area, the input area may be a free entry field. In this case, the keyword extraction unit 401 may extract keywords based on the input information.

  Next, the structure of the cause database 460 will be described.

  FIG. 10 is a diagram schematically illustrating an example of a cause record included in the cause database. The cause record included in the cause database 460 includes the same hierarchical structure as the occurrence status record included in the occurrence status database 450.

  For example, FIG. 10A shows an example of the structure of the cause record regarding the external factor, and the first portion 1001 of the cause record is the same as the structure of the input record (occurrence status record) of FIG. Structure.

  However, for a keyword set in each item of the occurrence status record, the cause record has a form in which a synonym, synonym, synonym, other language, paraphrase, wording, and the like of the keyword can be set. This is because, for example, the matching process also makes a match even when a notation fluctuation of a keyword included in each item of the occurrence status record occurs. For example, the item “bed” will be described as an example. The “bed” item in the cause record includes “bed”, “bed”, “bet”, “bed”, etc. In this way, a plurality of keywords may be set.

  The cause record further includes a second portion 1002. The second part 1002 includes data indicating various factors of the occurrence of an accident such as “a viewpoint to be pressed and a candidate for cause” according to the contents of each first part 1001. That is, the cause record can be said to be data in which a cause (second portion 1002) with respect to an event (first portion 1001) related to the occurrence of an accident is associated.

  FIG. 10B shows an example of the structure of the cause record relating to the internal factor. Like the external factor, the first portion 1051 of the cause record is the input record (occurrence status record of FIG. 9). ), And the second part 1052 of the cause record includes various types of accident occurrences such as “a viewpoint to be pressed and a candidate for cause” according to the contents of the first part 1051. Data indicating factors and the like are included.

  FIG. 11 is a schematic diagram for explaining the matching process executed by the matching process execution unit 405 in accordance with the matching method determined by the matching method determination unit 404.

  Prior to the description of the matching process, first, the type of matching method determined by the matching method determination unit 404 will be described. The matching method determination unit 404 refers to the matching rules held in the matching rule holding unit 403 and determines a matching method corresponding to the input record. The types of matching methods in the present embodiment include “horizontal matching”, “vertical matching”, and “intersection matching”. Of course, this is only an example, and various other matching methods such as “random matching” and “all-matching” are conceivable, and the present invention is not limited to this. Hereinafter, each matching method will be described.

[Horizontal matching]
As described above, “lateral matching” is a process of matching the same items at the same hierarchical level when matching each item of the input record with each item of the cause record included in the cause database. For example, in the example of FIG. 11, the item of the highest level (Lv1) of the input record 1110 of the category “discovery / occurrence location” and the highest level of the cause record 1152 included in the cause record 1151 group ( Match the items of Lv1). Specifically, the keyword included in the item of the highest hierarchy (Lv1) of the input record 1110 and the keyword included in the item of the highest hierarchy (Lv1) of the cause record 1152 are compared and matched. Determine. If they match, the score using the weight according to the weight coefficient 1102 of the input record is added to the score accumulated in the cause record 1152 (initial value is 0). Next, the items of the second hierarchy (Lv2) of the input record 1110 in the category of “discovery / occurrence location” and the items of the second hierarchy (Lv2) of the cause record 1152 included in the cause record 1151 group are matched. To do. In the example of FIG. 11, when the matching of the items of the lowest hierarchy (Lv7) and (Lv7) is completed, the occurrence status record 1110 continues to be matched with the next cause record 1153 included in the cause record group 1151. Processing will be performed.

  In this manner, the input record 1110 of the category “discovery / occurrence location” is matched with all the cause records included in the cause record group of the category “discovery / occurrence location”. When the processing of the input record 1110 is completed, matching processing is similarly performed using the input record 1111 next to the category of “discovery / occurrence location” in the occurrence status record group 1101 as the input record to be processed.

  When the matching process using the input record of the category “discovery / occurrence location” is completed, the input record of the category “obstacle” as the next category and the “obstacle” in the cause record group 1151 are continued. Matching processing with the cause record of the category is performed.

  In the present embodiment, the weighting factor 1102 is set according to the hierarchy. Specifically, the weighting coefficient 1102 is a coefficient that increases the weight as the level is lower. As described in the above examples, more detailed items are set in the occurrence status record and the cause record in the present embodiment as the hierarchy goes down. For example, taking the category of “discovery / occurrence location” as an example, if “room” is set at the upper level, “bed” is set at the lower level, and “second” is set at the lower level. Bunk beds ”are set. The more detailed the item, the more specific the viewpoint and cause candidates to be suppressed. Therefore, by using the weighting factor 1102 that increases the weight as the level is lower, the score of the cause record when the detailed items match can be increased. Therefore, it becomes easy to select a concrete “candidate of viewpoint and cause to be pressed”.

  In the example of FIG. 11, an example in which processing is performed for each category has been described. However, as described above, the highest hierarchy of the occurrence status record and the cause record is “internal factor” or “external factor”. And the next lowermost hierarchy can include items of a category such as “discovery / occurrence location”. Therefore, a form may be used in which all cause records are processed as processing targets for the input records to be processed without being conscious of the category.

[Vertical matching]
FIG. 12 is a diagram for explaining “vertical matching” and “crossing matching”. “Vertical matching” will be described. “Vertical matching” is a process of matching only items in a predetermined hierarchy in each cause record using a keyword in a specific hierarchy of input records of a specific category. In this way, matching is performed only for a specific hierarchy in each cause record, that is, matching is performed in the column direction (vertical direction). As a result, matching across categories is performed. It is assumed that a specific hierarchy of this specific category is defined in advance by a matching rule held in the matching rule holding unit 403. That is, when the matching method determination unit 404 receives an input record from the input record acquisition unit 402, the matching method determination unit 404 refers to the matching rule held in the matching rule holding unit 403 and sets “vertical matching”. Determine if it applies. If applicable, the matching method determination unit 404 determines to further execute the “vertical matching” process using the keyword included in the item. If no keyword is included in the item, the process is not executed.

  A specific example will be described. As matching rules, the following contents are defined in advance. That is, it is assumed that a matching rule that executes matching between a keyword set in a specific item of a specific category and an item in a specific hierarchy of each cause record is defined. For example, when the keyword “flicker” is included in the “unusual” category item (Lv5) of the input record to be processed, “action at the time of accident” “disease / disease / symptom” When “vertical matching” is performed on the “drug” category hierarchy (Lv5), the matching method determination unit 404 determines.

  Note that “vertical matching” is a matching process performed in addition to “horizontal matching”. When processing an input record including a specific keyword (for example, “flicker”), “horizontal matching” itself is used. This processing is also performed on the input record to be processed.

  For the specific item corresponding to the specific keyword (flicker) defined in the matching rule, the matching process execution unit 405 searches only the items in the specific hierarchy across categories according to the defined matching rule. To do. If there is a matching item, the weight corresponding to the item is added to the score accumulated in the cause record including the item. For example, various causes such as physical causes, illness symptoms, effects of drugs, etc. can be considered as causes of wandering. So, for example, in the “unusual appearance” category, if “unsteadiness” is included as an unconventional appearance, the “movement” item in the “action at the time of accident” category is searched, and the “disease” Search for the “symptom” item in the “disease / symptom” category, and search for the “side effect” item in the “drug” category. As a result, for example, the cause record of “ADL (Activities of Daily Living) / muscle weakness” included in the cause record of “action at the time of accident” becomes high, or “disease / disease / symptom” The cause record includes “peripheral symptoms of dementia” and “cerebrovascular disease” as the cause, and the cause record of “drug” includes “sleeping medicine”, “anxiolytic drug”, and “antiepileptic drug” The score of the cause record included as a cause becomes high.

  According to such processing, it is possible to collect as much as possible possible causes. Then, a process with a high score is presented to the user, and the user is prompted to confirm. For this reason, when a multifaceted cause is considered, such as “flickering”, the score of the cause record including the possibility of the cause is added. For this reason, the matter which is omitted from consideration according to a user's experience etc. can be reduced. In other words, when the user (staff) enters the occurrence status, the cause record score for the cause that cannot be immediately noticed from the entered information is high, so the reason why the user could not notice Increase the chances of noticing Further, since the vertical matching can be performed on a plurality of hierarchies including layers relatively lower in the hierarchy (layers in which detailed items are defined), as described above, weighting when matching is increased. Therefore, because the score of the cause record that matches the vertical matching is relatively higher than the score of the cause record that does not match the vertical matching, the score of the cause record related to the cause of the “stagger” is higher in the above example. The possibility of being selected as a matching result is further increased.

[Cross-matching]
Next, “intersection matching” will be described. Cross matching allows the input record acquisition unit 402 to newly acquire an input record whose occurrence state is selected when the item to be processed of the input record is an item of a specific hierarchy in a specific category. And it is the process which performs the matching process mentioned above using the newly acquired input record. In other words, if the item to be processed in the input record is an item of a specific level in a specific category, a process for matching an item in a different level of a different category using a keyword included in the item It is. It is assumed that matching rules are defined in the matching rule holding unit 403 in advance for items and keywords in specific hierarchies of specific categories to be cross-matched. If no keyword is included in the item, the process is not executed.

  For example, items that were not entered by the user (thus, items that do not contain a keyword in a particular item in the input record) are treated as if the user had entered them, and matching was done indirectly. Will be done. A specific example will be described. For example, it is assumed that Parkinson's disease is input as “disease / disease / symptom”. At this time, the user knows that the resident has Parkinson's disease, but may not know the drug that the person uses. In this case, in the “drug” category, no drug is selected, that is, blank. By using cross matching, an input record related to “drug” can be handled as an input record including the name of a drug related to Parkinson's disease even if it is blank in this way. Specifically, according to the matching rule defined in the matching rule holding unit 403, a new input record is obtained for an input record in which the name of the drug related to the Parkinson's disease is included in the corresponding item of the “drug” input record The part 402 acquires and processes as an input record to be processed. Thereby, the horizontal matching regarding the category of “drug” is executed in a state where the name of the medicine is inputted.

  According to such processing, it is possible to collect as much as possible possible causes. Then, a process with a high score is presented to the user, and the user is prompted to confirm. For this reason, the matter which is omitted from consideration according to a user's experience etc. can be reduced. In other words, when the user (staff) enters the occurrence status, the cause record score for the cause that cannot be immediately noticed from the entered information is high, so the reason why the user could not notice Increase the chances of noticing Similarly to the vertical matching, the intersection matching is performed in a relatively lower layer (a layer in which detailed items are defined), so that, as described above, weighting when matching is increased. Accordingly, the score of the cause record that matches the cross matching is relatively higher than the score of the cause record that does not match the cross matching, so that the possibility of being selected as a matching result increases.

  Note that when performing cross matching, the weight of the item in the specific hierarchy may be set lower than the weight of the input record acquired based on the information actually input by the user. This is because it is more reliable that the name of the actually used “drug” is entered, that is, the drug actually taken by the resident.

  As described above, the matching process execution unit 405 performs the matching process for each input record according to the matching method determined by the matching method determination unit 404. As a result, each score of the cause record in the cause database 460 is obtained. The matching result output unit 406 outputs a cause record whose score satisfies a predetermined condition. For example, output cause records that exceed a predetermined threshold score, output a predetermined number of cause records in higher order of scores, output a predetermined number of cause records in order of higher scores for each category, and set It is possible to output for the number of records that have been set, or not to output if the set score is not reached. The output unit 317 displays various factors of the occurrence of the accident, such as the contents of the second parts 1002 and 1052 included in the cause record output from the matching result output unit 406, that is, “a viewpoint to be pressed and a cause candidate”. And the like are transmitted to the user terminal 220.

  Whether the rule held in the matching rule holding unit 403 is to be searched, whether the search is to be ended or the search is to be continued, or limited to a predetermined range when there is no next item in the search. A rule may be included that specifies whether to skip one and continue the search. Further, when executing the search, a rule may be included in which whether the whole sentence matches or the partial matches are set according to the item. Further, a rule for changing the weighting factor according to the category may be included. Also, the matching rule may be a rule that refers to other information published on the Internet, for example. For example, when Parkinson's disease and a keyword are input, information on a corresponding therapeutic drug or new drug may be acquired by searching the web or the like, and cross matching may be executed using the information.

  FIG. 13 is a diagram illustrating an example of the matching result screen 1300 displayed on the display unit 323 of the user terminal 120. Here, information on viewpoints and causes that should be pressed is displayed side by side in order from the top of the score. The user confirms the matching result screen 1300 and checks a reasonable item with the check box 1310. When an instruction to select the OK button 1320 is input through the input unit 320, the checked content is transmitted to the service support system 210 through the communication unit 321. In the service support system 210, the checked content is determined as a point of view and cause to be suppressed. The storage control unit 312 stores the determined viewpoint and cause data in the storage unit 313. The stored viewpoint data and cause data are read out by the storage control unit 312 when the accident report is created and automatically set.

  FIG. 14 shows an example of a viewpoint / cause search screen 1400 representing the viewpoint and cause to be finally obtained, which are to be pressed. The viewpoint and cause search result screen 1400 is displayed on the display unit 323 of the user terminal 220.

[User terminal flowchart]
FIG. 15 is a flowchart illustrating an example of a control method of the user terminal 220.

  In step S <b> 1505, the display control unit 324 causes the display unit 323 to display the accident report creation screen 500 in accordance with the instruction input to the input unit 320. The user of the user terminal 220 inputs various values and information according to the creation screen 500.

  In step S1510, the communication unit 321 transmits the information input to the input unit 320 to the service support system 210. Thereafter, matching processing is executed in the service support system 210.

  In step S1515, the display control unit 324 causes the display unit 323 to display the matching result screen 1300 based on the information transmitted from the service support system 210. The user of the user terminal 220 confirms the content displayed on the matching result screen 1300 and selects an item that seems appropriate.

  In step S <b> 1520, the communication unit 321 transmits the selected item to the service support system 210 based on the selection instruction input to the input unit 320.

  In step S <b> 1525, the display control unit 324 displays a viewpoint or cause search result screen 1400 based on the information transmitted from the service support system 210.

[Flowchart of Service Support System 210]
FIG. 16 is a flowchart illustrating an example of a service support method in the service support system 210.

  In step S <b> 1605, the reception unit 314 receives information transmitted from the user terminal 220 through the communication unit 311.

  In step S1610, the matching unit 316 performs a matching process. The flow of the matching process will be described later.

  In step S <b> 1615, the output unit 317 transmits the matching result to the user terminal 220 through the communication unit 311.

  In step S <b> 1620, the reception unit 314 receives the item selected on the user terminal 220 through the communication unit 311.

  In step S <b> 1625, the storage control unit 312 writes the data of the item received in step S <b> 1620 to the storage unit 313.

  In step S1630, the output unit 317 transmits viewpoint and cause search result information to the user terminal 220 through the communication unit 311 based on the items received in step S1620.

  FIG. 17 is a flowchart illustrating an example of detailed processing of the matching processing in step S1610.

  In step S <b> 1705, the keyword extraction unit 401 extracts keywords for the selected item based on, for example, information input by the user on the accident report creation screen 500.

  In step 1710, the input record acquisition unit 402 acquires the occurrence status record corresponding to the keyword extracted in step S1705 from the occurrence status database 450 as an input record. At this time, an input record is acquired using a database corresponding to each type of accident. An input record is acquired for each category. A plurality of input records may be acquired in each category.

  In step S1715, the matching method determination unit 404 refers to the matching rule held in the matching rule holding unit 403, and determines a matching rule to be applied to each input record acquired in step S1710. For example, in addition to “horizontal matching”, various matching rules such as “vertical matching” and “crossing matching” can be determined.

  In step S1720, the matching process execution unit 405 uses each input record acquired in step S1610 to perform a matching process on each cause record stored in the cause database 460 according to the matching rule determined in step S1615. I do. At this time, matching processing is performed on the cause record stored in the database corresponding to the type of accident. The matching process execution unit 405 adds the scores accumulated in each cause record according to the matching result.

  In step S1725, the matching result output unit 406 specifies a matching result based on the score obtained in step S1720. For example, a cause record that exceeds a predetermined threshold is determined as a candidate for a matching result.

  In step S1730, the matching result output unit 406 outputs the matching result specified in step S1725 to the output unit 317.

  FIG. 18 is a flowchart illustrating an example of detailed processing in step S1720.

  In step S1805, the matching process execution unit 405 selects an unprocessed item in the input record to be processed. Processing is performed for each item from the item of the highest hierarchy of the input record to be processed toward the item of the lower hierarchy.

  In step S1810, the matching process execution unit 405 determines whether or not an item in the next hierarchy has been selected in step S1805. If the next item can be selected, the process proceeds to step S1815; otherwise, the process proceeds to step S1835.

  In step S1815, the matching process execution unit 405 determines whether the item to be processed is an item that matches a predetermined rule. For example, it is determined whether the item is a target of vertical matching or cross matching. If the item matches the predetermined rule, the process advances to step S1820. In step S1820, the matching process execution unit 405 executes a process according to the predetermined rule. Otherwise, the process proceeds to step S1825.

  In step S1825, the matching process execution unit 405 determines whether the item to be processed matches the keyword of the corresponding item in the cause record. That is, horizontal matching as described above is performed. If they match, the process proceeds to step S1830. Otherwise, the process proceeds to step S1832.

  In step S1830, the matching process execution unit 405 adds a score corresponding to the weight of the item to be processed to the score of the cause record to be processed. Then, the process proceeds to step S1832.

  In S1832, the matching process execution unit 405 determines whether to proceed to the next item. For example, when the matching result is inconsistent, there is a case where it is not desired to proceed to the next item, or there are cases where the structure of the cause record to be processed exists only up to an intermediate level. In such a case, if the currently processed item is an Lv3 item, the process proceeds to step S1835 without proceeding to the next item in step S1832. Otherwise, the process returns to step S1805. In this way, matching processing is performed between each item in the input record to be processed and each item in the cause record to be processed.

  If it is determined in step S1810 that the next item cannot be selected, the process advances to step S1835.

  In step S1835, the matching process execution unit 405 determines whether there is a cause record to be processed next. If there is a next cause record, the process proceeds to step S1840. Otherwise, since the processing for all the cause records is completed, this processing is terminated.

  In step S1840, the matching process execution unit 405 updates the cause record to be processed.

  In step S1845, the matching process execution unit 405 clears information on processed items in the input record. That is, each item of the input record is changed to an unprocessed item. Then, the process returns to step S1805. As a result, the horizontal matching between the highest level items is performed again from step S1805 on the cause record of the processing target updated in step S1840.

  FIG. 19 is a flowchart illustrating an example of detailed processing in step S1820.

  In step S1905, the matching process execution unit 405 determines whether the processing target item is a vertical matching target. If it is the target of vertical matching, the process proceeds to step S1910. Otherwise, the process proceeds to step S1935.

  In step S1910, the matching process execution unit 405 executes a search for items of a specific hierarchy defined in the matching rule.

  In step S <b> 1915, the matching process execution unit 405 determines whether or not it matches the keyword of the item in the specific hierarchy of the cause record. If they match, the process proceeds to step S1920, and the score corresponding to the weight of the item to be processed in the input record is added to the score accumulated in the matched cause record. Then, the process proceeds to step S1925.

  In step S1925, the matching process execution unit 405 determines whether the cause record to be processed is the last cause record to be processed. That is, it is determined whether it is the last row in the column direction. If it is the last line, the process proceeds to step S1935. Otherwise, the process proceeds to step S1930, the cause record to be processed is updated, and the process returns to step S1910.

  In step S1935, the matching process execution unit 405 determines whether the processing target item of the input record is a cross matching target. If it is an object of intersection matching, the process proceeds to step S1940, and if not, this process ends.

  In step S1940, the matching process execution unit 405 adds, as an unprocessed input record, an input record in which a specific keyword specified in the matching rule is input to the target item specified in the matching rule. Thereby, the horizontal matching using the input data in a state where the specific keyword is input is performed. The above is the description of the flowchart.

  So far, the case of a fall accident has been described as an example. In the following, in addition to a fall accident, a specific example of an accident that may occur in a nursing facility and its factors will be described. In addition to a fall accident, an accident occurring at a nursing facility includes an aspiration / suffocation accident (hereinafter referred to as an “aspiration accident”). In an aspiration accident, in addition to external factors such as the contents of the meal at the time of the accident, the location of the meal, the staff's assistance method, and the way the staff is involved, the resident's eating method, physical and physiological factors, Various internal factors related to the resident, such as illness, illness, symptoms, and drugs taken, can be cited as factors for accidental aspiration. In the case of an aspiration accident, the causal food type, the presence or absence of the use of a trolley, the meal time, the meal location, the tools used, and external factors such as dentures are classified in detail. In addition, staff assistance methods and involvement methods, including cooperation with the kitchen, are categorized in detail according to how they responded before, during and after meals. As for residents, the ability to eat, posture during meals, dietary movements, nutritional status, appetite / motivation, oral care status, environmental changes, unusual situations, diseases, diseases, Classify internal factors in detail, from symptoms to medications. In this way, by making the occurrence of the accident more detailed, it is possible to accurately match the causes related to the accident and the viewpoints to be suppressed. For example, in the case of a resident who suffers from dementia, “Is it better to recognize food, or something that has a clear taste and temperature is better?” “Respond to other residents' meals. Matching results screen is based on the viewpoint of `` Is it possible to eat, mix and eat anything, or if you are a resident with Parkinson's disease? '' 1300 will be listed.

  Another accident that occurs in nursing homes is a drug accident. In the case of a drug accident, until the resident takes the drug, such as prescribing by a doctor, dispensing and delivery at a dispensing pharmacy, drug management by a nursing staff at a nursing facility, or nursing assistance by a nursing staff or nursing staff A series of work flows cause drug accidents. Therefore, it can be classified into external factors such as factors of dispensing pharmacies, factors of nursing staff, and factors of nursing staff. Further, each classification can be further detailed. As a cause of a medicine accident and a point to be kept down, for example, a dispensing pharmacy error can be detailed into “dispensing error”, “packing error”, “printing error”, “mistake of doubt inquiry”, and the like. Nursing staff mistakes, for example, "Receiving error" "Setting unprescription medicine" "Setting wrong person" "Setting counting / measurement incorrectly" "Setting timing wrong" "Setting prescription days incorrectly" It can be refined to “set wrong taking method”, “forget to pass”, etc. For example, “I took a different medicine”, “I took a wrong person”, “I took a wrong timing”, “I took a wrong count / measurement, etc. It can be refined such as “I missed it”, “I missed my dose”, “I didn't take it”, and so on. The matching cause screen 1300 lists the cause and the viewpoint to be suppressed for each occurrence case.

  In the embodiment described so far, an accident that may occur in a facility has been described as an example. However, the present invention is not limited to this and can be applied to various cases. As an example of a case, it can be applied to incidents including accidents and near-misses. That is, the present invention can be applied not only to the case of creating an accident report but also to the case of creating a report or the like when a near-miss occurs in daily work. Also, it can be applied to other business cases other than accidents. An example is a care plan. Based on the assessment result of each resident, the optimal care plan candidate is derived. As a method for realizing this application example, each assessment item is classified, organized (structured, hierarchized), and databased. At the same time, cases of care plans are classified and systematized (structured, layered) to create a database. Since cases other than care plan cases for each assessment item are also assumed, it is possible to carry out vertical matching, cross matching, etc. while holding an arbitrary matching rule as in the above-mentioned fall accident. Examples of classifications for both assessment and care plans include: “Food / moisture”, “Oral care”, “Bathing”, “Adjustment”, “Excretion”, “Moving / transferring / body function”, “Sleeping”, “Hobbies / activities”, “Memory / cognition”, “ Various life scenes such as “Mental / Behavior”, “Health Management / Medical Care”, “Other Life”, and the abilities, motivation, characteristics, etc. of residents. Based on these classifications, the most appropriate care plan based on the resident's assessment is used to provide specific and appropriate life support that comprehensively considers and judges the abilities, motivation and characteristics of each resident. It can be carried out.

  In addition, the case may be a case in which an improvement has occurred or an improvement can occur, not a case in which a problem has occurred or a problem may occur. For example, if there is a certain event in a nursing facility (for example, decorating flowers, changing the route of a walk, making a different call, etc.), some improvement (for example, the mood of the resident) May have improved, began to sing songs, increased chatter, etc.). As described above, the configuration and processing described in the above-described embodiment can be applied to a case in which an improvement has occurred or an improvement can occur, not a case in which a problem has occurred or a problem may occur.

  Moreover, although the example used mainly in the nursing care facility was mentioned as an example until now, it is not restricted to this. For example, a case such as an accident of the same type can occur in a medical service facility, and the above-described service support system 210 may be used also in a medical service facility. In addition, the service recipient does not need to be an elderly person or a patient, and may be applied to a nursery school, a schoolchild club, or the like having a child as a service recipient, for example. In addition, the service support system 210 described in the above-described embodiment can be applied to cases that may occur in various scenes such as school and workplace.

  The systematization, structuring, and hierarchization of the various types of data described above can also be tagged with data for meaning. At the same time, various rules are implemented by a system equipped with artificial intelligence functions, and more limited databases are used as matching sources, rather than using a limited database as a target for matching. And speeding up can be realized. For example, the matching rules held in the matching rule holding unit 403 may be adaptively changed based on information displayed on the matching result screen 1300 and information on items selected by the user through the matching result screen 1300. For example, a plurality of pieces of information displayed on the matching result screen 1300 and information on items selected by the user through the matching result screen 1300 may be collected and used to optimize the weighting factor. Further, the database may be reconstructed based on information on items selected by the user through the matching result screen 1300. For example, a learning model may be constructed using the contents displayed on the user terminal 220 on the matching result screen 1300 and the items selected by the user through the matching result screen 1300 as teacher data. And the structure which outputs a matching result using the constructed learning model as a matching part may be adopted. The learning model may be constructed according to each of the service recipients, or may be grouped under specific conditions and a learning model may be constructed for each group.

[Modification]
Moreover, in the example demonstrated so far, although the example in which a matching process is performed by a user performing input through an accident report as shown in FIG. 5 was described as an example, the present invention is not limited to this. For example, the service support system 210 may automatically fetch data at a predetermined timing, and the matching process may be performed based on the fetched data. According to such processing, it is also possible to output a warning when an incident or the like occurs due to a change in physical condition, for example.

  An explanation will be given by taking a tenant of a care facility as an example. In the field of a care facility, the staff is required to always put up an antenna and take an appropriate response to the resident's condition change and danger. However, in daily life when staff provide daily care services on a shift basis, they are often unaware of resident status changes and dangers. This is because it may not be possible to immediately identify that it is an abnormal state if only one point is taken out. For example, if the amount of food intake or water intake continues for a predetermined number of times or less than a certain amount, if there is no excretion for a certain period of time, or if vitals such as body temperature, pulse, blood pressure, weight, etc. are specified for a certain period If the state continues to be different from normal, such as when the value is out of the range, there is a possibility that the resident's state changes and dangers occur. The embodiment described above can also be applied to such a form of alerting.

  A case where the case type is weight change will be described as an example. Data such as the weight of the resident is accumulated in the storage unit 313 and the like. Therefore, the reception unit 314 can access the data stored in the storage unit 313 and the like at a predetermined timing, and input the stored data as an occurrence status. Then, the input data is sent to the matching unit 316. As described above, the matching process may be automatically performed at a predetermined timing.

  The cause database 460 can include records of items related to time-series transitions. For example, when a predetermined reference date is set to the value (weight) of the Lv1 layer, the value of the Lv2 layer may store a cause record for an allowable value (weight) on the next day of the reference date. The matching unit 316 performs a matching process using an input record in which accumulated weight data is arranged as a time-series item. In the example of this process, a method of increasing the score can be used in the hierarchy after Lv2 when the item does not match the cause record item (allowable value (weight)). That is, when the item of the input record in the hierarchy after Lv2 matches the item of the cause record in the hierarchy after Lv2 (that is, in the case of a value within the allowable range), the matching process is terminated and does not match ( In other words, in the case of a value that is not within the allowable range, a method of adding scores may be used. When such a process is performed, the score of the cause record (for example, the cause record corresponding to the fact that the weight is decreasing daily) increases in the item and the value that should be noted about the physical condition change is related to the cause record. The cause (for example, attention because there is a possibility of illness) is output from the matching unit 316. The output unit 317 can also send a matching result output from the matching unit 316 to the user terminal 220 to urge the user to warn.

  As described above, according to the present embodiment, based on the occurrence status of various accidents occurring in the facility, the cause of the accident and candidates for the viewpoint to be suppressed are derived, and the analysis, response / prevention of the accident is performed. Can assist in planning. Further, the records of the occurrence status database 450 and the cause database 460 can be easily added or changed. Accordingly, maintenance is facilitated when a new item or the like needs to be set.

  In addition, according to the present embodiment, even a staff with a high level of specialized knowledge and experience value can ensure accuracy and completeness of a certain level or more simply by selecting the situation of the accident that occurred faithfully and accurately from the options. In addition, it is possible to display a list of candidates for the cause of the accident and the viewpoints to be suppressed. For this reason, it is possible to reduce the time required to investigate various specialized books and other materials, and to efficiently implement cooperation with related places based on the listed contents.

  In addition, according to the present embodiment, it is possible to prevent a true cause that is not noticed by the staff of the facility from being overlooked. In addition, it is possible to present the causes, factors, risk factors, considerations, etc. according to the situation of the accident to users such as staff from a multifaceted viewpoint.

  The embodiments described above are for facilitating the understanding of the present invention, and are not intended to limit the present invention. Each element included in the embodiment and its arrangement, material, condition, shape, size, and the like are not limited to those illustrated, and can be changed as appropriate. In addition, the structures shown in different embodiments can be partially replaced or combined.

  The program for realizing each embodiment of the present invention described above may be stored in a storage medium. If this storage medium is used, the program can be installed in any computer that is already used for other purposes in the facility or a computer that is newly purchased. Here, the storage medium storing the program may be a non-transitory storage medium. The non-transitory storage medium is not particularly limited, but may be a storage medium such as a CD-ROM.

210 ... Service support system, 220, 220a, 220b ... User terminal, 311 ... Communication unit, 312 ... Storage control unit, 313 ... Storage unit, 314 ... Reception unit, 315 ... Database, 316 ... Matching unit, 317 ... Output unit, 320 ... Input unit, 321 ... Communication unit, 323 ... Display unit, 324 ... Display control unit, 325 ... Storage unit, 326 ... Storage control unit, 401 ... Keyword extraction unit, 402 ... Input record acquisition unit, 403 ... Maintaining matching rule 404, matching method determination unit, 405 ... matching processing execution unit, 406 ... matching result output unit, 450 ... occurrence situation database, 451 ... fall accident occurrence situation database, 452 ... aspiration / suffocation accident occurrence situation database, 453 ... Drug accident occurrence database, 460 ... cause database, 461 ... falling Cause database, 462 ... aspiration, choking the cause of the accident database, 463 ... medicine cause of the accident database.

Claims (10)

A cause database that stores, for each case type, a data group that associates each cause for each event related to the occurrence of the case;
An accepting unit that accepts an input including a type of a case that has occurred and a state of occurrence of the case;
A matching unit that matches the received occurrence status and a data group corresponding to the type of the received case stored in the cause database;
A service support system comprising: an output unit that outputs a cause obtained as a result of matching in the matching unit. The matching unit accumulates and adds, to each data, a score based on a result of comparing each received occurrence situation and each data corresponding to the received case type stored in the cause database. And
The service support system according to claim 1, wherein the output unit outputs the cause associated with the data for which a cumulative score satisfies a predetermined condition. An occurrence situation database that stores a plurality of occurrence situation records that organize each event related to the occurrence of the incident for each type of the incident;
An acquisition unit for acquiring an occurrence status record corresponding to the type and occurrence status of the accepted case as an input record from the occurrence status database;
Further comprising
The cause database stores cause records including data structures organized in the same manner as the input records as data included in the data group,
The matching unit matches a keyword included in a specific hierarchy of the acquired input record with a keyword included in the specific hierarchy of each cause record stored in the cause database. Service support system described in 1. The matching unit is
A holding unit for holding matching rules;
The service support system of Claim 3 provided with the determination part which determines the method of matching based on the said rule.   The service support system according to claim 4, wherein the rule includes a rule for matching with a predetermined hierarchy in each cause record using a keyword of the specific hierarchy of the input record.   6. The rule according to claim 4, wherein when the processing target item of the input record is an item of a specific hierarchy, the rule includes a rule for newly acquiring an input record in which an occurrence state of the item is selected. Service support system. The reception unit can further receive a matter selected by the user among the causes output by the output unit,
The service support system according to any one of claims 1 to 6, wherein the cause database is reconstructed based on a cause output by the output unit and an item selected by the user. The event includes items related to the transition of time series data,
The reception unit inputs the accumulated data regarding the service provider as the occurrence state at a predetermined timing,
The service support system according to claim 1, wherein the matching unit matches the accumulated data with an item related to transition of the time-series data. Receiving an input including the type of incident that occurred and the occurrence status of the incident;
Of the data group stored in the cause database that stores the data group that associates each cause for each event related to the occurrence of the case with the received occurrence state, for the received case Matching the data group corresponding to the type;
Outputting a cause obtained as a result of the matching. On the computer,
Receiving an input including the type of incident that occurred and the occurrence status of the incident;
Of the data group stored in the cause database that stores the data group that associates each cause for each event related to the occurrence of the case with the received occurrence state, for the received case Matching the data group corresponding to the type;
And a step of outputting a cause obtained as a result of the matching.