HIPAA Compliance in the Cloud

April 1, 2014  |  HIPAA Company

The Datica Way: HIPAA Compliance in the Cloud

A Coalfire Perspective By: Gerald A. Drake III, QSA, MSIA


With numerous regulations and legislations dictating the methods of how data should be secured and maintained, organizations need to know that their data resides in a compliant and secure environment. Organizations are faced with the responsibility of securing the data that they create, receive, maintain, and transmit as a result of their business operations.

A particular point of interest in the ever-changing IT landscape is whether an organization should store their data internally or have their data managed by a third party service provider. Depending on the decision that is made, an organization can offload some of the burden of compliance onto their service provider. When selecting a third party service provider, it is vital that an organization performs due diligence to ensure that their data is secured in a compliant fashion.

Because of the choices that organizations have, it is important they are well informed of how best to achieve their compliance needs and maintain the highest security of their data. Organizations want the peace of mind that coincides with making the best decision for their business needs. Organizations need to answer some questions when selecting the right service provider and how they can achieve compliance. What is the exact pathway to compliance and how can they achieve it according to business needs? The purpose of this paper is to discuss how an organization can achieve HIPAA compliance utilizing a third party service provider as part of their compliance program, as well as providing an overarching view of the Datica Compliant Cloud.

HIPAA Overview

What is HIPAA?

The Health Insurance Portability and Accountability Act of 1996 (HIPAA), was established out of the vast need to gain access to health insurance, reduce fraud and abuse, and lower the overall cost of healthcare. HIPAA is comprised of the Privacy and Security Rule, which are specifications that require organizations to ensure the confidentiality, integrity, and availability of electronic protected health information (ePHI). Both the Privacy and Security Rules are beneficial in preventing unauthorized access and disclosure of patient information. For the duration of this paper, the focus will be on the various requirements that make up the Security Rule.

HIPAA applies to all covered entities and business associates in the healthcare industry. Per the United States Department of Health and Human Services (HHS), a covered entity is an organization that serves as a health plan or health care clearinghouse, or that is a health care provider who transmits any health information electronically in connection with certain transactions. Likewise, HHS defines business associates as any person or organization, other than a member of a covered entity’s workforce, who performs functions or activities on behalf of, or provides certain services to, a covered entity that involves Individually Identifiable Health Information. Such functions or activities include claims processing, data analysis, data management, utilization review, and billing. A third party service provider would fall under the HIPAA legislation as a business associate and henceforth be responsible for meeting all of the necessary HIPAA Security Rule safeguards, standards, and implementation specifications.

The HIPAA Security Rule was adopted and has been an established regulation that aids in the protection of individuals’ ePHI that is created, received, maintained or transmitted by a covered entity or business associate. The Security Rule requires appropriate administrative, physical and technical safeguards to ensure the confidentiality, integrity, and availability of ePHI.

With HIPAA breaking onto the scene first, the Health Information Technology and Clinical Health (HITECH) Act of 2009 works in close proximity to HIPAA. Specifically, the HITECH Act includes investments in health information technology (HIT) infrastructure, along with Medicare and Medicaid incentives to encourage doctors and hospitals to use HIT to electronically exchange patient’s health information. HITECH also strengthened Federal privacy and security law to protect identifiable health information from misuse as the health care sector increases use of Health IT. In addition, the HITECH Act has:

  • Strengthened the enforcement and penalties for HIPAA non-compliance
  • Extended the HIPAA Security Rule to apply to Business Associates
  • Requires that Business Associate Agreements be updated for additional privacy agreements
  • Requires notification to individuals, HHS, and the media in the event of a security breach

Responsive enforcement by the Office for Civil Rights (OCR) has increased through the issuance of fines, penalties, and compliance audits. The HIPAA Omnibus Rule of 2013 extends the compliance requirements to downstream vendors (“Subcontractors”) who create, receive, maintain, or transmit ePHI on behalf of Covered Entities or Business Associates. Additionally, the OCR has defined new rules to:

  • Expand the obligations of physicians and other health care providers to protect patients’ protected health information (PHI)
  • Extend these obligations to a host of other individuals and companies who, as “business associates,” have access to PHI
  • Increase the penalties for violations of any of these obligations.

The IT security-related requirements defined by the HITECH Act and the Omnibus Rule include:

  • Timeliness of Notification
  • Methods of Notice
  • Content of Notification
  • Breach Notification Procedures

What is ePHI?

Sensitive health and patient data that is created, received, maintained, or transmitted, received, or processed electronically refers to electronic protected health information (ePHI). The HIPAA Security Rule was created to protect the confidentiality, integrity, and availability of ePHI when it is being created, received, maintained, or transmitted. Safeguarding ePHI is essential as the individually identifiable health information included within the ePHI can be linked to a particular individual. This specific information can recount the following:

  • The individual’s past, present, or future physical or mental health or condition;
  • The provision of health care to the individual; or
  • The past, present, or future payment for the provision of health care to the individual.

Data becomes individually identifiable if it includes any portion of the 18 different types of data identifiers for an individual, an individual’s employer or family member, or if the information could be used by itself or combined with other specific information to identify an individual. These specific identifiers are as follows:

  • Name
  • Address
  • All elements, excluding years, of dates that relate to an individual (i.e. birth date, admission date, discharge date, date of death, and exact age if over 89)
  • Telephone number/s
  • FAX number
  • Email address
  • Social Security number
  • Medical record number
  • Health plan beneficiary number
  • Account number
  • Certificate/license number
  • Vehicle identifiers and serial numbers, including license plate numbers
  • Device identifiers or serial numbers
  • Web URLs
  • IP address
  • Biometric identifiers, including finger or voice prints
  • Full-face photographic images and any comparable images
  • Any other unique identifying number, characteristic, or code

Due to the sensitive nature of ePHI, organizations need to ensure they are appropriately safeguarding the data to protect themselves from breaches and potential fines that will result if a data breach occurs that involves ePHI.

Third Party Service Providers and Compliance

How Do You Select the Proper Service Provider?

When an organization makes the decision to select a third party service provider to manage their data and computing resources, it is crucial that they select the correct provider to meet their business needs. Specifically, an organization would most likely select a managed service provider for the purposes of managing specific IT aspects of their business operations. Because of the working relationship the service provider and the organization will have, it is vital that the service provider is a reputable organization, and has a compliant environment to house the data.

As such, the organization will need to perform the necessary due diligence with the service provider to ensure that the ePHI they are entrusting this provider with will be secured in accordance with the HIPAA regulations. As part of the due diligence process, there are some key decisions that need to be made when deciding to utilize a service provider. Key questions to ask are:

  • Has the service provider had an external assessment done by a third party?
  • Have they been assessed against the HIPAA Security Rule?
  • What assurance can the service provider make in safeguarding your data?
  • What does the service provider cover as part of the business associate agreement?

These specific questions must be addressed accordingly to ensure that the ePHI being managed by the service provider is done so in a HIPAA compliant fashion. In most instances, service providers should be able to provide evidence of a third party HIPAA compliance assessment.

Service Providers and the Cloud

There are many types of environments, physical, virtualized, and cloud, that a service provider might maintain in a compliant fashion. A large portion of service providers in today’s age are providing their services to customers utilizing the cloud model. There are multiple types of cloud environments to which an organization should become familiar. These cloud environments can be a private cloud, community cloud, or public cloud.

In a private cloud, the cloud infrastructure is operated for a single organization. It can be managed by the organization or by a third-party provider, and may be on premise or off-premise. In a private cloud, the infrastructure is dedicated to the use of that one identified entity and the organization’s data is completely segmented from all other organizations using the provider.

In a community cloud, the infrastructure is shared by multiple organizations and supports a specific business community with shared requirements or similar concerns (i.e. by type of business model, security requirements, or compliance considerations). Similar to the private cloud, the community alternative may be managed by the organization or a third party, and may be on or off-premise.

In a public cloud, the infrastructure is made available to the general public or a large industry group that is owned by the organization selling cloud services. The public cloud infrastructure exists solely on the premise of the cloud provider.

These cloud environments are important factors that an organization should consider when selecting a service provider that operates in the cloud. One important consideration that an organization needs to consider is the topic of multi-tenancy in the cloud, whether it is a private, community, or public. In a multi-tenant cloud environment, there are multiple customers or organizations that are sharing the same resources (i.e. infrastructure, data stores, virtual components, etc.) of the environment. An important note to remember about multi-tenancy in the cloud is that customers do not generally have any knowledge or insight into the customers with whom they are sharing resources. Additionally, customers do not have any knowledge or insight into the ways the other customer organizations are employing security of their internal environments used to access the cloud.

The Datica Way

Datica makes digital health in the cloud a reality by removing the risks that prevent its adoption. We turn HIPAA compliance on public infrastructure providers into a solved problem, and enable secure clinical data exchange between mission-critical digital health applications and EHR systems. Datica serves healthcare’s complete spectrum, from digital health startups and industry leaders to health systems across the nation. Hundreds of customers and partners trust Datica to ensure their clouds are HITRUST certified and data securely interoperable.

Datica is on the cutting edge of the software development forefront as it relates to developing secure mobile and web applications in a HIPAA compliant fashion. Datica was founded on the premise that safeguarding sensitive customer information, including ePHI, is a top priority. As a result, Datica has designed a cloud environment specifically for software developers and healthcare professionals who require maximum security for the ePHI data they introduce to the cloud. With the introduction of Datica Compliant Cloud, software developers can have the peace of mind that the applications they develop will be governed by imbedded controls that are capable of satisfying the requirements of HIPAA. How so, some may ask?

By choosing Datica Compliant Cloud, organizations can develop healthcare applications in an environment that is regularly evaluated by an independent, third party assessor organization. These assessments use a methodology, based on NIST 800-66, to ensure the environment’s control posture is designed and operating in accordance with the Administrative, Physical, and Technical safeguards defined by HIPAA. Additionally, Datica has been assessed against the IT security-related requirements of HITECH and Omnibus, including the Final Breach Notification requirements. The table below shows the metrics that Datica was assessed against during their third party HIPAA assessment.

Administrative Safeguards (see § 164.308)

Standard Reference Implementation Specifications (‘R’)= Required, (A)=Addressable
Security Management Process 164.308(a)(1)(i) Risk Analysis (‘R’) Risk Management (‘R’) Sanction Policy (‘R’) Information System Activity Review (‘R’)
Assigned Security Responsibility 164.308(a)(2) (‘R’)
Workforce Security 164.308(a)(3)(i) Authorization and/or Supervision (A) Workforce Clearance Procedure (A) Termination Procedures (A)
Information Access Management 164.308(a)(4)(i) Isolating Health care Clearinghouse Function (‘R’) Access Authorization (A) Access Establishment and Modification (A)
Security Awareness and Training 164.308(a)(5)(i) Security Reminders (A) Protection from Malicious Software (A) Log-in Monitoring (A) Password Management (A)
Security Incident Procedures 164.308(a)(6)(i) Response and Reporting (‘R’)
Contingency Plan 164.308(a)(7)(i) Data Backup Plan (‘R’) Disaster Recovery Plan (‘R’) Emergency Mode Operation Plan (‘R’) Testing and Revision Procedure (A) Applications and Data Criticality Analysis (A)
Evaluation 164.308(a)(8) (‘R’)

Physical Safeguards (see § 164.310)

Standard Reference Implementation Specifications (‘R’)= Required, (A)=Addressable
Facility Access Controls 164.310(a)(1) Contingency Operations (A) Facility Security Plan (A) Access Control and Validation Procedures (A) Maintenance Records (A)
Workstation Use 164.310(b) (‘R’)
Workstation Security 164.310(‘c’) (‘R’)
Device and Media Controls 164.310(d)(1) Disposal (R) Media Re-use (R) Accountability (A) Data Backup and Storage (A)

Technical Safeguards (see § 164.312)

Standard Reference Implementation Specifications (‘R’)= Required, (A)=Addressable
Access Control 164.312(a)(1) Unique User Identification (R) Emergency Access Procedure (R) Automatic Logoff (A) Encryption and Decryption (A)
Audit Controls 164.312(b) (‘R’)
Integrity 164.312(‘c’)(1) Mechanism to Authenticate Electronic Protected (A) Health Information
Person or Entity Authentication 164.312(d) (‘R’)
Transmission Security 164.312(e)(1) Integrity Controls (A) Encryption (A)

Organizational Requirements (see § 164.314)

Standard Reference Implementation Specifications (‘R’)= Required, (A)=Addressable
Business Associate Contracts or Other Arrangements 164.314(a)(1)(i) BusinessAssociateContracts (‘R’) Other Arrangements (‘R’)
Requirements for Group Health Plans 164.314(b)(1) Plan Documents (‘R’)

Policies and Procedures and Documentation Requirements (see § 164.316)

Standard Reference Implementation Specifications (‘R’)= Required, (A)=Addressable
Policies and Procedures 164.316(a) Policies and Procedures (‘R’)
Documentation 164.316(b)(1)(i) Time Limit (‘R’) Availability (‘R’) Updates (‘R’)

HITECH Act - Security Provisions

Area Reference Requirement
Notification in the Case of Breach 13402(a) In General
Notification in the Case of Breach 13402(b) Notification of Covered Entity by Business Associate
Timelines of Notification 13402(d)(1) In General
Content of Notification 13402(f)(1) [Description of Breach] [Description of EPHI Involved] [Actions by Individuals] [Actions by Covered Entity] [Contact Procedures]

The Datica HIPAA Environment

After being assessed against the aforementioned requirements of HIPAA, HITECH, and the Omnibus Rule, Datica now has the necessary means to provide their BaaS services to their customers in a HIPAA compliant fashion. The Datica environment is in a public cloud, multi-tenant service offering in which Datica manages. The virtualized infrastructure is made up of web, application, and database servers that have been hardened and which can only be remotely accessed through the load balancers and bastion host. Datica has employed a centralized logging solution in place to monitor activity and actions that occur within the environment. Segmentation has also been implemented by Datica through the use of load balancers and IPtables configured to restrict access to only approved ports and protocols. Strict logical access controls are in place so that only authorized personnel are provisioned to access the internal management servers. Data is transmitted via an SSL encrypted session and a series of API calls are made to the database servers where ePHI resides. Datica utilizes sophisticated logic to separate Individually Identifiable Information from the corresponding medical information. As a result of this mature security design, the risk of an unauthorized user gaining access to both data stores, while successfully linking the data, is mitigated.

External users will make an API call over SSL to the load balancer, which forwards the request via SSL to the application servers. Depending on the types of data, the application server will make an API call to one of the database servers over an SSL connection. When a customer requests to retrieve their specific ePHI from the database server, the application server makes an API call to the database server over SSL to retrieve the data, which is then transmitted back to the application server, load balancer, and ultimately the end user over an SSL encrypted connection. At no point in time, during transmission and storage, are the customers data unencrypted.


With the various types of service providers in existence and the complexity of their environments, organizations need to ensure that they perform the necessary due diligence. Organizations need to be armed with the appropriate information to select the service provider that best meets their needs while simultaneously achieving compliance with regulations. Prior to engaging any service provider, an organization needs assurances that the third party service provider is compliant, and the quickest way to receive this assurance is by asking for evidence of an external security assessment. A long pause at the end of the other line, a blank stare, or no evidence of an assessment are clear indicators that this might not be the right service provider for your organization. Datica Compliant Cloud has been assessed against the HIPAA Security Rule. By using Datica, organizations can create software applications in a HIPAA secure, hosted environment. Organizations should not be misled about having their data hosted in the cloud or in a multi-tenant environment. When the cloud is offered using multi-tenancy, customer organizations have no knowledge or insight into the data and resources that they are sharing with other organizations. Selecting a service provider like Datica will equip organizations with the assurances of securing their data in a compliant and secure environment.

Back to top