Core Platform

Document handling

iFACTS supports all Document handling activities in one integrated file storage system reachable from all available iFACTS modules. Documents are stored, classified and archived with version handling validation.

iFACTS approach to document handling offers a secure way of organizing and storing documents when using the system for asset, risk, claim and insurance management.

An aspect of document handling is that it stores files in securely protected from unauthorized access limited by the users login credentials and permission settings.

Document handling areas:

• Uploading and archiving documents: Any document can be uploaded and archived in the system
• Creating folders for documents: Documents can be structured in folders for easy accessibility and organization
• Classification: Documents and folders can be classified depending on confidentiality and access limited to specific user groups
• Document version handling: Version handling of documents with modification dates and changelogs are handled according standards.
• Labels: Adding labels to documents facilitates search and sorting of documents

When you need:

• A centralized and configurable file storage system reachable from your assets, risk registers, claims and policies.
• Document classification and permission management to limit access for documents to specific types of users
• Version handling of documents compliant with traceability requirements
• Ability to organize file into a configurable folder structure

Goal, measurements & KPI

Different goals, measurements and KPSs can be created here. Each goal is assigned a separate portal for documentation, measurement, distribution and monitoring.

The goals can be measured in several different ways.

• Distribution and data entry of values
• Distribution and data entry of taxonomy
• Distribution and data entry via iFACTS KPI

iFACTS KPIs are the key values configured within the information model.

For example, grade, value, weight, status, etc. Goals are visible in the entire iFACTS information model and can be linked to other parts such as Strategy, Risk, Incidents, Processes, Projects, IT resources or Facilities.

Requirements

Requirement handling makes it possible to distribute requirements to various organizational parts, such as Companies, Processes, Projects, IT or External suppliers.

The requirements are stored in the iFACTS Library in different groupings for e.g. requirements, controls, measures. These are activated by trigger logic based on classification, category or dependency type.

When the requirements are distributed to the right unit, a requirements handling process is initiated with date, approval, degree of fulfilment or exception.

Checklist

Checklist is a generic functionality that can be linked to the various parts of the iFACTS information model.

It provides the opportunity to create a checklist and distribute it to a selection of units in the organization.

Functionality for scheduling, distribution, portal page, reporting, deviation management is available.

Notifications

Notifications – a generic functionality that can be linked to the various parts of the iFACTS information model.

The notification can be generated from different reasons and processes, e.g. a task to be performed, due date passed, various thresholds passed, that something has been performed.

The notification can be sent either within the system or as an email. Functionality for scheduling, distribution, portal page, reporting, deviation management.

Reports & Dashboards

The application provides effective support for different types of reports.

Via Microsoft SSRS and standard reports integrated into the system, users can set up and save different designs of reports themselves. Parameter setting, column selection and report format are different types of settings that can be easily used.

Microsoft SSRS is integrated with iFACTS and can be used in all areas.

Kibana Dashboards to create dashboards from graph libraries.

All reports, document templates and dashboards can be access controlled and distributed within the system.

Portals

With iFACTS Portals user-specific portals can be configured.  The information is adapted to the needs of the user type. The portal consists of various widgets with specific functions and content that are dynamically placed in the Portal.

Various components and objects are combined to set-up different pages and work flows. The components are configurable and range from table components and charts, to annual wheels and interactive dashboards. This is done for each object type (including users) and several Portals for the same type, will form different perspectives.

The user portal when logging in, provides access to relevant functions depending on the user’s role; measurements to be made, planned activities, etc.

Examples of different Portals are:

• Business plan
• Risk management portal
• Customer portal
• Claims management portal
• Reinsurer portal
• Actuarial portal

Configuration

iFACTS is based on a configurable architecture in 16 main parts, where all are administered independently.

• Organization
• Permissions
• Users
• Information attributes
• Taxonomies
• Library
• Form builder
• Management entities
• Portal builder
• Assets
• Triggers
• Report builder
• Risk management
• Integrations
• Notifications
• Event management

Permissions

The permissions consist of three important parts in combination:

• Personal user account. Describes who the user is and which authentication method is used.
• Permission group. A logical grouping of permissions, often named to quickly give an idea of ​​the content, e.g. Administrators. The group controls exactly which modules, pages and functions the group has access to.
• Organization. Part of hierarchical representation of the organizational structure. All data in the application has a connection to organizations. Exv. a certain asset is owned by an organization, or a mailing is made to a certain organization.

User accounts are linked to one or more permission groups, and for resp. group can be assigned one or more organizations. This enables a set-up where a user can be the administrator for some parts of the business and a regular user for other parts.

In certain cases, a fourth part is used in addition to the three described above, described as an access list. Exv. when a user must be given access to a certain risk analysis.

Two-Factor-Authentication (2FA)

iFACTS offer a module for 2 factor authentication with several 2FA methods covered.

• Azure AD – single sign on possible depending on Office 365 level
• Moible Bank-ID – QR code/Social Security number, verify in app with fingerprint scan, facial or iris recognition, or PIN. Requires separate agreement with service provider
• Freija OrgID – QR code/user name, verify in app with fingerprint scan, facial recognition, or PIN. Requires separate agreement with service provider
• User & Password + 2FA with SMS – Sign in with username and password + One time code.
• User & Password + 2FA with Authenticator app – Sign in using a mobile phone with fingerprint scan, facial or iris recognition, or PIN.
• SITHS – Only for organizations withing Swedish health care. Requires separate agreement with service provider.

API - Integration

iFACTS External API is used both by iFACTS and third-party integrators to allow external applications querying and posting data to iFACTS installations.

Only registered client apps can access the API.

The API is versioned to minimizing risk of introducing breaking changes for existing users of the API when adding new functionality.

Every API client is associated with an application user allowing permission checks, change- and audit logging to be carried out just as if the associated user would act in the system through the normal application UI.

Technology

• .NET Core API Controllers
  • RESTful web API
• Documentation: Swagger / Open API
• API Versioning
• Authentication
  • OAuth2 Authentication using an Identity Provider
  • OpenID Connect (oicd)
  • API Key Authentication
• Authorization
  • Impersonates dedicated user configurable in the application
  • Permissions, logging and auditing work just as if the user would have acted in the application

The system is by standard not dependent on fetching information from any external systems. The system can, if needed, be delivered with connections to a few externa data sources and services. Communication with external systems is regulated by the external systems available protocols. Current connections are using web service requests (REST or SOAP).

Examples of external connections:

• Agresso: Invoicing (REST, XML)
• Biznode: Vehicle data (REST, JSON)
• ECB: Exchange rates (REST, XML)
• FASS: Medical product data (REST, XML)
• Infotorget: Person and organization data (SOAP, XML)
• Multivers: Claim transactions (FTP, CSV)
• Transportstyrelsen: Vehicle data (FTP, XML-like)
• Visma: Payment transactions and customer data (FTP, XML)

The API gives data and system functions for the systems available modules.

Access to the external API is regulated on two levels:

• API key. Every external service is given a unique API key that is used for access. The key makes it possible to monitor the integration and revert the key when needed without affecting other services.
• Every API key is connected to a specific user in the system. The user for each service is only given a minimum of permissions required to run the service. System activities that is done via the API is logged the same way as when a user manually does something in the system.

Integrations that communicate with external services for the IFACTS application or scheduled jobs are configured as external modules. The integrations can be configured on demand without affecting the rest of the system.

Integrations followed a predefined interface and all data is verified against a specification. When an error occurs, the transaction is rollbacked and the error is logged.