Skip to content
Snippets Groups Projects

Changes

Page history
  • New page
  • Templates
    • Hent veiledninger fra 13.09.2023 authored by Per Christian Gaustad's avatar Per Christian Gaustad
    Hide whitespace changes
    Inline Side-by-side
    Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information.md
    View page @ 0ebc062e
    ......@@ -2,10 +2,7 @@
    ## 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:
    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
    ......@@ -17,24 +14,15 @@ has the following functionality:
    ## 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.
    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:![](uploads/Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information/0c10029f715249d78fe07439a98c91e40becf7ca.png){width="5.0in"
    height="1.3125in"}
    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:![](uploads/Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information/0c10029f715249d78fe07439a98c91e40becf7ca.png){width="5.0in" height="1.3125in"}
    We receive the following information with the access request from
    eInnsyn:
    We receive the following information with the access request from eInnsyn:
    - Orderer\'s e-mail address
    - Orderer's e-mail address
    - eInnsyn\'s unique ID on current Access request
    - eInnsyn's unique ID on current Access request
    - Name of unit (E.g. NTNU)
    ......@@ -60,8 +48,7 @@ The Transparency Request Management workflow has the following order:
    Creating a case
    An application for a request for access may be made in the following
    channels:
    An application for a request for access may be made in the following channels:
    1. Outlook add-in
    ......@@ -71,83 +58,52 @@ channels:
    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.
    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:
    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:
    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)
    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
    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.
    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.
    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.
    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.
    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 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.
    When using the component for "Dissemination" for sending out decisions, all documentation will now be automatically included.
    See also the document \"Dissemination of decision\"
    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.
    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\".
    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.
    UH Sak comes with the possibility of using a public form for applications for access.
    ![Graphical user interface, text, application, email Description
    automatically
    generated](uploads/Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information/media/image2.png){width="6.3in"
    height="6.1930555555555555in"}
    ![Graphical user interface, text, application, email Description automatically generated](uploads/Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information/media/image2.png){width="6.3in" height="6.1930555555555555in"}
    Access requests that are registered via the public form become a
    registered case of the type \"Access request\".
    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:
    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:
    ![](uploads/Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information/786575259c2470822b9feae359d3edef201a4357.png){width="6.228813429571304in"
    height="3.0625in"}
    ![](uploads/Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information/786575259c2470822b9feae359d3edef201a4357.png){width="6.228813429571304in" height="3.0625in"}