Ramkumar: live master directory link is ready. Ayush will update the link once the remaining documents still on google drive have been moved to Confluence.
Whatever we develop, we must think beyond ministerial or function silos and abandon the digitalization of paper processes (getting registered, filling out forms, etc.). We need to prepare our products, consumers, and beneficiaries for the time when every service is prefilled, happens behinde the scene, and is events (triggers) based proactive service. Many countries are not there yet, but we must prepare them.
Whatever the country is, it should be founded on the ideals of the rule of law. Everything we create (whether a use-case or a solution) should take place in this context. We must address the topic of legal certainty in our use-cases.
IM is the only solution around (together with X-road) that enables the whole of gov digital architecture design while preserving the division of powers (an important rule for a democratic society), and still being highly scalable.
IM is a distributed architecture-based cyber resilient by design network that has/is a trust framework for services provision (register of registers; the process of becoming a network member; a regulatory framework that supports once-only principle; data based decision-making and etc..)
IM has no single point of faliure. The system logs each transaction in 3 locations (transaction log, respective peer logs). Such logging enables necessary data lineage for digital forensics that stands in court when disputed. This leads to legal certainty of data in digital registers, which is an underlying necessity for digital society development (if the court cannot rely on digital register data in its decision-making and still need to bring paper proof, then people will not trust digital services)
True that there are prerequisites in that must be in place. For example, a single source of truth requirement must be in law to successfully implement a once-only principle in a cross gov case. Yes, we produce solutions, not regulations, but we need to enable and push for it as designers and engineers. Otherwise, we are just another OSS/MOSIP reseller, below the bar. In our use cases, we need to go beyond regular thinking and explain this to our beneficiaries even if this will not be implemented immediately.
IM true value comes from cross-ministerial use-case delivery, but in a user-centric approach for services, there are usually non of those.
We hold a seminar with the CEO of NIIS.org the mantainer of x-road, titled “From connectivity between databases towards an ecosystem of ecosystems – lessons learned through the development of X-Road”
Margus: More clarification needed if this step is mimicking the process of registration building block steps - a generic process that is applicable in any kind of registration process?
Margus: In the whole of government approach, to register a user should not happen because in an ideal case, everybody should have a singular digital identity - either from the certificate authority or the population registry. There should be in place a single system.
In this instance, issuing a username and password to establish certain services or start using certain services should not be a step. However aware that the current reality is different.
Step 4: Data Verification and Validation
Ramkumar: The description assumes permission has already been granted to access and share applicants data (legal person/legally registered person/entities). This can cause privacy issues especially for businesses.
This step should clarify and ensure permission has been granted from applicants. If it's a legal entity, there'll be an authorized person who has to officially give permission to share the relevant records of the organization.
This step seems out of order - makes more sense to follow the unconditional cash transfer steps order. Could be moved to step 3.
Margus: Information mediator should be added as an additional BB - responsible for data exchange needs and verification processes.
Step 5: Review
Ramkumar: Name of step could be changed to Eligibility Check to align with the terminology used in other use cases.
Step 7: Ongoing Case Management
Sarah: There should be a different treatment for complaints which requires a different process that is outlined here. Addressing complaints should have a separate step as it also differs to monitoring and evaluation.
Margus: from the registration perspective, change requests and disputes can be addressed in the same process via a task management system to address disputes or amendment requests.
Additional steps to incorporate
Meelis: This use case seems to provide only a half service. If the aim is safety and sustainability at state and municipality level, then it should include a process (similar to application) - which validates the quality and accuracy of the building plan post construction. If the aim is to pilot a small part of a full digital service then it is OK, but is should be implicated at least.
Sarah: Based on how the product use case is currently defined (single generic process), the current steps are enough. But if we're thinking about it from a service angle/end to end service delivery, then we could add this step. Need to officially decide how we are defining use cases as Govstack and then keeping that consistency throughout.
Ramkumar: A separate step should be added on method of issuing the permit. Maybe requires generating a new ID, communicating with different parties - informing relevant individuals/stakeholders of the issuance.
Messaging BB should be added.
Issuing of the permit could be called enrollment. This process is similar to the step in the unconditional cash transfer use case.
Sarah: Add a cancelation step outlining process of when an applicant who started the application process wishes to cancel the permit request.
General use case format feedback
Sarah: Likes the visualization depicted on the Miroboard. We should consider displaying visuals in the use cases on Gitbook.
A visualization for each use case step. It could be embedded within the use case pages itself.
Ramkumar: We should figure out how to incorporate capabilities. If we can standardize a generic registration process/template. Offer registration as a generic capability.
Then for the next use case, before working on the detailed outline from scratch, we can first check how its different from the standardized use case steps, and what additional requirements are needed. If the process is similar and generic then instead of creating a whole new use case document, these subject domain matters can be included as example implementations for i.e. registration, payment etc.
Creating a standard template for these capabilities and adding example implementations per subject matter.
Accelerated Use Case Process
5 min
Status Update
Review EPR Use Case (
PRD-112
-
Getting issue details...STATUS
)
Goal is to incorporate feedback received today from Yolanda.
Compile Online Construction Permit Documents (Epic Required)
Identify/Invite Country Representatives (
PRD-117
-
Getting issue details...STATUS
)
✅ Action items
Shukla, Ayush to create a live master directory document (on Confluence) with links to all relevant GovStack folders/files across the technical and non-technical workstreams. PSRAMKUMAR to then circulate this master directory link to all team members.
PRD-120
-
Getting issue details...STATUSRamkumar requested this item be checked as complete.
Martinez, Yolanda (Deactivated) to create proposal for where to host country content so that it can be linked in the Use Case on gitbook (Will present next week)
Agreement and alignment on sandbox purpose - Sandbox is intended for Reference Systems that are a staging-level prototype of a service, not anything approaching a production-level system
For accelerated work, UC do not have to have Example Implementation to proceed (though these will be worked on as a higher priority)