Review Meeting on Technical Requirements for Common Functions, etc. concerning Unification and Standardization of core business systems in local governments (3rd)

Overview

Date and time: Wednesday, February 1, 2023 (2023), from 16:00 to 18:00
Location: Online Meeting
Agenda:
1. Opening
2. Agenda
  - Continued examination Examination of Issue
3. Other
4. Adjournment

Materials

Relevant policies

Unification and standardization of core business systems in local governments

Summary of proceedings

Date

Wednesday, February 1, 2023 (2023), from 4:00 p.m. to 5:50 p.m.

Location

Held online

Summary of proceedings

1. Agenda

1. Review of Issue for Continued Review

[Status of review on Issue for continued review]

Observer: Regarding the revision of the Regarding the "concept of parallel operation" on P4, it is understood that there is a transitional measure for API cooperation because a parallel operation period occurs, but isn't it unnecessary for file cooperation because a parallel operation period is not assumed?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in file cooperation. However, it is assumed that the timing of the provision of the system based on the new version will differ depending on the local government. It is assumed that the system will be operated in parallel when the entire local government is viewed, instead of the parallel operation of the new and old cooperation in one local government like the API cooperation.
- Observer: Regarding the revision of the Understood.

Member: I would like to know when the Regarding "Linkage between the application management function and the application data of core business systems" on page 5, please explain the reason why it is decided to implement application management by file linkage.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in There are two reasons. The first is that the overall policy of the Agency's data connections is to ensure consistency with the point that API cooperation is used only in cases where online processing using the response results is required from the provision of the data on the request side. The other is that file cooperation is considered to be more preferable in terms of data capacity because attachment files are also subject to cooperation in this cooperation.
- Member: I would like to know when the Understood.
Member: I would like to know when the application data will be linked by specifying a directory even if they are linked as files?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in At present, when linking to core business systems from the application management function, it is assumed that the application ZIP acquired from the Justin Service will be linked as it is. It is assumed that the storage destination will be in accordance with the folder structure and naming convention described in the detailed technical specifications for file linkage.
- Member: I would like to know when the Understood.

Observer: Regarding the revision of the P7 remains as "2: Moving-out person" and does not become "X: Non-resident"?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in other than the core business systems Resident Record System is managed as a non-resident, it shall be updated to "X: Non-resident" as a change.
Observer: Regarding the revision of the Is it correct to understand that in the "Transition Diagram of Resident Classification" on page 18, when a person who has moved to "X: Non-resident" re-enters, the extraction of candidates for re-entering persons is performed using the data of the common function?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in Common Function, it is described on page 18. On the other hand, when assigning resident address numbers in the resident record system, candidate extraction is performed using the data in the resident record system.
Observer: Regarding the revision of the family registry and family registry Ticket will be managed as non-residents. Is it correct to understand that there is no change in the fact that management will be started as non-residents at the timing when management is required in each core business systems as before?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in As you are aware, it is not intended to expand the current definition of non-resident.
Observer: Regarding the revision of the , it is recognized that "1: Residents" and "X: Non-residents" are in an exclusive relationship. In addition, among those who have been changed to "X: Non-residents", non-residents who were "2: Those who moved out" and non-residents who were "3: Those who died" will be mixed, and it will be impossible to distinguish them. Is it necessary to distinguish them? It may be better to maintain the "Resident Status" in the Resident Record System as it is and manage the fact that they are managed as non-residents as a separate item.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in , it is considered that it is sufficient if it can manage whether or not a person is a non-resident. In addition, it is intended to ensure continuity with the "resident status" of the resident record system to some extent, and such update specifications (draft) of the resident specifications are used.
- Observer: Regarding the revision of the Understood.
Member: I would like to know when the , we recognize that a person who is scheduled to move out includes a person who is scheduled to move out by specifying a future date. In addition, we believe that if a person is scheduled to move out, he or she will still be treated as a resident strictly. In the case of a person who is scheduled to move out, it is accurate to change him or her to a person who is scheduled to move out at the arrival of the scheduled date, but it is necessary to build it into the system. On the other hand, if it is only to change him or her to a person who is scheduled to move out in accordance with the transfer information from the resident record system, the construction will be simplified. Regarding this point, we would like to clarify how it will be handled as a common function.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in We will consider it in light of your comments. We believe that it will be consistent with the transfer information from the resident record system.

Observer: Regarding the revision of the As stated in the "Regulations on the Standardization of Identity Verification Levels and Methods for Non-Residents" on page 8, the Identity Verification Level is related to the system for each business, and therefore, it is not considered to be included in the standard specifications of the system.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in Standard Specifications. As the background of the discussion, it is assumed that the address information of non-residents is information acquired through Juki Net, temporary residence information, etc., and the registration of address information at various identification levels is considered, so there was a discussion that the operation should be specified according to the identification level.
- Observer: Regarding the revision of the Certainly. It was understood that the study was not intended to standardize the level of identity verification, but to focus on the difference in the accuracy of address information of non-residents.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in As you know.
Observer: Regarding the revision of the Regarding "Identity Verification" on P8, the intention pointed out in the Review Meeting so far is to request that the functions be rearranged assuming that there are differences in the identity verification levels. Under the current regulations, there are two points of Issue. The first point is that there is a doubt about the accuracy of the information that the basic 4 information of the address acquired by the Juki Net is overwritten by the latest information, including those with low reliability. The second point is that there is a concern that the reliability of the address number itself will be shaken due to a difference in the accuracy of the judgment of the same person premised on the first point. It is also possible to take measures as a function on the premise that the identity verification levels are the same and that there are differences in the identity verification levels. It should be reminded in some form that address information with different identity verification levels is registered for local government and that it is necessary to deal with it in business operation on the premise that it is registered.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in We will consider it in light of your comments.
Observer: Regarding the revision of the On page 8, there is a description that "Regarding the identity verification information received from the Juki Net, (Omitted) careful response is required." However, in reality, it is considered difficult to register the identity verification information acquired by the Juki Net because it can be used by services other than those specified in the Appendix of the Basic Resident Registration Act.

Observer: Regarding the revision of the , we believe that it is necessary for the competent ministries and agencies to present their interpretation of the management of support measure information. Please tell us what kind of assumption you have. We believe that the definition of personal data protection will be unified in local government from FY 2023, and the difference in handling by local government will basically be eliminated. On that premise, we believe that it is necessary for the competent ministries and agencies to present their interpretation to local government.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in It is not prohibited for each ministry and agency to present their interpretation, but we would like to discuss the issue of presenting the interpretation by each ministry and agency as a general policy in the future.

[Status of consideration of horizontal alignment policy]
No particular discussion

[Status of examination of other matters to be examined]

Observer: Regarding the revision of the Page 12 (4) states, "It is assumed that data will be provided on behalf of the standard compliance system (including the integrated DB)." However, it is considered that methods other than those described can be used, and the expression is not accurate. In addition to the cooperation with the original action plan system, it is necessary to configure the office work not subject to standardization and the functions not subject to standardization by loose coupling with the University. Therefore, it is necessary to organize and examine whether the provisions of the current cooperation specifications are sufficient for all of them.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in As you pointed out, the wording is not accurate. We will consider it based on your comments.
Observer: Regarding the revision of the 's own action plan system provides data to standard compliance system?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in In the previous opinion inquiry, it was not possible to explicitly narrow down the cases in which the original action plan system is provided. In addition to confirming the content of the past opinions again, we would like to determine whether or not to make another opinion inquiry to the members based on the schedule for future revision of written specifications.

Observer: Regarding the revision of the Regarding the "deletion flag" on P14, how is the "linked data" identified? Is it necessary to assign some identification number to the linked data?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in . However, if information for identification is insufficient, additional provisions will be considered.
- Observer: Regarding the revision of the Understood.

Member: I would like to know when the Regarding (2) on page 14, it is stated that the group for cooperation with other operations will be deleted. However, the EUC function requires cooperation with the items in the Basic Data List, and if the group for cooperation with other operations is deleted from the Basic Data List, it may not be possible to cooperate with the EUC.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in We are aware of your concerns and plan to update the horizontal alignment policy. At that time, we plan to add that items belonging to the Other Business Cooperation group can be linked to the EUC function even if they are not specified in the Basic Data List.
- Member: I would like to know when the Understood.

Member: I would like to know when the Regarding the "method of file cooperation" on page 13, it is stated that it is basically created as an object storage in the provider system. Is it correct to understand that the policy has been changed from the assumption that one file server is provided as a common function?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in As you understand.
Member: I would like to know when the Regarding the "Method of File Cooperation" on page 13, is cooperation with 4 csp an essential function of implementation?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in Continue to consider whether cooperation with the four CSPs is an essential function for implementation. It is assumed that sample code for accessing the object storage of each CSP will be provided.
- Member: I would like to know when the Understood.
Member: I would like to know when the Regarding the "method of file cooperation" on page 13, shouldn't it be considered that there are cases in which object storage cannot be used when both parties are on-prem?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in We will consider it based on your comments. If you have any comments on our response policy, we would like to hear them.
- Member: I would like to know when the Until now, we have assumed that FTP and SFTP servers will be used for implementation. We have thought that using them will enable file cooperation in a secure manner and without dependence on CSP. However, we can understand the direction if object storage is used in anticipation of the promotion of cloud use in the future. We would like both parties to share the results of the study in the future, including the treatment of on-preh.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in Understood.
Member: I would like to know when the In "File Linkage Method" on page 14, [implementation Required in Government Cloud], there is a description that IAM is used in the case of AWS. It is recognized that in the explanatory material on the use of Government Cloud for local government, the IAM user's payment authority is supposed to be held by the Government Cloud Operation Management Assistant, and it is necessary to organize it in accordance with this point.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in We will consider it in light of your comments.

Observer: Regarding the revision of the Regarding (2) on P15, if additional provisions are not made for the management items of standard compliance system corresponding to the preset items of the perfect service, any data item can be captured, so both local government and vendor may have difficulty. Even if it is difficult to respond within this fiscal year, it is necessary to set a deadline for when to implement it.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in As you pointed out, we believe that it is desirable to present a correspondence table after all the preset items and corresponding management items of the perfect service are specified in the standard specifications. On the other hand, we would like you to understand that it is practically difficult to have each ministry and agency responsible for the system review all the management items in the schedule for the revision of specifications by the end of this fiscal year. We will cooperate with each ministry and agency responsible for the system and promote responses in the next fiscal year and beyond.

Member: I would like to know when the On page 16 (1), it is stated that "the specifications for the internal unified address and the connection specifications with the intermediate server are considered to be unclear" have been discussed with J-LIS. Based on the results of the discussion, is it correct to think that something will be reflected in the revision of the specifications in March?
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in As you are aware, the content will basically be completed within the Common Function Specifications and will not affect the specifications for the intermediate server. Therefore, it is assumed that the direction will not change during the consultation.

Observer: Regarding the revision of the Common Function Specifications, we believe that how to apply it to prefectural governments is an important issue. We recognize that there are cases in which certain prefectural governments maintain the intra-organization unified address function.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in We are considering the points you pointed out, and we plan to reflect the policies in the revision by the end of the fiscal year. We understand that the internal unified address, etc., that you mentioned is being used, and we are considering a policy that if it is configured, it will be in accordance with these specifications. However, we have not been able to grasp the introduction status of prefectures, and we plan to conduct an additional survey.
Member: I would like to know when the character requirements will be shown.
- Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in Office is considering the details and will indicate the direction by the end of the fiscal year. We will provide the information separately.

2. Other

Secretariat: Regarding the requirements for Integrated Collection and Delinquency Management as a common function in , at the second review meeting at the end of last year, we announced that we would show the status of the review to the members as of the end of January, but at present, the preparation has not been completed. We would like to share the status as of February 10 in advance. In addition, we would like you to understand that we plan to confirm the complete set of materials such as functional requirements, item definitions, and functional cooperation specifications in the national opinion inquiry.