rss
J Am Med Inform Assoc 19:161-165 doi:10.1136/amiajnl-2011-000162
  • Perspective

Reconciliation of the cloud computing model with US federal electronic health record regulations

Editor's Choice
  1. Eugene J Schweitzer
  1. Department of Surgery, Division of Transplantation, University of Maryland Medical School, Baltimore, Maryland, USA
  1. Correspondence to Dr Eugene J Schweitzer, 29 S. Greene Street Suite 200, Baltimore, MD 21201, USA; gschweitzer{at}smail.umaryland.edu
  • Received 2 February 2011
  • Accepted 10 June 2011
  • Published Online First 4 July 2011

Abstract

Cloud computing refers to subscription-based, fee-for-service utilization of computer hardware and software over the Internet. The model is gaining acceptance for business information technology (IT) applications because it allows capacity and functionality to increase on the fly without major investment in infrastructure, personnel or licensing fees. Large IT investments can be converted to a series of smaller operating expenses. Cloud architectures could potentially be superior to traditional electronic health record (EHR) designs in terms of economy, efficiency and utility. A central issue for EHR developers in the US is that these systems are constrained by federal regulatory legislation and oversight. These laws focus on security and privacy, which are well-recognized challenges for cloud computing systems in general. EHRs built with the cloud computing model can achieve acceptable privacy and security through business associate contracts with cloud providers that specify compliance requirements, performance metrics and liability sharing.

Introduction

The costs of electronic health records (EHRs) and their low return on investment are cited as the main barriers to adoption.1 2 High costs accrue from the size and complexity of these systems, which must be useful to clinicians and administrators while complying with privacy regulations. Large, expensive systems designed with a traditional in-house, client–server architecture are typically purchased as a major capital expenditure by healthcare institutions and deployed within the corporate perimeter. The buyer also allocates funds to acquire, maintain, and upgrade the hardware to host the system, and supports an IT department to manage it. Vendors often charge substantial fees to code custom interfaces to outside EHR systems. This traditional approach makes EHR applications expensive to acquire and modify, and often renders them unresponsive to the business workflow and other special needs of individual clinical practice groups within the organization.

The software cost, complexity, and inflexibility issues of traditional EHR systems have also burdened other business sectors, which have developed modern, innovative architectures to resolve them. New approaches like cloud computing are emerging and gaining increasing attention.3 4 These modern design patterns could be used to achieve more ideal EHR applications (table 1).

Table 1

Implementation of desirable EHR qualities with the cloud computing model

Cloud computing

Widespread connectivity to computers outside our own office, company, and even national boundaries provides the pre-requisite for recent trends like cloud computing. The internet itself is sometimes referred to as ‘the cloud’ because, historically, networks would often be depicted as the outline of a cloud in diagrams representing transport of data from one endpoint to another.6 However, ‘cloud computing’ does not mean ‘internet computing’ as one might infer from this metaphor. The term refers to a family of computing architectures that offer utility programming, where resources are provided as a metered service, similar to the way a public utility company supplies gas and electricity.7 As defined by the National Institute of Standards and Technology (NIST), ‘Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (eg, networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.’ The NIST definition of cloud computing lists five essential characteristics:

  1. On-demand self-service. Customers can utilize or release more or less computing resources as needed, and automatically, without the need for human intervention at the cloud provider.

  2. Broad network access. Services are provided over the network in formats that promote access by a wide variety of desktop and mobile client devices.

  3. Resource pooling. The cloud provider pools its computing resources, dynamically allocating and releasing resources like storage, processing, memory, network bandwidth, and virtual machines, to multiple consumers.

  4. Rapid elasticity. The provider's resources can be elastically scaled out or quickly released to scale in, depending on customer demand, giving the customer the appearance that resources are unlimited.

  5. Measured service. The provider monitors and reports consumer usage of services.

Currently, the three most common cloud computing service models are Software-As-A-Service (SAAS), Platform-As-A-Service (PAAS), and Infrastructure-As-A-Service (IAAS).8 The SAAS model offers software, PAAS offers a development environment, and IAAS offers processing power and disk space, all rented on a pay-per-use charge plan. Cloud providers can offer combinations of these services, so a PAAS provider might offer a software development environment, and then rent server space to host the applications and store data. Services can be deployed as public clouds (multiple customers from the general public share a common infrastructure), private clouds (a single organization uses the cloud services), community clouds (infrastructure is shared by several organizations with a common mission), or hybrid clouds (several clouds bound together by some technology that allows data and application sharing).9

Cloud computing is gaining acceptance as a model for business information technology (IT) applications because of its potential to increase capacity and functionality on the fly without major investment in infrastructure, personnel, or software licensing fees.10 The NIST believes that government and industry should work to overcome the barriers11 and migrate to cloud computing because it offers the potential for massive cost savings and increased IT agility.12

Cloud computing service models could be used for entire EHR systems, or to support some of their components. EHR software applications and data storage are already starting to appear through cloud providers that advertise SAAS.13–17 Clients can access their systems in a variety of formats, including desktop client executables, browsers, and smartphones. These companies advertise their SAAS systems as economical because a capital expenditure is converted to operational expense, they have device and location independence, and they automatically increase capacity with demand.17 18 Such SAAS systems are being marketed to small practices that seek rapid EHR adoption to become eligible for federal ‘meaningful use’ incentives.19 Potentially, EHRs built with the PAAS model, using programming and database tools from vendors like Microsoft, could be offered to practices large enough to have IT support, who are interested in rapidly customizing their EHR.20 Such systems would not only offer the pre-fabricated EHR software offered by SAAS providers, but would also supply the customer's software developers with the tools needed to build on the basic functionality. This additional flexibility over immutable SAAS software would address clinician's concerns that EHR applications would be more useful if they were agile and adaptable to local business workflow. The PAAS provider's framework would facilitate EHR application development by supplying standard features like user account management, encryption, database backup, terminology picklists, and National Health Information Network (NHIN) messaging.

Rather than implementing entire EHRs, cloud providers could support components of complex EHR systems that the owners wish to outsource. An obvious example would be medical database storage or backup by an IAAS provider. Cloud providers could offer data aggregation and software services to support personal health record (PHR) repositories. Health information exchange services, data processing for connectivity with the NHIN, and offsite master patient indexing could also be supplied on demand by specialized cloud providers. Outsourcing to cloud providers could be used to make EHRs more useful, agile, economical, and interoperable. However, in order to implement the features of being secure and compliant, they must adhere to government regulations and industry standards.

Federal security and privacy regulation

The federal legislation which calls for regulations to safeguard the privacy and security of electronic protected health information (ePHI) is part of the 1996 Health Insurance Portability and Accountability Act (HIPAA).21 The rationale behind the HIPAA legislation includes (1) enhancing patients rights by providing them with access to their medical records; (2) protecting their rights by controlling access to their records; (3) improving the efficiency and effectiveness of healthcare delivery and data exchange; and (4) reducing healthcare costs.22 The security regulations concerned with electronic medical information were published by the Department of Health and Human Services as The Security Rule in 2003.23 The regulations require appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and security of stored or in-transit ePHI, and to protect it against any reasonably anticipated threats or hazards.24 Failure to comply with federal HIPAA regulations carries severe sanctions, including fines of up to $1.5 million and up to 10 years in prison. The Health Information Technology for Economic and Clinical Health (HITECH) Act, part of the American Recovery and Reinvestment Act of 2009, is also relevant because it has several provisions that strengthen the civil and criminal enforcement of the HIPAA rules, mainly by defining levels of culpability and corresponding penalties.25 The penalties are intended to have ePHI owners take privacy and security seriously.

The Security Rule contains 42 implementation specifications (table 2) that are sufficiently broad and complex to elicit the publication of multiple articles and books that attempt to explain and simplify them.21 22 They include guidelines that relate to security administration (conducting risk analyses and implementing policies and procedures to address vulnerabilities; assigning responsibility; screening and educating the workforce; limiting access to PHI; developing incident response plans), physical safeguards (protecting and limiting access to servers, storage media, and workstations), and technical safeguards (user identity management; encryption; activity audits; data integrity verification; transmission security).

Table 2

Cloud provider business associate contract stipulations needed to ensure compliance with the HIPAA Security Rule

Movement of EHR applications and data outside the healthcare establishment's corporate perimeter involves implementation of many of the HIPAA-required security processes and technologies by the cloud provider. The actual implementation of many of the security measures remains essentially the same, regardless of who applies them, although there are some issues that are specific to the cloud architecture.

Security measures common to traditional and cloud architectures

Most of the HIPAA-specified controls listed above can be directly transferred from a traditional in-house system to an outside provider of simple EHR hosting or of cloud architecture services (table 2). The provider must conduct risk analyses, implement policies and procedures to address vulnerabilities, assign responsibility to a security officer, screen and educate its workforce, limit workforce access to PHI, develop incident response plans, protect and limit access to servers, storage media, and workstations, manage user identity, encrypt data both at rest and in transit, monitor and audit system activity, and verify data integrity. The provider can accomplish this with standard security controls like physical plant security, firewalls, intrusion detection/prevention systems, anti-virus software, patch maintenance, encryption, activity monitoring, identity and access management, and with governance-risk management-compliance policies and processes.26

Security concerns specific to cloud architectures

If the third-party provider offers cloud services, rather than simple EHR hosting, then there are specific privacy and security issues that must be addressed in addition to those listed above.27–29 Many of the cloud-specific issues relate to multitenancy, which refers to cloud architectural designs that allow multiple customers to share infrastructure, services, and applications in order to enable the economies of scale and operational efficiency. Degrees of isolation can range from the entire data center, to the physical server, to a virtual server, to an application, a database, a database table, or to data elements (ordered from most to least isolated). Generally, the higher the degree of isolation between different customers' assets that a cloud architecture offers, the higher the cost.30 In the case of EHR, a high degree of isolation should be used to ensure that ePHI is not commingled with that of other patients or cloud clients, since commingling complicates data security, data destruction, encryption, and geo-location restrictions. Some of the security concerns relating to multitenancy for cloud-based EHRs could be ameliorated by exploiting the ‘community clouds’ design, so computing resources are only utilized by EHR systems. The cloud provider could then apply HIPAA-compliant data management and disposal techniques to all the clients in its EHR cloud community.

Approaches to the problems arising from multitenancy and other cloud-specific problems like encryption key management are detailed in the Cloud Security Alliance's Guidance.9 Much of the CSA's Guidance focuses on ensuring that the client understands the cloud provider's security controls, confirming that they are transparent, consistent with and supportive of the cloud client's own security framework, and defining contractual responsibilities and liabilities with a detailed business associate contract.

Business associate contract

Contracts between EHR data owners and cloud providers should stipulate compliance requirements, service levels, and legal liability.31 Federal law requires that third parties handling PHI enter into a ‘Business Associate Contract’ with the client, stipulating that they will adhere to Privacy Rule guidelines.32 33 As such the contract must specify that the cloud provider will not use or disclose PHI other than permitted or required by the contract or by law, use appropriate safeguards, report illegal use or disclosure of PHI, document its internal practices, books, and records relating to the use PHI, agree to turn this documentation over to the HHS Secretary if requested, and return or destroy all PHI upon termination of the contract.

The contract should also detail service levels, including which security controls of the entire EHR system are the responsibility of the client versus the provider, what security metrics the provider must meet, and how performance will be audited. The contracts should include constraints on how the provider's business associates will handle the client's data, procedures for electronic discovery and other litigation activities, and limitations on the geographic locations where data and backups can be stored.34 The provider should detail its incident detection and response plan, and a formal arrangement for return or disposal of the client's data and other assets upon termination of the business relationship with the provider.

The contract with the cloud provider should also establish legal liability for breaches. Since liability assignment can be contentious and the negotiations complicated, the HITECH Act of 2009 clarified the responsibility for issues relating to misuse of PHI by business associates. Federal law privacy and security provisions that previously applied only to covered entities have been also assigned to business associates. Business associates now have both contractual and HIPAA liability, and are subject to mandatory periodic audits by the Office of Civil Rights.35 Civil and criminal liability now extends to business associates for violations of HIPAA and HITECH security provisions. The CSA recommends that cloud clients negotiate penalties payable by providers in the case of a breach

The federal incentives in the HITECH Act constitute a strong temptation for healthcare groups to enroll in online EHR applications that offer rapid, low-cost startups like those offered by cloud providers. Lists of their security features and claims of HIPAA compliance by online EHR providers are comforting, but do nothing to alleviate practitioners from liability for damages resulting from compromised patient privacy. A worst case scenario for the healthcare provider could result by clicking through a series of friendly EHR sign-up screens and unwitting agreeing to release the provider from all financial responsibility for a security breach. Far better for the EHR client to have legal counsel negotiate a detailed, meaningful business associate contract with the cloud provider as described by the CSA before any ePHI is sent.

The other side of clouds

Beyond security there are other issues that must be examined before migrating to the cloud platform. An economic analysis should be conducted to ensure net savings are not overestimated, especially after considering potential hidden costs.30 Some of these could include legal fees for writing contracts and defending disputes with the cloud provider, salaries of security staff to monitor the provider's performance and compliance, costs of in-house IT support for custom-built PAAS applications, and the expense of data migration at the beginning and end of the contract's lifetime. There are also concerns about the maturity of the service model itself, and whether it is compatible with the high standards that must be maintained in a complex and sophisticated IT environment like that found in healthcare.36 37

Conclusions

Traditional in-house EHR applications are hampered by many unsatisfactory features that could be improved by re-designing them with modern computing architectures. EHR hosting by cloud computing providers could potentially promote acquisition and modification of sophisticated EHR applications through improved efficiency and pricing plans. Implementation of the privacy and security standards that are currently under development within the cloud community, including business associate contracts that specify auditable, enforceable performance metrics and sharing of liabilities, should allow such a system to achieve compliance with federal privacy and security regulations. By enabling easy adoption of feature-rich EHR systems, modern IT architectures can facilitate the federal government's expressed goals of enhancing patients' access to their medical records, improving data exchange, and reducing healthcare costs.

Footnotes

  • Competing interests Yes, I will upload an HREF http://www.icmje.org/coi_disclosure.pdf - ICMJE conflicts of interest form for each author of this manuscript.

  • Provenance and peer review Not commissioned; externally peer reviewed.

References

No Related Web Pages

Related Article

Free Sample

This recent issue is free to all users to allow everyone the opportunity to see the full scope and typical content of JAMIA.
View free sample issue >>

Access policy for JAMIA

All content published in JAMIA is deposited with PubMed Central by the publisher with a 12 month embargo. Authors/funders may pay an Open Access fee of $2,000 to make the article free on the JAMIA website and PMC immediately on publication.

All content older than 12 months is freely available on this website.

AMIA members can log in with their JAMIA user name (email address) and password or via the AMIA website.