- Česky (cs)
- English (en)
Systems and services related to law and legislation
Description of Systems and services related to law and legislation
Public administration is primarily governed by legislation. Therefore, it is extremely important to both understand the legal order well and to include legislation as a motivating and contracting framework in the architectures.
Basic Components of State Legal Systems
Basic state information systems and services related to law and legislation
System | Legal | Description | Examples of Use |
---|---|---|---|
eCollection | Ministry of the Interior | An electronic collection of legislation with its consolidated temporal text | Using the ESEL interface services, it will be possible to automatically download decomposed legislation and thus have it as a linking resource for incentive, process and business architecture. eCollection will be the initial reference source for text and changes to legislation |
eLegislation | Ministry of the Interior | Information system to support the drafting and negotiation of legislative amendments and to computerize the process of legislation adoption | The ESEL services will provide tracking of the status of drafting and negotiation of amendments and proposals, as well as an environment and tools for the creation of proposals for legislative amendments (may come from the results of optimization proposals according to the architecture) |
ODOK | Government Office | IS for the circulation of documents for the government agenda and for meetings of the government and its bodies | This information system contains documents and information within the government agenda, documents for government meetings, but also tracks government and legislative tasks |
EKLEP | Government Office | The Electronic Library of the Legislative Process serves as an IS to support the entire process of discussing, commenting on and approving legislative proposals | |
EKLEP | Government Office | The public part of the EKLEP library | It is also published schematically according to XML schema metadata and as opendata, so it can be used in many cases as an information resource |
RPP | Ministry of the Interior | The Register of Rights and Obligations also contains reference and binding data on individual agendas, links to legislation, OVM competences and actions and activities in these agendas | It serves as an authoritative and reference source on the performance of public administration |
Each of these IS can and should be used both as a source of information for the authorities and as one of the components in optimising the activities of the authority. For example, if we want to optimize an agenda in an office, we should have its architecture. One of the inputs for this architecture is the legislation (source ESEL) and the agenda model of the given agenda (source RPP). After designing the process optimisation, it will probably be necessary to amend the legislation as well, which in turn will be supported by the above-mentioned information systems.
Rules of Systems and services related to law and legislation
The extent to which the above-mentioned information systems and their shared services can, and even must, be used depends on the position of the relevant authority in relation to the specific legislation.
In this case, we can therefore divide the authorities into the following three categories:
- Legislation Gestor: Responsible for the preparation, implementation of the commenting and discussion process and the subsequent implementation of the approved legislation. The Gestor should also periodically carry out an assessment of the legislation in force and propose amendments to it on that basis.
- Co-operating body: This is a body that is actively involved in the co-creation of legislation and is actively involved in the process of commenting on and evaluating the proposals
- Legislation user: This is an entity that is governed by the legislation in question, either as part of its public law activities as an exercise of competence in the agenda in question, or is otherwise bound by the legislation in question and is affected by it in some way
In each of these three basic roles, the information systems mentioned above can be actively used.
Not forgetting the duties of the file service, which of course also apply to the processes of drafting and debating legislation. Therefore, if I am the responsible person for legislation, I will first of all ensure the integration of my authoring systems into the ESSL and subsequently the integration into the obligatory information systems (eLegislation, ODOK, EKLEP, etc.).
In the evaluation and subsequent preparation of proposals for change, the two key sources are the legislation in force (the actual wording of the legislation and its links) and the impact on actual performance (the source is the RPP and the agenda model and list of tasks in the agenda). Using the links with other legislation, the Authority will also map the context to other capabilities. For example, with the agenda law, the file service obligations, the obligation not to request data that I already have, etc. should also be taken into account. Even with this in mind, it is always useful to have the current or expected versions of legislation as a source.
When designing the architecture, it is then highly advisable to have elements of the architecture linked to the relevant legislation. For example, if I am managing an information system, this is used to support the process in the law. Thus, I know that I am operating the system based on the ISVS Act and the relevant agency Acts and function requirements must ensure that the relevant processes in each Act are implemented.
Sources of information on laws and their projection into public administration agendas are also useful for creating and updating internal directives and regulations in the organization. For example, if the legislation on the basic registers or the filing service changes, I know that this will have an impact on my processes and therefore on the regulations and directives that define the processes. So there will certainly be changes to the agenda process methodologies, changes to the Filing Regulations, etc. This is also why I have to use the above mentioned resources and ensure their integration to the components I use to maintain documentation.
If the office in question is not the authority responsible for the relevant legislation, but is nevertheless bound by the legislation, then it should also comply with some of the above basic principles. Up-to-date data on the status of legislation, including the link between each provision and each piece of legislation, must serve as the basis for the business architecture. The second source is the data in the register of rights and obligations.
It is therefore advisable to:
- Build and maintain a mechanism to process decomposed legislation in an automated way where possible.
- Can be implemented using eCollection services or similar system
- Ensure notification of updates to legislation of interest and updates of links from other legislation to it
- Establish processes and support for tracking draft amendments and the status of their consideration
- Be able to relate key elements of the architecture to specific provisions or at least to specific legislation
- Maintain an awareness of all legislation that governs
In terms of architecture, the following changes are expected at central and local level
- Following the launch of the eCollection system into live operation (assumed to be 1 January 2022), authorities will reassess their policy on the acquisition of commercial legal information systems, in particular the volume and scope of licences required to carry out their activities, taking into account the individual nature of the work activities of specific staff who use these systems to carry out their work. It will then restrict the scope of commercial legal information system licences, if any, to meeting only those needs underlying the performance of its activities that cannot be met by the use of the eCollection system, taking into account the contractual terms of the supplies contracted in this area and the needs of the specific staff.
- The eCollection and the eLegislation and ODoK information system must be functionally linked in such a way as to fulfil the prerequisites for the functioning of the electronic legislative process pursuant to Act No 222/2016 Coll., on the Collection of Acts and International Treaties and on the production of legislation published in the Collection of Acts and International Treaties (Act on the Collection of Acts and International Treaties), as amended.
- From the moment of launching the eCollection and e-Legislation information system, all authorities will be obliged to enrich legal citations of legal acts contained in the eCollection with the type "§1 of Act No. 100/2000 Coll." in their systems and newly created materials. technically, by including references to the eCollection system, which they will create using the citation creation functionality contained in the eCollection.
Discussion