In a hospital setting, information risk management is vital.

• Patient's information must be kept confidential, with access only granted on a need to have basis.
• Information integrity should be guaranteed, with changes only made by authorized personnel.
• Information should be available to ensure work progresses.

Bearing these in mind, the eHMIS application is designed with four security levels:

Level I: Log on / Sign out with username and password

In order to access the eHMIS environment, the user must have a username and password. The administrator also reserves the right to make an account inactive. In which case, even a username and password will not be useful.

Users are encouraged to create strong passwords, i.e. combinations of both alpha-numeric and non-alpha-numeric signs, at least 8 characters etc. Furthermore, users are encouraged to change their passwords on a regular basis, and immediately if you believe it has been compromised.

Level II: Module-based access control

The eHMIS application is designed in modules. Modules in turn have sub-modules, which can be looked at as a functionality category. Access can be restricted to only particular modules, and sub-modules under a specific module.

Take for example, the module MAIN, with sub-modules: SYSADMIN, CLIENT, NEWS etc. An employee in the health facility supposed to manage only News, can be granted the navigation profile (module) NEWS. When they log into the application, they will not be able to see any other sub-module under MAIN, apart from News.

With this kind of control, users are not only restricted from access, but they actually cannot see anything, other than what they are supposed to see.

Also note that modules and submodules do not appear at all, unitl a user has selected a duty station. So when you log into the application, ensure you select a duty station before you begin work. This is also a form of access control.

Level III: Function-based access control

Having access to a sub-module, e.g. NEWS, does not imply access to all functions under NEWS, e.g. create, delete, update, display etc. should be accessible. Some functionalities must be restricted. In a hospital environment, functionalities like delete, update, shoud be restricted, and when executed should be subjected to an audit trail.

The eHMIS application enables the restriction of functionalities at that level. So in effect, one can be granted the sub-module NEWS, but restricted to only display or update without the possibility to delete.

Level IV: Audit trail

The level is currently being developed. Generally we would like to ensure that all important activities in the eHMIS environment are logged, so it possible to know who did what.