In a government digital service, ESIA and SMEV serve different purposes. ESIA concerns user identification and authentication, while SMEV supports information exchange between systems when services are provided and government functions are performed. Treat them as separate parts of the architecture and work plan. Official materials for preparing a project are published in the Ministry of Digital Development’s ESIA recommendations and the Situational Center’s SMEV questions section.
Separate sign-in from application permissions
For ESIA, start with the user scenario: who signs in to the service, what information is needed after sign-in, and what the person will be able to do in the application. The client should approve the data received and the basis for using it. Authorization within the service requires its own role model: a verified account does not by itself determine an employee’s authority within a particular organization. Describe local profile creation, linking to an existing record, and actions when information changes. Users representing an organization need separate attention.
Prepare a list of connection dependencies in advance: registration steps, integration parameters, access to environments, certificates, and approvals that apply to the selected scenario. For each dependency, specify an owner and the expected outcome. Check the requirements against the documentation for the selected version. Provide clear interface states when sign-in is interrupted, the user declines, or the external service is temporarily unavailable. The person should understand whether sign-in succeeded and what action they can take next.
Describe each information exchange
For SMEV, prepare a separate specification for each required information type: the purpose of the request, provider, version, input data, and rules for using the response in your process. The information type catalog is available on the official Situational Center portal. Clarify access conditions and requirements for the selected exchange before estimating development work. Decide early what happens if a response contains incomplete information or does not allow the application to continue being processed.
If the selected exchange sends a request and receives its response separately, reflect this in the task state. The system should link the response to the original request, show that it is waiting, and account for repeated processing. Test a successful response, a format error, missing data, a late response, and the temporary unavailability of the external party. The log should help locate a specific exchange by identifier and understand its state while retaining the agreed set of diagnostic data. Include rules for manually reviewing exceptions in acceptance testing as well.
Plan launch and ongoing operation together
A production launch depends on the readiness of the application and external connections. In the overall plan, identify which scenarios can be checked in a test environment, which require coordination with a related party, and who records the outcome. Before handover, prepare information about document versions, settings, the validity periods of certificates in use, and the incident reporting channel. A change to an information type or sign-in conditions should trigger a compatibility check. ESIA and SMEV then become clear parts of the service with their own owners, checks, and support procedures.