×
  •  
  •  

introduction

1.0 Software as a Service (SaaS)

The iDialogs Platform which includes its  web-based applications, mobile applications, add-ons, APIs, systems, services,  3rd party integrations, and processes will be rendered as Software as a Service (SaaS).  This is defined as the iDialogs platform being centrally hosted, maintained, and provided in an "on-demand" fashion from iDialogs' infrastructure.  Customers can access the platform through the internet on a subscription-based licensing model.

1.1 Platform Add-ons

Add-ons are compliant API-driven services that are offered as part of the iDialogs Platform. These services currently include our back-end as a Service and secure Messaging Service. With Add-ons, iDialogs has access to data models and manages all application level configurations and security.

In the future, there may be 3rd party Add-on services available as part of the iDialogs Platform. These 3rd party, or Partner Services will be fully reviewed by iDialogs to assure they do not have a negative impact on iDialogs' information security and compliance posture.

1.2 Compliance Inheritance

iDialogs provides compliant hosted software infrastructure for its Customers. iDialogs has been through a HIPAA compliance audit by a national third-party compliance firm to validate and map organizational policies and technical controls to HIPAA rules. iDialogs company policies, procedures, and technologies are HITRUST Certified. iDialogs service offerings are available through Rackspace which is a HITRUST certified provider; current production systems on these platforms are included in iDialogs third-party audits and HITRUST certification.

iDialogs signs business associate agreements (BAAs) with its Customers. These BAAs outline iDialogs obligations and Customer obligations, as well as liability in the case of a breach. In providing infrastructure and managing security configurations that are a part of the technology requirements that exist in HIPAA and HITRUST, as well as future compliance frameworks; iDialogs manages various aspects of compliance for Customers. The aspects of compliance that iDialogs manages for Customers are inherited by Customers, and iDialogs assumes the risk associated with those aspects of compliance. In doing so, iDialogs helps Customers achieve and maintain compliance, as well as mitigates Customers risk.

iDialogs acts as a Covered Entity (CE) and as such is bound by HIPAA regulation.  iDialogs stores Electronic Protected Health Information (ePHI) on behalf of business associates under an iDialogs BAA which inherit certain HIPAA and HITRUST provisions as a CE under iDialogs.

Certain aspects of compliance cannot be inherited. Because of this, iDialogs Customers, in order to achieve full compliance or HITRUST Certification, must implement certain organizational policies. These policies and aspects of compliance fall outside of the services and obligations of iDialogs.

Mappings of HIPAA Rules to iDialogs controls and a mapping of what Rules are inherited by Customers, are covered in iDialogs Policy #2.

1.3 iDialogs Organization Concepts

The physical infrastructure environment is hosted on Amazon Web Services (AWS). The network components and supporting network infrastructure are contained within the AWS infrastructures and are managed by Amazon; a HITRUST certified provider. iDialogs has limited physical access into the network components. The iDialogs environment consists of multiple Linux Web servers utilizing PHP and NGINX application servers; Amazon Aurora database clusters; Linux monitoring servers; Chef configuration management servers; OSSEC and SNORT IDS services; and developer tool servers running on Linux.

Within the iDialogs Platform on AWS, all data transmission encrypted and all hard drives are encrypted so data at rest is also encrypted; this applies to all servers - those hosting application servers, databases, APIs, log servers, etc. iDialogs assumes all data may contain ePHI, even though our Risk Assessment does not indicate this is the case, and provides appropriate protections based on that assumption.

The data and network segmentation mechanism differs depending on the primitives offered by the underlying cloud or dedicated provider infrastructure:

  1. Within AWS, hosted load balancers segment data across dedicated Virtual Private Clouds (VPCs).  Development and production environments exist on different VPC networks.

The result of segmentation strategies employed by iDialogs effectively create RFC 1918, or dedicated, private segmented, and separated networks and IP spaces.

Additionally, AWS security groups are used for logical segmentation. Security groups are configured to restrict access to only justified ports and protocols. iDialogs has implemented strict logical access controls so that only authorized personnel are given access to the internal management servers. This also extends to servers only receiving access to systems through specific ports based on their roles. The environment is configured so that data is transmitted from the load balancers to the application servers over a TLS encrypted session.

In the case of Platform Add-ons, once the data is received from the application server, a series of Application Programming Interface (API) calls is made to the database servers where the ePHI resides. The ePHI is separated into AWS Aurora databases through programming logic built, so that access to one database server will not present you with the full ePHI spectrum. Data is encrypted at rest on all database servers.

All servers are located on the internal iDialogs network and can only be accessed through a bastion host over a VPN connection to authorized personnel and to application servers requiring database access through restricted IP/Port traffic shaping.  No instance is directly accessible from the internet, not even the application servers which are accessible only through the AWS firewall and load balancers.  Access to the internal database is restricted to a limited number of personnel and strictly controlled to only those personnel with a business-justified reason. Remote access to internal servers is not accessible except through a VPN via Firewall to authorized iDialogs workforce members.

All Platform Add-ons and operating systems are tested end-to-end for usability, security, and impact prior to deployment to production.

1.4 Requesting Audit and Compliance Reports

iDialogs, at its sole discretion, shares audit reports, including its HITRUST reports and Corrective Action Plans (CAPs), with customers on a case by case basis. All audit reports are shared under explicit NDA in iDialogs format between iDialogs and the party to receive materials. Audit reports can be requested by iDialogs workforce members for Customers or directly by iDialogs Customers.

The following process is used to request audit reports:

  1. Email is sent to privacy@idialogs.com. In the email, please specify the type of report being requested and any required timelines for the report.
  2. iDialogs staff will log an Issue with the details of the request into the iDialogs Compliance Review Activities Project on JIRA. JIRA is used to track requests status and outcomes.
  3. iDialogs will confirm if a current NDA is in place with the party requesting the audit report. If there is no NDA in place, iDialogs will send one for execution.
  4. Once it has been confirmed that an NDA is executed, iDialogs staff will move the JIRA Issue to  Under Review .
  5. The iDialogs Security Officer or Privacy Officer must Approve or Reject the Issue. If the Issue is rejected, iDialogs will notify the requesting party that we cannot share the requested report.
  6. If the Issue has been Approved, iDialogs will send the customer the requested audit report and mark the JIRA Issue  Closed  for the request.

1.5 Compliance Template

Some policies have been sourced from Datica used under an open source license.

Refer to the GitHub repository at https://github.com/catalyzeio/policies/ for open source version history of these policies.