JP7825585B2 - Consent acquisition device, consent acquisition method, and program - Google Patents

Description

The present invention relates to technology for assisting parties in obtaining consent for providing some type of support to a target person, such as information sharing or proxy procedures.

Currently, social issues such as child abuse and domestic violence (DV) are becoming more apparent. As a result, there is an increasing need for support for people in need of assistance, such as abused children, children living in poverty, and victims of DV. This support is expected to include sharing information about these people and handling procedures on their behalf.

For example, Patent Document 1 proposes technology for linking personal information. Its objective is to "eliminate 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-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 the statistical information converted in the statistical processing."

Japanese Patent Publication No. 2022-150526

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 recipients. For this reason, some form of "consent" is required. Furthermore, the recipients mentioned above include children, victims of domestic violence, and dementia patients, and it may be difficult or impossible for the individuals themselves to "consent."

The present invention aims to achieve the objective of obtaining consent from parties involved, including third parties other than the recipient, regarding support such as the provision of personal information and the delegation of a representative.

To solve the above problem, the present invention dynamically identifies those who agree to support based on the status indicating the status of support factors for a subject who requires support.

More specifically, the consent acquisition device for obtaining consent to provide support to a subject who requires support includes: a communications unit that receives, from a first related party device used by a first related party related to the subject, a request to obtain 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 factor 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 communications 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 communications unit.

The present invention also includes a consent acquisition method using a consent acquisition device, a program for causing a consent acquisition device to function as a computer, and a recording medium for storing such a program. Furthermore, the present invention also includes a consent acquisition system that includes a consent acquisition device, as well as other devices and subcombinations that constitute such a system.

This invention makes it possible to obtain consent from parties involved in the support, including third parties other than the recipient.

1 is a system configuration diagram of a consent acquisition system according to an embodiment of the present invention. FIG. 2 is a functional block diagram of a consent acquisition server 1 according to an embodiment of the present invention. FIG. 2 is a functional block diagram of a child consultation center terminal 20 according to an embodiment of the present invention. FIG. 2 is a functional block diagram of a hospital terminal 30 according to an embodiment of the present invention. FIG. 2 is a functional block diagram of a school terminal 40 according to an embodiment of the present invention. FIG. 2 is a functional block diagram of a support facility terminal 50 according to an embodiment of the present invention. FIG. 2 is a hardware configuration diagram of a consent acquisition server 1 according to one embodiment of the present invention. FIG. 10 is a diagram showing a consent management list 171 used in one embodiment of the present invention. FIG. 2 is a diagram showing a child status list 261 used in one embodiment of the present invention. FIG. 10 is a status transition diagram according to an embodiment of the present invention. FIG. 2 is a sequence diagram showing an overall processing sequence according to an embodiment of the present invention. 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. FIG. 10 is a sequence diagram showing details of consent acquisition processing (step S14) under normal circumstances in one embodiment of the present invention. 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. 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.

Below, one embodiment of the present invention will be explained, divided into <Overview>, <Configuration>, <Information>, and <Processing Flow>.

<Overview>
In this embodiment, child abuse is used as an example. In this example, children who may be abused are used as persons requiring support, i.e., targets, and support is provided by information sharing (provision, acquisition, sharing, etc.) of the children's personal information. Examples of related parties and organizations (hereinafter simply referred to as related parties) include parents, school officials such as teachers, support facilities, child consultation centers, and hospital officials such as doctors.

Note that these are merely examples, and the present invention is not limited to them. For example, in addition to child abuse, various support factors may 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 victims of domestic violence, dementia patients, alcoholics, the poor, and caregivers such as young carers. Furthermore, such support may also include nursing care, handling procedures on behalf of the recipient, proxy delegation, protection, victim prevention, and evacuation support.

This embodiment will explain situations 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 relevant parties in order to confirm the abuse and determine whether or not to report it to a child consultation center or the police. In other words, there is a need to make a comprehensive judgment regarding abuse, not just based on bruises and injuries, but also by taking other information into consideration. Furthermore, to make a comprehensive judgment, there is 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, this embodiment implements information sharing regarding that personal information as an example of support for children.

<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.

The following provides 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 performs the main processing 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.

Next, the child consultation center system 2 is a system used at a child consultation center, which is an example of a related party of a child, and in this embodiment 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 installed. It is intended that this system will be used by child consultation center staff.

The hospital system 3 is a system used in hospitals, clinics, and other facilities that 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 installed. It is intended that this system will be used by hospital staff such as doctors.

The school system 4 is a system used at a school, which is an example of a related party of a child, and in this embodiment is composed 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 intended that this system will be used by school staff such as teachers.

The support facility system 5 is a system used by 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, a support facility is a facility available for use by children, such as a children's cafeteria or a child welfare facility such as a children's center. More preferably, a 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 will be used by staff at the support facility.

The parent terminal 6 is a terminal device used by a parent who has legal guardianship over a child, which is an example of a related party, and can be realized by a smartphone, tablet, PC, or the like. The network 7 connects the above-mentioned devices and can be realized by the Internet, for example. The consent acquisition server 1 may also 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.

Next, each device will be described in detail. First, Figure 2 is a functional block diagram of the consent acquisition server 1 in this embodiment. In Figure 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.

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 a status. Therefore, consent may be identified by the consent acquisition server 1 itself.

The consent management list creation unit 12 also creates a consent management list 171, which contains 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.

The consent acquisition unit 13 also executes processing to acquire consent from potential consenters who may become consenters among related parties. The proxy consent acquisition unit 14 also executes processing to acquire consent from potential proxy consenters who may become proxy consenters in the case of a specified status.

The collaboration authorization unit 15 also executes processing for information collaboration, which is an example of support. More specifically, it issues a permission ticket for information collaboration. The communication unit 16 also 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, but this is an example of a support authorization unit that authorizes support. Furthermore, the recording unit 17 records the consent management list 171.

Next, Figure 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 the related party device used at the child consultation center, but at least some of the functions of the child consultation center terminal 20 may be realized by the child consultation center server 200.

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

In addition, the child status list update unit 22 updates the child status list 261 according to the child abuse status. In addition, the status confirmation unit 23 confirms the child abuse status based on the child status list 261.

The consent unit 24 also works in conjunction with the consent acquisition unit 13 to execute processing for obtaining consent. The communication unit 25 also communicates with other devices via the network 7. The recording unit 26 also records the child status list 261.

Next, Figure 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 some of the functions of the hospital terminal 30 may be implemented by the hospital server 300.

In FIG. 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 showing the medical record for each patient, including children, and records it in the recording unit 37.

The collaboration request unit 32 also sends 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.

The collaboration permission unit 34 also executes processing for information collaboration. At this time, this processing is executed in accordance with the permission ticket issued by the collaboration authorization unit 15.

In addition, the proxy consent unit 35 executes processing regarding consent by the user of the hospital terminal 30 or the hospital as the proxy consenter when a specified status is met. The communication unit 36 communicates with other devices via the network 7. Furthermore, the recording unit 37 records electronic medical record data 371.

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

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

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

Next, Figure 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 at the support facility, but at least some of the functions of the support facility terminal 50 may be implemented by the support facility server 500.

In FIG. 6, the support facility terminal 50 has an activity record data creation unit 51, a collaboration request unit 52, a consent confirmation unit 53, a collaboration permission unit 54, a proxy consent unit 55, a communication unit 56, and a recording unit 57. First, the 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 and the details of the activities, and records this in the recording unit 57.

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

The above-mentioned hospital terminal 30, school terminal 40, and support facility terminal 50 may each have similar functions (units). In this embodiment, the hospital is the source of the information collaboration request, so it has the collaboration request unit 32, and the school is the source of the information, so it has the consent confirmation unit 43. Furthermore, other terminals may also have these functions, and they will be used when they become the source of the information collaboration request.

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

Next, we will explain one implementation example of the consent acquisition server 1. Figure 7 is a hardware configuration diagram of the consent acquisition server 1 in this embodiment. In Figure 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.

First, the CPU 101 is an example of a processing device (processor) that performs calculations in accordance with the programs recorded in the auxiliary storage device 107 (described below). The main storage device 102 is a so-called memory in which the programs recorded in the auxiliary storage device 107 and information used for calculations by the CPU 101 are expanded.

Furthermore, the network I/F 103 corresponds to the communication unit 16 in Figure 2, and has an interface function for connecting to the network 7 and communicating with other devices. The display I/F 104 connects to the display device 81 and has an interface function for displaying various information on it. Furthermore, the input I/F 105 connects to an input device 82 such as a mouse or keyboard and has an interface function for accepting input in response to user operations on these. Here, 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 realized by a terminal device such as a tablet or PC.

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 as a so-called storage, and records the status acquisition program 108, consent management list creation program 109, consent acquisition program 110, proxy consent acquisition program 111, linked authorization program 112, and the consent management list 171 described above. Therefore, the main recording device 102 and auxiliary recording device 107 correspond to the recording unit 17 in Figure 2.

The auxiliary recording device 107 may be implemented as various recording media such as an external HDD (Hard Disk Drive), SSD (Solid State Drive), or memory card, or may be implemented as a device separate from the consent acquisition server 1, such as a file server.

Here, for each program, at least some of the functions may be realized as modules, and these may be combined to realize one or more programs.

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.

<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 fields: 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 also be information that identifies the child.

The status indicates the status of child abuse, which is the support factor. In this embodiment, the following statuses are used: "Normal," "Abuse Suspected," "Abuse Confirmed," and "Abuse Improved." The concepts behind these are explained in the <Processing Flow> section below.

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 for this field to change dynamically depending on the status of the status determination process and consent acquisition process. For 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 more detail in the <Processing Flow> section.

Also, "Consent" indicates whether consent has been obtained (yes) or not (no) in the consent acquisition process. Also, "Number of times of collaboration" indicates the number of times information collaboration, which is support, has been attempted. Furthermore, "Number of times of collaboration refusal" 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. Other items may also be added.

Next, Figure 9 is a diagram showing the child status list 261 used in this embodiment. The child status list 261 is composed of a collection of child abuse information indicating the status of child abuse, which is an example of a support factor, for each child. For example, as shown in Figure 9, for each number that identifies child abuse information, it has the following items: name, address, date of birth, status, number of connections, and number of connection refusals.

First, the name is the name of the child who is the subject, but any information that can identify the child will suffice. 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.

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

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

<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.

Figure 10 is a status transition diagram for 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."

Furthermore, as further investigation into the child's situation progresses, the status will transition from "abuse suspected" to "abuse confirmed." Then, if the abuse improves due to intervention by a child consultation center or other such institution, the status will transition from "abuse confirmed" to "abuse improved." Furthermore, if the situation further stabilizes and intervention or other measures are no longer necessary, the status will transition from "abuse improved" to "normal."

Note that these statuses and their transitions are not limited to the examples 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 be to "normal." Furthermore, if abuse is confirmed during "normal," the transition may skip "abuse suspected" and transition to "abuse confirmed." In this way, 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 an indicator 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."

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

This concludes the explanation of the concept of status, particularly its transitions, and now we will explain the details of the processing flow. Figure 11 is a sequence diagram showing the overall processing sequence in this embodiment. First, as a premise for this processing, it is assumed that a child is examined at a hospital and the doctor believes that the child's injuries may be the result of abuse. In this case, in step S301, the input unit of the hospital terminal 30 receives a linkage request instruction from a hospital staff member such as a doctor regarding information linkage regarding the child in question. The communication unit 36 then 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.

In step S101, the communication unit 16 of the consent acquisition server 1 accepts a collaboration request. In step S102, the consent management list creation unit 12 registers the accepted collaboration request in the consent management list 171. To do this, the consent management list creation unit 12 determines whether the consent management information for the child who is the subject of the collaboration request is included in the consent management list 171.

If the result shows that the child is not included, the consent management list creation unit 12 creates a new record in the consent management list 171 and records the child's name in the name field. Furthermore, if consent management information for the child is included, the consent management list creation unit 12 initializes the corresponding 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, the number of link attempts and the number of link refusals may also be erased. Furthermore, during initialization, the consent management list creation unit 12 may record the parent as the consenter. Furthermore, if consent management information is included, this consent management information may be reused. In this case, the consent management information may include the status, which may be used to determine the status. In this case, the status determination process described below can be omitted.

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 will create a new record in the consent management list 171 regardless of whether consent management information is included.

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 processes are described below using Figures 12 to 15. Figure 12 is a sequence diagram showing part of the status determination process and consent acquisition process in this embodiment.

First, in step S11, the status acquisition unit 11 of the consent acquisition server 1 sends 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.

Furthermore, 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 was accepted.

The status confirmation unit 23 also 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 also determine a predetermined status.

Furthermore, 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). Subsequently, the consent acquisition process (step S20) is executed.

First, in step S13, the consent acquisition unit 13 determines the status of the child who is the subject, as 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 performed in different procedures depending on the acquired status, and a response to the consent request is obtained.

In step S14, consent acquisition processing is performed under normal circumstances. Details of this will be described later using Figure 13. In step S15, consent acquisition processing is performed when abuse is suspected. Details of this will be described later using Figure 14. In step S16, consent acquisition processing is performed when abuse is confirmed. Details of this will be described later using Figure 15.

Furthermore, in step S17, the consent acquisition unit 13 identifies the consenter as a "parent" and registers this 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 this as the initial value.

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, i.e., that the abuse has been improved.

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

When the communication unit 16 receives a response from the parent terminal 6 indicating consent, the consent acquisition unit 13 adds one to the number of linkages in the consent management list 171 and updates it. The consent acquisition unit 13 also performs a process to confirm the "parent" recorded as a consenter in the consent management list 171 from a consenter candidate to a consenter.

Furthermore, if the communication unit 16 receives a response from the parent terminal 6 indicating that the parent does not consent, the consent acquisition unit 13 adds one to the number of collaboration refusals in the consent management list 171 and updates it. The consent acquisition unit 13 also 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 processing similar to step S14.

This concludes the explanation of Figure 12, and steps S14 to S16 will now be described in detail. First, Figure 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," as in step S17. More preferably, as described above, the consent acquisition unit 13 sets the "parent" as a consenter candidate.

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

Furthermore, in step S640, the input unit of the parent terminal 6 accepts the confirmation result for the collaboration consent request. In other words, information indicating whether consent is granted or denied is accepted. Then, in step S641, the parent terminal 6 notifies the consent acquisition server 1 of the information indicating whether consent is granted or denied. Note that this information also includes whether consent is granted or denied for a request for the child's personal information, which is an example of a collaboration request to another related party (in this example, the school).

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). If the result is no consent (NO), the process proceeds to step S144. If the result is consent (YES), the process proceeds to step S145.

In addition, in step S144, the consent acquisition unit 13 adds 1 to the number of collaboration refusals in the consent management list 171 and updates it. In addition, in step S145, the consent acquisition unit 13 records "Yes" as the consent in the consent management list 171.

Furthermore, in step S146, the consent acquisition unit 13 uses the information indicating whether consent has been granted to confirm whether consent has been granted to the collaboration request for other related parties (in this example, the school). If consent has been granted (YES), the process proceeds to step S148. If consent has not been granted (NO), the process proceeds to step S147.

In addition, in step S147, the consent acquisition unit 13 adds 1 to the number of collaboration refusals in the consent management list 171, updating it. In addition, 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 about the parent who is the consenter and a request for the provision of learning data 471.

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.

Furthermore, 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 accepts 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.

Furthermore, in step S149, the communication unit 16 of the consent acquisition server 1 accepts the linkage permission/denial notified in step S440. This concludes the explanation of Figure 13, and the process will now proceed to step S103 in Figure 11. Note that before explaining step S103, details of step S15 will be explained using Figure 14.

Figure 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, 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.

Furthermore, 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. Each of these terminals is a related party device of the multiple identified 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 on the school terminal 40 and the activity record data 571 on the support facility terminal 50. Of this data, the data for the relevant child is also confirmed.

For this purpose, the proxy consent unit 45 and the proxy consent unit 55 each output their own data to the output unit. As a result, each user can check the output data and determine whether or not they can give consent. The input unit also accepts input of the user's decision.

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

In addition, in step S152, the proxy consent acquisition unit 14 of the consent acquisition server 1 determines whether the number of consent-indicating 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.

Furthermore, 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. Further, in step S154, the proxy consent acquisition unit 14 updates the consenter in the consent management list 171 from "provisional 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.

In steps S155 to S158, the same processing as in steps S145 to S148 is executed. In this example, the destination of the collaboration consent request in step S158 is set to school terminal 40. This is the related device that notified the consent decision result in step S50. However, this destination of the collaboration consent request is merely an example, and the destination may also be a related device that does not consent. 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, we will proceed to step S103 in Figure 11. Before explaining step S103, details of step S16 will be explained using Figure 15.

Figure 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 in the consent management list 171 to "child consultation center." More preferably, as described above, the consent acquisition unit 13 sets "child consultation center" as a consenter candidate.

Furthermore, in step S161, the consent acquisition unit 13 notifies the child consultation center terminal 20 of a collaboration consent request via the communication unit 16. Note that the collaboration consent request has the same content as that notified in step S141.

Furthermore, 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. Furthermore, the input unit accepts input of the user's determination result.

Then, in step S261, the consent unit 24 notifies the consent acquisition server 1 of the judgment result received in step S260 via the communication unit 25. From then on, steps S162 to S169 are executed in the same manner as steps S142 to S149. This concludes the explanation of Figure 15, and we will return to Figure 11 and explain the processing from step S103 onwards.

In step S103, the collaboration authorization unit 15 determines whether information collaboration, which is an example of support, is possible. To do this, the collaboration authorization unit 15 uses the notifications regarding 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.

In step S104, the collaboration authorization unit 15 adds 1 to the collaboration count in the consent management list 171 and updates it. 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. In addition, when support is information collaboration, the scope 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 that identifies the target person and information indicating that support is permitted.

Then, in step S106, the collaboration authorization unit 15 transmits the permission ticket via the communication unit 16 to the hospital terminal 30, which is the related source device that requested the information collaboration.

Furthermore, in step S302, the communication unit 25 of the hospital terminal 30 receives the transmitted permission ticket. In response, 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.

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.

Furthermore, in step S304, the collaboration request unit 32 of the hospital terminal 30 outputs the data for which access has been permitted to its output unit. As a result, the user of the hospital terminal 30 can view the data.

Then, in step S305, the input unit of the hospital terminal 30 accepts the results of sorting and reviewing the viewed data, and the collaboration request unit 32 records this in the recording unit 37.

Now, let's return to the case where step S103 is NO and explain further. 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 as a transition from step S144, step S147, step S153, step S157, step S164, and step S167.

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 collaboration 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 in a direction of increasing 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 in a direction of increasing necessity means, in the example of Figure 10, the order is normal or when abuse is improved - when abuse is suspected - when abuse is confirmed. In other words, it means that the probability of support factors is high.

Then, in step S108, the collaboration authorization unit 15 notifies the hospital terminal 30 via the communication unit 16 of a collaboration denial, indicating that collaboration has been denied. In response, the user of the hospital terminal 30 reviews the child's electronic medical record recorded in the recording unit 37. Then, in step S305, 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.

Furthermore, in step S306, the input unit of the hospital terminal 30 accepts a request from the user to report child abuse and/or to seek counseling. The communication unit 36 then notifies the child consultation center terminal 20 of this. This request to report and/or request for counseling includes information indicating that the user wishes to report and/or seek counseling, as well as information identifying the child.

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 check, 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.

This concludes the explanation of the processing flow of this embodiment, but the present invention is not limited to the content described above. For example, the consenter or potential consenter 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 that constitutes it may be invalidated after a certain period of time, or may be managed as permanently retained. In the former case, this can be achieved 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 that constitutes it were created or updated, and performing the invalidation process.

Furthermore, the identification of the consenting party in steps S140, S150, and S160 may be set in advance in the consent management list 171. Furthermore, the child's name and status in the consent management list 171 may also be set in advance. Note that the consent acquisition server 1 may acquire the identification of the consenting party and the child's name and status from the child consultation center terminal 20.

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...connection request unit, 43...consent confirmation unit, 44...connection 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...connection request unit, 53...consent confirmation unit, 54...connection 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 (15)

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. 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. 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. 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. 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. 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. 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. 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. 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. 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 support is equal to or greater than a threshold value. 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. The program according to claim 11,
The status acquisition unit is a program that acquires the status from another device connected via a network. The program according to claim 11,
The consent acquisition unit is a program that acquires a response to the consent request in a different procedure depending on the acquired status. 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. 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.