Information Systems Integration

Certain obligations for integration between information systems can be derived from other parts of the NAP. It is necessary to distinguish whether the integration is internal or external and also what data is exchanged in the integration and for what purpose. The integration of information systems can be divided as follows:

1. Integration within an ISVS between several components
2. Integration within the systems of one administrator (internal integration)
   • between two public administration information systems
   • between an information system and a filing system and between an information system and a name register
   • between the ISVS and the operational information system
   • to a portal for publication purposes
3. Integration to systems of another administrator (external integration)

Integration between information systems of a single administrator is primarily the responsibility and domain of that administrator. This does not mean that such integration is not subject to compliance with the EG Principles, but it is not a primary concern of OHA until the ISMS administrator demonstrates compliance with the principles stated here (such as entity records or a linked data pool).

Technically, the recommended optimal method is to build a single integration platform and provide integration between the information systems in the form of services called and orchestrated in that integration platform. However, even when integrating (or exchanging data between) individual IS or agencies, consideration must be given to, for example, proper logging of transactions and auditing of personal data processing, especially if it concerns data on natural or legal persons.

However, the following always applies to internal integration:

• The AIFO shall be used as the subject identifier for the data exchange also in the internal integration, if the integration is provided by translation via eGSB/ISSS.
• If the integration takes place only within the perimeter of the administrator, and thus outside the eGSB/ISSS translation, then either the client number or the contact identifier shall be used as the identifier. This is also true in multi-agency operation where entities are integrated in a single AIS record used to support multiple agencies.
• The AIFO identifier shall not be used in any case when integrating AIS to operational systems, unless these systems use AIFO in their agenda. In the case of integration of entities between AIS and operational systems that do not have an AIFO assigned to the entity in the supported agenda, the client identifier shall be used.
• The AIFO shall not be recorded and provided in common registers and in multi-agency AISs, the AIFO shall only be used in such cases for external integration and, of course, to identify and update data for a specific agenda. Between multiple Agencies in one ISVS, the client identifier is used for linking and AIFAs are only entered in the AIS components for the individual Agencies, never in the common record. In the case of external integration, the AIS then calls the eGSB/ISSS or ISZR service via its AIFO via the common record.

In internal integration between components and systems of a single administrator, the AIFO is not primarily used because the client identifier is used. By using the client identifier and linking all data held on the subject across all agencies (always via a single AIS), the obligation not to request data already held once can be met and, combined with a single case record, the obligations to provide the subject with rights from the ISVS and to keep track of the data held on the subject and the relevant facts relating to the subject can be easily ensured.

As far as the integration between AIS and operational information systems is concerned, operational IS other than ESSL do not use AIFO in their agendas. Therefore, it is also necessary to use a client identifier or to establish another non-public identifier in the office, which can be used to link the data held in the operational systems. In any case, we do not use one of the AIFO identifiers to replace our own identifier in the office.

External integration makes maximum use of reference interfaces, in particular eGSB/ISSS as a technical means of exchanging data on subjects and objects of law. The technical implementation of integration via eGSB/ISSS shall be governed by the relevant eGSB/ISSS operational documentation.

For external integration the following shall be used:

• the translation of AIFO identifiers when exchanging subject (natural person) data; direct exchange via another identifier shall never be used,
• when exchanging data about an object (e.g. vehicle) its identifier (e.g. license plate number), but if a set of data about the subject is included, then for individuals (e.g. vehicle owner) the translation of AIFOs between the two agendas is used again.

When exchanging data within a linked data pool, the exchange mechanism via the translation of agency identifiers (AIFOs) via the ORG is always used. The integration takes place via the eGSB/ISSS services. Even in the situation where the OVM maintains some additional identifiers on the subject, it always proceeds in accordance with § 8, para. 3, of the Basic Registers Act and uses the service call provided by the agency information system providing the data, calls the service via eGSB/ISSS and calls it with the subject's AIFO identification, when subsequently eGSB/ISSS provides the translation of the AIFO, the providing AIS then sends the answer again via eGSB/ISSS, again with the translated AIFO of the interviewer. Thus, no other identifiers are necessary.

Of course, both sides of the integration log all transactions, and eGSB/ISSS itself stores information about the usage of the service.

If an OVM wants to retrieve subject data from another AIS, it must first identify the subject and have its agenda AIFO assigned to it. If it does not obtain the data from the provider, for example because the permissions to the data in the RPP are not set correctly, or because the provider has not properly identified the subject and does not have an AIFO for it, it will claim this with the provider as a breach of its obligations under the Basic Registers Act. The provider will then take corrective action.

Please note: For data so obtained from other agencies, this is data that the Authority maintains (even if technically obtained from another AIS) and therefore the Authority must follow Section 6, paragraph 2, of the Administrative Code and does not require or request the subject to provide it.