​

INTERACTIVE LIFE HIPAA COMPLIANCE POLICIES

System Access Policy

Access to production systems is managed through a centralized user management system. Each workforce member has a unique ID and password to access production systems. Access to production systems is restricted to authorized personnel only and requires two-factor authentication. The centralized system audits any successful or failed attempt to login, along with other significant details for documentation.

Additionally, privileged users have limited pseudo access where appropriate to perform privileged operations. The host where the credentials are saved is protected and encrypted. All users are granted access on minimum necessary basis. All users are responsible for reporting an incident of unauthorized user or access of the organization’s information systems.

The connection to production systems is only allowed through a VPN via bastion/jump hosts to ensure all communication is over a secure channel and access is managed.

Workforce are not allowed to download any ePHI on any workstation. This policy is enforced by disabling file transfer from the servers or any system that contains ePHI.

Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or "X-rated". Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual’s race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through organization's system.

Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization's best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.

Solicitation of non-company business, or any use of organization’s information systems /applications for personal gain is prohibited.

Transmitted messages may not contain material that criticizes the organization, its providers, its employees, or others.

Users may not misrepresent, obscure, suppress, or replace another user’s identity in transmitted or stored messages.

All workforce workstations are encrypted at rest and protected from unauthorized physical access or malicious software use using centralized anti-virus software and intrusion detection systems.

All production systems clocks are synchronized to an authoritative source using NTP.

All servers have firewalls enabled to prevent unauthorized access unless explicitly granted.

IPtables is configured to restrict access to only justified ports and protocols.

 

Audit Log

We audit hardware, software and procedural mechanisms that record and examine application, system, and network that may contain ePHI including user identification and authentication attempts, network vulnerabilities, breaches in confidentiality and out of date software use. We log specific data with each audit such as origin, API call, and time. Logs are also reviewed by a designated security employee each week. Any significant finding in the logs will be reported to the security officer in a written format.

Audit logs will be limited to internal use on a minimum necessary need-to-know basis. Individually-identifiable ePHI shall not be included in the reports.

Audit reports will be stored on AWS cloudwatch to be protected and separated from other system components. Logs will be maintained based on organizational needs.

A logging service for unifying system logs, encrypting them, and providing a dashboard for statistical reviews is also implemented.

 

Employee Training

Employees are provided training to ensure awareness of responsibility of safeguarding the privacy of ePHI. The training includes but is not limited to:

• HIPAA Privacy, Security, and Breach notification rules

• Risk Management procedures and documentation

• Auditing. We may monitor access and activities of all users

• Workstations may only be used to perform assigned job responsibilities

• Users may not download software onto workstations that contains or accesses ePHI and/or systems without prior approval from the Security Officer

• Users are required to report malicious software to the Security Officer immediately

• Users are required to report unauthorized attempts, uses of, and theft of systems and/or workstations

• Users are required to report unauthorized access to facilities

• Users may not alter ePHI maintained in a database, unless authorized to do so by a the Customer

• Users are required to understand their role in the contingency plan

• Users may not share their usernames nor passwords with anyone

• Requirements for users to create and change passwords

• Users must set all applications that contain or transmit ePHI to automatically log off after 15 minutes of inactivity

• Users must not leave their workstations unattended

• Supervisors are required to report terminations of workforce members and other outside users

• Supervisors are required to report a change in a user’s title, role, department, and/or location

• Procedures to backup ePHI

• Procedures to move and record movement of hardware and electronic media containing ePHI

• Procedures to re-use electronic media containing ePHI

• SSH key and sensitive document encryption procedures

 

System architecture overview

The information systems involved in the operation of the servers and applications may process, transmit or store ePHI in different contexts.

The systems that may handle ePHI are the following:

• AWS load-balancer

• Proxy domains

• Bastion hosts

• Authentication application servers

• Studio application servers

• PostgreSQL databases (hosted on AWS RDS)

• AWS S3 service

• MongoDB Enterprise Advanced databases

 

The ePHI that is handled by these systems falls under one of these categories:

• The profile data of the patients

• The answers of patients to forms and questionnaires

• Information about the patients' devices (e.g. iOS/Android device ids, IP addresses, browser user agents, etc.)

• Files uploaded by the patients, including profile pictures and other documents uploaded in specific forms

• Meta data about what questionnaires the patients answered and may answer eventually

• What locations (e.g. hospitals/clinics) a patient has been to (or goes to) with date/time information

The ePHI data is stored in different databases to mitigate the impact of a compromise.

 

Encryption

Encryption at rest

All drives and servers that may contain ePHI are encrypted at rest.

• PostgreSQL database is encrypted by AWS RDS encryption.

• MongoDB database encryption is handled by the "wiredTiger" storage engine of MongoDB Enterprise Advanced.

• Server storage devices are encrypted by AWS EBS encryption.

• All files uploaded to S3 instance are encrypted at rest by AWS S3 encryption.

All key management is handled by AWS KMS, and access to those keys is logged by AWS CloudTrail and controlled by AWS IAM.

Encryption in transit

All communication between mobile apps and application load balancers is encrypted using the SSL/TLS protocol. The HTTPS connection is terminated at the load balancer and the certificates are managed and renewed by AWS.

Internally, communication between application servers, database servers and cache servers is assumed to contain ePHI and encrypted using the SSL/TLS protocol. Shared static resources that do not contain ePHI may be transmitted unencrypted internally.

 

Access Control

Internally, all employee accounts are managed by a FreeIPA server to manage access to all application servers, database servers and internal developer tools. When needed, employees are also given access to AWS on least privilege principle.

The end users are divided in two separate groups: the application users (for access to the mobile apps and web apps, e.g. patients) and the studio users (for access to the management platform, e.g. practitioners, nurses and any other users depending on the customer).

For studio users, the authentication is handled by the studio server. Each user has an auto-generated user ID. Each studio user can be assigned tight user-defined roles to handle authorization as needed by the customer, to control access to ePHI to what is strictly necessary by their job description. The studio user authenticates using an email address and a password. The studio application is configured to terminate the session of a user after 15 minutes of inactivity and this is enforced by the use of short lived cryptographically strong authentication tokens.

For application users, the authentication is handled by the authentication server. Each user has an auto-generated user ID, and all profile data (as defined by the customer) is stored on an encrypted, isolated and highly available PostgreSQL database. The application user also can have different login identifiers (e.g. email, phone number, username) and passwords. The login methods are set up as needed by the customer. The Android and iOS mobile applications are configured to terminate the session of a user after 15 minutes of inactivity and this is enforced by the use of short lived cryptographically strong authentication tokens. Optionally, access to the app itself can be protected by a lock screen at the customer's discretion.

On all systems, passwords are hashed using a secure one-way hashing function with a random salt before storage in the database and are always transmitted over a SSL/TLS encrypted channel. The password hashing algorithms used are routinely reviewed to keep up to date to the industry standards. Currently, the BCrypt2 algorithm is used across the board.

All login and password reset attempts are logged to CloudWatch, for the mobile applications and the studio. Any unusual activity triggers an alert to the relevant team within 5 minutes. No ePHI is stored or transmitted in the audit logs and the alert emails in any case.

The authorization policies are not enforced cryptographically by encrypting individual fields. Any unauthorized access that bypasses the application level and/or database level authorization checks is audited and tightly controlled by the security officer. The data needs to be available in plain text to authorized users to compute statistics and send out periodic alerts to patients as the application requirements dictate.

The integrity of the ePHI stored in the MongoDB and PostgreSQL databases is managed by the DBMS itself. This protects the data from accidental or environmental errors. The files uploaded by the user are stored on S3 and their integrity is verified cryptographically.

 

Automation Scripts

Ansible scripts are used to automate:

• Deployment

• Testing

• Configuration management (server, databases, logging, etc.)

• Daily Backups

• Reviewing audit logs

• Configuring VPN In case of disaster, automation scripts are useful to deploy and decrease the downtime of the application.

 

Data (ePHI) Integrity

Data (ePHI) is protected from unauthorized access and is available when needed. We do so by:

• All production systems disable unneeded services.

• All access to production systems is logged automatically.

• All production systems use the ClamAV anti-virus software to detect malicious or unauthorized software every two hours and on reboot.

• All production systems use the OSSEC host-based Intrusion Detection System (IDS) to monitor logs continuously for any suspicious behavior.

• Production systems are used exclusively for the company's business.

• Software updates are done on a timely manner.

• Encryption key management is done and secured by AWS.

• All data transmission, data at rest and machines are encrypted and secured.

• All encryption keys are rotated yearly.

• System logs all data transmission and edit.

• All production systems that handle ePHI run unit testing and integration testing (where possible) before deployment.

• Daily encrypted backups for data.

• Access to running servers can only be through a bastion host.

• Upon termination of customer contract, we will provide the customer with 30 days from the date of termination to export data, after that we will dump all ePHI.

• No customer have access outside their own environment.

• Penetration tests for the system are run on a regular basis.

• Any code change has to go through a pull request on Github and is reviewed by the CTO. Any new feature in components that handle sensitive data is also reviewed by the security officer.

 

Risk Management Policy

We conduct a timely risk assessments of the potential threats and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) (and other confidential and proprietary electronic information) we store, transmit, and/or process for our Customers and to develop strategies to efficiently and effectively mitigate the risks identified in the assessment process as an integral part of the information security program.

Risk life cycle happens when:

• Integration of new system technology (new customer or new code developed for operations and management of the platform).

• Introducing new hardware.

• Environmental or operational changes affecting the security of ePHI.

We implement measure to reduce risks and vulnerabilities to a reasonable and appropriate level to:

• Ensure the confidentiality, integrity, and availability of all ePHI we receive, maintain, process, and/or transmit for our Customers.

• Protect against any reasonably anticipated threats or hazards to the security or integrity of Customer ePHI.

• Protect against any reasonably anticipated uses or disclosures of Customer ePHI that are not permitted or required.

• Ensure compliance by all workforce members.

 

Risk Management Procedure

1. Risk Assessment

   1. System Characterization: Identify where ePHI is received, maintained, processed or transmitted.

   2. Threat Identification: All potential threat-sources are identified by historical incidents and data from intelligent agencies.

   3. Vulnerability Identification: List technical and non-technical platform vulnerabilities.

   4. Control Analysis: List current or planned controls to mitigate the likelihood of a vulnerability.

   5. Likelihood Determination: Calculate overall likelihood rating that indicates the probability that a vulnerability could be exploited.

   6. Impact Analysis: Analyze a vulnerability impact on the sensitivity and criticality, costs associated, loss of confidentiality, and availability of systems and data.

   7. Risk Determination: Establish the degree of level of risk (low, medium, high). Refer to NIST SP 800-30.

   8. Control Recommendations: Create a document that describes the controls and alternative solutions to mitigate risks.

   9. Results Documentation: Create an official document that describe the details of the current risk assessment process.

2. Risk Mitigation 

   1. Prioritize Actions: Sort the threats from high to low

   2. Evaluate Recommended Control Options: Review the recommended options and list the feasible ones.

   3. Conduct Cost-Benefit Analysis: Document cost-benefit of either implementing or not implementing each specific control.

   4. Select Control(s)

   5. Assign Responsibility

   6. Develop Safeguard Implementation Plan: Develop an overall implementation or action plan and individual project plans needed to implement safeguards and controls identified.

   7. Implement Selected Controls: Implemented controls may lower a risk but not completely eliminate the risk.

3. Documentation
   Maintain official documentation of all risk assessment for a minimum of six years.

 

Policy Management

Formal request including but not limited for:

• Access of ePHI

• Change of access

• Start a risk assessment procedure

• Termination of access

• Reviewing access of a user

• Reviewing logs

• Provisioning a system

• Internal penetration tests

• Report breach or unauthorized access incident

All formal requests are passed through a process on a dedicated compliance Github repository. The process is:

1. The employee initiates a policy change request by creating an Issue in the Github repository project. The change request may optionally include a GitHub pull request from a separate branch or repository containing the desired changes.

2. The Security Officer or the Privacy Officer is assigned to review the policy change request.

3. Once the review is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.

4. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.

5. If the policy change requires technical modifications to production systems, those changes are carried out by authorized personnel.