Difference between revisions of "Subscription and Notification Pattern"

From DE4A
Jump to navigation Jump to search
 
(103 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
Is used by [[Doing Business Abroad Pilot]] in [[Use Case "Doing Business in Another Member State" (DBA UC2)]]
+
The pattern is used by the [[Doing Business Abroad Pilot]] in [[Use Case "Doing Business in Another Member State" (DBA UC2)|Use Case "Doing Business in Another Member State" (DBA UC2).]]
  
−
After receiving evidence from a Data Owner (DO), it can be essential for a Data Evaluator (DE) to be informed on changes regarding the subject of this evidence to be able to take appropriate action. The goal of this interaction pattern is to allow the DE to subscribe to a service of the DO that provides autmatic and regual notifications. The cross-border message exchange for the subscriptions and notifications are put in the responsibility of the Data Requester (DR) and the Data Transferor (DT) respectively to allow an easier distribution of responsibility on national level, i.e. to intermediary platforms an national gateway providers.
+
After receiving evidence from a Data Owner (DO), it can be essential for a Data Evaluator (DE) to be informed on changes regarding the subject of this evidence to be able to take appropriate action. The goal of this interaction pattern is to allow the DE to subscribe to a service of the DO that provides automatic and regular notifications. The cross-border message exchange for the subscriptions and notifications are put in the responsibility of the Data Requester (DR) and the Data Transferor (DT) respectively to allow an easier distribution of responsibility on national level, i.e. to intermediary platforms and national gateway providers.
  
 
=== Functional Variants of the Subscription and Notification Pattern ===
 
=== Functional Variants of the Subscription and Notification Pattern ===
−
There are two distinct purposes, or business requirements for Subscription and Notification, which both are relevant for the DE4A [[Doing Business Abroad Pilot]]: Evidence update notification and Event notification.
+
There are two distinct purposes, or business requirements for Subscription and Notification, both of which are relevant for the DE4A [[Doing Business Abroad Pilot]]: Evidence update notification and Event notification.
  
 
==== Evidence Update Notification ====
 
==== Evidence Update Notification ====
 
The goal is to keep previously shared evidence data that is stored at the DE up to date.  
 
The goal is to keep previously shared evidence data that is stored at the DE up to date.  
  
−
Description: Data may change in the base register. In case the DE needs an exact copy of the evidence data on record, they need to be notified in case the data has changed in teh base registry.
+
Description: Data may change in the base register. In case the DE wants an exact copy of the evidence data on record, they need to be notified in case the data has changed in the base registry.
  
 
==== Business or Life Event Notification ====
 
==== Business or Life Event Notification ====
−
The goal is to assess the impact of company changes on the eServices provided by the data evaluator.  
+
The goal is to assess the impact of changes to the subject (e.g. company) on the public services provided by the data evaluator.  
  
−
Description: Some eServices oblige the subject (i.e. company or citizen) to continue in a specifc situation or state to remain entitled to the benefits of an eService provided to the subjcet. E.g., an agricultural company may receive a subsidy for its permanent pasture. As a prerequisite, the company must preserve the pasture for five consecutive years. The data evaluator needs to be notified of the company ending its operations and hence not meeting the five-year requirement. “ending its operation” is an example of a business event. Others examples are: going bankrupt, merge, etc.  
+
Description: Some public services oblige the subject (i.e. company or citizen) to continue in a specific situation or state to remain entitled to the benefits of the public service provided. An agricultural company may, for example, receive a subsidy for its permanent pasture. As a prerequisite, the company must preserve the pasture for five consecutive years. The data evaluator needs to be notified of the company ending its operations and hence not meeting the five-year requirement. “Ending its operation” is an example of a business event. Other examples are: going bankrupt, a merger, etc.  
  
 
==== Alternative Solution Approaches ====
 
==== Alternative Solution Approaches ====
 
Essentially there are two ways to approach the dual requirements for Subscription and Notification, either specific solutions for each requirement or hybrid approaches that can serve both.
 
Essentially there are two ways to approach the dual requirements for Subscription and Notification, either specific solutions for each requirement or hybrid approaches that can serve both.
  
−
Looking at specific solutions would mean that two specialized systems would need to be developed and implemented:
+
Looking at specific solutions means that two specialized systems would need to be developed and implemented:
  
−
# Specific Evidence Update Solution: The subscription would be linked directly to the previously exchanged evidence, hence the subscription would need to register the evidence type the subject ID and the subscriber ID. For any data change in the evidence type data set at the DO, the DP would need to push a complete new evidence to the DC, irrespective of that specific change being relevant for the public service provided to the user by the DC. Apart from this being not optimal from a data minimization principle perspective, it can not cover changes of the subject that are not represented in the evidence type data set, giving rise to a second subscription system for event. In addition, the subscription system would be impacted by changes in the canonical evidence type definitions over time. This approach might, however, be easier to integrate in the legal framework of the SDGR (see Legal Considerations below).
+
# Specific Evidence Update Solution: The subscription would be linked directly to the previously exchanged evidence, hence the subscription would need to register the evidence type, the subject ID and the subscriber ID. For any data change in the evidence type data set at the DO, the DP would need to push a complete new evidence to the DC, irrespective of that specific change being relevant for the public service provided to the user by the DC. Apart from this being not optimal from a data minimization principle perspective, it can not cover changes of the subject that are not represented in the evidence type data set, giving rise to the need of a second subscription system for events. In addition, the subscription system would be impacted by changes in the canonical evidence type definitions over time. This approach might, however, be easier to integrate in the legal framework of the SDGR (see Legal Considerations below).
−
# Pure Event Notification: The subscription would not need to be directly related to a previously shared exchanges evidence, but the subscription would be registered for an agreed set of events relating to a given subject. The subscription system would consequently be based on a list of events, rather than a list of evidence types. Quite obviously, this requires an agreement on a set of DE4A events, or canonical cross-border events. We expect that resolving existing legal barriers especially in the citizen domain would be easier for pure event notifications, becaus the notification would only contain identifiers rather than the underlying (personal) data.
+
# Pure Event Notification: The subscription is not directly related to a previously exchanged evidence, but the subscription could be registered for an agreed set of events relating to a given subject. The subscription system would consequently be based on a list of events, rather than a list of evidence types. Quite obviously, this requires an agreement on a set of DE4A events, or canonical cross-border events.
  
−
Technical approach and business requirement do not relate one two one, giving rise to several hybrid approaches, where one solution is used to cater for both requirements:  
+
Technical approach and business requirements do not relate one to one, giving rise to several hybrid approaches, where one solution is used to cater for both requirements:  
  
−
# Extended Evidence Type: The Specific Evidence Update can be used to derive relevant Events at the DC, if the evidence type definition is scoped, or extended, so that all relevant events are represented by data changes in the evidence type data set. This would require the DC to run a event identification routine on each received update to react accordingly. This hybrid solution would also meet its limitations for events that are dealt with by procedural means at the DP-side, rather than by data mutations. The extension of evidence type definitions beyond what is actually required by the eProcedure is, again, not optimal from a data minimization principle perspective.
+
# Extended Evidence Type: The Specific Evidence Update can be used to derive relevant Events at the DC, if the evidence type definition is scoped, or extended, so that all relevant events are represented by data changes in the evidence type data set. This would require the DC to run an event identification routine (either immediately or periodically) after receiving updates in order to react accordingly. The extension of evidence type definitions beyond what is actually required by the eProcedure is, again, not optimal from a data minimization principle perspective. This hybrid solution can not resolve events that are dealt with by procedural means at the DP-side, rather than by data mutations.
−
# Extended Notification Message: The pure Event Notification could be extended to carry an updated evidence as part of the Notification message, essentially piggy-bagging the evidence on an event notification. This approach would need to extend the event-centric subscription system to maintain with underlying evidence type, or potentially multiple evidence types, are potentially relevant for each event type, so that evidence can be retrieved and packed as extension of the Notification Message. This solution would consequently end up to be rather complext and again not optimal from a from a data minimization principle perspective. [A BPMN Process Analysis of this approach is available on request]
+
# Extended Notification Message: The pure Event Notification could be extended to carry an updated evidence as part of the Notification message, essentially piggybacking the evidence onto an event notification. This approach would need to extend the event-centric subscription system to maintain with underlying evidence type, or potentially multiple evidence types, are relevant for each event type, so that evidence can be retrieved and packed as extension of the Notification Message. Which evidence is required for which event can additionally differ by public service provided and hence per subscriber. This solution would consequently end up to be rather complex and again not optimal from a data minimization principle perspective. [A BPMN Process Analysis of this approach is available on request]
−
# Event Notification + Lookup: The pure Event Notification is used as described above, while it is made sure that the agreed event set of canonical DE4A events is complete in the sense that in covers also relevant update needs, for example a company that moved HQ means that the adres (part of the Company Registration evidence) changed as an effect. It is then left at the discretion of the DC, whether a particular event requires an update of the evidence on record. It could be that, i.e. the postal adres of a company is nor relevant for the continuation of the public service provisioning, in which case a flag that the adres on record is not up to date, or a change to "unknown" would be sufficient as event response. This is fully in line with the data minimization principle perspective. If the DC considers that an an update of one evidence or potentially several evidences is required as part of the event response, then the DC would use the [[Lookup Pattern]] to request new copies of evidences.
+
# Event Notification + Lookup: The pure Event Notification is used as described above, while it is made sure that the agreed event set of canonical DE4A events is complete in the sense that in covers also relevant update needs, for example a company that moved HQ means that the address (part of the Company Registration evidence) changed as an effect. It is then left at the discretion of the DC, whether a particular event requires an update of the evidence on record. It could be that, i.e. the postal address of a company is not relevant for the continuation of the public service provisioning, in which case a flag that the address on record is not up to date, or a change to "unknown" would be sufficient as event response. This is fully in line with the data minimization principle perspective. If the DC considers that an update of one evidence or potentially several evidences is required as part of the event response, then the DC would use the [[Lookup Pattern]] to request new copies of evidences if and when required.  The effort needed to make this approach work for evidence updates mostly concerns the Notification process: The DP might need to add "weak" events to their platform to cover changes that are not considered relevant enough to be in their event list yet, e.g. change of e-mail address. The DC will need to define or extend a decision table that relate event type to public service and returned the correct action to be taken, i.e. request a new evidence via the [[Lookup Pattern]].
−
 
+
The reference Architecture for the DE4A projects focusses on the third option, the combination of Event Notification and [[Lookup Pattern]] to cover both business requirements with one hybrid solution, rather then setting up two specific solutions next to each other. The combination of Event Notification and [[Lookup Pattern]] appears to be the most flexible approach and is expected to have the following advantages:
−
The reference Architecture for the DE4A projects focusses on the third option, on Event Notification combined with the [[Lookup Pattern]] to cover both business requirements with one hybrid solution, rather then setting up two specific solutions next to each other. The combination of Event Notification and [[Lookup Pattern]] appears to be the most flexible approach is expected to have the following advantages:  
 
  
 
* Data minimization: Evidences are only requested if they are actually needed for the public service provided by the DC
 
* Data minimization: Evidences are only requested if they are actually needed for the public service provided by the DC
−
* Low complexity of message definitions: The required message definitions for the notifications and updates between DP and DC remains low in complexity: A simple event notification (consisting of event type, identifiers and timestamp) and and evidence response analogous to the event response message of the [[Intermediation Pattern]] and [[User-supported Intermediation Pattern]].
+
* Low complexity of message definitions: The required message definitions for the notifications and updates between DP and DC remains low in complexity: A simple event notification (consisting of event type, identifiers and timestamp) and evidence response analogous to the event response message of the [[Intermediation Pattern]] and [[User-supported Intermediation Pattern]].
−
* Multiplicity: Case that single events require multiple evidences to be updated, or several events require the update of the same evidence can be covered quiet easily without requiring overly complex message definitions.  
+
* Multiplicity: Case that single events require multiple evidences to be updated, or several events require the update of the same evidence can be covered quiet easily without requiring complex message definitions.
−
* Flexibility in legal basis and authorizations: As the Event Notification does only contain identifiers and not the underlying (personal) data, the legal basis and corresponding authorizations might differ between Notification and Lookup, adding flexibility to the overall solution.
+
* Flexibility in legal basis and authorizations: As the Event Notification does only contain identifiers and not the underlying (personal) data (which requires the eIDAS revision to create a European Unique Identifier for natural persons), the legal basis and corresponding authorizations might differ between Notification and Lookup, adding flexibility to the overall solution.
 
* Independence from a previously shared evidence: The solution approach is not directly linked to a previously shared evidence, which means that a subscription and subsequent lookup can also be applied in cases where the original procedure (leading to the public service being provided) was completed without any automated evidence exchange, i.e. evidence was provided by the user electronically or in person, provided that there is a legal basis (see below).
 
* Independence from a previously shared evidence: The solution approach is not directly linked to a previously shared evidence, which means that a subscription and subsequent lookup can also be applied in cases where the original procedure (leading to the public service being provided) was completed without any automated evidence exchange, i.e. evidence was provided by the user electronically or in person, provided that there is a legal basis (see below).
 +
* Extension of scope: New events can be added flexibly without immediate impact on existing subscriptions and without maintaining different versions of an (canonical) evidence definition.
 +
 +
== Working hypotheses and implementation principles ==
  
−
=== Legal Considerations ===
+
{| class="wikitable"
 +
|+Subscription and Notification Pattern working hypotheses and implementation principles
 +
|'''Interdisciplinary Topic'''
 +
|'''Hypothesis / Principle'''
 +
|'''Implications and Limitations'''
 +
|-
 +
|Orchestration / Choreography
 +
|Subscription: The DC controls the overall flow for the subscription. This means that the process on DP side is a child process of  the process on the DC side.
 +
 
 +
 
 +
Notification: The Notification is conceived as a "fire and forget" coinversation, meaning that the processes are not really orchestrated. The DP process triggers (if successful) the DC process.
 +
|If issues on the DC-side (subscriber) prevented receiving notifications, a resubmission would need to be requested explicitly. The DP required functionality for such (manual) resubmission of notifications.
 +
|-
 +
|Interrupted vs. Uninterrupted exchange
 +
|Both the Subscription and the Notification are considered to be uninterrupted, not sending any deferred responses.
 +
|For the subscription, this means that the DC must assume that the subscription was not successful if not receiving a confirmation delay. For the DP, this means that their subscription system must be robust against receiving the same subscription twice.
 +
|-
 +
|Encryption Gap
 +
|OOP in the public sector does not require true E2E encryption. The exchange between DR and DP must be encrypted  and signed, as well as the transfers (if applicable on national level)  between DR and DE on DC side and DT and DO on DP side (i.e. using the  national OOP layer), but the encryption gap within the systems of the DR and DT is acceptable.
 +
|This might not hold for cases where the gateway  would be outsourced to a private sector subcontractor, which is not foreseen  for the DE4A pilots.
 +
|-
 +
|Automated re-use of data
 +
|Subscription and Notification are structured and adhere to known semantics and format that allow fully automated processing after receipt.
 +
|To facilitate automated re-us of data requires establishing canonical event definitions.
 +
|-
 +
|Production system and real-life cases
 +
|If the events relate to a legal person, not a natural person, subscription and notification can be run in production environments (see: Legal Considerations below)
 +
|The DC still needs a legitimate reason to subscribe to events of a subject (i.e. company)
 +
|-
 +
|Payment for evidence
 +
|In the context of the pilots we assume that no payments are required.
 +
|This can restrict transition of pilot solutions to production in cases that competent authorities require payment for issuing evidence.
 +
|-
 +
|BRIS integration
 +
|A technical re-use or bridge to BRIS is not possible because of differences in scope and accessibility by competent authorities other then business registers.
 +
|The pilot system for the [[Doing Business Abroad Pilot]] need to be set-up separate from BRIS.
 +
|-
 +
|Matching evidences between Member States
 +
|The Event Subscription and Notification is based on a set of harmonized events definitions.
 +
|The participants need a semantic agreement in a set of standardized life/business events.
 +
|}
 +
 
 +
== Legal Considerations ==
 
From a legal perspective, the central challenge is the need for a legal basis that allows impacted authorities to exchange Evidence Updates and/or Event Notifications. This is certainly critical for personal data (since the GDPR requires a legal basis), but even in the case of pure business data that contains no personal data, authorities will need to be able to demonstrate that they have a legal basis allowing them to send Evidence Updates and/or Event Notifications abroad.  
 
From a legal perspective, the central challenge is the need for a legal basis that allows impacted authorities to exchange Evidence Updates and/or Event Notifications. This is certainly critical for personal data (since the GDPR requires a legal basis), but even in the case of pure business data that contains no personal data, authorities will need to be able to demonstrate that they have a legal basis allowing them to send Evidence Updates and/or Event Notifications abroad.  
  
 
The SDGR is in principle not an answer to this issue, since it focuses on user-driven exchanges (based on a user request, and with a preview option). While a user request could have been scoped in a way that allows a user to define a time period for exchanges ('I request authority A to send evidence X to authority B, including any updates, for a period of Y years'), this is not the implementation path that has been chosen in the Implementing Act. Moreover, such a request wouldn't enable a preview as the SDGR requires. Thus, referring to the SDGR is not a sufficiently encompassing option.  
 
The SDGR is in principle not an answer to this issue, since it focuses on user-driven exchanges (based on a user request, and with a preview option). While a user request could have been scoped in a way that allows a user to define a time period for exchanges ('I request authority A to send evidence X to authority B, including any updates, for a period of Y years'), this is not the implementation path that has been chosen in the Implementing Act. Moreover, such a request wouldn't enable a preview as the SDGR requires. Thus, referring to the SDGR is not a sufficiently encompassing option.  
  
−
This does not imply that subscriptions or event notifications are impossible, but rather than an alternative legal basis must be chosen. A few options are available, which will be discussed briefly below. For the avoidance of doubt: these options should only be applied in relation to business data; subscriptions/event notifications relating to individual persons (citizens) do not have a clear legal basis under data protection law, and due to the public sector context, reliance on consent or legitimate interest of the public administrations is not legally feasible.  
+
This does not imply that subscriptions or event notifications are impossible, but rather than an alternative legal basis must be found. A few options are available, which will be discussed briefly below. For the avoidance of doubt: these options should only be applied in relation to business data; subscriptions/event notifications relating to individual persons (citizens) do not have a clear legal basis under data protection law, and due to the public sector context, reliance on consent or legitimate interest of the public administrations is not legally feasible.  
  
 
For business data subscriptions and event notifications, the following options would be available:  
 
For business data subscriptions and event notifications, the following options would be available:  
Line 49: Line 93:
 
- there should be no legal challenge in principle if the relevant information is already made publicly accessible by the relevant authority. If the information can be freely accessed and lawfully used by the public, proactively communicating it to specific authorities (in the form of evidence or a notification) should not be problematic either. While typically some terms and conditions would apply even to publicly accessible databases (e.g. to forbid commercial exploitation), it would be possible to conclude comparable agreements in the context of DE4A as well.  
 
- there should be no legal challenge in principle if the relevant information is already made publicly accessible by the relevant authority. If the information can be freely accessed and lawfully used by the public, proactively communicating it to specific authorities (in the form of evidence or a notification) should not be problematic either. While typically some terms and conditions would apply even to publicly accessible databases (e.g. to forbid commercial exploitation), it would be possible to conclude comparable agreements in the context of DE4A as well.  
  
−
- exchanges should similarly be possible for information that's not publicly available, but that can only be accessed and used by parties if they conclude a suitable agreement with the relevant business register. In some Member States, business register data is made available to commercial entities on the basis of (usually) paid contracts, e.g. allowing them to integrate that data into business intelligence services. Companies can subscribe to such services to check e.g. credit rating or bankruptcy status of their customers. In countries that support this model, it should be legally feasible to conclude similar agreements to support DE4A pilot exchanges, hopefully on a free of charge basis, if this is acceptable to the data source.  
+
- exchanges should similarly be possible for information that is not publicly available, but that can only be accessed and used by parties if they conclude a suitable agreement with the relevant business register. In some Member States, business register data is made available to commercial entities on the basis of (usually) paid contracts, e.g. allowing them to integrate that data into business intelligence services. Companies can subscribe to such services to check e.g. credit rating or bankruptcy status of their customers. In countries that support this model, it should be legally feasible to conclude similar agreements to support DE4A pilot exchanges, hopefully on a free of charge basis, if this is acceptable to the data source.  
  
 
These scenarios are likely more relevant for Updates of evidences than for pure Event Notifications, since formal evidences (extracts, certificates, attestations etc) are normally not included in these models.  
 
These scenarios are likely more relevant for Updates of evidences than for pure Event Notifications, since formal evidences (extracts, certificates, attestations etc) are normally not included in these models.  
  
−
Specifically for Evidence Subscriptions, the principal legal solution would be to establish a legal basis for the subscription outside of the SDGR. This could be viable under national laws, in combination with the request of a representative of the affected legal entity. A pure appeal to national law (without any request for a subscription service from the user) likely will not work; this is only possible if there's already a specific legal basis for direct evidence exchanges between the authorities, and that does not seem to be the case. The BRIS Directive is the closest approximation, but doesn't provide a basis for evidence subscriptions. This is why the request is important, as a way to strengthen the legal mandate of the evidence provider, allowing them to build on any existing right of the company representative to obtain evidences in relation to their company.
+
Specifically for Evidence Subscriptions, the principal legal solution would be to establish a legal basis for the subscription outside of the SDGR. This could be viable under national laws, in combination with the request of a representative of the affected legal entity. A pure appeal to national law (without any request for a subscription service from the user) likely will not work; this is only possible if there's already a specific legal basis for direct evidence exchanges between the authorities, and that does not seem to be the case. The BRIS Directive is the closest approximation, but does not provide a basis for evidence subscriptions. This is why the request is important, as a way to strengthen the legal mandate of the evidence provider, allowing them to build on any existing right of the company representative to obtain evidences in relation to their company.
  
−
== Business Process of the Event Subscription and Notification ==
+
== Business Process of the Event Subscription and Notification Pattern ==
 
The subscription and notification pattern realizes the goal to inform the data evaluator of relevant changes in the subject (i.e. company or citizen). This is done in two steps:
 
The subscription and notification pattern realizes the goal to inform the data evaluator of relevant changes in the subject (i.e. company or citizen). This is done in two steps:
  
Line 66: Line 110:
  
 
* Harmonised DE4A events: a list of harmonised, canonical events needs to be agreed upon so DE knows how to interpret events notified by DO. For the DE4A-pilots, i.e. the [[Use Case "Doing Business in Another Member State" (DBA UC2)]], it is an option to start with a short list of harmonised business evens.
 
* Harmonised DE4A events: a list of harmonised, canonical events needs to be agreed upon so DE knows how to interpret events notified by DO. For the DE4A-pilots, i.e. the [[Use Case "Doing Business in Another Member State" (DBA UC2)]], it is an option to start with a short list of harmonised business evens.
−
* Subscription registration: the subscription consists at least of the subject identifier and the subscriber identification (i.e. DE Id).
+
* Subscription registration: the subscription consists at least of the subject identifier and the subscriber identification (i.e. DE ID).
−
* Business or Life event based notification: the event-based approach informs the DC, i.e. the subscriber, of every business of life event of the subject (i.e. company or citizen) subscribed to. Examples of such events: address changed, new owner, bankruptcy, employed/unemployed, death.  
+
* Business- or Life event-based notification: the event-based approach informs the DC, i.e. the subscriber, of every business of life event of the subject (i.e. company or citizen) subscribed to. Examples of such events: address changed, new owner, bankruptcy, employed/unemployed, death.
 
* Notification message: the notification consists at least of the subject (i.e. company) identifier, the harmonised event type of the event that took place and the timestamp of the event.
 
* Notification message: the notification consists at least of the subject (i.e. company) identifier, the harmonised event type of the event that took place and the timestamp of the event.
 
* Data evaluator post-processing: the DE needs to interpret the event and decide on the actions needed: e.g., request updated data, discard notification, start a specific procedure.
 
* Data evaluator post-processing: the DE needs to interpret the event and decide on the actions needed: e.g., request updated data, discard notification, start a specific procedure.
Line 73: Line 117:
 
=== Event Subscription ===
 
=== Event Subscription ===
  
−
==== Business Process ====
+
==== Business Process Collaboration ====
−
[[File:Event Subscription process.jpg|alt=BPMN 2.0 Collaboration diagram of the Event Subscription process where the Data Owner registers a subscription for a Data Consumer on events of a relevant data subject|none|thumb|Event Subscription process]]
+
The BPMN diagram below shows the Business Process Collaboration of DC and DP that starts with the need for a subscription being identified (i.e. in a public service procedure) and leads to the DE logging the confirmation that their subscription was successful.
−
 
+
[[File:Event Subscription process.jpg|alt=Event Subscription Business Process Collaboration View|none|thumb|Event Subscription Business Process Collaboration View]]
 +
The DE initiates the subscription and lets the DR identify the correct DO and sending the subscription request. Please note that a change of an already existing subscriptions follows the same process; The subscription end-date would, for example, be changes to effect a cancellation or prolongation of a subscription. The option of a perpetual subscription with explicit cancellation was also discussed and discarded. The DP process registers the subscription and returns a confirmation or an error (in case the subject could not be found in the registry). The Table below provides a description of each of the activities in the process.
 
==== Activity Table====
 
==== Activity Table====
 
{| class="wikitable"
 
{| class="wikitable"
Line 83: Line 128:
 
|'''Description'''
 
|'''Description'''
 
|-
 
|-
−
|'''Trigger: Need for a subscription idenfitied'''
+
|'''Trigger: Need for a subscription identified'''
 
|Public Service Procedure
 
|Public Service Procedure
 
|Process
 
|Process
−
|A procedure of a public service provider (e.g.: subsidy) leads to the registration of a subject. After this registration events can occur to the subject that could have impact on the service delivery to this subject. In order to be informed on these events, the public service provider can subscribe to the life-events or business-events of the subject.
+
|A procedure of a public service provider (e.g.: subsidy) leads to the registration of a subject (e.g. company). After this registration, events can occur to the subject that could have impact on the service delivery to this subject. In order to be informed on these events, the public service provider can subscribe to the life-events or business-events of the subject.
  
−
The  subscription process can also be triggered for technical reasons: for instance to resend failed subscription requests.
+
The subscription process can also be triggered for technical reasons: for instance to resend failed subscription requests.
  
 
E.g.: In the pilot Doing Business Abroad the subject is the represented company itself or a new branch of the represented company (the parent-company of the branch) and Data Evaluators subscribe to be notified on the business events of the represented company.
 
E.g.: In the pilot Doing Business Abroad the subject is the represented company itself or a new branch of the represented company (the parent-company of the branch) and Data Evaluators subscribe to be notified on the business events of the represented company.
Line 98: Line 143:
 
|Potential triggers to change a subscription are:
 
|Potential triggers to change a subscription are:
  
−
* Public service: public service delivery can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the  branch-office registration).
+
* Public service: public service delivery can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the branch-office registration).
  
 
* eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription.
 
* eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription.
Line 113: Line 158:
 
* subject identifier
 
* subject identifier
 
* data owner identifier
 
* data owner identifier
−
* subscriber identifier
+
* subscriber (data evaluator) identifier
  
 
* event catalogue
 
* event catalogue
 +
* subscription start and end date/time
  
−
* action 'subscribe'
+
The subscription need is forwarded to the Data Requestor.
−
* subscription start and end date
 
−
 
 
−
The subscription need is forwarded to the Data Requestor (if applicable).
 
 
|-
 
|-
 
|'''Change subscription'''
 
|'''Change subscription'''
Line 128: Line 171:
 
* subject identifier
 
* subject identifier
 
* data owner identifier
 
* data owner identifier
−
* subscriber identifier
+
* subscriber (data evaluator) identifier
 
* event catalogue
 
* event catalogue
−
* action 'cancel subscription'
+
* new subscription start and end date/time
−
* new subscription end date
 
  
−
The cancellation of a subscription is thus a a change of the end date the current date.
+
The cancellation of a subscription is thus a change of the end date the current date.
  
−
The changed subscription need is forward to the Data Requestor (if applicable).
+
The changed subscription need is forwarded to the Data Requestor.
 
|-
 
|-
 
|'''Lookup event provider routing information'''
 
|'''Lookup event provider routing information'''
Line 141: Line 183:
 
|Service
 
|Service
 
|The DR uses the data owner identifier to look up routing information of the competent authority that facilitates subscription service. It is possible that at the DP-side the service provider of the subscription is different from the service provider of the evidence.
 
|The DR uses the data owner identifier to look up routing information of the competent authority that facilitates subscription service. It is possible that at the DP-side the service provider of the subscription is different from the service provider of the evidence.
−
|-
 
−
|'''''REMOVE: Inform National Contact point that subscription or change was not successful'''''
 
−
|''DR''
 
−
|''User''
 
−
|''In case of the cancellation of a subscription there is a slight chance the participant ID of DO has changed: a manual process deals with this (unhappy) flow.''
 
 
|-
 
|-
 
|'''Send subscription request'''
 
|'''Send subscription request'''
 
|DR
 
|DR
 
|Service
 
|Service
−
|The request to subscribe or unsubscribe is send to the participant facilitating the subscription service using the previously retrieved routing information.
+
|The request to subscribe is send to the participant facilitating the subscription service using the previously retrieved routing information.
−
 
 
−
 
 
−
The subscription / cancel subscription request contains: the participant id of the subscriber, the subject identifier, the event catalogue, the period of subscription and the requested action (subscribe / cancel subscription).
 
−
 
 
−
|-
 
−
|'''Exception: Forward subscription error'''
 
−
|DR
 
−
|Service
 
−
|The subscription error message received from Data Transferor is forwarded to the Data Evaluator.
 
−
|-
 
−
|'''Exception: Investigate reason for subscription error'''
 
−
|DE
 
−
|User
 
−
|The received error message is analysed and appropriate actions are taken. This exception flow is not further detailed in this design.
 
−
|-
 
−
|'''Forward confirmation'''
 
−
|DR
 
−
|Service
 
−
|The confirmation of the subscription  (received from the DT) is forwarded to the Data Evaluator.
 
−
|-
 
−
|'''Log subscription information'''
 
−
|DE
 
−
|Service
 
−
|The confirmation is logged to complete the audit trail.
 
  
−
Note: register in a way that it is easily readable (optional: include subscription id).
+
The subscription request contains: the participant id of the subscriber, the subject identifier, the event catalogue, the period of subscription and the requested action (subscribe / cancel subscription).
 
|-
 
|-
 
|'''Validate subscription request'''
 
|'''Validate subscription request'''
 
|DT
 
|DT
 
|Service
 
|Service
−
|The request is validated on a technical level and check on DE authorisation. If the request validates it is forwarded to the Data Owner. [Technical exceptions are out of scope.]
+
|The request is validated on a technical level and checked on DE authorisation. If the request is valid, it is forwarded to the Data Owner. A technical exception flow is out of scope of this process description.
 
|-
 
|-
 
|'''Evaluate subscription request'''
 
|'''Evaluate subscription request'''
 
|DO
 
|DO
 
|Service
 
|Service
−
|The subscription request is evaluated to check if the request can be completed: Subscription functional checks: does subject exists, is event catalogue supported, is the subscription changing an existing subscription
+
|The subscription request is evaluated to check if the request can be completed: Subscription functional checks: does subject exist, is event catalogue supported, is the subscription changing an existing subscription (i.e. update)
−
If the request does not pass the functional checks, the request is rejected and an error message will be send.
+
If the request does not pass the functional checks, the request is rejected and an error message will be sent.
 
|-
 
|-
 
|'''Exception: Prepare subscription error message'''
 
|'''Exception: Prepare subscription error message'''
 
|DO
 
|DO
 
|Service
 
|Service
−
|Collect the content of the error message and send it to the Data Transferor (if applicable).
+
|Collect the content of the error message and send it to the Data Transferor.
  
  
−
The (un)subscription error message contains: participant id of subscriber, subject identifier, requested action, reference to the request message, full request message and the errorcode.
+
 
 +
The subscription error message contains: participant id of subscriber, subject identifier, requested action, reference to the request message, full request message and the error code.
 
|-
 
|-
 
|'''Exception Send subscription error message'''
 
|'''Exception Send subscription error message'''
Line 201: Line 215:
 
|Service
 
|Service
 
|The error message is forwarded to the Data Requestor from whom the request was received.
 
|The error message is forwarded to the Data Requestor from whom the request was received.
 +
|-
 +
|'''Exception: Forward subscription error'''
 +
|DR
 +
|Service
 +
|The subscription error message received from Data Transferor is forwarded to the Data Evaluator.
 +
|-
 +
|'''Exception: Investigate reason for subscription error'''
 +
|DE
 +
|User
 +
|The received error message is analysed and appropriate actions are taken. This exception flow is not further detailed in this design.
 
|-
 
|-
 
|'''Register subscription'''
 
|'''Register subscription'''
 
|DO
 
|DO
 
|Service
 
|Service
−
|The Data Owner creates or changes the subscription according the subscription request.
+
|The Data Owner creates or changes the subscription according to the subscription request.
 
|-
 
|-
 
|'''Confirm subscription'''
 
|'''Confirm subscription'''
 
|DO
 
|DO
 
|Service
 
|Service
−
|The confirmation of the subscription is created and send to the Data Transferor (if applicable).
+
|The confirmation of the subscription is created and send to the Data Transferor.
  
−
The confirmation message contains: subscription result (success), timestamp of subscription, subscription request reference, subscription id.
+
The confirmation message contains: subscription result (success), timestamp of subscription, subscription request reference
 
|-
 
|-
 
|'''Send subscription confirmation'''
 
|'''Send subscription confirmation'''
Line 218: Line 242:
 
|Service
 
|Service
 
|The subscription confirmation is sent to the Data Requestor from whom the request was received. The subscription confirmation message is added to the log.
 
|The subscription confirmation is sent to the Data Requestor from whom the request was received. The subscription confirmation message is added to the log.
 +
|-
 +
|'''Forward confirmation'''
 +
|DR
 +
|Service
 +
|The confirmation of the subscription (received from the DT) is forwarded to the Data Evaluator.
 +
|-
 +
|'''Log subscription information'''
 +
|DE
 +
|Service
 +
|The confirmation is logged to complete the audit trail.
 +
 +
Note: register in a way that it is easily readable.
 
|}
 
|}
−
<nowiki>*</nowiki>[[Activity Type and Task Type]] in accordance with BPMN 2.0
+
<small><nowiki>*</nowiki>Activity Type and Task Type in accordance with BPMN 2.0</small>
  
 
==== Design decisions ====
 
==== Design decisions ====
  
 
===== Explicit request and preview =====
 
===== Explicit request and preview =====
−
The nature of the subscription and notification pattern leads to a different use of the explicit request and preview as stated in the SDG-regulation:
+
The nature of the Subscription and Notification pattern leads to a different use of the explicit request and preview as stated in the SDG Regulation:
  
−
* Notification is performed without a user transaction, making real-time explicit request and preview impossible.
+
* Notification is performed without a user involvement, making real-time explicit request and preview impossible.
−
* Fraud prevention outweighs user centricity, making explicit request and preview less opportune.
+
* Fraud prevention is an important driver for notifications, making explicit request and preview less opportune.
 
* The public nature of company data relaxes the need of explicit request and preview.
 
* The public nature of company data relaxes the need of explicit request and preview.
  
−
Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration, with for instance options to retract a previously given explicit request
+
Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration or even management of consent, with for instance options to revoke a previously given consent - these are arguably more relevant for citizen use cases.
  
−
''Design decision'': for the Business event notification explicit request and preview as defined in the SDG-regulation is not applicable.
+
''Design decision'': for the Business event notification explicit request and preview as defined in the SDG Regulation is not applicable.
  
 
===== Positioning of subscription registration =====
 
===== Positioning of subscription registration =====
−
For the location of the subscription registration certain options can be considered:
+
For the location of the subscription registration various options can be considered:
  
−
* Fully at the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription).
+
* At the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription).
  
−
* Split between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DE’s subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE.
+
* Split between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DEs subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE.
−
* At a central component: The DE4A-architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component.
+
* At a central component: The DE4A architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component.
  
 
''Design decision'': The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO.
 
''Design decision'': The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO.
  
−
==== Subscription period ====
+
===== Subscription period =====
−
Including a subscription period with start and end date has several consequences... todo
+
Both perpetual subscriptions and the use of a subscription period with start and end date were considered. A perpetual subscription would require an explicit cancellation from the DE if the subscription is not needed anymore. This option was discarded, mainly because of the risk of an increasing number of "ghost subscriptions" that send automated notifications that are then automatically filtered out as irrelevant upon receiving.
  
 
''Design decision:'' a subscription period with mandatory start and end dates is included in the subscription.
 
''Design decision:'' a subscription period with mandatory start and end dates is included in the subscription.
−
 
−
==== Catalogue of DE4A business events ====
 
−
TBD, see table below
 
−
 
−
==== Subscription register requirements ====
 
  
 
===== Evidence exchange and subscription request =====
 
===== Evidence exchange and subscription request =====
−
The main flow of the DBA-pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways:
+
The main flow of the DBA pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways:
  
 
* As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n.
 
* As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n.
Line 263: Line 294:
 
''Design decision'': the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch.
 
''Design decision'': the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch.
  
−
Combining the subscription request with the evidence exchange would be too early in the process. It would lead to (possibly a relative high number of) requests to cancel the subscription if no consent was given or the registration was not successful. This would also introduce the risk of unauthorised subscriptions and notifications if the cancellation fails.
+
''Design decision: not all business events are related to an evidence, subscriptions must therefore be made to business events to cover all notifications to be sent''
−
 
 
−
There are two main choices for the subscription criteria, subscribe to changes in:
 
−
 
 
−
* business events
 
−
* evidences
 
−
 
 
−
''Design decision: not all business events are related to an evidence, subscriptions must therefore be made to business events to cover all notifications to be sent, see table below.''
 
−
 
 
−
==== Business event - evidence mapping ====
 
−
Below example for [[Doing Business Abroad Pilot]]. Each pilot (domain) must define their common event list including a clear semantic explanation of each business or life event in order for the Data Evaluator to be able to interpret the event correctly and define an appropriate course of action, e.g. request an updated evidence or discontinue the public service.
 
−
{| class="wikitable"
 
−
|+
 
−
!DE4A Business event
 
−
!Event includes changes in
 
−
!Related evidence type
 
−
!Comment
 
−
|-
 
−
|'''Company info event'''
 
−
|EUID,  Updated company name/updated address/updated head quarters/changed identifier  (EUID)/changed legal form/changed representatives
 
−
|Company registration
 
−
|Split this event in: address change, name change, ...? And with a status change, notify the specific status?
 
−
|-
 
−
|'''Annual report event'''
 
−
|Annual reports
 
−
|Annual report
 
−
|What is the event? New annual report available, annual report changed, ...? Split this event?
 
−
|-
 
−
|'''Directors disqualification event'''
 
−
|Disqualifications updated for directors
 
−
|Directors  disqualification
 
−
|
 
−
|-
 
−
|'''National merger event'''
 
−
|Merger initiated/completed/cancelled, transferring company identifier, aquring company identifier
 
−
|
 
−
|Notifications are only relevant when the transferring company has subscribers.
 
−
|-
 
−
|'''Cross border merger event'''
 
−
|Merger initiated/completed/cancelled, transferrring company identifier, aquaring company identifier
 
−
|
 
−
|Notifications are relevant when the transferring company has subscribers.
 
−
This event is also relevant without a subscription. The business register of a company involved in a merger wants notifications even if there is no prior subscription to the foreign company in the cross border merger.
 
−
|}
 
  
 
=== Event Notification ===
 
=== Event Notification ===
−
 
+
==== Business Process Collaboration View ====
−
==== Business Process ====
+
The BPMN diagram below shows the Business Process Collaboration view of the Event Notification process that starts by analysing domestic event definitions from a Registry (considered external to this process) and concludes with the DE logging the appropriate action to be taken as result of the notification. Pleas note that the process starts with the DP, hence the upper pool in the diagram is the DP.[[File:Event Notification process.jpg|alt=Business Process Notification View of the Notification Process|none|thumb|Business Process Notification View of the Notification Process]]As can be seen in the Figure above, the Notification is not expecting any business-level confirmation. The DP filters events from the registry that are relevant for cross-border notifications and the DT sends them to the DC. The set of harmonized events allows for an automated processing of the notification and the identification of the correct action. These actions are not only dependent on the type of event (identified by the DP), but also the type of public service provided by the DC. A simple response would be to lookup a changed evidence (see [[Lookup Pattern]]). More complex cases will require a business response and expert analysis. The reference process informs the responsible organisation or department to come into action.
−
[[File:DE4A D2.5 PSA 0.8 not.jpg|none|thumb]]
 
  
 
==== Activity Table ====
 
==== Activity Table ====
Line 320: Line 307:
 
|'''Description'''
 
|'''Description'''
 
|-
 
|-
−
|'''Identify cross-border event'''
+
|'''Identify event'''
 
|DO
 
|DO
 
|Service
 
|Service
Line 327: Line 314:
 
Note that the DO must have a mapping of it's own business events to the list of DE4A business events.
 
Note that the DO must have a mapping of it's own business events to the list of DE4A business events.
 
|-
 
|-
−
|'''Check subscription'''
+
|'''Check subscriptions'''
 
|DO
 
|DO
 
|Service
 
|Service
−
|The subscription register is queried for subscribers to the subject related to the event:
+
|The subscription register is queried for subscribers to the subject (e.g. company) related to the event:
  
 
* No active subscriptions: end of process
 
* No active subscriptions: end of process
Line 338: Line 325:
 
|DO
 
|DO
 
|Service
 
|Service
−
|Make a list of the subscribers to notify in terms of cross-border participant identifiers and create the payload of the notification, mainly the DE4A event name and subject identifer and the timestamp the event took place.  
+
|Make a list of the subscribers to notify in terms of cross-border participant identifiers and create the payload of the notification, mainly the DE4A event name and subject identifier and the timestamp the event took place.
 +
|-
 +
|'''Exception trigger: Request from DE to resend event notifications'''
 +
|DE
 +
|User
 +
|Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested.
 +
|-
 +
|'''Exception: Resend past events'''
 +
|DT
 +
|User
 +
|The resending of previously sent notifications requires a manual action at the DT, based on logs.
 
|-
 
|-
 
|'''Resolve service metadata'''
 
|'''Resolve service metadata'''
Line 346: Line 343:
 
The messages contain: subject identifier, secondary subject identifier (in case the identifier changed), subscriber identification, event identification, event timestamp, subscription reference (optional).
 
The messages contain: subject identifier, secondary subject identifier (in case the identifier changed), subscriber identification, event identification, event timestamp, subscription reference (optional).
 
|-
 
|-
−
|'''Resolve subscriber participant ID and inform National Coordinator'''
+
|'''Exception: Resolve subscriber participant ID and inform National Contact Point'''
 
|DT
 
|DT
 
|User
 
|User
−
|If address / DE participant id is not found in the metadata, manual action is needed: contact DE / MS of participant id to analyse the exception and take appropriate measures.
+
|If address / DE participant ID is not found in the metadata, manual action is needed: contact DE / MS of participant to analyse the exception and take appropriate measures.
−
|-
 
−
|'''Request from DE to resend event notifications'''
 
−
|DE
 
−
|User
 
−
|Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested.
 
−
|-
 
−
|'''Resend past event notifications'''
 
−
|DT
 
−
|User
 
−
|The resending of previously sent notifications requires a manual action at the DT, based on logs.
 
 
|-
 
|-
 
|'''Send event notification'''
 
|'''Send event notification'''
 
|DT
 
|DT
 
|Service
 
|Service
−
|The event notification is send to the Data Requestor, a technical acknowledgement that the notification has been received by the DR is received. The audit log is updated with both the event notification and the acknowledgement.
+
|The event notification is sent to the Data Requestor, a technical acknowledgement that the notification has been received by the DR is received. The audit log is updated with both the event notification and the acknowledgement.
 
|-
 
|-
 
|'''Validate event notification'''
 
|'''Validate event notification'''
Line 374: Line 361:
 
|DE
 
|DE
 
|Service
 
|Service
−
|The notified event is analysed and the appropriate response is determined.
+
|The notified event is analysed, and the appropriate response is determined.
−
Depenting on the event, different courses of action are possible (see details below):
+
Depending on the event, different courses of action are possible:
  
 
* Event is not relevant
 
* Event is not relevant
Line 386: Line 373:
 
* Subject identifier
 
* Subject identifier
 
* Notified event
 
* Notified event
−
* Request id
+
* Request ID
 
* Determined response
 
* Determined response
 
* Timestamp of determination
 
* Timestamp of determination
Line 393: Line 380:
 
|DE
 
|DE
 
|Subprocess
 
|Subprocess
−
|When the company cannot be identified or the registered company or branch is no longer active a change (i.e. cancellation) of the  subscription is requested. Afterwards this will be analysed to find the cause of this apparently wrong subscription and to take appropriate measures. This subprocess includes user tasks ad is not end-to-end automated.
+
|When the company cannot be identified, or the registered company or branch is no longer active, a change (i.e. cancellation) of the  subscription is requested. Afterwards this will be analysed to find the cause of this apparently wrong subscription and to take appropriate measures. This subprocess includes user tasks and is not end-to-end automated.
 
|-
 
|-
 
|'''Dismiss event'''
 
|'''Dismiss event'''
 
|DE
 
|DE
 
|Service
 
|Service
−
|The notified event doesn't have impact on the procedures of the Data Evaluator and is dismissed. No further actions need to be taken.
+
|The notified event does not have impact on the procedures of the Data Evaluator and is dismissed. No further actions need to be taken.
 
|-
 
|-
 
|'''Trigger evidence lookup'''
 
|'''Trigger evidence lookup'''
 
|DE
 
|DE
 
|Service
 
|Service
−
|The lookup pattern is triggered to request a new, current, copy of the relevant evidence.
+
|The [[Lookup Pattern]] is triggered to request a new, current, copy of the relevant evidence.
  
 
The [[Doing Business Abroad Pilot]] will e.g.: request the Company Registration Evidence.
 
The [[Doing Business Abroad Pilot]] will e.g.: request the Company Registration Evidence.
 
|-
 
|-
−
|'''Identify business responses and notify responsible party'''
+
|'''Identify business response and notify responsible party'''
 
|DE
 
|DE
 
|Subprocess
 
|Subprocess
Line 418: Line 405:
 
Functional responses from Data Evaluator to Data Owner after receiving an event notification, for example to inform that appropriate actions have been taken, are out of scope of the Subscription and Notification pattern.
 
Functional responses from Data Evaluator to Data Owner after receiving an event notification, for example to inform that appropriate actions have been taken, are out of scope of the Subscription and Notification pattern.
  
−
==== Notifications from Subscriber ====
+
===== Notifications from Subscriber =====
−
Notifications from Data Evaluator to Data Owner, for example to inform Data Owner on changes in the branch registration, are out of scope of the Subscription and Notification pattern.
+
Notifications from Data Evaluator to Data Owner, for example to inform Data Owner on changes in the branch registration, are out of scope of the Subscription and Notification pattern.
  
 
== Process Realisation ==
 
== Process Realisation ==
Line 427: Line 414:
 
* Two Views concerning Event Notification, starting with the view of the DP, as it is the DP that starts a Notification
 
* Two Views concerning Event Notification, starting with the view of the DP, as it is the DP that starts a Notification
  
−
This pattern does not provide any Process Realization views as the user is not directly involved in the exchange. As can be see in the Business Process above, Subscription is triggered by a public service process that requires updates for as long as the public service is provided and the Notification is triggered by Events identified in the Base Registry.
+
This pattern does not provide any User Process Realization views as the user is not directly involved in the exchange. As can be seen in the Business Process above, Subscription is triggered by a public service process that requires updates for as long as the public service is provided, and the Notification is triggered by Events identified in the Base Registry.
  
−
Please refer to the respective sections of the Reference Application Architecture on each  
+
Please see to the respective sections per [[DE4A Service Interoperability Solutions Toolbox#Library of components and building blocks|Application Collaborations]] in the Reference Application Architecture for detailed descriptions of each Application Service.
  
 
=== Event Subscription ===
 
=== Event Subscription ===
−
The figure below shows the Process Realisation of the Subscription process at the Data Consumer, triggered by the need for a subscription, i.e. for public service provided over an extended period of time, and resulting (if successful) in receiving and logging the subscrition.  [[File:Subscription Process Realization - DC.png|alt=Subscription Process Realization of of the Data Consumer|none|frame|Subscription Process Realization of the Data Consumer]]
+
The figure below shows the Process Realisation of the Subscription process at the Data Consumer, triggered by the need for a subscription, i.e. for public service provided over an extended period of time, and resulting (if successful) in receiving and logging the subscription.  [[File:Subscription Process Realization - DC.png|alt=Subscription Process Realization of of the Data Consumer|none|frame|Subscription Process Realization of the Data Consumer]]
 +
 
 +
The Process Realisation view above shows that both Initiation and Change subscription is provided by essentially the same service from the [[EProcedure Back-office]]. Changes, i.e. changes of the subscription end-date are handled in the process essentially identical as new subscriptions and are used to effect prolongations (new, later end-date) and cancellation (new end-data set to current date) of subscriptions. This provides maximum freedom to  [[Cross-border Subscriptions]] systems of the DP to handle cancellations and prolongation in the context of their own application architecture. For update cases a reference to the original subscription could be included as optional attribute in the request message. Service from the [[Information Desk]], the [[Trust Architecture]] and [[Data Logistics]] are used to address and send the subscription request to the right DP. Even if the DP identity might already be known, at least the  technical rooting information is looked up, given the highly distributed nature of cross-border systems.     
 +
 
 +
The right half of the Process realization shows reaction to receiving either a subscription error or confirmation. Investigating the reasons for a subscription error is a subprocess that usually includes manual work, as reasons can reach from simple ID mismatches to fraud.   
 +
 
 +
Application Collaborations used by this Process Realization diagram:   
 +
 
 +
* [[EProcedure Back-office]]
 +
*[[Information Desk]]
 +
*[[Trust Architecture]]
 +
*[[Data Logistics]]
 +
 
 +
The figure below shows the Process Realisation of the Subscription process at the Data Provider, triggered by receiving a subscription request from the DC and resulting, if successful, by sending a confirmation that the subscription was registered in the [[Cross-border Subscriptions]] system.   
 +
[[File:Subscription_Process_Realization_-_DP.png|alt=Subscription Process Realization of the Data Provider|none|frame|Subscription Process Realization of the Data Provider]]
 +
The Process Realisation view above shows that the process requires, apart from a simple technical validation, some sort of authorization at the start, the Authority Check, realized by the [[Information Desk]]. This is considered more relevant for Subscriptions than for the [[Intermediation Pattern]], let alone the [[User-supported Intermediation Pattern]], because the user is not directly involved here. The main part of the process is supported by a [[Cross-border Subscriptions]] system. This application collaboration realizes all Application services required to evaluate, register and confirm the subscription. Please note that the Subscription Creation and Update Service must identify whether a subscription request relates to an already existing subscription, i.e. is an update. This should happen based on the subject ID and subscriber ID and overlapping subscription times. In addition, [[Trust Architecture]] and [[Data Logistics]] are involved to guarantee secure and reliable message exchange.
  
−
The Process Realisation view above shows that both Initiation and Change subscription is provided by essentially the same service from the [[EProcedure Back-office]].
+
Application Collaborations used by this Process Realization diagram:
−
[[File:Subscription Process Realization - DP.png|alt=Subscription Process Realization of the Data Provider|none|frame|Subscription Process Realization of the Data Provider]]
+
 
 +
*[[Cross-border Subscriptions]]
 +
*[[Information Desk]]
 +
*[[Trust Architecture]]
 +
*[[Data Logistics]]
  
 
=== Event Notification ===
 
=== Event Notification ===
−
[[File:Notification_Process_Realization_-_DP.png|alt=Notification Process Realization of the Data Provider|none|frame|Notification Process Realization of the Data Provider]]
+
The Figure below shows the Process Realisation of the Notification process at the Data Provider, triggered by changes in the base registry and resulting, if successful, in sending a Notification to the DC.[[File:Notification_Process_Realization_-_DP.png|alt=Notification Process Realization of the Data Provider|none|frame|Notification Process Realization of the Data Provider]]
 +
 
 +
The Process Realisation view above shows that the event stream from the base registry is first filtered to identify Cross-border events, i.e. events that are mapped to DE4A canonical event definitions. These events are then used to lookup active subscriptions, which are then collected into a subscriber list per event, coupled to the Notification Message (i.e. event type and subject ID). All of these steps are realized by the [[Cross-border Subscriptions]] Application Collaboration. The [[Information Desk]] is again used to lookup at least the technical part of the routing. This gives rise to an exception flow if for a subscriber, registered in [[Cross-border Subscriptions]], no service metadata (i.e. consumer) can be found in the [[Information Desk]]. Resolving such a situation is a subprocess, involving manual work and often resulting in corrective action required at the subscriber-side (e.g: reorganisation in the DC country did not update subscriptions, service metadata not maintained). Finally, [[Trust Architecture]] and [[Data Logistics]] providing for secure messaging. 
 +
 
 +
It is important to note that the DP Process ends with sending the actual Notification message. Even though the transport protocol should ensure that this Notification was received by the gateway of the DC, this still means that it is functionally a "fire and forget" exchange; The DP is not informed whether the Notification was successfully processed by the DC. This gives rise to a second starting point of the process for exception handling: The DT might be asked by a DC, who experiences problems receiving or processing notifications to have all notifications (both successful and unsuccessful) of a given time period to be resent from the logs. 
  
 
Application Collaborations used by this Process Realization diagram:
 
Application Collaborations used by this Process Realization diagram:
Line 446: Line 456:
 
* [[Trust Architecture]]
 
* [[Trust Architecture]]
 
* [[Data Logistics]]
 
* [[Data Logistics]]
 +
The Figure below shows the Process Realisation of the Notification process at the Data Consumer, triggered by receiving an Event Notification message and resulting in the correct event response being triggered and logged.
 
*  
 
*  
  
−
[[File:Notification_Process_Realization_-_DC.png|alt=Notification Process Realization of the Data Consumer|none|frame|Notification Process Realization of the Data ConsumerDC]]Application Collaborations used by this Process Realization diagram:
+
[[File:Notification_Process_Realization_-_DC.png|alt=Notification Process Realization of the Data Consumer|none|frame|Notification Process Realization of the Data Consumer]]The Process Realisation view above shows that [[Trust Architecture]] and [[Data Logistics]] play again their role in secure message exchange, while the [[EProcedure Back-office]] plays the central role in determining the event response and in triggering the associated actions.
 +
 
 +
* For the hybrid approach described above, a lookup of an evidence (i.e. company registration) could be triggered.
 +
* Changing or cancelling the subscription
 +
* Notifying the responsible organisation to take actions (e.g. termination of public service, suspicion of fraud)
 +
* No immediate reaction is required
 +
 
 +
Application Collaborations used by this Process Realization diagram:
  
 
* [[Trust Architecture]]
 
* [[Trust Architecture]]
 
* [[Data Logistics]]
 
* [[Data Logistics]]
 
* [[EProcedure Back-office]]
 
* [[EProcedure Back-office]]
−
 
−
== Used by the following use cases ==
 
−
 
−
[[Use Case "Doing Business in Another Member State" (DBA UC2)|DBA (UC2)]]
 
−
 
−
== Application collaborations ==
 
−
 
−
TBD
 
 
[[Category:wip]]
 
[[Category:wip]]

Latest revision as of 13:32, 17 September 2021

The pattern is used by the Doing Business Abroad Pilot in Use Case "Doing Business in Another Member State" (DBA UC2).

After receiving evidence from a Data Owner (DO), it can be essential for a Data Evaluator (DE) to be informed on changes regarding the subject of this evidence to be able to take appropriate action. The goal of this interaction pattern is to allow the DE to subscribe to a service of the DO that provides automatic and regular notifications. The cross-border message exchange for the subscriptions and notifications are put in the responsibility of the Data Requester (DR) and the Data Transferor (DT) respectively to allow an easier distribution of responsibility on national level, i.e. to intermediary platforms and national gateway providers.

Functional Variants of the Subscription and Notification Pattern

There are two distinct purposes, or business requirements for Subscription and Notification, both of which are relevant for the DE4A Doing Business Abroad Pilot: Evidence update notification and Event notification.

Evidence Update Notification

The goal is to keep previously shared evidence data that is stored at the DE up to date.

Description: Data may change in the base register. In case the DE wants an exact copy of the evidence data on record, they need to be notified in case the data has changed in the base registry.

Business or Life Event Notification

The goal is to assess the impact of changes to the subject (e.g. company) on the public services provided by the data evaluator.

Description: Some public services oblige the subject (i.e. company or citizen) to continue in a specific situation or state to remain entitled to the benefits of the public service provided. An agricultural company may, for example, receive a subsidy for its permanent pasture. As a prerequisite, the company must preserve the pasture for five consecutive years. The data evaluator needs to be notified of the company ending its operations and hence not meeting the five-year requirement. “Ending its operation” is an example of a business event. Other examples are: going bankrupt, a merger, etc.

Alternative Solution Approaches

Essentially there are two ways to approach the dual requirements for Subscription and Notification, either specific solutions for each requirement or hybrid approaches that can serve both.

Looking at specific solutions means that two specialized systems would need to be developed and implemented:

  1. Specific Evidence Update Solution: The subscription would be linked directly to the previously exchanged evidence, hence the subscription would need to register the evidence type, the subject ID and the subscriber ID. For any data change in the evidence type data set at the DO, the DP would need to push a complete new evidence to the DC, irrespective of that specific change being relevant for the public service provided to the user by the DC. Apart from this being not optimal from a data minimization principle perspective, it can not cover changes of the subject that are not represented in the evidence type data set, giving rise to the need of a second subscription system for events. In addition, the subscription system would be impacted by changes in the canonical evidence type definitions over time. This approach might, however, be easier to integrate in the legal framework of the SDGR (see Legal Considerations below).
  2. Pure Event Notification: The subscription is not directly related to a previously exchanged evidence, but the subscription could be registered for an agreed set of events relating to a given subject. The subscription system would consequently be based on a list of events, rather than a list of evidence types. Quite obviously, this requires an agreement on a set of DE4A events, or canonical cross-border events.

Technical approach and business requirements do not relate one to one, giving rise to several hybrid approaches, where one solution is used to cater for both requirements:

  1. Extended Evidence Type: The Specific Evidence Update can be used to derive relevant Events at the DC, if the evidence type definition is scoped, or extended, so that all relevant events are represented by data changes in the evidence type data set. This would require the DC to run an event identification routine (either immediately or periodically) after receiving updates in order to react accordingly. The extension of evidence type definitions beyond what is actually required by the eProcedure is, again, not optimal from a data minimization principle perspective. This hybrid solution can not resolve events that are dealt with by procedural means at the DP-side, rather than by data mutations.
  2. Extended Notification Message: The pure Event Notification could be extended to carry an updated evidence as part of the Notification message, essentially piggybacking the evidence onto an event notification. This approach would need to extend the event-centric subscription system to maintain with underlying evidence type, or potentially multiple evidence types, are relevant for each event type, so that evidence can be retrieved and packed as extension of the Notification Message. Which evidence is required for which event can additionally differ by public service provided and hence per subscriber. This solution would consequently end up to be rather complex and again not optimal from a data minimization principle perspective. [A BPMN Process Analysis of this approach is available on request]
  3. Event Notification + Lookup: The pure Event Notification is used as described above, while it is made sure that the agreed event set of canonical DE4A events is complete in the sense that in covers also relevant update needs, for example a company that moved HQ means that the address (part of the Company Registration evidence) changed as an effect. It is then left at the discretion of the DC, whether a particular event requires an update of the evidence on record. It could be that, i.e. the postal address of a company is not relevant for the continuation of the public service provisioning, in which case a flag that the address on record is not up to date, or a change to "unknown" would be sufficient as event response. This is fully in line with the data minimization principle perspective. If the DC considers that an update of one evidence or potentially several evidences is required as part of the event response, then the DC would use the Lookup Pattern to request new copies of evidences if and when required. The effort needed to make this approach work for evidence updates mostly concerns the Notification process: The DP might need to add "weak" events to their platform to cover changes that are not considered relevant enough to be in their event list yet, e.g. change of e-mail address. The DC will need to define or extend a decision table that relate event type to public service and returned the correct action to be taken, i.e. request a new evidence via the Lookup Pattern.

The reference Architecture for the DE4A projects focusses on the third option, the combination of Event Notification and Lookup Pattern to cover both business requirements with one hybrid solution, rather then setting up two specific solutions next to each other. The combination of Event Notification and Lookup Pattern appears to be the most flexible approach and is expected to have the following advantages:

  • Data minimization: Evidences are only requested if they are actually needed for the public service provided by the DC
  • Low complexity of message definitions: The required message definitions for the notifications and updates between DP and DC remains low in complexity: A simple event notification (consisting of event type, identifiers and timestamp) and evidence response analogous to the event response message of the Intermediation Pattern and User-supported Intermediation Pattern.
  • Multiplicity: Case that single events require multiple evidences to be updated, or several events require the update of the same evidence can be covered quiet easily without requiring complex message definitions.
  • Flexibility in legal basis and authorizations: As the Event Notification does only contain identifiers and not the underlying (personal) data (which requires the eIDAS revision to create a European Unique Identifier for natural persons), the legal basis and corresponding authorizations might differ between Notification and Lookup, adding flexibility to the overall solution.
  • Independence from a previously shared evidence: The solution approach is not directly linked to a previously shared evidence, which means that a subscription and subsequent lookup can also be applied in cases where the original procedure (leading to the public service being provided) was completed without any automated evidence exchange, i.e. evidence was provided by the user electronically or in person, provided that there is a legal basis (see below).
  • Extension of scope: New events can be added flexibly without immediate impact on existing subscriptions and without maintaining different versions of an (canonical) evidence definition.

Working hypotheses and implementation principles

Subscription and Notification Pattern working hypotheses and implementation principles
Interdisciplinary Topic Hypothesis / Principle Implications and Limitations
Orchestration / Choreography Subscription: The DC controls the overall flow for the subscription. This means that the process on DP side is a child process of the process on the DC side.


Notification: The Notification is conceived as a "fire and forget" coinversation, meaning that the processes are not really orchestrated. The DP process triggers (if successful) the DC process.

If issues on the DC-side (subscriber) prevented receiving notifications, a resubmission would need to be requested explicitly. The DP required functionality for such (manual) resubmission of notifications.
Interrupted vs. Uninterrupted exchange Both the Subscription and the Notification are considered to be uninterrupted, not sending any deferred responses. For the subscription, this means that the DC must assume that the subscription was not successful if not receiving a confirmation delay. For the DP, this means that their subscription system must be robust against receiving the same subscription twice.
Encryption Gap OOP in the public sector does not require true E2E encryption. The exchange between DR and DP must be encrypted and signed, as well as the transfers (if applicable on national level) between DR and DE on DC side and DT and DO on DP side (i.e. using the national OOP layer), but the encryption gap within the systems of the DR and DT is acceptable. This might not hold for cases where the gateway would be outsourced to a private sector subcontractor, which is not foreseen for the DE4A pilots.
Automated re-use of data Subscription and Notification are structured and adhere to known semantics and format that allow fully automated processing after receipt. To facilitate automated re-us of data requires establishing canonical event definitions.
Production system and real-life cases If the events relate to a legal person, not a natural person, subscription and notification can be run in production environments (see: Legal Considerations below) The DC still needs a legitimate reason to subscribe to events of a subject (i.e. company)
Payment for evidence In the context of the pilots we assume that no payments are required. This can restrict transition of pilot solutions to production in cases that competent authorities require payment for issuing evidence.
BRIS integration A technical re-use or bridge to BRIS is not possible because of differences in scope and accessibility by competent authorities other then business registers. The pilot system for the Doing Business Abroad Pilot need to be set-up separate from BRIS.
Matching evidences between Member States The Event Subscription and Notification is based on a set of harmonized events definitions. The participants need a semantic agreement in a set of standardized life/business events.

Legal Considerations

From a legal perspective, the central challenge is the need for a legal basis that allows impacted authorities to exchange Evidence Updates and/or Event Notifications. This is certainly critical for personal data (since the GDPR requires a legal basis), but even in the case of pure business data that contains no personal data, authorities will need to be able to demonstrate that they have a legal basis allowing them to send Evidence Updates and/or Event Notifications abroad.

The SDGR is in principle not an answer to this issue, since it focuses on user-driven exchanges (based on a user request, and with a preview option). While a user request could have been scoped in a way that allows a user to define a time period for exchanges ('I request authority A to send evidence X to authority B, including any updates, for a period of Y years'), this is not the implementation path that has been chosen in the Implementing Act. Moreover, such a request wouldn't enable a preview as the SDGR requires. Thus, referring to the SDGR is not a sufficiently encompassing option.

This does not imply that subscriptions or event notifications are impossible, but rather than an alternative legal basis must be found. A few options are available, which will be discussed briefly below. For the avoidance of doubt: these options should only be applied in relation to business data; subscriptions/event notifications relating to individual persons (citizens) do not have a clear legal basis under data protection law, and due to the public sector context, reliance on consent or legitimate interest of the public administrations is not legally feasible.

For business data subscriptions and event notifications, the following options would be available:

- there should be no legal challenge in principle if the relevant information is already made publicly accessible by the relevant authority. If the information can be freely accessed and lawfully used by the public, proactively communicating it to specific authorities (in the form of evidence or a notification) should not be problematic either. While typically some terms and conditions would apply even to publicly accessible databases (e.g. to forbid commercial exploitation), it would be possible to conclude comparable agreements in the context of DE4A as well.

- exchanges should similarly be possible for information that is not publicly available, but that can only be accessed and used by parties if they conclude a suitable agreement with the relevant business register. In some Member States, business register data is made available to commercial entities on the basis of (usually) paid contracts, e.g. allowing them to integrate that data into business intelligence services. Companies can subscribe to such services to check e.g. credit rating or bankruptcy status of their customers. In countries that support this model, it should be legally feasible to conclude similar agreements to support DE4A pilot exchanges, hopefully on a free of charge basis, if this is acceptable to the data source.

These scenarios are likely more relevant for Updates of evidences than for pure Event Notifications, since formal evidences (extracts, certificates, attestations etc) are normally not included in these models.

Specifically for Evidence Subscriptions, the principal legal solution would be to establish a legal basis for the subscription outside of the SDGR. This could be viable under national laws, in combination with the request of a representative of the affected legal entity. A pure appeal to national law (without any request for a subscription service from the user) likely will not work; this is only possible if there's already a specific legal basis for direct evidence exchanges between the authorities, and that does not seem to be the case. The BRIS Directive is the closest approximation, but does not provide a basis for evidence subscriptions. This is why the request is important, as a way to strengthen the legal mandate of the evidence provider, allowing them to build on any existing right of the company representative to obtain evidences in relation to their company.

Business Process of the Event Subscription and Notification Pattern

The subscription and notification pattern realizes the goal to inform the data evaluator of relevant changes in the subject (i.e. company or citizen). This is done in two steps:

  1. In the subscription step the DE expresses the need to be informed on changes regarding a certain subject and this need is registered as a subscription.
  2. In the notification step the DO monitors the subject and if a change occurs, all subscribers will be informed on this change

These two steps are independently triggered processes and are hence represented below in two separate BPMN Business Process Collaboration views. Please note that the Subscription is triggered by the DC (i.e. DC is the upper participant in the Subscription BPMN diagram), while the Notification is triggered by the DP (i.e. the DP is the upper participant in the Notification BPMN diagram).

Event Subscription and Notification Starting Points

Some high-level starting points for the process design of this pattern are:

  • Harmonised DE4A events: a list of harmonised, canonical events needs to be agreed upon so DE knows how to interpret events notified by DO. For the DE4A-pilots, i.e. the Use Case "Doing Business in Another Member State" (DBA UC2), it is an option to start with a short list of harmonised business evens.
  • Subscription registration: the subscription consists at least of the subject identifier and the subscriber identification (i.e. DE ID).
  • Business- or Life event-based notification: the event-based approach informs the DC, i.e. the subscriber, of every business of life event of the subject (i.e. company or citizen) subscribed to. Examples of such events: address changed, new owner, bankruptcy, employed/unemployed, death.
  • Notification message: the notification consists at least of the subject (i.e. company) identifier, the harmonised event type of the event that took place and the timestamp of the event.
  • Data evaluator post-processing: the DE needs to interpret the event and decide on the actions needed: e.g., request updated data, discard notification, start a specific procedure.

Event Subscription

Business Process Collaboration

The BPMN diagram below shows the Business Process Collaboration of DC and DP that starts with the need for a subscription being identified (i.e. in a public service procedure) and leads to the DE logging the confirmation that their subscription was successful.

Event Subscription Business Process Collaboration View
Event Subscription Business Process Collaboration View

The DE initiates the subscription and lets the DR identify the correct DO and sending the subscription request. Please note that a change of an already existing subscriptions follows the same process; The subscription end-date would, for example, be changes to effect a cancellation or prolongation of a subscription. The option of a perpetual subscription with explicit cancellation was also discussed and discarded. The DP process registers the subscription and returns a confirmation or an error (in case the subject could not be found in the registry). The Table below provides a description of each of the activities in the process.

Activity Table

Activity / UC Role Activity Type* Description
Trigger: Need for a subscription identified Public Service Procedure Process A procedure of a public service provider (e.g.: subsidy) leads to the registration of a subject (e.g. company). After this registration, events can occur to the subject that could have impact on the service delivery to this subject. In order to be informed on these events, the public service provider can subscribe to the life-events or business-events of the subject.

The subscription process can also be triggered for technical reasons: for instance to resend failed subscription requests.

E.g.: In the pilot Doing Business Abroad the subject is the represented company itself or a new branch of the represented company (the parent-company of the branch) and Data Evaluators subscribe to be notified on the business events of the represented company.

Trigger: Change subscription eProcedure / Public service / Notification Process Potential triggers to change a subscription are:
  • Public service: public service delivery can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the branch-office registration).
  • eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription.
  • Notification: after receiving a notification the assessment can be that the subscription is no longer needed (exception flow).
  • Technical reasons: for instance an error at the DO-side could lead to the need to resend the request to cancel a subscription.
Initiate subscription DE Service To initiate subscription data is collected and the subscription need is formulated:
  • subject identifier
  • data owner identifier
  • subscriber (data evaluator) identifier
  • event catalogue
  • subscription start and end date/time

The subscription need is forwarded to the Data Requestor.

Change subscription DE Service To change a subscription data is collected and the changed subscription need is formulated:
  • subject identifier
  • data owner identifier
  • subscriber (data evaluator) identifier
  • event catalogue
  • new subscription start and end date/time

The cancellation of a subscription is thus a change of the end date the current date.

The changed subscription need is forwarded to the Data Requestor.

Lookup event provider routing information DR Service The DR uses the data owner identifier to look up routing information of the competent authority that facilitates subscription service. It is possible that at the DP-side the service provider of the subscription is different from the service provider of the evidence.
Send subscription request DR Service The request to subscribe is send to the participant facilitating the subscription service using the previously retrieved routing information.

The subscription request contains: the participant id of the subscriber, the subject identifier, the event catalogue, the period of subscription and the requested action (subscribe / cancel subscription).

Validate subscription request DT Service The request is validated on a technical level and checked on DE authorisation. If the request is valid, it is forwarded to the Data Owner. A technical exception flow is out of scope of this process description.
Evaluate subscription request DO Service The subscription request is evaluated to check if the request can be completed: Subscription functional checks: does subject exist, is event catalogue supported, is the subscription changing an existing subscription (i.e. update)

If the request does not pass the functional checks, the request is rejected and an error message will be sent.

Exception: Prepare subscription error message DO Service Collect the content of the error message and send it to the Data Transferor.


The subscription error message contains: participant id of subscriber, subject identifier, requested action, reference to the request message, full request message and the error code.

Exception Send subscription error message DT Service The error message is forwarded to the Data Requestor from whom the request was received.
Exception: Forward subscription error DR Service The subscription error message received from Data Transferor is forwarded to the Data Evaluator.
Exception: Investigate reason for subscription error DE User The received error message is analysed and appropriate actions are taken. This exception flow is not further detailed in this design.
Register subscription DO Service The Data Owner creates or changes the subscription according to the subscription request.
Confirm subscription DO Service The confirmation of the subscription is created and send to the Data Transferor.

The confirmation message contains: subscription result (success), timestamp of subscription, subscription request reference

Send subscription confirmation DT Service The subscription confirmation is sent to the Data Requestor from whom the request was received. The subscription confirmation message is added to the log.
Forward confirmation DR Service The confirmation of the subscription (received from the DT) is forwarded to the Data Evaluator.
Log subscription information DE Service The confirmation is logged to complete the audit trail.

Note: register in a way that it is easily readable.

*Activity Type and Task Type in accordance with BPMN 2.0

Design decisions

Explicit request and preview

The nature of the Subscription and Notification pattern leads to a different use of the explicit request and preview as stated in the SDG Regulation:

  • Notification is performed without a user involvement, making real-time explicit request and preview impossible.
  • Fraud prevention is an important driver for notifications, making explicit request and preview less opportune.
  • The public nature of company data relaxes the need of explicit request and preview.

Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration or even management of consent, with for instance options to revoke a previously given consent - these are arguably more relevant for citizen use cases.

Design decision: for the Business event notification explicit request and preview as defined in the SDG Regulation is not applicable.

Positioning of subscription registration

For the location of the subscription registration various options can be considered:

  • At the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription).
  • Split between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DEs subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE.
  • At a central component: The DE4A architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component.

Design decision: The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO.

Subscription period

Both perpetual subscriptions and the use of a subscription period with start and end date were considered. A perpetual subscription would require an explicit cancellation from the DE if the subscription is not needed anymore. This option was discarded, mainly because of the risk of an increasing number of "ghost subscriptions" that send automated notifications that are then automatically filtered out as irrelevant upon receiving.

Design decision: a subscription period with mandatory start and end dates is included in the subscription.

Evidence exchange and subscription request

The main flow of the DBA pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways:

  • As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n.
  • In a separate subscription request message: after a user consent to the preview and a successful completion of the registration process a separate subscription message is sent.

Design decision: the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch.

Design decision: not all business events are related to an evidence, subscriptions must therefore be made to business events to cover all notifications to be sent

Event Notification

Business Process Collaboration View

The BPMN diagram below shows the Business Process Collaboration view of the Event Notification process that starts by analysing domestic event definitions from a Registry (considered external to this process) and concludes with the DE logging the appropriate action to be taken as result of the notification. Pleas note that the process starts with the DP, hence the upper pool in the diagram is the DP.

Business Process Notification View of the Notification Process
Business Process Notification View of the Notification Process

As can be seen in the Figure above, the Notification is not expecting any business-level confirmation. The DP filters events from the registry that are relevant for cross-border notifications and the DT sends them to the DC. The set of harmonized events allows for an automated processing of the notification and the identification of the correct action. These actions are not only dependent on the type of event (identified by the DP), but also the type of public service provided by the DC. A simple response would be to lookup a changed evidence (see Lookup Pattern). More complex cases will require a business response and expert analysis. The reference process informs the responsible organisation or department to come into action.

Activity Table

Activity / UC Role Type Description
Identify event DO Service The Data Owner evaluates all events identified in the register and identifies events that are potentially relevant for cross-border notifications.

Note that the DO must have a mapping of it's own business events to the list of DE4A business events.

Check subscriptions DO Service The subscription register is queried for subscribers to the subject (e.g. company) related to the event:
  • No active subscriptions: end of process
  • Active subscriptions for the DE4A event catalogue found: continue notification process
Prepare notification message and subscriber list DO Service Make a list of the subscribers to notify in terms of cross-border participant identifiers and create the payload of the notification, mainly the DE4A event name and subject identifier and the timestamp the event took place.
Exception trigger: Request from DE to resend event notifications DE User Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested.
Exception: Resend past events DT User The resending of previously sent notifications requires a manual action at the DT, based on logs.
Resolve service metadata DT Service Single notifications messages (one for each subscriber) are created from the list of subscribers and the notification payload. The routing information for each notification message is looked up.

The messages contain: subject identifier, secondary subject identifier (in case the identifier changed), subscriber identification, event identification, event timestamp, subscription reference (optional).

Exception: Resolve subscriber participant ID and inform National Contact Point DT User If address / DE participant ID is not found in the metadata, manual action is needed: contact DE / MS of participant to analyse the exception and take appropriate measures.
Send event notification DT Service The event notification is sent to the Data Requestor, a technical acknowledgement that the notification has been received by the DR is received. The audit log is updated with both the event notification and the acknowledgement.
Validate event notification DR Service The Data Requestor performs a technical validation of the event notification and forwards it to the Data Evaluator. A technical exception flow is out of scope of this process description.
Determine event response DE Service The notified event is analysed, and the appropriate response is determined.

Depending on the event, different courses of action are possible:

  • Event is not relevant
  • Event requires a new (i.e. updated) evidence
  • Business response required
  • Exception: The notification does not match the record or the record is not active, hence the subscription needs to be changes (i.e. cancelled)

The determination result is logged as a part of the audit trail:

  • Subject identifier
  • Notified event
  • Request ID
  • Determined response
  • Timestamp of determination
Request change of subscription DE Subprocess When the company cannot be identified, or the registered company or branch is no longer active, a change (i.e. cancellation) of the subscription is requested. Afterwards this will be analysed to find the cause of this apparently wrong subscription and to take appropriate measures. This subprocess includes user tasks and is not end-to-end automated.
Dismiss event DE Service The notified event does not have impact on the procedures of the Data Evaluator and is dismissed. No further actions need to be taken.
Trigger evidence lookup DE Service The Lookup Pattern is triggered to request a new, current, copy of the relevant evidence.

The Doing Business Abroad Pilot will e.g.: request the Company Registration Evidence.

Identify business response and notify responsible party DE Subprocess The responsible organisational unit is identified and informed in order to take appropriate action. It depends on the specific process if this action can be performed automated or manually.

Design decisions

Response on event notification

Functional responses from Data Evaluator to Data Owner after receiving an event notification, for example to inform that appropriate actions have been taken, are out of scope of the Subscription and Notification pattern.

Notifications from Subscriber

Notifications from Data Evaluator to Data Owner, for example to inform Data Owner on changes in the branch registration, are out of scope of the Subscription and Notification pattern.

Process Realisation

As with the Business Process Collaboration Views above, the Subscription & Notification pattern has two sets of Process Realization Views that provide the details on functional Application Services required to realize the business process.

  • Two Views concerning Event Subscription, starting with the view for the DC, as it is the DC that starts a Subscription
  • Two Views concerning Event Notification, starting with the view of the DP, as it is the DP that starts a Notification

This pattern does not provide any User Process Realization views as the user is not directly involved in the exchange. As can be seen in the Business Process above, Subscription is triggered by a public service process that requires updates for as long as the public service is provided, and the Notification is triggered by Events identified in the Base Registry.

Please see to the respective sections per Application Collaborations in the Reference Application Architecture for detailed descriptions of each Application Service.

Event Subscription

The figure below shows the Process Realisation of the Subscription process at the Data Consumer, triggered by the need for a subscription, i.e. for public service provided over an extended period of time, and resulting (if successful) in receiving and logging the subscription.

Subscription Process Realization of of the Data Consumer
Subscription Process Realization of the Data Consumer

The Process Realisation view above shows that both Initiation and Change subscription is provided by essentially the same service from the EProcedure Back-office. Changes, i.e. changes of the subscription end-date are handled in the process essentially identical as new subscriptions and are used to effect prolongations (new, later end-date) and cancellation (new end-data set to current date) of subscriptions. This provides maximum freedom to Cross-border Subscriptions systems of the DP to handle cancellations and prolongation in the context of their own application architecture. For update cases a reference to the original subscription could be included as optional attribute in the request message. Service from the Information Desk, the Trust Architecture and Data Logistics are used to address and send the subscription request to the right DP. Even if the DP identity might already be known, at least the technical rooting information is looked up, given the highly distributed nature of cross-border systems.

The right half of the Process realization shows reaction to receiving either a subscription error or confirmation. Investigating the reasons for a subscription error is a subprocess that usually includes manual work, as reasons can reach from simple ID mismatches to fraud.

Application Collaborations used by this Process Realization diagram:

The figure below shows the Process Realisation of the Subscription process at the Data Provider, triggered by receiving a subscription request from the DC and resulting, if successful, by sending a confirmation that the subscription was registered in the Cross-border Subscriptions system.

Subscription Process Realization of the Data Provider
Subscription Process Realization of the Data Provider

The Process Realisation view above shows that the process requires, apart from a simple technical validation, some sort of authorization at the start, the Authority Check, realized by the Information Desk. This is considered more relevant for Subscriptions than for the Intermediation Pattern, let alone the User-supported Intermediation Pattern, because the user is not directly involved here. The main part of the process is supported by a Cross-border Subscriptions system. This application collaboration realizes all Application services required to evaluate, register and confirm the subscription. Please note that the Subscription Creation and Update Service must identify whether a subscription request relates to an already existing subscription, i.e. is an update. This should happen based on the subject ID and subscriber ID and overlapping subscription times. In addition, Trust Architecture and Data Logistics are involved to guarantee secure and reliable message exchange.

Application Collaborations used by this Process Realization diagram:

Event Notification

The Figure below shows the Process Realisation of the Notification process at the Data Provider, triggered by changes in the base registry and resulting, if successful, in sending a Notification to the DC.

Notification Process Realization of the Data Provider
Notification Process Realization of the Data Provider

The Process Realisation view above shows that the event stream from the base registry is first filtered to identify Cross-border events, i.e. events that are mapped to DE4A canonical event definitions. These events are then used to lookup active subscriptions, which are then collected into a subscriber list per event, coupled to the Notification Message (i.e. event type and subject ID). All of these steps are realized by the Cross-border Subscriptions Application Collaboration. The Information Desk is again used to lookup at least the technical part of the routing. This gives rise to an exception flow if for a subscriber, registered in Cross-border Subscriptions, no service metadata (i.e. consumer) can be found in the Information Desk. Resolving such a situation is a subprocess, involving manual work and often resulting in corrective action required at the subscriber-side (e.g: reorganisation in the DC country did not update subscriptions, service metadata not maintained). Finally, Trust Architecture and Data Logistics providing for secure messaging.

It is important to note that the DP Process ends with sending the actual Notification message. Even though the transport protocol should ensure that this Notification was received by the gateway of the DC, this still means that it is functionally a "fire and forget" exchange; The DP is not informed whether the Notification was successfully processed by the DC. This gives rise to a second starting point of the process for exception handling: The DT might be asked by a DC, who experiences problems receiving or processing notifications to have all notifications (both successful and unsuccessful) of a given time period to be resent from the logs.

Application Collaborations used by this Process Realization diagram:

The Figure below shows the Process Realisation of the Notification process at the Data Consumer, triggered by receiving an Event Notification message and resulting in the correct event response being triggered and logged.

Notification Process Realization of the Data Consumer
Notification Process Realization of the Data Consumer

The Process Realisation view above shows that Trust Architecture and Data Logistics play again their role in secure message exchange, while the EProcedure Back-office plays the central role in determining the event response and in triggering the associated actions.

  • For the hybrid approach described above, a lookup of an evidence (i.e. company registration) could be triggered.
  • Changing or cancelling the subscription
  • Notifying the responsible organisation to take actions (e.g. termination of public service, suspicion of fraud)
  • No immediate reaction is required

Application Collaborations used by this Process Realization diagram:

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