Skip to main content

This page has been translated using TexTra by NICT. Please note that the translation may not be completely accurate.
If you find any mistranslations, we appreciate your feedback on the "Request form for improving the automatic translation ".

Application Management Working Team (2nd) and data connections Working Team (3rd) of the Review Meeting on Technical Requirements for Common Functions, etc. on Unification and Standardization of core business systems in local governments

Overview

  • Date and Time: Tuesday, November 29, 2022 (2022) from 10:00 to 12:00
  • Location: Online Meeting
  • Agenda:
    1. Opening
    2. Add Member
    3. Agenda
      • Application Management Working Team
        1. Overall picture of the best proposal opinions on application management and how to proceed in the future
        2. Discussion of Issue's approach to application management
      • Data connections Working Team
        1. Overall picture of the opinions on the best plan for data connections and how to proceed in the future
        2. Description of Issue's response policies regarding data connections
    4. Other
    5. Adjournment

Materials

Relevant policies

Summary of proceedings

Date

Tuesday, November 29, 2022 (2022), from 10:00 a.m. to 12:00 p.m.

Location

Online Meetings

1. Addition of Members

  • No particular discussion

2. Agenda

Application Management Working Team

1. Overall picture of the opinions on the best proposal for application management and how to proceed in the future
  • No particular discussion
2. Discussion of Issue's response policies on application management

& lt; 1.1.2. Organizing perfect service and core business systems item correspondence>

  • Observer: by setting one API as the core business systems endpoint. In that case, since the management items that can be held by the core business systems are determined in the standard specifications, whether or not it is a preset item of the perfect service may not affect the sorting. On the other hand, if there is a management item of the core business systems that is not in the application item of the perfect service, it is necessary to add it to the service side. By doing so, the optional setting items may be eliminated.
    • Secretariat: core business systems need to be captured, and preset items for the Perfect Service will be associated with them. Items without presets will be scrutinized and handled, and consideration will be made in the direction of correspondence, including addition to presets. Since local government can be optionally added to items other than presets, handling will be examined on the premise that there is a certain amount of optional setting items.
    • Observer: optional items will change in the future. It is free to set optional items in the exact service, and it can be used for examination in the application management function, but it will not be possible to work on core business systems. It is necessary to organize the data to be worked on core business systems together with the fact that it is not possible to add it at the discretion of local government because it has been standardized, and if it is necessary to add it, it is necessary to make it an original action plan system.
    • Secretariat: We will consider it in light of your comments.
  • Member: At present, when an application ZIP is obtained from the Matome Service, an item mapping CSV is downloaded. In it, mapping is performed between three items: the screen entry item name, the form-specific item name, and the APPLIC standard item name. We recognize that the APPLIC standard item name is an item of the current area Information Platform, but is there a plan to replace it with the item name of the basic data list in the future? The APPLIC standard item name also remains in the specification of the application data inquiry API, but we believe that it is actually the item name of the basic data list, and we would like to consider that in the future.
    • Secretariat: I understand. The APPLIC standard item names are listed as per the current specifications of the Perfect Service, but we believe that they should be replaced with the item names in the Basic Data List, and we will add them to future discussions.

& lt; 1.2.2. Clarification of the handling of procedures in which presets are not specified>

  • Observer: Action Plan (draft) states that "It shall be possible to incorporate items other than presets as management items in the basic data list." The comment is the same as "1.1.2. Arrangement of Correspondence between Items of Fitted service and core business systems," but items other than those specified as functional requirements of core business systems cannot be incorporated. It may be added to the application items of the Fitted service, but it is necessary to clarify that it is necessary to use it only for visual inspection confirmation of the application management function or to incorporate it into the original action plan system.
    • Secretariat: We will consider it in light of your comments.

& lt; 2.1.3. Sorting out the division of roles and flow of the entire online application & gt;

  • Member: Main Sub Issue, format check, format examination, substantive examination, etc. are specified, but the substantive examination is to be performed on the core business systems side. On the other hand, the standard specifications for resident records do not specify the function of rejection or return in the examination of the moving OSS, and are specified to the extent that the content is confirmed by another person in charge. In the future, if rejection or return is required on the core business systems side, how much rough schedule will be specified?
    • Secretariat: core business systems side to the application management falls under the application processing status registration API described in the Division of Roles (Draft) diagram. It will be a review Issue after the transition Support Period until the twenty twenty-five. As a response to the transition Support Period, as shown in the Current Horizontal Alignment Adjustment Policy, it is sufficient if the application processing status in core business systems can be displayed on the screen or output, and it is assumed that the application management function will register the application processing status based on the content.
    • Member: Roger.
  • Observer: Perfect Service, but we recognize that there are some procedures that are not one stop applications online. Face-to-face procedures for applications for long-term care insurance and pregnancy notification are required in Ministry of Health, Labor and Welfare, and you have to go to the counter after all. Even for the system, it may be necessary to assume an inflow route from other than online applications even in the same procedure, such as when you bring the application documents face-to-face. In addition, we would like to ask each ministries and agencies to make it possible to make one stop applications online.
    • Secretariat: We will continue to respond in cooperation with the ministries and agencies with jurisdiction over the system.

  • Observer: suspension until the application data inquiry API is constructed" in the implementation materials means that the function construction of the core business systems is suspended until the application management function constructs the application data inquiry API?
    • Secretariat: As you know.
    • Observer: Since the common functions will be standardized after fiscal 2026, I think the application management function is also essential for implementation. Will the grace period be under twenty twenty-five? If it is allowed after fiscal 2026, there will be a period in which an application management system that does not satisfy the standard specifications of the application management function is allowed.
    • Secretariat: I explained earlier that the grace period for API construction will be until the application management function provides the API, but we will continue to consider the scope of the transitional period.
  • Observer: There is a description that "Methods 3 and 4 are to be standard optional functions." Is it correct to understand that they are to be standard optional functions of core business systems so that the functions already implementation to core business systems as Methods 3 and 4 can be used?
    • Secretariat: As you are aware, it is planned to specify in the horizontal adjustment policies that implementation to core business systems is possible as a standard option function.
    • Observer: Methods 3 and 4 are used as standard optional functions, isn't it unnecessary to "postpone the implementation until the application data inquiry API is built"? Or does it mean that even if Methods 3 and 4 are used, the application data acquisition API is also necessary in the end?
    • Secretariat: This is the latter recognition. Since the standard option function is a transitional measure, it is necessary to eventually unify the application data inquiry API. We will continue to consider the description of the horizontal adjustment policy so that the concerns will be resolved.
    • Observer: Roger.
  • Member: . Does it mean that implementation of the application data inquiry API is essential for core business systems, but implementation is not necessary in the transitional period? In that case, one of Methods 1 to 4 is adopted for the application management function, but core business systems may use the application data inquiry API, and the cooperation method of the common function and the cooperation method of the core business systems side may not be compatible?
    • Secretariat: In the case of using Methods 1 to 4 in a transitional period, it is assumed that the application management system was created based on the current Ministry of Internal Affairs and Communications Specifications, and it is not assumed that the cooperation methods do not overlap. However, based on the opinions of users, we will specify the methods so that there are no inconsistencies while compensating for points that are difficult to sort out.
    • Member: Roger.

  • Member: form examination, date, month, and time as request items to a minimum because the system will need to be repaired. Next, if a request is made for date-related items such as the date of the form examination or the date of acquisition, we believe that there is a possibility that data that cannot be acquired will remain if the period of the request is shifted. In addition, we believe that it is better to add a flag to the API as a request item so that if there is any unacquired data, it will be acquired so that the application management function will go to the service to acquire the data, and if it is specified from the core business systems side, all the unacquired data will be linked so that there will be no acquisition omission.
    • Secretariat: We will consider this based on your comments. We think it is desirable to have a flag that has not been obtained, but as stated in the request for information, we would like to hear your opinion on when to set the flag. There is a concern that when some error occurs, the application management function will set the acquired flag even though it has not been received by core business systems. There is also a concern that the receipt by core business systems will be notified to the application management function and the acquired flag will be set, but there is also a concern that the processing will be complicated. The exact service has the same function, so the final policy will be determined based on that point.

  • Member: Working Team has proposed that the acquisition of implementation application data should be done through API. However, the data connections Working Team recognizes that the scope of file cooperation is being considered to be expanded overall. It is considered that it is very difficult to prepare an authentication function only for the application data acquisition API. We would like you to consider this in conjunction with other data connections policies.
    • Secretariat: I understand. We will continue to consider the number of targets for overall file cooperation and API cooperation.

Data connections Working Team

1. Overall picture of the opinions on the best plan for data connections and how to proceed in the future
  • No particular discussion
2. Explanation of Issue's response policies regarding data connections

  • Member: I think that individual API specifications will not be created, but in the list of API provisions, only Japanese names of request items are currently written. Is it correct to think that it can be provided after the parameter name, type, number of characters, etc. are specified?
    • Secretariat: The "List of API Regulations" contains matters that can be changed for each cooperation (call name and parameters). Since the "Detailed Technical Specifications for API Cooperation" specify the parameters, data types, essential / optional items, etc. that are commonly specified, it is recognized that there is no shortage of necessary matters in this specification.
    • Secretariat: items other than Japanese names are specified in the "Basic Data List" and should be referred to together with the "List of API Provisions".

  • Observer: API is a PULL type, I can understand the #1 that the original action plan system receives, but I cannot imagine the operational use cases of the #2 that the original action plan system passes. In addition, as the core business systems, the target system to be called is specified by the functional requirements and the cooperation requirements. Therefore, isn't it necessary to separately organize the handling of the function to be called as the API of the original action plan system without the specification? If there is #2, it is assumed that it will be passed on behalf of the core business systems. If it is illustrated, the original action plan system may be inserted between the standard compliance system.
    • Secretariat: At present, we are not assuming a specific use cases in the case of "handed over by the original action plan system," but are indicating the response policies based on what is logically assumed. The specific use cases will be scrutinized.
    • Observer: Roger.
  • Member: Horizontal Alignment Adjustment Policies, the address management system is specified as an original action plan system. Is the arrangement of this sub Issue applied?
    • Secretariat: As you know.
  • Observer: medical care for the Elderly System currently receives resident record information, etc., including address numbers from municipalities. At that time, since the current resident record system does not have unified data, it works together after converting it to standard data. In the future, since the resident record system will be standardized, it is assumed that the conversion function will be unnecessary, but it is considered that the conversion function will continue to be necessary if the address management system continues to exist as an original action system.
    • Secretariat: Understood.
  • Observer: education, etc., where data from the resident record system and the system such as the school register are currently used in an integrated manner, is there any assumption that a new API that will be passed after data integration will be considered in the standardization process?
    • Secretariat: is assumed. It is assumed that data is received from each core business systems and used by integrating the data in the system of the user with the address number as a key.

  • Member: Agency, the necessity of adding risk items will be examined again. Please tell us the schedule. Is it assumed that it will be in time for the revision at the end of this fiscal year?
    • Secretariat: Office are linked by file, we believe that the IF, which was a concern, can be resolved by using it as a search item in each core business systems without adding a request item. If it remains as an API, the addition of a request item specific to a business is scheduled to be included in the revision of the specification at the end of the fiscal year.
    • Member: Roger.

  • Member: Sub- Issue are non-binding references? In particular, it is stated that the version number that allows parallel operation is two generations, but is it correct to understand that this is also non-binding?
    • Secretariat: Basically, as you know. On the other hand, if the version number of the opinion is used as a reference, it is assumed that the entire version number may not be consistent. Therefore, we will consider the provisions so that there will be no inconsistency in the future.

  • Member: "1. Method for using the basic data list (* There are conditions)"? In addition, can the basic data list that is linked with standard compliance system through the original action plan system be linked without restrictions?

    • Secretariat: Personal Identification Numbers, a specific personal data cannot be linked. In addition, it is necessary for each local government to determine how much information in the Basic Data List can be used in accordance with the characteristics of the office work of the unique action plan system, including the exchange between office work using Personal Identification Numbers, in light of the system of the business side.

  • Observer: At present, the output file of the basic data list is not a linkage requirement but is specified as a data requirement for transition. We are concerned about whether each company can respond to the point that all items are output to be linked to the original action plan system on a daily basis and the point that all items are updated when the original action plan system captures data.

    • Secretariat: As you have commented, the basic data list is currently regulated only as data requirements. Therefore, it will be regulated so that differential linkage, which is an update, can be performed as a linkage requirement. Other necessary matters will be examined based on your comments.

  • Member: If multiple patterns are specified as references, there is a possibility that a discrepancy in recognition may occur between the two parties in the cooperation, and as a result, there is a concern that multiple IFs will have to be created. Can't you specify what the basic principle will be?
    • Secretariat: Since it is specified as a case where the existing IF used in the current system is continued (#2 in the document), we will consider, for example, presenting a basic response policy based on the opinions.

3. Other

  • No particular discussion

End