Obsah
eGovernment On-Line Service Bus / Shared Service Information System
The eGovernment On-Line Service Bus (eGSB), also known as the Information Shared Service System (ISSS) according to the legislative wording, is a unified interface for sharing data between different public administration information systems. It is part of the reference interface allowing individual AIS to draw on and publish data held on individual legal entities. Where an agency is required by law to maintain its own data records, it is obliged to publish its data to other agencies through eGSB/ISSS as a secure, standardised and documented interface for authorised readers. It is managed and operated by the Basic Registries Administration. The eGSB / ISSS interface allows:
- Publish services for sharing data relating to specific subjects and objects of law
- Use data sharing based on published services
- Translation of agency identifiers of individuals for whom data is exchanged between agencies (AIFO translation)
- Exchange of data files with data on subjects based on pseudonymised identifiers in relation to translated AIFO identifiers
- Provision of claim, notification and update services for data provided by AIS services
- Provision of independent auditing of the data exchange (stores information identifying the query and response and the technical cryptographic fingerprint of the message - hash)
In eGSB/ISSS there is a restrictive condition for the use of the MapAIFO element compared to ISZR. This element can only contain a single AIFO when called by G1:gsbCtiData and G11:gsbZapisData. There may be more than one AIFO in the response. This is because
eGSB/ISSS is fundamentally a multi-source system. A single context can be published by multiple publishers/AIS and the reader does not need to know in which one the information about the individual is located. ISSS performs a logical search, using ORG to identify target AISs (they maintain the AIFO and publish the context) and then sends a request to these publishers. At the same time, the eGSB/ISSS must not alter the payload of the message in any way, i.e. it cannot "split" and send one at a time to different targets. The above applies to all calls for now, but a so-called multi-source to single-source narrowing method is planned. That is, if the target AIS is uniquely identified, and thus known to the user of G1:gsbCtiData or G11:gsbZapisData. This would remove the requirement for a single AIFO only for the narrowing method on the target AIS.
The functionality of the principle is verified on the reference data held in the basic registers, where the client does not have to prove these data and their changes, but the whole public administration obtains these data through ISZR services and then makes decisions based on them. The principle of data sharing via eGSB / ISSS is only an extension of this functional unit to include other data.
Two main roles are defined for the use of eGSB / ISSS:
| Role | Description | What it provides |
|---|---|---|
| Publisher (provider) | ISVS administrator from which data is provided | Services publishing data via eGSB / ISSS, based on the agenda providing data from the AIS |
| Reader (user) | OVM retrieving data from another agenda based on its permission in RPP | Connection to eGSB / ISSS and calling publisher services (even multiple AIS of a given agenda), AIFO translation from the provider's agenda is used, the reader calls according to the AIFO of its agenda in case of a natural person. No translation is used for a legal entity. |
In the context of data sharing via eGSB / ISSS, the following aspects apply:
- The data are reported in the register of rights and obligations as data processed by the agenda on the basis of a legal mandate.
- The data must be held in the AIS
- The data is clear how it was created, who is responsible for its entry, changes and management, in which AIS it is held and how it can be amended or cancelled.
- The data provider is always the administrator of the AIS in which the data is held and recorded.
- The data is always linked to a right subject or right object in ZR.
- It shall be possible for the right holder to extract the data as an extract from the public administration information system.
As the aim is to link data efficiently and effectively, primarily to reduce the need for the client to prove facts, the data will be retrievable by the public authority:
- on the basis of the consent of the right holder (on behalf of the right holder), or
- on the basis of a legal mandate to keep the data in an agenda with a drawdown flag in RPP (ex officio)
Information on the data sharing information system is available at MoI website, including documents:
List of eGSB / ISSS services
| Code | Detailed description of the service | Version |
|---|---|---|
| G1 | gsbCtiData | 1.00 |
| G2 | gsbCtiZmeny | 1.00 |
| G3 | gsbVlozOdpoved | 1.01 |
| G4 | gsbVlozSoubor | 1.00 |
| G5 | gsbCtiSoubor | 1.00 |
| G6 | gsbVypisFronty | 1.00 |
| G7 | gsbOdpovedZFronty | 1.00 |
| G8 | gsbSmazatFrontu | 1.00 |
| G9 | gsbProbe | 1.00 |
| G10 | gsbCtiKontexty | 1.00 |
| G11 | gsbZapisData | 1.03 |
| K1 | katCtiSluzby | 1.00 |
| K2 | katCtiDetailServices | 1.00 |
| K3 | katCtiPrilohu | 1.00 |
| K4 | katCtiEndpoint | 1.00 |
Context eGSB / ISSS
Each agenda is defined by the relevant legislation. Within the agenda, the data necessary and specific for its execution are kept on subjects and objects. These data can also only be recorded on the basis of the relevant legal provisions. Subjects and objects are dealt with within an agenda in a certain context (given by legislation), i.e. subjects and objects are understood in a certain 'context' within the performance of that agenda. These contexts differ in the execution of different agendas, which is reflected, inter alia, by the fact that different objects are dealt with in relation to subjects in different agendas and different data are recorded and, where appropriate, exchanged on subjects and objects. We can therefore say that the context:
- determines the legal status of the entity (subject or object) within the agendas and
- the specific data (attributes) of the entity defined in the agenda are associated with it.
Methodologies for creating contexts address the detailed process
The context creation methodology introduces two levels of context - technical and conceptual. The technical level of context consists of an XSD schema that defines the syntax of the XML messages in which the shared data is expressed. In particular, to use eGSB/ISSS services for a linked data pool, it is necessary to know:
- The agency from which the reader wants to use the data,
- The agenda that the reader is executing and in which the data is read,
- The context for querying the data from the publishing AIS.
Before using eGSB/ISSS, the reader must first determine the context and its XSD schema according to which it will receive query responses in the eGSB/ISSS services. Therefore, he must first call a special eGSB/ISSS service to read the Context Catalog, in which he then finds out which context he must call to get the data from the providing agenda.
Conceptual Context Models
The conceptual level of a context consists of a conceptual model that defines the semantics (meaning) of a context by describing its semantic (meaning) links to other contexts maintained within the same agenda, as well as in other agendas, and by describing its semantic links to the public administration ontology. The ontology of public administration defines the basic concepts of public administration that exist across the legal order of the Czech Republic and the semantic links between them. Examples of such concepts are subject of law, object of law, natural person, legal person, etc.
The ambition of the conceptual model of the context is not to model the real world, but its abstraction describing the subjects and objects of data, data about them and the relationships between them as they are defined in the legislation and as they are understood in the given agenda. The conceptual model is derived from the general meanings defined in the ontology of public administration, it takes over, specialises and extends these and redefines them if necessary. The elements of the conceptual model are linked to the corresponding legislative provisions from which they derive. As the conceptual model of context is linked to the conceptual models of related contexts and to the ontology of public administration, it is itself an ontology. The set of conceptual models of all contexts then forms an ontology describing
- the subjects and objects of law,
- the contexts in which they exist,
- the data held about them in the contexts
- the semantic relationships between them
This forms a conceptual semantic map of the data held by the public administration.
List of contexts
A detailed list of contexts is available at https://egsbkatalog.cms2.cz/. This list is only available from the CMS/KIVS network, not from the public internet.
| Order | Code | Name |
|---|---|---|
| 1 | A1029.1 | Insured |
| 2 | A1029.2 | Self-employed |
| 3 | A1029.3 | Employer |
| 4 | A1029.4 | Territorial organizational unit |
| 5 | A1046.1 | Driver's licence holder - documents for applying for a driving licence |
| 6 | A1046.2 | Driver - application for driving licence |
| 7 | A1046.RidicRozsirene | Driver - extended data |
| 8 | A1046.RidicBasic | Driver - basic data |
| 9 | A1046.RidicBasic | Driver - basic data |
| 10 | A1061.1 | NBU Avizace |
| 11 | A121.1 | Authenticated Person Data Overview |
| 12 | A121.2 | List of business entity data |
| 13 | A124.1 | ISKN - Record of rights for a person |
| 14 | A124.2 | ISKN - Certificate of Ownership |
| 15 | A1341.1 | Insurer's Certificate of Insurance |
| 16 | A1341.2 | OSVC PP notice |
| 17 | A1341.3 | OsVC PP ZP notification |
| 18 | A1341.4 | List of OSVC PP |
| 19 | A344.1 | Notification via Citizen Portal |
| 20 | A3726.1 | Patient |
| 21 | A385.1 | Notification of OSVC PP |
| 22 | A385.2 | List of OSVC PP |
| 23 | A392.1 | Debtor |
| 24 | A392.2 | ODU |
| 25 | A4003.1 | Health Service Providers |
| 26 | A4003.2 | Patient medical records |
| 27 | A418.1 | Person under investigation |
| 28 | A418.2 | Vehicle under investigation |
| 29 | A418.3 | NBU Lustration |
| 30 | A483.1 | Criminal Records Bureau |
A view of the integration platform interconnections
