Implementation is simple...

Things to note:

You will want to make sure the myIH webdomain is whitelisted on your site so all techs connected to your network can load the platform.

In the Project tab, a user can type in a unique identifier in Search Projects box to quickly filter through projects in myIH. The user can also increase the number of rows listed per page by using the icon at the bottom right portion of the Project tab.

When your team decides to implement myIH, you will recieve personilized training by our experts to ensure a seemless implementation.

At the moment we do not natively integrate with Cority, but our data can be exported and imported into Cortity with a few clicks. In this way you're able to remove the paper based observations and repetition of typing notes into Cority.

Security concerns have been divided into six categories, based on components in the process.

1. User's computer

2. Portal application running on the user's computer

3. Communication between the portal application (user's computer) and central server

4. Central server

5. Portal application on the central server

6. Data storage on the central server

1. User's Computers

Data-leaks often happen due to issue on the user's computer. i.e. not locking a computer, installing a virus, not updating operating system, etc. This is the user’s responsibility.

2. Portal Application running on the users computer

The Portal Application runs in a web browser (eg. Google Chrome, Microsoft Edge, Apple Safari etc). The web browser plays an important role in keeping the data of the user safe. It's important to keep the web browser up-to-date. This is the user's responsibility.

Portal stores:

Access Token; short living key to identify the user on central server

(Cached) data entered by user; all data entered by the user might be stored in the web browsers on the user’s machine.

Note: myIH data is not encrypted. if user's computer gets hacked or is stolen and the user has not protected its computer correctly, data might be read. This is the user's responsibility.

The application makes use of the latest techniques to aid the browser in keeping the data secure (eg. Good instructions for the browser on what to trust and what not).

3. Communication between the portal application and central server

From this point on data is leaving the user's computer and the Portal gets more control over the data.

Communication is forced over secured encrypted lines (SSL), enforcing strong enough encryption protocols. This reduces the risk of the user's web browser choosing a weak security level.

Identification and authorization of the user is provided using the widely used and attested OAuth2 (+OpenID) protocol.

Currently, the system provides only Single Factor Authentication (username / password).

4. Central Server

The Central Server is responsible for serving the application, storing the user's data, and providing the user's data (only to the authorized people).

The central server is not 'cloud based', meaning there is a physical server structure and not a system with separate nodes. Servers are located in the European Union, The Netherlands (Delft and Amsterdam) and maintained by a certified (NEN 7510, ISO 9001, ISO 27001) company. Servers are physically only accessible by authorized personnel. Remote Access to the server (maintenance level) is only possible for authorized personnel.

The systems run on Ubuntu and are actively maintained. Data is encrypted and data carriers are destroyed according to high level security protocols when end of life.

5. Portal application on the Server

The Portal Application is developed in Python using the Django Framework. Both professional systems with good security track record. System is actively kept up to date. Hacking these systems using common/trivial techniques are prevented using up-to-date version of these frameworks.

The Portal Application is responsible for storing data correctly and providing the data only to the correct authorized users. It's the portal application where most of so-called sophisticated hacks take place. Most of the time they are not sophisticated though, but simply the result of a human-error like 'forgetting to check permissions'. The myIH developer has a lot of measures in place to prevent such human-errors; for instance, code reviewing and extensive automated testing.

6. Data storage on the server

Data is stored on the server, which is the most valuable part. Getting access to this data is prevented in many ways (see section 'central server') and very unlikely to happen in other ways than the 'human error' part mentioned in the 'portal application on the server'-section. The fact that the data is valuable and resided on the server for a long time, increased the likeliness though.