Consent acquisition device, consent acquisition method, and program

Abstract

To acquire the consent of concerned parties including third parties other than a person in need of support.SOLUTION: In a consent acquisition system in which a consent acquisition server is connected to an apparatus of related parties including hospitals, schools, and support facilities via a network, a consent acquisition server 1 for acquiring consent to support of a person in need of support includes: a communication unit 16 for accepting an acquisition request of a user of a first related party-apparatus to acquire consent from the first related party-apparatus used by the first related party related to a person in need of support; a status acquisition unit 11 for acquiring a status indicating a situation of a support factor that is a factor of support; a consent acquisition unit 13 for identifying a consenter candidate who is the other party of the consent according to the status and acquiring a consent result of the consent request to a second related-party apparatus used by the identified consenter candidate; and a cooperation authorization unit 15 for issuing a permission ticket indicating that the support is permitted, and transmitting the permission ticket to the first related party-apparatus via the communication unit 16, when the consent result indicates a consent to the support.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a technique for supporting the acquisition of consent from related parties for some kind of support for a subject, such as information sharing or proxy procedures. [Background technology]

[0002] Currently, social problems such as child abuse and domestic violence (DV) are becoming more apparent. As a result, there is an increasing need for support for those in need (those requiring support), such as abused children, children in poverty, and victims of domestic violence. This support is expected to involve sharing information about the target individuals and handling procedures on their behalf.

[0003] For example, Patent Document 1 proposes a technology for realizing the linking of personal information. Patent Document 1 addresses the issue of "eliminating the need to obtain consent for the provision of personal information to a third party" such as medical information. To this end, Patent Document 1 discloses a processing system 100 that "distributes and stores original data in the form of fragmented shares across multiple servers, and each of the multiple servers 20A to 20C has a statistical processing unit that performs statistical processing on the shares used in calculations requested by a requesting terminal device 30, and a calculation processing unit that performs the calculations requested by the requesting terminal device 30 using statistical information converted in the statistical processing." [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2022-150526 Summary of the Invention [Problem to be solved by the invention]

[0005] In Patent Document 1, the data is converted into statistical information that does not identify individuals, thereby avoiding the need for "consent" (paragraph 0050). However, statistical information alone cannot provide support to the target individuals. Therefore, some form of "consent" is required. Furthermore, the target individuals mentioned above include children, victims of domestic violence, and dementia patients, and it may be difficult or impossible for the individuals themselves to "consent."

[0006] Therefore, an object of the present invention is to realize the acquisition of consent from related parties, including third parties other than the recipient, regarding the provision of personal information, delegation of proxy, etc. [Means for solving the problem]

[0007] In order to solve the above problem, in the present invention, consenters to support are dynamically identified according to a status indicating the state of support factors for a subject who requires support.

[0008] More specifically, a consent acquisition device for obtaining consent for support for a subject who requires support has: a communication unit that receives, from a first related party device used by a first related party related to the subject, a request for obtaining the consent, which is a request from the user of the first related party device; a status acquisition unit that acquires a status indicating the status of the support factors that will be the cause of the support; a consent acquisition unit that identifies a consenting party candidate who is the other party to the consent based on the status, creates a consent request for a second related party device used by the identified consenting party candidate, and acquires a consent result for the consent request via the communication unit; and a support authorization unit that, if the consent result indicates consent to the support, issues a permission ticket indicating that the support is permitted and sends the permission ticket to the first related party device via the communication unit.

[0009] Furthermore, the present invention also includes a consent acquisition method using the consent acquisition device, a program for causing the consent acquisition device to function as a computer, and a recording medium for storing the program.Furthermore, the present invention also includes a consent acquisition system including the consent acquisition device, other devices that constitute the consent acquisition system, and subcombinations thereof. [Effects of the Invention]

[0010] According to the present invention, it is possible to obtain consent from parties involved in support, including third parties other than the recipient. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a system configuration diagram of a consent acquisition system according to an embodiment of the present invention. [Figure 2] 1 is a functional block diagram of a consent acquisition server 1 according to an embodiment of the present invention. [Figure 3] 2 is a functional block diagram of a child consultation center terminal 20 according to an embodiment of the present invention. FIG. [Figure 4] FIG. 2 is a functional block diagram of a hospital terminal 30 according to an embodiment of the present invention. [Figure 5] FIG. 2 is a functional block diagram of a school terminal 40 according to an embodiment of the present invention. [Figure 6] FIG. 2 is a functional block diagram of a support facility terminal 50 according to an embodiment of the present invention. [Figure 7] FIG. 2 is a hardware configuration diagram of a consent acquisition server 1 according to one embodiment of the present invention. [Figure 8] FIG. 10 is a diagram showing a consent management list 171 used in one embodiment of the present invention. [Figure 9] FIG. 2 is a diagram showing a child status list 261 used in one embodiment of the present invention. [Figure 10] FIG. 10 is a status transition diagram according to an embodiment of the present invention. [Figure 11] FIG. 2 is a sequence diagram showing an overall processing sequence according to an embodiment of the present invention. [Figure 12]FIG. 10 is a sequence diagram showing a part of a status determination process and a consent acquisition process according to an embodiment of the present invention. [Figure 13] FIG. 10 is a sequence diagram showing details of consent acquisition processing (step S14) under normal circumstances in one embodiment of the present invention. [Figure 14] FIG. 10 is a sequence diagram showing details of the consent acquisition process (step S15) when abuse is suspected in one embodiment of the present invention. [Figure 15] FIG. 10 is a sequence diagram showing details of the consent acquisition process (step S16) when determining abuse in one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0012] An embodiment of the present invention will be described below, divided into <Overview>, <Configuration>, <Information>, and <Processing Flow>.

[0013] <Summary> In this embodiment, child abuse is used as an example. In this example, children who may be abused are used as those requiring support, that is, as targets, and information sharing (provision, acquisition, sharing, etc.) of the children's personal information is used as support. In addition, examples of related parties and organizations (hereinafter simply referred to as related parties) include those with parental authority (parents), school-related personnel such as teachers, support facilities, child consultation centers, and hospital-related personnel such as doctors.

[0014] These are merely examples, and the present invention is not limited to them. For example, in addition to child abuse, various support factors can be targeted, such as domestic violence, illnesses such as dementia and alcoholism, poverty, and various family conditions requiring care such as nursing care. Therefore, those requiring support also include caregivers such as victims of domestic violence, dementia patients, alcoholics, the poor, and young carers. Furthermore, such support can also include nursing care, handling procedures on behalf of the recipient, proxy delegation, protection, victim prevention, and evacuation support.

[0015] In this embodiment, a situation will be described in which information sharing regarding a child's personal information is necessary. For example, when a child is examined at a hospital, the doctor may consider the possibility of abuse based on the condition of bruises and injuries. In this case, the doctor or the hospital may wish to obtain the child's personal information from other parties in order to confirm the abuse and determine whether or not to report it to a child consultation center, police, or the like. In other words, there is a need to make a comprehensive judgment regarding the possibility of abuse, rather than simply determining the possibility based on bruises and injuries, by incorporating other information as well. Furthermore, to make a comprehensive judgment, there is also a need to disclose and share the child's personal information (e.g., medical record information) managed by the hospital. In order to meet these needs, in this embodiment, information sharing regarding the personal information is realized as an example of support for children.

[0016] <Configuration> The configuration of this embodiment will be described below with reference to the drawings. Fig. 1 is a system configuration diagram of a consent acquisition system in this embodiment. In this system, a consent acquisition server 1, a child consultation center system 2, a hospital system 3, a school system 4, a support facility system 5, and a parent terminal 6 are connected to each other via a network 7.

[0017] Below, we will provide an overview of each of these devices, followed by a detailed description. The consent acquisition server 1 is an example of a consent acquisition device of the present invention, and executes the main process for consent acquisition in this embodiment. To this end, the consent acquisition server 1 works in conjunction with a child consultation center system 2, a hospital system 3, a school system 4, a support facility system 5, and a parent terminal 6.

[0018] Next, the child consultation center system 2 is a system used in a child consultation center, which is an example of a related party of a child, and in this embodiment, it is composed of a child consultation center terminal 20 and a child consultation center server 200. The child consultation center terminal 20 and the child consultation center server 200 are each an example of a related party device, and the system may consist of only one of them, or multiple devices may be provided. It is assumed that this will be used by staff at a child consultation center.

[0019] The hospital system 3 is a system used in hospitals, clinics, and the like, which are examples of related parties of children, and in this embodiment is made up of a hospital terminal 30 and a hospital server 300. The hospital terminal 30 and the hospital server 300 are each examples of related party devices, and the system may consist of only one of them, or multiple devices may be provided. It is assumed that this system will be used by hospital staff such as doctors.

[0020] The school system 4 is a system used in a school, which is an example of a related party of a child, and in this embodiment, is made up of a school terminal 40 and a school server 400. The school terminal 40 and the school server 400 are each an example of a related party device, and the system may consist of only one of them, or multiple devices may be provided. It is assumed that this will be used by school staff such as teachers.

[0021] Furthermore, the support facility system 5 is a system used in various support facilities, which are examples of related parties for children, and in this embodiment, is composed of a support facility terminal 50 and a support facility server 500. Here, the support facility is a facility available to children, such as a so-called children's cafeteria, a children's center, or other child welfare facility. More preferably, the support facility is a facility that can protect and support children. Here, the support facility terminal 50 and the support facility server 500 are each an example of a related party device, and the system may consist of only one of them, or multiple devices may be installed. In this case, this also includes cases where there are multiple support facilities. It is assumed that this system will be used by staff at the support facility.

[0022] The parent terminal 6 is a terminal device used by a parent who has parental authority over a child, which is an example of a related party, and can be realized by a smartphone, tablet, PC, etc. Furthermore, the network 7 connects the above-mentioned devices and can be realized by the Internet, etc. Furthermore, the consent acquisition server 1 may be provided at a related party such as a child consultation center. In this case, the function of the consent acquisition server 1 may be provided in a related party device such as the child consultation center server 200, or may be realized as a separate device.

[0023] Next, each device will be described in detail. First, Fig. 2 is a functional block diagram of the consent acquisition server 1 in this embodiment. In Fig. 2, the consent acquisition server 1 has a status acquisition unit 11, a consent management list creation unit 12, a consent acquisition unit 13, a proxy consent acquisition unit 14, a collaboration authorization unit 15, a communication unit 16, and a recording unit 17.

[0024] First, the status acquisition unit 11 acquires a status indicating the cause of support, i.e., the status of child abuse, which is a cause of information sharing, from another device. This status acquisition unit 11 is an example of a status identification unit that identifies the status. Therefore, consent may be identified by the consent acquisition server 1 itself.

[0025] In addition, the consent management list creation unit 12 creates a consent management list 171, which is information regarding consent for information sharing for each child, and records this in the recording unit 17. The consent management list 171 will be explained in the <Information> section below.

[0026] The consent acquisition unit 13 also executes a process for acquiring consent from potential consenters who may become consenters among related parties. The proxy consent acquisition unit 14 also executes a process for acquiring consent from potential proxy consenters who may become proxy consenters in the case of a predetermined status.

[0027] Furthermore, the collaboration authorization unit 15 executes processing for information collaboration, which is an example of support. More specifically, it issues a permission ticket for information collaboration. Furthermore, the communication unit 16 executes communication with other devices via the network 7. Note that in this embodiment, the collaboration authorization unit 15 is used to perform information collaboration as support, which is an example of a support authorization unit that authorizes support. Furthermore, the recording unit 17 records the consent management list 171.

[0028] 3 is a functional block diagram of the child consultation center terminal 20 in this embodiment. In this example, the child consultation center terminal 20 is used as a related party device used in the child consultation center, but at least a part of the functions of the child consultation center terminal 20 may be realized by the child consultation center server 200.

[0029] 3, child consultation center terminal 20 has child situation list creation unit 21, child situation list update unit 22, status confirmation unit 23, consent unit 24, communication unit 25, and recording unit 26. Child situation list creation unit 21 creates a child situation list 261, which is information indicating the status of child abuse, which is an example of a support factor, for each child, and records this in recording unit 26. Child situation list 261 will be explained in the <Information> section below.

[0030] Furthermore, the child status list update unit 22 updates the child status list 261 in accordance with the status of child abuse. Furthermore, the status confirmation unit 23 confirms the status of child abuse based on the child status list 261.

[0031] Furthermore, the consent unit 24 executes processing for obtaining consent in cooperation with the consent acquisition unit 13. Furthermore, the communication unit 25 executes communication with other devices via the network 7. Furthermore, the recording unit 26 records the child status list 261.

[0032] 4 is a functional block diagram of the hospital terminal 30 in this embodiment. In this example, the hospital terminal 30 is used as a related party device used in the hospital, but at least a part of the functions of the hospital terminal 30 may be realized by the hospital server 300.

[0033] 4, the hospital terminal 30 has an electronic medical record creation unit 31, a collaboration request unit 32, a consent confirmation unit 33, a collaboration permission unit 34, a proxy consent unit 35, a communication unit 36, and a recording unit 37. First, the electronic medical record creation unit 31 creates electronic medical record data 371 indicating the medical record for each patient, including children, and records it in the recording unit 37.

[0034] Furthermore, the collaboration request unit 32 transmits a collaboration request, which requests information collaboration as an example of support, to the consent acquisition server 1 via the communication unit 36 ​​described below. The consent confirmation unit 33 confirms the consent acquired by the consent acquisition unit 13, the consent unit 24, etc.

[0035] The cooperation permission unit 34 also executes a process for information cooperation, in accordance with the permission ticket issued by the cooperation authorization unit 15.

[0036] Furthermore, the proxy consent unit 35 executes processing for consent by the user of the hospital terminal 30 or the hospital as a proxy consenter in a predetermined status. The communication unit 36 ​​executes communication with other devices via the network 7. Furthermore, the recording unit 37 records electronic medical record data 371.

[0037] 5 is a functional block diagram of the school terminal 40 in this embodiment. In this example, the school terminal 40 is used as a related device used at school, but at least some of the functions of the school terminal 40 may be realized by the school server 400.

[0038] 5, school terminal 40 has learning data creation unit 41, collaboration request unit 42, consent confirmation unit 43, collaboration permission unit 44, proxy consent unit 45, communication unit 46, and recording unit 47. First, learning data creation unit 41 creates learning data 471 related to learning and school life for each student, including the number of days attended (including early departures and absences), grades, lifestyle attitudes, etc., and records the data in recording unit 47.

[0039] Furthermore, the collaboration request unit 42, the consent confirmation unit 43, the collaboration permission unit 44, the proxy consent unit 45, and the communication unit 46 have the same functions as the collaboration request unit 32, the consent confirmation unit 33, the collaboration permission unit 34, the proxy consent unit 35, and the communication unit 36, respectively. Furthermore, the recording unit 47 records learning data 471.

[0040] 6 is a functional block diagram of the support facility terminal 50 in this embodiment. In this example, the support facility terminal 50 is used as a related party device used in the support facility, but at least a part of the functions of the support facility terminal 50 may be realized by the support facility server 500.

[0041] 6, support facility terminal 50 has activity record data creation unit 51, collaboration request unit 52, consent confirmation unit 53, collaboration permission unit 54, proxy consent unit 55, communication unit 56, and recording unit 57. First, activity record data creation unit 51 creates activity record data 571 regarding the child's activities at the support facility, including the number of days of use, activity content, etc., for the child, and records it in recording unit 57.

[0042] Furthermore, the collaboration request unit 52, the consent confirmation unit 53, the collaboration permission unit 54, the proxy consent unit 55, and the communication unit 56 have the same functions as the collaboration request unit 42, the consent confirmation unit 43, the collaboration permission unit 44, the proxy consent unit 45, and the communication unit 46, respectively. Furthermore, the recording unit 57 records activity record data 571.

[0043] The above-described hospital terminal 30, school terminal 40, and support facility terminal 50 may each have the same functions (units). In this embodiment, the hospital is the source of the information collaboration request, and therefore has the collaboration request unit 32, and the school is the source of the information provision, and therefore has the consent confirmation unit 43. Furthermore, other terminals may also have these functions, and these may be used when they become the source of the information collaboration request.

[0044] Next, the parent terminal 6 executes various processes related to obtaining consent in accordance with operations from the parent, and transmits and receives information to and from each of the above-mentioned devices via the network 7. These functions can be realized by a browser or a dedicated app (program). These functions may also be realized by email, a dedicated message function of the parent terminal 6, or a social network service (SNS). Furthermore, the parent terminal 6 may have the same functions as the child consultation center terminal 20, the hospital terminal 30, the school terminal 40, and the support facility terminal 50. Furthermore, the parent terminal 6, the child consultation center terminal 20, the hospital terminal 30, the school terminal 40, and the support facility terminal 50 each have an input unit that can be realized by an input device that accepts user input, and an output unit that can be realized by a display device that outputs various information.

[0045] Next, we will explain one implementation example of the consent acquisition server 1. Fig. 7 is a hardware configuration diagram of the consent acquisition server 1 in this embodiment. In Fig. 7, the consent acquisition server 1 has a CPU 101, a main recording device 102, a network I / F 103, a display I / F 104, an input I / F 105, an auxiliary recording I / F 106, and an auxiliary recording device 107, which are connected to each other via a bus or the like.

[0046] First, CPU 101 is an example of a processing device (processor) and executes calculations in accordance with each program recorded in auxiliary storage device 107, which will be described later. Main storage device 102 is a so-called memory, into which each program recorded in auxiliary storage device 107 and information used for calculations by CPU 101 are expanded.

[0047] 2, and has an interface function for connecting to the network 7 and communicating with other devices. The display I / F 104 has an interface function for connecting to a display device 81 and displaying various information thereon. The input I / F 105 has an interface function for connecting to an input device 82 such as a mouse or keyboard and receiving input in response to user operations thereon. The display device 81 and the input device 82 may be configured as part of the consent acquisition server 1, or may be configured as separate devices. In the latter case, they may be implemented as a terminal device such as a tablet or PC.

[0048] The auxiliary recording I / F 106 also has an interface function for connecting to the auxiliary recording device 107, which will be described later. The auxiliary recording device 107 can be realized by a so-called storage, and records the status acquisition program 108, the consent management list creation program 109, the consent acquisition program 110, the proxy consent acquisition program 111, the linked authorization program 112, and the consent management list 171. Therefore, the main recording device 102 and the auxiliary recording device 107 correspond to the recording unit 17 in FIG. 2.

[0049] In addition, the auxiliary recording device 107 may be realized by various recording media such as an external HDD (Hard Disk Drive), SSD (Solid State Drive), or memory card, or may be realized as a device separate from the consent acquisition server 1, such as a file server.

[0050] Here, with regard to each program, at least a part of each function may be realized as a module, and these may be combined and realized as one or more programs.

[0051] The functions realized by each program are the same as those of the respective units in Fig. 2. That is, the CPU 101 executes calculations to realize the functions of the status acquisition unit 11, the consent management list creation unit 12, the consent acquisition unit 13, the proxy consent acquisition unit 14, and the collaboration authorization unit 15 in accordance with the above-mentioned programs. The configuration shown in Fig. 2 that executes the same functions as each program is as follows: Status acquisition program 108: Status acquisition unit 11 Consent management list creation program 109: consent management list creation unit 12 Consent acquisition program 110: consent acquisition unit 13 Proxy consent acquisition program 111: Proxy consent acquisition unit 14 Collaboration Authorization Program 112: Collaboration Authorization Unit 15 This concludes the description of the configuration of this embodiment, and next, the <information> will be described.

[0052] <Information> First, FIG. 8 is a diagram showing the consent management list 171 used in this embodiment. The consent management list 171 is composed of a collection of consent management information regarding consent to information collaboration for each child. For example, as shown in FIG. 8, each No. that identifies the consent management information has the following items: name, status, consent status, number of collaborations, and number of collaboration refusals. First, the name is the name of the target child, but any information that can identify the child will suffice. Note that the above-mentioned No. may be information that identifies the child.

[0053] The status indicates the status of child abuse, which is a support factor. In this embodiment, "normal," "abuse suspected," "abuse confirmed," and "abuse improved" are used. The concept of these will be explained in the <Processing flow> section below.

[0054] Additionally, the consenter indicates the person involved who consents to the information sharing that is support, i.e., the sharing of the child's personal information. It is desirable that this field be dynamically changed depending on the status of the status determination process and consent acquisition process. As an example, "parent" is initially recorded as the initial value, and when the status is "abuse suspected" or "abuse confirmed," "consenter candidate" is recorded, and when consent is acquired, "consenter" (including proxy) is recorded. This is explained in detail in the <Processing flow> field.

[0055] Furthermore, the presence or absence of consent indicates whether consent has been obtained in the consent acquisition process (yes) or not (no). Furthermore, the number of times of collaboration indicates the number of times information collaboration, which is support, has been attempted. Furthermore, the number of times collaboration has been refused indicates the number of times information collaboration has been refused. Note that these items are merely examples, and as long as the consenter can manage them, some of them can be omitted. Furthermore, other items may be added.

[0056] Next, Fig. 9 is a diagram showing a child status list 261 used in this embodiment. The child status list 261 is composed of a collection of child abuse information that indicates the status of child abuse, which is an example of a support factor, for each child. For example, as shown in Fig. 9, for each No. that identifies child abuse information, the list has the following items: name, address, date of birth, status, number of times of linkage, and number of times of linkage refusal.

[0057] First, the name is the name of the child who is the subject, but any information that can identify the child is sufficient. Note that the above-mentioned No. may also be information that identifies the child. Furthermore, the address, name, and date of birth are information that indicate the child's attributes.

[0058] The status, number of times of linkage, and number of times of linkage refusal are the same information as those in the consent management list 171. Note that these items are merely examples, and some of them can be omitted as long as the status can be managed. Other items may also be added.

[0059] The electronic medical record data 371, the learning data 471, and the activity record data 571 have already been explained in the section <Configuration>, and detailed explanations thereof will be omitted. This concludes the explanation of the information used in this embodiment, and next, the <Processing Flow> will be explained.

[0060] <Processing flow> First, before explaining the processing flow, we will explain the concept of the status that is the premise of this. The status indicates the status of the abuse, which is the support factor. Therefore, the status will change and transition depending on the implementation of some kind of action or confirmation of the status.

[0061] Figure 10 is a status transition diagram in this embodiment. In the case of child abuse, if no child abuse has occurred, the status will be "normal." If the possibility of abuse is found based on the child's clothing, etc., the status will transition from "normal" to "abuse suspected."

[0062] Furthermore, as the child's situation is further investigated, the status will change from "abuse suspected" to "abuse confirmed." If the abuse improves due to intervention by a child consultation center or other such institution, the status will change from "abuse confirmed" to "abuse improved." Furthermore, if the situation calms down further and intervention or other measures are no longer necessary, the status will change from "abuse improved" to "normal."

[0063] Note that these statuses and their transitions are not limited to the examples described above. For example, other statuses may be added, or some may be deleted. Furthermore, if abuse is not confirmed during "abuse suspected," the transition may transition to "normal." Furthermore, if abuse is confirmed during "normal," the transition may skip "abuse suspected" and transition to "abuse confirmed." Thus, the transitions are not limited to the example in Figure 8, and skipping or transitions in the opposite direction are also included. Furthermore, these statuses can also be used as indicators of the degree of need for support. In the example of Figure 8, the need for support can be defined in decreasing order as "normal," "abuse improved," "abuse suspected," and "abuse confirmed."

[0064] Furthermore, it is desirable that these statuses be managed by a child consultation center that takes measures against abuse. For this reason, in this embodiment, they are managed in a child status list 261 of the child consultation center terminal 20. However, this may also be managed by the consent acquisition server 1.

[0065] This concludes the explanation of the concept of status, particularly its transitions, and now we will explain the details of the processing flow. FIG. 11 is a sequence diagram showing the overall processing sequence in this embodiment. First, as a premise of this processing, it is assumed that a child is examined at a hospital and the doctor considers the child's injuries to be the possibility of abuse. In this case, in step S301, the input unit of the hospital terminal 30 receives a linkage request instruction for information linkage about the child from a hospital staff member such as a doctor. Then, the communication unit 36 ​​sends a linkage request to the consent acquisition server 1. This linkage request includes identification information such as the child's name and information indicating a desire for information linkage.

[0066] In step S101, the communication unit 16 of the consent acquisition server 1 receives a linkage request. In step S102, the consent management list creation unit 12 registers the received linkage request in the consent management list 171. To this end, the consent management list creation unit 12 determines whether the consent management information for the child who is the subject of the linkage request is included in the consent management list 171.

[0067] As a result, if the consent management list creation unit 12 does not contain the child's name, it creates a new record in the consent management list 171 and records the child's name in the name field. If consent management information for the child is contained, it initializes the record (consent management information). That is, the consent management list creation unit 12 erases the records of the status, consenter, and consent status. At this time, it may also erase the number of linkage attempts and the number of linkage refusals. Furthermore, during initialization, the consent management list creation unit 12 may record the parent as the consenter. Furthermore, if consent management information is contained, this consent management information may be reused. In this case, the consent management information may include the status, and this may be used to determine the status. In this case, the status determination process described below may be omitted.

[0068] In this embodiment, it is determined whether consent management information about the child is included in the consent management list 171, but this process can be omitted. In this case, the consent management list creation unit 12 creates a new record in the consent management list 171 regardless of whether consent management information is included.

[0069] Furthermore, in step S10, a status determination process is executed, and in step S20, a consent acquisition process is executed. First, in step S10, the consent acquisition server 1 and the child consultation center terminal 20 work together to determine the status of the subject child. Furthermore, in step S20, the consent acquisition server 1 and the related device work together to identify the consenter. Specific examples of these will be described below with reference to Figs. 12 to 15. Fig. 12 is a sequence diagram showing a part of the status determination process and consent acquisition process in this embodiment.

[0070] First, in step S11, the status acquisition unit 11 of the consent acquisition server 1 transmits a request to confirm the status of the subject child to the child consultation center terminal 20 via the communication unit 16. This confirmation request includes a request to confirm the status and identification information that identifies the child.

[0071] In step S21, the communication unit 25 of the child consultation center terminal 20 accepts a status confirmation request. In response to this, in step S22, the status confirmation unit 23 checks the child status list 261 and identifies the child confirmation information corresponding to the identification information of the child for which the confirmation request has been accepted.

[0072] Furthermore, the status confirmation unit 23 extracts the status included in the identified child status information. Then, in step S23, the status confirmation unit 23 notifies the consent acquisition server 1 of the extracted status via the communication unit 25. If the child status list 261 does not include management information for the child in question, the status confirmation unit 23 determines the status to be "normal." This means that the status is determined to be the one with the lowest need for support. However, this is merely an example, and the status confirmation unit 23 may determine a predetermined status.

[0073] In addition, in step S12, the status acquisition unit 11 of the consent acquisition server 1 registers the notified status in the corresponding record in the consent management list 171. This completes the status determination process (step S10). Thereafter, the consent acquisition process (step S20) is executed.

[0074] First, in step S13, the consent acquisition unit 13 determines the status of the child, who is the subject, recorded in the consent management list 171. As a result, if the status is "normal", the process transitions to step S14. If the status is "abuse suspected", the process transitions to step S15. If the status is "abuse confirmed", the process transitions to step S16. If the status is "abuse improved", the process transitions to step S17. As described above, in this embodiment, the consent acquisition process is executed in different procedures depending on the acquired status, and a response to the consent request is obtained.

[0075] In step S14, consent acquisition processing for normal times is executed. Details of this will be described later using FIG. 13. In step S15, consent acquisition processing for when abuse is suspected is executed. Details of this will be described later using FIG. 14. In step S16, consent acquisition processing for when abuse is determined is executed. Details of this will be described later using FIG. 15.

[0076] Furthermore, in step S17, the consent acquisition unit 13 identifies the consenter as a "parent" and registers it in the consenter column of the consent management list 171. Note that if "parent" is recorded as the initial value, the consent acquisition unit 13 leaves it as the initial value.

[0077] Then, in step S18, the consent acquisition unit 13 notifies the hospital terminal 30 via the communication unit 16 that the child abuse status is at the time of abuse improvement, that is, that the child abuse status has been improved.

[0078] Here, in step S17, the consenter is identified as the "parent," but this may be identified as a potential consenter in the process described below. For this purpose, the consent acquisition unit 13 notifies the parent terminal 6 of a request for consent to information collaboration via the communication unit 16. This consent collaboration request includes information indicating that consent is being requested, the child's name, and the scope of the target's personal information. Here, in this embodiment, the target's personal information is the target's electronic medical record included in the hospital's electronic medical record data 371.

[0079] Then, when the communication unit 16 receives a response from the parent terminal 6 indicating consent, the consent acquisition unit 13 adds 1 to the number of linkages in the consent management list 171 and updates it. Also, the consent acquisition unit 13 performs a process of confirming the "parent" recorded as a consenter in the consent management list 171 from a consenter candidate to a consenter.

[0080] Furthermore, when the communication unit 16 receives a response from the parent terminal 6 indicating that the parent terminal 6 does not consent, the consent acquisition unit 13 adds one to the number of times that cooperation has been refused in the consent management list 171 and updates it. Furthermore, the consent acquisition unit 13 deletes the "parent" who is a consenter candidate recorded in the consent management list 171. Furthermore, from step S18 onwards, consent acquisition may be performed using the same processing as in step S14.

[0081] This concludes the explanation of Fig. 12, and steps S14 to S16 will now be described in detail. First, Fig. 13 is a sequence diagram showing details of the consent acquisition process (step S14) under normal circumstances in this embodiment. First, in step S140, the consent acquisition unit 13 sets the consenter in the consent management list 171 as "parent", similar to step S17. More preferably, as described above, the consent acquisition unit 13 sets the "parent" as a consenter candidate.

[0082] In step S141, the consent acquisition unit 13 notifies the parent terminal 6 of a request for consent to cooperation via the communication unit 16. The request for consent to cooperation also includes confirmation of consent to a request for cooperation with other related parties (in this example, the school). In this example, a request for personal information of the child is used as the cooperation request.

[0083] In step S640, the input unit of the parent terminal 6 receives a confirmation result for the collaboration consent request. That is, information indicating whether or not consent is granted is received. Then, in step S641, the parent terminal 6 notifies the consent acquisition server 1 of the information indicating whether or not consent is granted. Note that this information also includes whether or not consent is granted for a request for personal information about a child, which is an example of a collaboration request to another related party (in this example, a school).

[0084] Then, in step S142, the communication unit 16 of the consent acquisition server 1 receives information indicating whether consent is granted or denied. In response to this, in step S143, the consent acquisition unit 13 determines whether the received information indicates consent (either yes or no). As a result, if consent is not granted (NO), the process proceeds to step S144. On the other hand, if consent is granted (YES), the process proceeds to step S145.

[0085] In step S144, the consent acquisition unit 13 adds 1 to the number of cooperation refusals in the consent management list 171, and updates it. In step S145, the consent acquisition unit 13 records “yes” as the consent in the consent management list 171.

[0086] In step S146, the consent acquisition unit 13 uses the information indicating whether or not consent has been given to confirm whether or not there is consent to the collaboration request for other related parties (in this example, the school). If there is consent (YES), the process proceeds to step S148. If there is no consent (NO), the process proceeds to step S147.

[0087] In step S147, the consent acquisition unit 13 adds 1 to the number of times of refusal of collaboration in the consent management list 171, and updates it. In step S148, the consent acquisition unit 13 notifies the school terminal 40 of a collaboration consent request via the communication unit 16. Here, the collaboration consent request includes information on the parent who is the consenter and a request for provision of the learning data 471.

[0088] Furthermore, in this example, as described above, a school is used as another related party, so the destination for this step is the school terminal 40, or other devices may be added as notification destinations, or other devices may be used instead of the school terminal 40.

[0089] In step S440, the consent confirmation unit 43 of the school terminal 40 outputs the contents of the collaboration consent request. In response to this, the consent confirmation unit 43 of the school terminal 40 receives from the user the confirmation result for the consenter and the approval or disapproval of the collaboration request. Then, in step S441, the communication unit 46 notifies the consent acquisition server 1 of the approval or disapproval of the collaboration request accepted in step S440.

[0090] In step S149, the communication unit 16 of the consent acquisition server 1 accepts the linkage availability notified in step S440. This concludes the explanation of Fig. 13, and the process will now proceed to step S103 in Fig. 11. Before explaining step S103, details of step S15 will be explained using Fig. 14.

[0091] FIG. 14 is a sequence diagram showing details of the consent acquisition process (step S15) when abuse is suspected in this embodiment. First, in step S150, the consent acquisition unit 13 sets the consenter in the consent management list 171 as a "provisional proxy." More preferably, as described above, the consent acquisition unit 13 sets the "provisional proxy" as a consenter candidate. In this example, it is assumed that a school or support facility other than the parent is identified as this "provisional proxy." In this way, in this embodiment, multiple related parties are identified.

[0092] In step S151, the proxy consent acquisition unit 14 notifies the school terminal 40 and the support facility terminal 50 of a proxy consent request via the communication unit 16. These terminals are related party devices of the identified multiple related parties. In response to this, in step S40, the proxy consent unit 45 and the proxy consent unit 55 confirm the data owned by the relevant organization. This data is the learning data 471 in the school terminal 40 and the activity record data 571 in the support facility terminal 50. Of these, the data for the relevant child is also confirmed.

[0093] For this purpose, each of the proxy consent units 45 and 55 outputs its own data to the output unit. As a result, each user can check the output data and determine whether or not consent is possible. The input unit also accepts input of the user's decision result.

[0094] Then, in step S50, the proxy consent unit 45 and the proxy consent unit 55 notify the consent acquisition server 1 of the determination result received in step S40 via the communication unit 46 and the communication unit 56, respectively.

[0095] In step S152, the proxy consent acquisition unit 14 of the consent acquisition server 1 determines whether the number of consent-agreeing judgment results among the notified judgment results is equal to or greater than a pre-recorded threshold. If the result is less than the threshold (NO), the process proceeds to step S153. If the result is equal to or greater than the threshold (YES), the process proceeds to step S154. The threshold may be, for example, 1 or greater, depending on the case depending on the subject, support factors, etc.

[0096] In addition, in step S153, the proxy consent acquisition unit 14 adds 1 to the number of collaboration refusals in the consent management list 171 and updates it. In addition, in step S154, the proxy consent acquisition unit 14 updates the consenter in the consent management list 171 from "temporary proxy" to "proxy." Here, "proxy" does not refer to a specific related party, but rather means that all of the above-mentioned multiple related parties are managed as consenters.

[0097] Hereinafter, in steps S155 to S158, the same processing as in steps S145 to S148 is executed. Here, in this example, the destination of the notification of the collaboration consent request in step S158 is set to school terminal 40. This is the related party device that notified the decision result of consent in step S50. However, this destination of the notification of the collaboration consent request is merely an example, and the notification destination may also be a related party device that does not consent. Hereinafter, in steps S450 to S159, the same processing as in steps S440 to S149 is executed. This concludes the explanation of Figure 14, and from here on, the process will proceed to step S103 in Figure 11. Before explaining step S103, details of step S16 will be explained using Figure 15.

[0098] 15 is a sequence diagram showing details of the consent acquisition process (step S16) when determining abuse in this embodiment. First, in step S160, the consent acquisition unit 13 sets the consenter to "child consultation center" in the consent management list 171. More preferably, as described above, the consent acquisition unit 13 sets "child consultation center" as a consenter candidate.

[0099] In step S161, the consent acquisition unit 13 notifies the child consultation center terminal 20 of a cooperation consent request via the communication unit 16. The cooperation consent request has the same content as that notified in step S141.

[0100] Also, in step S260, the consent unit 24 checks the relevant child status information in the child status list 261. To do this, the consent unit 24 outputs the relevant child status information to the output unit. As a result, each user can check the output data and determine whether or not consent is possible. Also, the input unit accepts input of the user's determination result.

[0101] Then, in step S261, the consent unit 24 notifies the consent acquisition server 1 of the determination result received in step S260 via the communication unit 25. Thereafter, for steps S162 to S169, the same processing as for steps S142 to S149 is executed. This concludes the explanation of Fig. 15, and we will return to Fig. 11 to explain the processing from step S103 onwards.

[0102] In step S103, the collaboration authorization unit 15 determines whether information collaboration, which is an example of support, is possible. To this end, the collaboration authorization unit 15 uses the notifications of collaboration availability received in steps S149, S159, and S169. As a result, if information collaboration is possible (YES), the process proceeds to step S105. On the other hand, if information collaboration is not possible (NO), the process proceeds to step S107.

[0103] Furthermore, in step S104, the collaboration authorization unit 15 adds 1 to the collaboration count in the consent management list 171 and updates it. Furthermore, in step S105, the collaboration authorization unit 15 issues a permission ticket. This permission ticket is information indicating that information collaboration, which is support, is permitted. This permission ticket is information indicating that information collaboration, which is support, is permitted. One implementation example of a permission ticket is a token defined in the UWA (User-Managed Access) specification, which is an access management protocol. Furthermore, when support is information collaboration, the range of information collaboration permitted is the information of the relevant child. In this way, the permission ticket is information for permitting limited processing for the relevant target person regarding support. For this reason, the permission ticket includes information for identifying the target person and information indicating that support is permitted.

[0104] Then, in step S106, the cooperation authorization unit 15 transmits the permission ticket via the communication unit 16 to the hospital terminal 30, which is the related source device that has made the information cooperation request.

[0105] In step S302, the communication unit 25 of the hospital terminal 30 receives the transmitted permission ticket. In response to this, in step S303, the collaboration request unit 32 uses the permission ticket to make an access request to the database that will be the information collaboration destination. Here, the database that will be the information collaboration destination is the recording unit 47 of the school terminal 40, and more specifically, the data of the relevant student from the learning data 471.

[0106] Furthermore, in step S401, the collaboration permission unit 44 of the school terminal 40 verifies the permission ticket used in step S303. This verification can be achieved using technology such as public key cryptography. As a result, if the verification is successful, in step S402 the collaboration permission unit 44 discloses the data for which access is requested, i.e., the child's data, to the hospital terminal 30. In other words, access is permitted.

[0107] In step S304, the cooperation request unit 32 of the hospital terminal 30 outputs the data for which access is permitted to its own output unit, so that the user of the hospital terminal 30 can view the data.

[0108] Then, in step S305, the input unit of the hospital terminal 30 receives the results of sorting and examining the viewed data, and the collaboration request unit 32 records this in the recording unit 37.

[0109] Here, returning to the case of NO in step S103, the explanation will be given. In this case, in step S107, the collaboration authorization unit 15 adds 1 to the collaboration refusal count in the consent management list 171 and updates it. Here, this step may be processed so as to transition from step S144, step S147, step S153, step S157, step S164, and step S167.

[0110] The status acquisition unit 11 or the status confirmation unit 23 of the consent acquisition server 1 may update the status in accordance with the number of linkage refusals updated in steps S144, S147, S153, S157, S164, and S167. In this case, the status acquisition unit 11 updates the status in the consent management list 171 to indicate a higher level of necessity. The status acquisition unit 11 then notifies the child consultation center terminal 20 of the status update result via the communication unit 16. As a result, the status confirmation unit 23 similarly updates the status in the child status list 261. Alternatively, the status confirmation unit 23 may first update the status in the child status list 261, notify the consent acquisition server 1, and update the consent management list 171. Here, updating to indicate a higher level of necessity means, in the example of FIG. 10, the order is normal or abuse improvement - suspected abuse - abuse confirmation. In other words, it means that the probability of support factors is high.

[0111] Then, in step S108, the collaboration permission unit 15 notifies the hospital terminal 30 via the communication unit 16 of a collaboration denial, indicating that the collaboration has been denied. In response to this, the user of the hospital terminal 30 reviews the child's electronic medical record recorded in the recording unit 37. Then, in step S305, to which this transition has been made, the input unit of the hospital terminal 30 accepts the results of this review, and the collaboration request unit 32 records them in the recording unit 37.

[0112] In step S306, the input unit of the hospital terminal 30 receives a request from the user to report child abuse and / or to seek counseling. The communication unit 36 ​​then notifies the request to the child consultation center terminal 20. The request to report and / or to seek counseling includes a request to report and / or to seek counseling, and information identifying the child.

[0113] As a result, the child consultation center can confirm the safety of the child in question. Then, in step S201, the input unit of the child consultation center terminal 20 accepts the results of the safety confirmation, i.e., the situation including the abuse status. Then, in step S202, the child situation list update unit 22 updates the child situation list 261 to reflect the accepted situation.

[0114] This concludes the explanation of the processing flow of this embodiment, but the present invention is not limited to the described content. For example, the consenter or consenter candidate may be a related party other than a third party. For example, they may be the target person themselves, or these may be omitted (unnecessary). Furthermore, the consent management list 171 and the consent management information constituting it may be invalidated after a certain period of time, or may be managed as a permanently retained list. In the former case, this can be realized by the consent management list creation unit 12 detecting a certain period of time from the time the consent management list 171 and the consent management information constituting it were created or updated, and performing the invalidation process.

[0115] Furthermore, the identification of the consenter in steps S140, S150, and S160 may be set in advance in the consent management list 171. Furthermore, the name and status of the child may also be set in advance in the consent management list 171. Note that the consent acquisition server 1 may acquire the identification of the consenter and the name and status of the child from the child consultation center terminal 20. [Explanation of symbols]

[0116] 1...consent acquisition server, 11...status acquisition unit, 12...consent management list creation unit, 13...consent acquisition unit, 14..., proxy consent acquisition unit, 15...collaboration authorization unit, 16...communication unit, 17...recording unit, 171...consent management list, 2...child consultation center system, 20...child consultation center terminal, 21...child status list creation unit, 22...child status list update unit, 23...status confirmation unit, 24...consent unit, 24, 25...communication unit, 26...recording unit, 261...child status list, 200...child consultation center server, 3...hospital system, 30...hospital terminal, 31...electronic medical record creation unit, 32...collaboration request unit, 33...consent confirmation unit, 34...collaboration Permission unit, 35...proxy consent unit, 36...communication unit 36, 37...recording unit, 300...hospital server, 4...school system, 40...school terminal, 41...learning data creation unit, 42...collaboration request unit, 43...consent confirmation unit, 44...collaboration permission unit, 45...proxy consent unit, 46...communication unit, 47...recording unit, 471...learning data, 400...school server, 5...support facility system, 50...support facility terminal, 51...activity record data creation unit, 52...collaboration request unit, 53...consent confirmation unit, 54...collaboration permission unit, 55...proxy consent unit, 56...communication unit, 57...recording unit 57, 571...activity record data, 500...support facility server, 6...parent terminal 6

Claims

1. A consent acquisition device for acquiring consent for providing support to a subject who requires support, a communication unit that receives, from a first related party apparatus used by a first related party related to the subject, a request from a user of the first related party apparatus to obtain the consent; a status acquisition unit that acquires a status indicating a status of a support factor that is a factor of the support; Identifying a potential consenter to whom the consent is to be given according to the status; creating a consent request for a second participant device used by the identified consenter candidate; a consent acquisition unit that acquires a consent result for the consent request via the communication unit; A consent acquisition device having a support authorization unit that, if the consent result indicates consent to the support, issues a permission ticket indicating that the support is permitted and transmits it to the first related party device via the communication unit.

2. The consent acquisition device according to claim 1, The status acquisition unit is a consent acquisition device that acquires the status from another device connected via a network.

3. The consent acquisition device according to claim 1, The consent acquisition unit acquires a response to the consent request in a different procedure depending on the acquired status.

4. The consent acquisition device according to claim 3, Further, a proxy consent acquisition unit is provided, The supporting factor is child abuse, The status is usually when abuse is suspected, when abuse is confirmed, and when abuse is improved. When the status of the subject child is suspected of abuse, the proxy consent acquisition unit notifies a proxy consent request to a plurality of second related device used by the provisional proxy, using a plurality of potential consenters as provisional proxy, and if the number of consent results indicating consent to the proxy consent request is equal to or greater than a threshold value, the consent acquisition device records the provisional proxy as a proxy.

5. The consent acquisition device according to claim 1, Further, a recording unit is provided for recording a consent management list configured by a set of consent management information regarding consent to the support for each of the subjects, The status acquisition unit updates the status included in the consent management list when a consent result indicating a refusal to support is equal to or greater than a threshold value.

6. A consent acquisition method for acquiring consent for providing support to a subject who requires support, the method being executed by a consent acquisition device, receiving, by a communication unit, from a first related party apparatus used by a first related party related to the subject, a request from a user of the first related party apparatus to obtain the consent; a status acquisition unit acquires a status indicating a status of a support factor that is a factor of the support; The consent acquisition department Identifying a potential consenter to whom the consent is to be given according to the status; creating a consent request for a second participant device used by the identified consenter candidate; obtain a consent result for the consent request via the communication unit; A consent acquisition method in which, if the consent result indicates consent to the support, a support approval unit issues a permission ticket indicating that the support is permitted and sends it to the first related party device via the communication unit.

7. The consent acquisition method according to claim 6, A consent acquisition method in which the status acquisition unit acquires the status from another device connected via a network.

8. The consent acquisition method according to claim 6, A consent acquisition method in which the consent acquisition unit acquires a response to the consent request in different procedures depending on the acquired status.

9. The consent acquisition method according to claim 8, The consent acquisition device further includes a proxy consent acquisition unit, The supporting factor is child abuse, The status is usually when abuse is suspected, when abuse is confirmed, and when abuse is improved. When the status of the subject child is suspected of abuse, the proxy consent acquisition unit designates multiple potential consenters as provisional proxies and notifies a proxy consent request to multiple second related device devices used by the provisional proxies, and if the number of consent results indicating consent to the proxy consent request is equal to or greater than a threshold value, the provisional proxies are recorded as the proxy.

10. The consent acquisition method according to claim 6, The consent acquisition device further includes a recording unit that records a consent management list configured of a set of consent management information regarding consent to the support for each of the subjects, The consent acquisition method includes updating the status included in the consent management list when the consent result indicating refusal to the support is equal to or greater than a threshold value.

11. A consent acquisition device that is a computer and that is used to acquire consent for providing support to a subject who requires support, a communication unit that receives, from a first related party apparatus used by a first related party related to the subject, a request from a user of the first related party apparatus to obtain the consent; a status acquisition unit that acquires a status indicating a status of a support factor that is a factor of the support; Identifying a potential consenter to whom the consent is to be given according to the status; creating a consent request for a second participant device used by the identified consenter candidate; a consent acquisition unit that acquires a consent result for the consent request via the communication unit; A program for functioning as a support authorization unit that issues a permission ticket indicating that the support is permitted and sends it to the first related party device via the communication unit if the consent result indicates consent to the support.

12. The program according to claim 11, The status acquisition unit is a program that acquires the status from another device connected via a network.

13. The program according to claim 11, The consent acquisition unit is a program that acquires a response to the consent request in different procedures depending on the acquired status.

14. 14. The program according to claim 13, The consent acquisition device further includes a proxy consent acquisition unit, The supporting factor is child abuse, The status is usually when abuse is suspected, when abuse is confirmed, and when abuse is improved. When the status of the subject child is suspected of abuse, the proxy consent acquisition unit designates multiple potential consenters as provisional proxies and notifies a proxy consent request to multiple second related device devices used by the provisional proxies, and if the number of consent results indicating consent to the proxy consent request is greater than or equal to a threshold value, records the provisional proxies as a proxy.

15. The program according to claim 11, The consent acquisition device further includes a recording unit that records a consent management list configured of a set of consent management information regarding consent to the support for each of the subjects, The status acquisition unit is a program that updates the status included in the consent management list when the consent result indicating refusal to the support is equal to or greater than a threshold value.

Images