Difference between revisions of "MA Use case Definition"

From DE4A
Jump to navigation Jump to search
m (→‎Planned Pilot Scenarios: removed Sweden)
m
 
(14 intermediate revisions by one other user not shown)
Line 23: Line 23:
  
 
The Ministerio de Política Territorial y Función Pública (former Ministerio de Hacienda y Función Pública - MINHAP) is the Spanish public body in charge and full responsible for the eGovernment strategy. It promotes the complete incorporation of information technologies and communications for the provision of public services through simplified procedures and processes aiming at the modernization of the entire sector.
 
The Ministerio de Política Territorial y Función Pública (former Ministerio de Hacienda y Función Pública - MINHAP) is the Spanish public body in charge and full responsible for the eGovernment strategy. It promotes the complete incorporation of information technologies and communications for the provision of public services through simplified procedures and processes aiming at the modernization of the entire sector.
 +
 +
== Planned Pilot ScenariosUse Cases ==
 +
{| class="wikitable"
 +
|
 +
|
 +
|
 +
| colspan="5" |Data Evaluator
 +
|-
 +
| colspan="3" |
 +
|RO
 +
|PT-AMA
 +
|ES
 +
|LU
 +
|SI
 +
|-
 +
|
 +
|
 +
|
 +
|UC1
 +
 +
UC2
 +
|UC1.deregist
 +
|
  
  
−
'''Sweden'''
+
UC2
 +
|UC1
  
−
'''Skatteverket (SKV):''' The main functions of the Swedish tax agency (Skatteverket) are: Taxes, Population registration and Estate inventories. Skatteverket is accountable to the government but operates as an autonomous public authority. This means that the government has no influence over the tax affairs of individuals or businesses. SKV decided to leave the project based on reconsideration of internal resources. They have learned a lot from the project and will be implementing similar services to be in production by end 2022.  
+
UC2
−
{| class="wikitable"
+
|UC1
−
|'''Component'''
+
 
−
|'''National application(s)'''
+
UC2
−
|'''Implementation'''
+
|-
−
|'''Description (MS-specific details/constraints)'''
+
| rowspan="13" |Data Owner
 +
| rowspan="2" |RO
 +
|UC1
 +
|
 +
|
 +
|
 +
|UC1
 +
|UC1
 +
|-
 +
|UC2
 +
|
 +
|
 +
|UC2
 +
|UC2
 +
|UC2
 +
|-
 +
| rowspan="3" |PT-AMA
 +
|UC1
 +
|UC1
 +
|
 +
|
 +
|UC1
 +
|UC1
 +
|-
 +
|UC1.deregist
 +
|
 +
|
 +
|
 +
|UC1.deregist
 +
|
 +
|-
 +
|{UC2} IRN
 +
|{UC2}
 +
|
 +
|{UC2}
 +
|{UC2}
 +
|{UC2}
 +
|-
 +
| rowspan="3" |ES
 +
|UC1
 +
|UC1
 +
|
 +
|
 +
|UC1
 +
|UC1
 +
|-
 +
|UC2
 +
|UC2
 +
|
 +
|
 +
|UC2
 +
|UC2
 +
|-
 +
|UC3
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| rowspan="3" |LU
 +
|UC1
 +
|UC1
 +
|
 +
|
 +
|
 +
|UC1
 +
|-
 +
|UC1.deregist
 +
|
 +
|UC1.deregist
 +
|
 +
|
 +
|
 
|-
 
|-
−
|eProcedure Portal frontend
+
|UC2
−
|Skatteverket.se/folkbokforing
+
|UC2
−
|In development
+
|
−
|Estimated in production 2022-01-04
+
|UC2
 +
|
 +
|UC2
 
|-
 
|-
−
|eProcedure Portal backend
+
| rowspan="2" |SI
−
|Folkbokforing
+
|UCI
 +
|UC1
 +
|
 
|
 
|
 +
|UC1
 
|
 
|
 
|-
 
|-
−
|Portal to OOP TS interface
+
|UC2
−
|Folkbokforing/Skatteverket/SSBTGU
+
|UC2
−
|To be developed
+
|
−
|Parts of the infrastructure is in place.
+
|UC2
 +
|UC2
 +
|
 
|}
 
|}
−
 
+
The description of the MA Use cases in the pilot includes:
−
== Planned Pilot Scenarios ==
 
−
[[File:Planned Pilot Scenarios.png|alt=As after sweden left|none|frame|Planned Pilot Scenarios]]
 
−
 
 
−
== Use Cases ==
 
−
The description of the MA Use cases in the first pilot iteration includes:
 
  
 
* User Support Intermediation pattern (USI)
 
* User Support Intermediation pattern (USI)
Line 62: Line 161:
 
* Use Evidence in Procedure
 
* Use Evidence in Procedure
 
* Three evidence types:  Change of Address and Civil State Certificate and Birth Certificate
 
* Three evidence types:  Change of Address and Civil State Certificate and Birth Certificate
−
* Interrupted Procedure with support for Save and Resume (optional but recommended)
 
 
* Static Look-up of Evidence Type, Data Service, Authorized Authorities
 
* Static Look-up of Evidence Type, Data Service, Authorized Authorities
  
−
== Second Iteration Description and Requirements ==
 
−
In the Second iteration, the following list is a proposal of functional scope of the Moving Abroad pilots. The actual list of items to be included in the second iteration is yet to be decided by the participating Member State.
 
−
* '''Request multiple Evidences'''; Multiple evidences in the same procedure instance.
 
−
* '''Intermediation pattern;''' for UC#3 Means of living eg. Pension information and other means of support.
 
−
* '''De-registration Notification'''; Portugal needs to de-register the old domicile address when there is a change of domicile address also when some one is moving abroad. All other piloting countries also see this new process as a needed function. It is thought to be a new process and it will need a new EvidenceType. Member States are not in agreement if it should be invoked automatically (Agency to Agency) or if there needs to be a new procedure started or at least a consent given by the domicile registrant to acknowledge that this has taken place. WP7 supports the idea of involving the data subject directly. Some MS (eg. Sweden and possibly Luxembourg) think they may have to change laws to make it happen. The proposed solution is based upon making the eIDASPersonIdentifier attribute mandatory in the evidence response to the registration procedure. When the registration procedure is completed, the deregistration procedure can be started using the same eIDASPersonIdentifier. The eIDASPersonIdentifier could be a reliable identifier for this purpose, since it is used in the preview of the evidence and is already mapped to the requested evidence. It is not sure this will be piloted but software will be developed and demoed in test environments (LU/PT). The intention was to use the USI pattern as a problem with the Subscribe & Notification pattern for the case of deregistration is that you first need to subscribe to a DO catalogue of events. It was then decided the "My-Space/MY-Guichet" could be used. Including the new "deregistration-evidence" (no preview needed as it is the same content just in a technically different format). In this context, every deregistration DE does not need to, but could be be subscribed to every Domicile Registry (DO) for every citizen that can be registered in that DO. Therefore, the deregistration use case needs a “Push-lik pattern”, to unilaterally communicate an event, instead aof  “Subscribe & Notification Pattern”. This means we need to update the consent text of the UC1-procedure to include deregistration purpose. The UC-flow is:
 
−
** PT Citizen will move to LU. PT citizen selects new domicile registration in LU portal, and LU(DE) requests current domicile from PT (DO). In this registration process a new check will be included, asking the citizen for consent to send the evidence back to PT once LU (DE) process it. Once LU verifies the evidence and any additional checks, LU (DE) will send to PT(DO) the evidence of de-registration. The citizen is informed by the LU portal (any means) about this 2 different procedures that have been performed: successful registration in LU and evidence sent back to PT with new domicile.
 
  
−
*'''Delegation of Powers;''' A family member of legal age is allowed to act as a proxy and contact person on behalf of other family members, to request moving between countries within EU. If there is support for delegation of powers between family members, the family member acting as proxy, may give consent to retrieve the required evidences, and to preview the retrieved evidences, before completing the eProcedure. Otherwise, each family member must give consent and preview their own evidences before the eProcedure can be completed. There are many complex family situations and special cases that would require further analysis. Only the most simple and straight forward cases may be considered for the second iteration of the Moving Abroad pilot. This will not be piloted but software will be developed and demoed.
+
'''Second Iteration overview'''
−
*'''Improved usability''' in Procedure and data Service based upon knowledge gained from the first iteration regarding
+
{| class="wikitable"
 +
|
 +
|ES
 +
|LU
 +
|PT
 +
|RO-DO (later DE)
 +
|SL
 +
|-
 +
|Multiple Evidences
 +
|Yes-1-2
 +
|Yes-1-2
 +
|NO
 +
|Yes-1-2
 +
|Unknown
 +
|-
 +
|Interrupted Procedure
 +
|NO
 +
|Yes-1-2
 +
|NO
 +
|NO (using cookies or other)
 +
|Unknown
 +
|-
 +
|Deregistration 1
 +
|NO
 +
|YES
 +
|YES
 +
|Maybe
 +
|Unknown
 +
|}
 +
*'''Interrupted Procedure''' with support for Save and Resume (optional but recommended)
 +
*'''Request multiple Evidences'''; Multiple evidences in the same procedure instance.
 +
*'''Intermediation pattern;''' for UC#3 Means of living eg. Pension information and other means of support.
 +
*'''"Deregistration" sub-use-case-procedure'''; Portugal needs to deregister the old domicile address when there is a change of domicile address also when some one is moving abroad. All other piloting countries also see this process finalization as a needed function. It is not thought to be a new process, but a finalization of the process, but it will need a new EvidenceType. Member States are not in agreement if it should be invoked automatically (Agency to Agency) or if there needs to be a new procedure started or at least a consent given by the domicile registrant to acknowledge that this has taken place. WP7 supports the idea of involving the data subject directly up front when starting the process. Some MS (eg. Sweden and possibly Luxembourg) think they may have to change laws to make it happen. The proposed solution is based upon making the eIDASPersonIdentifier and email attribute mandatory in the evidence response to the registration procedure. When the registration procedure is completed, the "deregistration" sub-procedure can be started using the same eIDASPersonIdentifier and email. The eIDASPersonIdentifier could be a reliable identifier for this purpose, since it is used in the preview of the evidence and is already mapped to the requested evidence. It is not sure this will be piloted but software will be developed and demoed in test environments (LU/PT). The intention was to use the USI pattern as a problem with the Subscribe & Notification pattern for the case of de-registration is that you first need to subscribe to a DO catalogue of events.
 +
[[File:Image discarded option.png|alt=Discarded option|left|thumb|Discarded option due to being to centralized]]
 +
[[File:Image MS side option.png|alt=Chosen option|left|thumb|Chosen option based on MS configuration]]
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
It was then decided the "My-Space/MY-Guichet" backend could be used. Including the new "deregistration-evidencetype" (no preview needed as it is the same content as demicileregistration just in a technically different format). In this context, every deregistration DE does not need to, but could be be subscribed to every Domicile Registry (DO) for every citizen that can be registered in that DO. Therefore, the deregistration sub-use-case needs a “Push-like pattern”, to unilaterally communicate an event, instead of  a “Subscribe & Notification Pattern”. This means we need to use a specific consent text of the UC1-procedure to include deregistration purpose.
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
The UC-flow is: PT Citizen will move to LU. PT citizen selects new domicile registration in LU portal, and LU (DE) requests current domicile from PT (DO). In this registration process a new check will be included in PT, asking the citizen for consent to send the evidence back to PT once LU (DE) processed it. Once LU verifies the evidence and any additional checks, LU (DE) will send to PT(DO) the evidence of deregistration. The citizen is informed by the LU portal (any means) about this 2 different procedures that have been performed: successful registration in LU and evidence sent back to PT. PT then send a PDF/message printed on paper with a Unique code to the new domicile adress of the Portuguese citizen.
 +
 
 +
 
 +
*'''Improved usability''' in Procedure and data Service based upon knowledge gained during the pilot regarding
 
**Information about the OOP System in Procedure
 
**Information about the OOP System in Procedure
 
**Giving consent to use the OOP System in Procedure
 
**Giving consent to use the OOP System in Procedure
Line 81: Line 230:
 
**Using the exchanged Evidence in the Procedure
 
**Using the exchanged Evidence in the Procedure
 
**User support and guidance
 
**User support and guidance
−
**Improved fault tolerance and error handling in the OOP System, for example: OOP System not available, Evidence not available, data Service not available, Evidence Provider not availableDelayed response from Evidence Provider, Evidence not received, Incorrect Evidence received
+
**Improved fault tolerance and error handling in the OOP System, for example: OOP System not available, Evidence not available, data Service not available, Evidence Provider not available Delayed response from Evidence Provider, Evidence not received, Incorrect Evidence received
 
**GDPR Incident and Problem Management in the OOP System
 
**GDPR Incident and Problem Management in the OOP System
 
**(Re-)Alignment with SDG
 
**(Re-)Alignment with SDG
 
**Handle critical deviations from the SDG and progress made in other important EU-related projects
 
**Handle critical deviations from the SDG and progress made in other important EU-related projects
−
 
+
*'''Not Included in Pilot, Delegation of Powers;''' A family member of legal age is allowed to act as a proxy and contact person on behalf of other family members, to request moving between countries within EU. If there is support for delegation of powers between family members, the family member acting as proxy, may give consent to retrieve the required evidences, and to preview the retrieved evidences, before completing the eProcedure. Otherwise, each family member must give consent and preview their own evidences before the eProcedure can be completed. There are many complex family situations and special cases that would require further analysis. This will not be piloted but software will be developed and demoed.
 +
*'''MOR: (Multilingual Ontology Repository)''' for more efficient translations/transcodings. For a Demo view see https://de4a-wp3.github.io/MOR/ To be tested between Romania and Spain.
 
==Interaction Patterns==
 
==Interaction Patterns==
−
The development of the DE4A Reference Architecture started in the context of D2.4 Project Start Architecture (PSA) - First iteration and recognizes three distinct Reference Interaction Patterns; out of which MA will use mainly the USI-pattern.  
+
The development of the DE4A Reference Architecture started in the context of D2.4 Project Start Architecture (PSA) - MA recognizes three distinct Reference Interaction Patterns; out of which MA will use mainly the USI-pattern.  
  
−
*Intermediation Pattern (MA UC#3 Pensions)
+
*[https://wiki.de4a.eu/index.php/Intermediation_Pattern Intermediation Pattern (IM)]  (MA UC#3 Pensions)
−
*User-supported Intermediation Pattern (USI)
+
*[https://wiki.de4a.eu/index.php/User-supported_Intermediation_Pattern User-supported Intermediation Pattern (USI)]
 +
*Push for deregistration
  
−
The USI pattern is a new pattern (developed with in the project) and it will be further developed after learning from the first iteration piloting. The first iteration has architectural shortcomings and does not allow all member states to pilot.
+
The USI pattern is a new pattern (developed within the project) and it will be further developed after learning from the pilots.

Latest revision as of 12:02, 3 May 2023

Partners

Luxembourg

CTIE is the IT Centre of Luxembourg Central Government. Due to the highly centralized nature of management, development, maintenance and support in the field of eGovernment and ICT at central Government level, CTIE is responsible directly or indirectly for more than 90 % of all ICT infrastructures, solutions, projects, etc. at the level of central Government in Luxembourg.

Portugal

AMA is the public institute that exercises the powers of the Ministry of State Modernization and Public Administration in the areas of modernization and administrative simplification and digital government, under the supervision of the Secretary of State for Innovation and Administrative Modernization. Its action is divided in three axis: public service delivery, digital transformation and simplification.


Romania

CIO Office: The CIO Office is part of the General Secretariat of the Government (aka the Prime Minister’s Office). It coordinates the IT&C of the Romanian central public administration, establishes the architecture of the IT&C systems, oversees the investments in IT&C and cooperates in the field of cybersecurity with the other law enforcement, defense and intelligence agencies. The CIO Office will coordinate Romania’s participation in the pilot.

Slovenia

The Ministry of Public Administration is one of 14 ministries that constitute the Slovenian government and has around 550 employees. Its main task is to optimize and ensure resources needed by other ministries and the wider public sector in order to provide efficient and high quality public services to its citizens.


Spain

The Ministerio de Política Territorial y Función Pública (former Ministerio de Hacienda y Función Pública - MINHAP) is the Spanish public body in charge and full responsible for the eGovernment strategy. It promotes the complete incorporation of information technologies and communications for the provision of public services through simplified procedures and processes aiming at the modernization of the entire sector.

Planned Pilot ScenariosUse Cases

Data Evaluator
RO PT-AMA ES LU SI
UC1

UC2

UC1.deregist


UC2

UC1

UC2

UC1

UC2

Data Owner RO UC1 UC1 UC1
UC2 UC2 UC2 UC2
PT-AMA UC1 UC1 UC1 UC1
UC1.deregist UC1.deregist
{UC2} IRN {UC2} {UC2} {UC2} {UC2}
ES UC1 UC1 UC1 UC1
UC2 UC2 UC2 UC2
UC3
LU UC1 UC1 UC1
UC1.deregist UC1.deregist
UC2 UC2 UC2 UC2
SI UCI UC1 UC1
UC2 UC2 UC2 UC2

The description of the MA Use cases in the pilot includes:

  • User Support Intermediation pattern (USI)
  • One Evidence Request
  • Request Evidence in Procedure
  • Preview Evidence in data Service
  • Use Evidence in Procedure
  • Three evidence types:  Change of Address and Civil State Certificate and Birth Certificate
  • Static Look-up of Evidence Type, Data Service, Authorized Authorities


Second Iteration overview

ES LU PT RO-DO (later DE) SL
Multiple Evidences Yes-1-2 Yes-1-2 NO Yes-1-2 Unknown
Interrupted Procedure NO Yes-1-2 NO NO (using cookies or other) Unknown
Deregistration 1 NO YES YES Maybe Unknown
  • Interrupted Procedure with support for Save and Resume (optional but recommended)
  • Request multiple Evidences; Multiple evidences in the same procedure instance.
  • Intermediation pattern; for UC#3 Means of living eg. Pension information and other means of support.
  • "Deregistration" sub-use-case-procedure; Portugal needs to deregister the old domicile address when there is a change of domicile address also when some one is moving abroad. All other piloting countries also see this process finalization as a needed function. It is not thought to be a new process, but a finalization of the process, but it will need a new EvidenceType. Member States are not in agreement if it should be invoked automatically (Agency to Agency) or if there needs to be a new procedure started or at least a consent given by the domicile registrant to acknowledge that this has taken place. WP7 supports the idea of involving the data subject directly up front when starting the process. Some MS (eg. Sweden and possibly Luxembourg) think they may have to change laws to make it happen. The proposed solution is based upon making the eIDASPersonIdentifier and email attribute mandatory in the evidence response to the registration procedure. When the registration procedure is completed, the "deregistration" sub-procedure can be started using the same eIDASPersonIdentifier and email. The eIDASPersonIdentifier could be a reliable identifier for this purpose, since it is used in the preview of the evidence and is already mapped to the requested evidence. It is not sure this will be piloted but software will be developed and demoed in test environments (LU/PT). The intention was to use the USI pattern as a problem with the Subscribe & Notification pattern for the case of de-registration is that you first need to subscribe to a DO catalogue of events.
Discarded option
Discarded option due to being to centralized
Chosen option
Chosen option based on MS configuration





It was then decided the "My-Space/MY-Guichet" backend could be used. Including the new "deregistration-evidencetype" (no preview needed as it is the same content as demicileregistration just in a technically different format). In this context, every deregistration DE does not need to, but could be be subscribed to every Domicile Registry (DO) for every citizen that can be registered in that DO. Therefore, the deregistration sub-use-case needs a “Push-like pattern”, to unilaterally communicate an event, instead of a “Subscribe & Notification Pattern”. This means we need to use a specific consent text of the UC1-procedure to include deregistration purpose.





The UC-flow is: PT Citizen will move to LU. PT citizen selects new domicile registration in LU portal, and LU (DE) requests current domicile from PT (DO). In this registration process a new check will be included in PT, asking the citizen for consent to send the evidence back to PT once LU (DE) processed it. Once LU verifies the evidence and any additional checks, LU (DE) will send to PT(DO) the evidence of deregistration. The citizen is informed by the LU portal (any means) about this 2 different procedures that have been performed: successful registration in LU and evidence sent back to PT. PT then send a PDF/message printed on paper with a Unique code to the new domicile adress of the Portuguese citizen.


  • Improved usability in Procedure and data Service based upon knowledge gained during the pilot regarding
    • Information about the OOP System in Procedure
    • Giving consent to use the OOP System in Procedure
    • Using the OOP System for Evidence Exchange
    • Preview of Evidence in data Service
    • Redirection between Procedure and data Service
    • Using the exchanged Evidence in the Procedure
    • User support and guidance
    • Improved fault tolerance and error handling in the OOP System, for example: OOP System not available, Evidence not available, data Service not available, Evidence Provider not available Delayed response from Evidence Provider, Evidence not received, Incorrect Evidence received
    • GDPR Incident and Problem Management in the OOP System
    • (Re-)Alignment with SDG
    • Handle critical deviations from the SDG and progress made in other important EU-related projects
  • Not Included in Pilot, Delegation of Powers; A family member of legal age is allowed to act as a proxy and contact person on behalf of other family members, to request moving between countries within EU. If there is support for delegation of powers between family members, the family member acting as proxy, may give consent to retrieve the required evidences, and to preview the retrieved evidences, before completing the eProcedure. Otherwise, each family member must give consent and preview their own evidences before the eProcedure can be completed. There are many complex family situations and special cases that would require further analysis. This will not be piloted but software will be developed and demoed.
  • MOR: (Multilingual Ontology Repository) for more efficient translations/transcodings. For a Demo view see https://de4a-wp3.github.io/MOR/ To be tested between Romania and Spain.

Interaction Patterns

The development of the DE4A Reference Architecture started in the context of D2.4 Project Start Architecture (PSA) - MA recognizes three distinct Reference Interaction Patterns; out of which MA will use mainly the USI-pattern.

The USI pattern is a new pattern (developed within the project) and it will be further developed after learning from the pilots.

Retrieved from ‘https://wiki.de4a.eu/index.php?title=MA_Use_case_Definition&oldid=6011’