|
|
|
# Description of functionality for the process of Processing access requests
|
|
|
|
|
|
|
|
## Introduction
|
|
|
|
|
|
|
|
This article describes the specific functionality established for the
|
|
|
|
\"Access Request Processing\" process. In addition to system
|
|
|
|
capabilities and capabilities in standard case management, the process
|
|
|
|
has the following functionality:
|
|
|
|
|
|
|
|
- Integration with eInnsyn
|
|
|
|
|
|
|
|
- Workflow
|
|
|
|
|
|
|
|
- Reductant
|
|
|
|
|
|
|
|
- Public form
|
|
|
|
|
|
|
|
## Integration with eInnsyn
|
|
|
|
|
|
|
|
The integration with eInnsyn is handled by the spoke \"UH eFormidling
|
|
|
|
Spoke\". Every 5 minutes, UH Sak v / ServiceNow retrieves new registered
|
|
|
|
access requests and creates corresponding case complex for further case
|
|
|
|
processing.
|
|
|
|
|
|
|
|
To ensure that cases are routed correctly and that the correct
|
|
|
|
processing unit is set, access requests are split at the registration
|
|
|
|
level. A case file with two registrations and associated documents will
|
|
|
|
then become two unique cases in UH Sak. For
|
|
|
|
example:{width="5.0in"
|
|
|
|
height="1.3125in"}
|
|
|
|
|
|
|
|
We receive the following information with the access request from
|
|
|
|
eInnsyn:
|
|
|
|
|
|
|
|
- Orderer\'s e-mail address
|
|
|
|
|
|
|
|
- eInnsyn\'s unique ID on current Access request
|
|
|
|
|
|
|
|
- Name of unit (E.g. NTNU)
|
|
|
|
|
|
|
|
- Case number folder
|
|
|
|
|
|
|
|
- Journal entry
|
|
|
|
|
|
|
|
- Document number
|
|
|
|
|
|
|
|
##
|
|
|
|
|
|
|
|
## Workflow
|
|
|
|
|
|
|
|
The Transparency Request Management workflow has the following order:
|
|
|
|
|
|
|
|
1. Creating a case
|
|
|
|
|
|
|
|
2. Case processing
|
|
|
|
|
|
|
|
3. Approval
|
|
|
|
|
|
|
|
4. Dissemination of decision
|
|
|
|
|
|
|
|
Creating a case
|
|
|
|
|
|
|
|
An application for a request for access may be made in the following
|
|
|
|
channels:
|
|
|
|
|
|
|
|
1. Outlook add-in
|
|
|
|
|
|
|
|
2. Manually registered by case worker
|
|
|
|
|
|
|
|
3. Publicly available form
|
|
|
|
|
|
|
|
4. eInnsyn
|
|
|
|
|
|
|
|
Case processing for the first three channels is identical, here the case
|
|
|
|
worker must manually search for the documentation and there is no
|
|
|
|
metadata that can contribute to case routing and access management.
|
|
|
|
|
|
|
|
For access requests that come via eInnsyn , there are the following
|
|
|
|
support functions:
|
|
|
|
|
|
|
|
1. **Lookup against the archive core.** If the system is able to find
|
|
|
|
the specified case folder and journal entry in the archive kernel,
|
|
|
|
the following will occur:
|
|
|
|
|
|
|
|
a. The case worker will be assigned to the same case worker who
|
|
|
|
originally handled the case (If he exists as an active user)
|
|
|
|
|
|
|
|
b. The case processing unit will be assigned the same department as
|
|
|
|
the original casesdeals with
|
|
|
|
|
|
|
|
c. Documentation will be downloaded. Both public version and
|
|
|
|
archive version if present.
|
|
|
|
|
|
|
|
Case processing
|
|
|
|
|
|
|
|
Case processing consists of assessing the documentation requested for
|
|
|
|
access and, if necessary, redactingon the documentation where it can be
|
|
|
|
partially appropriated.
|
|
|
|
|
|
|
|
If a new or updated public version of the documentation is created in
|
|
|
|
the process, it will be uploaded on the original case if possible. This
|
|
|
|
happens automatically if access is Granted or partially Granted.
|
|
|
|
|
|
|
|
Approval
|
|
|
|
|
|
|
|
Approval of the Freedom of Information request follows the same process
|
|
|
|
as during basic case processing.
|
|
|
|
|
|
|
|
Dissemination of decision
|
|
|
|
|
|
|
|
When the decision is approved, all documentation that has been granted
|
|
|
|
access to will be collected on the same registration. The documents sent
|
|
|
|
out will now be able to be viewed together under the tab
|
|
|
|
\'Documentation\' and the decision that has been prepared. The decision
|
|
|
|
will be so-called \"Main Document\".
|
|
|
|
|
|
|
|
When using the component for \"Dissemination\" for sending out
|
|
|
|
decisions, all documentation will now be automatically included.
|
|
|
|
|
|
|
|
See also the document \"Dissemination of decision\"
|
|
|
|
|
|
|
|
##
|
|
|
|
|
|
|
|
## Reductant
|
|
|
|
|
|
|
|
Reductant is a capability that is available for all processes, but for
|
|
|
|
the process \"Request for access\", this functionality also has an
|
|
|
|
interaction with the processing of the document to which access is
|
|
|
|
requested. As described under \"Workflow\", the system can automatically
|
|
|
|
identify if a new redacted version is being created and update the
|
|
|
|
original journal entry.
|
|
|
|
|
|
|
|
See also the document \"How to redact a document on UH Task\".
|
|
|
|
|
|
|
|
## Public form
|
|
|
|
|
|
|
|
UH Sak comes with the possibility of using a public form for
|
|
|
|
applications for access.
|
|
|
|
|
|
|
|
{width="6.3in"
|
|
|
|
height="6.1930555555555555in"}
|
|
|
|
|
|
|
|
Access requests that are registered via the public form become a
|
|
|
|
registered case of the type \"Access request\".
|
|
|
|
|
|
|
|
The system will attempt to folder the provided email address of an
|
|
|
|
existing user, if there are no matches, the system will create a
|
|
|
|
contact. Illustrated:
|
|
|
|
|
|
|
|
{width="6.228813429571304in"
|
|
|
|
height="3.0625in"} |