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

Local governments Working Team (1st) of the Review Meeting on Technical Requirements for Common Functions, etc. on the Unification and Standardization of core business systems in data connections

Overview

  • Date and Time: Friday, October 21, 2022 (2022) from 14:00 to 16:00
  • Location: Online Meeting
  • Agenda:
    1. Opening
    2. Agenda
      1. Study Overview
      2. Issue on API Alignment
      3. Issue for file linkage
      4. Issue relating to data connections during the transition period
    3. Other
    4. Adjournment

Materials

References

Relevant policies

Summary of proceedings

Date

October 21, 2022 (2022) (Friday), from 14:00 to 16:00

Location

Online Meetings

Summary of proceedings

1. Outline of the review

  • No particular discussion

2. Issue related to API cooperation

  • Member: In the functional cooperation specifications, it is considered that the PUSH type API is necessary even for cooperation in which file cooperation is not permitted. It is assumed that it is not realistic to obtain the PULL type every time it is updated.
    • Secretariat: Although file cooperation is not specified for all collaborations, we are considering expanding the scope of file cooperation. Is it correct to understand that if file cooperation is specified, the need for PUSH-type APIs will be eliminated?
    • Member: As you know.
  • Member: is supposed to acquire PULL type data from the core business systems Pittari service. Will the PUSH type also be considered in the future?
    • Secretariat: Based on the PULL type API, we assume that each standard compliance system will make periodic inquiries about data connections. However, we would like to discuss the necessity of providing PUSH type data at this Review Meeting and consider whether to consider it based on your opinions.
  • Member: transition period, is data connections performed using the PUSH type API when data is linked to the integrated DB (Link Infrastructure) located between the pre-standardization system and the post-standardization system?
    • Secretariat: Functional Cooperation Specifications is not allowed, in the case of API cooperation, the integrated DB (cooperation infrastructure) will PULL the API provided by standard compliance system, and in the case of file cooperation, the integrated DB (cooperation infrastructure) will capture the data output by standard compliance system. Therefore, we are not thinking of realizing cooperation with the integrated DB (cooperation infrastructure) using the PUSH type API.
    • Member: I understand. In that case, it is considered that the PUSH type API is unnecessary. It is considered that it is difficult to process if the update data arrives in the PUSH type during the execution of the file capture batch.

  • No particular discussion

  • Member: tax, core business systems takes in one year's worth of data, so there is a concern about linking large amounts of data with APIs.
    • Secretariat: Basically, file cooperation is assumed for the cooperation of large amounts of data. In the case of processing large amounts of data through partial API cooperation, it is assumed that each local government and vendor will set a timeout period. In addition, we are considering expanding the scope of file cooperation from the current situation.
  • Member: It is considered that 1.1.9. and "1.1.2. Setting the upper limit of the number of items to be retrieved, the storage size, and the timeout value" should be discussed together because they are caused by the same Issue.
    • Secretariat: and the limit for the number of items to be acquired differ from local government to region, it is assumed that the upper limit and the limit for the number of items to be acquired are set by external parameters.
    • Member: Does each vendor have a check function for request parameters that may cause an error, for example, when only a city code is specified in search conditions? Does each vendor have a design for the check function?
    • Secretariat: We would like to hear your opinions on whether the control of individual parameters should be specified in common or whether it should be left to the judgment of each vendor's implementation. We will check the total number of responses, and we believe that not performing control by individual parameters is an option.
    • Member: When checking the total number of acquired data, it is considered unnecessary to check individual parameters. Considering the load of the application, the load of implementation is small. First, the number of acquired data is counted, and if it exceeds the maximum number of data that can be acquired, it is regarded as an "excess error."
    • Secretariat: I understand. In addition to the function to check the number of data acquisition, we would like to consider setting an upper limit on the number of data acquisition.
  • Member: Is it correct to understand that it is possible to search by identifying an individual using individual parameters and that it is possible to search without identifying an individual using common parameters?
    • Secretariat: As you know.
    • Member: Resident Record System, it is difficult to set an upper limit on the number of data to be acquired on the request side due to the large amount of data. Therefore, it is desirable to check the number of data to be acquired and select whether to continue or stop the processing.
    • Secretariat: We will consider it based on your comments.

  • Member: The state in which the data connections with other systems depends on the implementation of each operator leads to customization. Since the testing pattern will be identified and sample data will be created at the time of the collaborative development, we believe that the relocation can be efficiently performed without inconsistency if the sample data is provided as specifications.
    • Secretariat: For specific parts that require sample data, we would like to ask for your opinions on unclear parts after checking the standard specifications of each business along with the functional cooperation specifications. The Secretariat will also consider providing sample data.

  • Member: Is it correct to recognize that when data is corrected retroactively, the operation date is updated without changing the history number?
    • Secretariat: As you know, it is assumed that the operation date will be updated.
    • Member: If the past history number is not changed, it is better to fix the history number, so it is better to hold the latest flag instead of all 9.
    • Secretariat: Certainly.

  • Member: Does the statement "There is a parameter to acquire the transferred portion" mean the operation date and time? When the business side that has been transferred holds the operation date and time and acquires the transferred portion, is it necessary to acquire the data after the held operation date and time? Is it necessary to acquire the data connections date and time?
    • Secretariat: As you know.
    • Member: For the following three reasons, there is a possibility that the acquisition of transfer data may be omitted. Therefore, it is desirable to manage by sequential numbers instead of operation dates and times.
      • Since operation date and operation time are managed in units of seconds, there is a possibility that data acquisition in units of milliseconds may be omitted.
      • The time is obtained from the server, but the set time for each server may be different.
      • It is assumed that the concept of recording the operation date and time differs depending on the application, and there is a time lag between processing in the application and writing to the DB.
    • Member: operation date and time refer to the "time operated by the Employee" or the "time stored in the DB". It is better to specify them in written specifications, etc. because there is a possibility that a misunderstanding may occur.
    • Secretariat: Specifications, etc.
  • Member: In the case of national health insurance, second semester, and nursing care, there is no address number in the primary key, and it is difficult to obtain data from other operations. Therefore, it is better to add the address number to the common parameters.
    • Secretariat: Insured Number, etc. We will consider it.

  • Member: In authentication and authorization, who is assumed to build the authorization server?
    • Secretariat: File Server, the building entity of the authorization server is not specified. If a baseline for the building entity of the authorization server is required, such as the file server, we would like to hear your opinions.
    • Member: local government, we would like you to issue a policy as soon as possible. If the national government provides an ID management function, we would like you to make it known as soon as possible.
    • Secretariat: State, the timing of the provision is expected to be after the response to standardization. Therefore, in response to standardization, it is necessary to build an authorization server by vendor and local government without assuming that a unified ID platform will be provided. We would like to show at the review meeting by the end of this year what kind of unit is desirable to build.

3. Issue related to file linkage

  • Member: baseline, but from the perspective of procurement as a local government, it is difficult to know how to procurement. Shouldn't the provision of a file server be provided as a common function, not as an integral part of the resident record system?
    • Secretariat: We will consider it in light of your comments.
  • Member: Since the order of systems to be standardized differs from local government to region, there may be an idea of building a file server in combination with the system to be introduced first. We assume that there are many resident record systems, but there may be other cases.
    • Secretariat: If the construction of a file server is combined with the first system to be introduced, any system and any vendor may build a file server.
    • Member: In the case of multi-vendor, since the system to be introduced first starts cooperation, it is considered that procurement as a set of the system to be introduced first and the common function is also an option.

  • Member: is described in the standard specifications of the data connections Service, it is considered unnecessary to review or add specifications.
    • Secretariat: Certainly.

  • Member: 's opinion is that a mechanism for identifying the version number of specifications is necessary. It is considered that the version number of the linkage specifications cannot be determined based on the time stamp in the response.
    • Secretariat: completion notice file.

  • Member: Concept where there is no vendor that performs the system common function mean the case where local government constructs file servers?

    • Secretariat: As you know.
    • Member: In general, it is considered that it is better for the entity building the file server to grant the authority.
    • Secretariat: Is your opinion based on the idea that it is inefficient to build an authorization function on each core business systems side?
    • Member: As you know.

  • Member: file servers, which department in the local government is assumed to grant the necessary authority to the provider system that performs the authority granting operation? If the authority is to be granted, it is considered better to grant the authority centrally at the file servers.

    • Secretariat: local government and the mechanism and division of authority as a system function.

4. Issue Relating to data connections during the transition Period

  • Member: What is the intention of the description that "a form in which it is constantly provided is also possible"?
    • Secretariat: Integrated DB will continue to be used not only during the transition period but also after the transition period, it has been described as "permanently."
    • Member: Certainly.
  • Member: When a system after standardization and a system before standardization work together, it is considered that the system before standardization does not support API cooperation after standardization. What specific measures should be taken?
    • Secretariat: In exceptional cases, it is possible to establish an existing IF (pre-standardization IF) in the post-standardization system and work with the pre-standardization system.
    • Member: standardization be considered?
    • Secretariat: The new cooperation to be started after standardization is the arrangement in which both systems cooperate in the post-standardization IF after standardization.
    • Secretariat: As a general rule, only the IF after standardization will be established in standard compliance system. Therefore, we would like to add that the basic response is to establish the IF after standardization in the system before standardization. On the other hand, it is possible to establish the existing IF in local government as a response when it is difficult to do so based on the circumstances of the transition method for each standard compliance system.
  • Observer: In the case of a system with a direct IF, it is stated that "a conversion function that temporarily absorbs the IF difference is required on the standard compliance system side." Is it assumed that the functional requirements will be specified in the standard specifications for each service? If they are not specified in the standard specifications for each service, it is recognized that this falls under customization. As an external system to avoid customization, a system that mediates the conversion function may be good.
    • Secretariat: Standardization Act, and we would like to arrange it so that implementation is possible even if there is no provision in the standard specifications.

  • Member: Since questions are expected to arise in the course of promoting development in the future, it is requested that a contact point be established to respond to questions from vendors.
    • Secretariat: Since we have been communicating with APPLIC member business operators on GitHub, it is possible to continuously respond there. We would like to consider how to respond to questions and answers, including such response.

5. Other

  • Secretariat: The next Application Management Working Team was expected to be held from 14:00 to 16:00 on November 1 (Tue), but we will contact you again after adjusting the date and time based on the fact that the J-LIS Fair will be held on the same date.

End