What is HIPAA?

什么是HIPAA？

Health Insurance Portability and Accountability Act of 1996(HIPAA), is a law which provides standard to handle patient data and protected health information (PHI). HIPAA regulations are divided into several rules like- Privacy, Security, Transaction & Codes, Identifiers, Enforcement, Breach Notification, Omnibus final rule.

1996年的《健康保险携带与责任法案》(HIPAA)是一项法律，为处理患者数据和受保护的健康信息(PHI)提供了标准。 HIPAA规则分为几个规则，例如-隐私，安全，交易和代码，标识符，执行，违约通知，综合最终规则。

HIPAA Security rules provides guidance to protect individually identifiable health information which a system creates, receives, maintains, or transmits in electronic form. This information is called “electronic protected health information” (e-PHI). The Security Rule does not apply to PHI transmitted orally or in writing.

HIPAA安全规则提供了指导，以保护系统以电子形式创建，接收，维护或传输的个人可识别健康信息。 此信息称为“电子保护健康信息”(e-PHI)。 安全规则不适用于以口头或书面形式传送的PHI。

Any service which deals with medical data of a person, needs to be HIPAA compliant. The service needs to follow HIPAA guidance, at various layer from the frontend to the persistence storage.

处理个人医疗数据的任何服务都必须符合HIPAA。 该服务需要遵循从前端到持久性存储的各个层次的HIPAA指导。

In this article, I will be covering the HIPAA security rules and steps needed for a service to be HIPAA compliant. This is based on my experience in building scalable and resilient HIPAA complaint service at Walmart. Most of these practices are followed to build HIPAA compliant services at Walmart.

在本文中，我将介绍HIPAA安全规则和服务符合HIPAA所需的步骤。 这是基于我在沃尔玛建立可扩展且具有弹性的HIPAA投诉服务的经验。 遵循这些实践中的大多数，在沃尔玛构建符合HIPAA要求的服务。

HIPAA合规性要求是什么？ (What are the HIPAA Compliance requirements?)

A service intending to be HIPAA compliant will need to adhere to certain standards in order to be HIPAA compliant. These standards can be broadly categorized into 4 areas.

打算符合HIPAA的服务将需要遵守某些标准才能符合HIPAA。 这些标准可以大致分为4个领域。

1.诚信 (1. Integrity)

The whole idea of this rule is to make sure that data or information is not compromised or destroyed in an unauthorized manner. Integrity of data can be compromised by accidental or intentional changes. Due to technical issues like Hard Disk crash data can be lost. Similarly data integrity issues can arise by intentional or unintentional incorrect data modification.

该规则的整体思想是确保不会以未经授权的方式破坏或破坏数据或信息。 数据完整性可能会因意外或有意更改而受到影响。 由于诸如硬盘之类的技术问题，可能会丢失数据。 同样，有意或无意的不正确数据修改也可能引起数据完整性问题。

In order to avoid data integrity issues, systems must follow the below principles.

为了避免数据完整性问题，系统必须遵循以下原则。

·认证 (· Authentication)

Any person who needs to access ePHI data be it a customer or a developer must be authenticated. Authentication needs to be followed at frontend, backend, database and server layer.

任何需要访问ePHI数据的人，无论是客户还是开发人员，都必须经过身份验证。 需要在前端，后端，数据库和服务器层进行身份验证。

From the frontend (web pages, native or hybrid mobile apps) before accessing any ePHI info, the user should be asked to verify his identity. For users who are not logged in, only non ePHI information should be presented.

在访问任何ePHI信息之前，应从前端(网页，本机或混合移动应用程序)开始，要求用户验证其身份。 对于未登录的用户，仅应显示非ePHI信息。

In the backend systems, calls requesting for ePHI info should be verified for authentication headers. In case the authentication token is expired or compromised an appropriate authentication failure request should be sent in the response.

在后端系统中，应验证请求ePHI信息的呼叫的身份验证头。 如果身份验证令牌过期或受到破坏，则应在响应中发送适当的身份验证失败请求。

At Server/database layer only authorized user should be allowed to access data. The server and database access should be controlled by centralized AD or a security group, so that only verified users can access data. Shared accounts should be avoided, as these can be misused by developers. Ideally developers should be provided read-only access, so that they don’t accidentally modify or delete any data. Modification of data should be done by a process or an application.

在服务器/数据库层，仅应允许授权用户访问数据。 服务器和数据库访问应由集中的AD或安全组控制，以便只有经过验证的用户才能访问数据。 应避免使用共享帐户，因为开发人员可能会滥用这些帐户。 理想情况下，应该为开发人员提供只读访问权限，以便他们不会意外修改或删除任何数据。 数据修改应由流程或应用程序完成。

A password-based authentication can sometimes be compromised, so ideally, we should have a secondary authentication like KBA/PIN or a Multi factor authentication. This will provide additional security to the system.

基于密码的身份验证有时可能会受到影响，因此理想情况下，我们应该具有辅助身份验证，例如KBA / PIN或多因素身份验证。 这将为系统提供额外的安全性。

·服务的高可用性 (· High Availability of Services)

We should try to avoid any downtime of services, which will lead to a loss of access to ePHI data. We should have multiple instances of the service is running across multiple nodes, so that even if one node goes down, other nodes can serve the request. A multi data center setup is preferred, as it will ensure service availability even if there is a data center disaster. All dependent databases/caching layers should be designed for High Availability.

我们应尽量避免任何服务中断，这将导致无法访问ePHI数据。 我们应该有跨多个节点运行的服务的多个实例，以便即使一个节点发生故障，其他节点也可以处理请求。 首选多数据中心设置，因为即使发生数据中心灾难，它也可以确保服务可用性。 所有相关数据库/缓存层均应设计为具有高可用性。

In order to avoid any unwanted loss of data, ePHI data should be replicated across multiple replicas. Multi geography DC setup of the replicated data will ensure, the data is not lost in case of a natural calamity at one geography.

为了避免任何不必要的数据丢失，应在多个副本之间复制ePHI数据。 复制数据的多地理DC设置将确保在一个地理区域发生自然灾害的情况下不会丢失数据。

2.访问控制 (2. Access Control)

Access control fundamentally deals with providing the minimum required information to the right user. Any data which does not belong to a particular user, should not be provided to him at any point of time. Similarly, developers and admins should have access to only minimum necessary subset of data.

访问控制从根本上处理为正确的用户提供最少的信息。 不属于特定用户的任何数据都不应在任何时间提供给他。 同样，开发人员和管理员应只能访问最少的必要数据子集。

As a first step we should create different privilege groups, which broadly covers all the use cases of an application and then selectively place users in those groups. By default, users should be placed on a group which has minimum rights on the application. Necessary due diligence should be done while placing a user, in a highly privileged group.

第一步，我们应该创建不同的特权组，该特权组广泛涵盖应用程序的所有用例，然后有选择地将用户置于这些组中。 默认情况下，应将用户置于对应用程序具有最小权限的组中。 将用户放入一个特权较高的组时，应进行必要的尽职调查。

Access control must be in place for both frontend and backend. At the frontend different user experience can be created based on the role of a user. From the backend side APIs should only be accessed based on the role of a user. At the database layer view-based access control can be provided, to restrict everybody accessing all data.

前端和后端都必须有访问控制。 在前端，可以根据用户角色创建不同的用户体验。 从后端方只能根据用户角色访问API。 在数据库层，可以提供基于视图的访问控制，以限制每个人访问所有数据。

HIPAA also mandates, below specifications for adhering to Access Control standards.

HIPAA还要求在遵循规范的情况下遵守访问控制标准。

·唯一的用户标识 (· Unique User Identification)

Any user who accesses the ePHI information should be uniquely identifiable. We can use the user-id, email-id, customer-id or any predefined identifier for this purpose. Unique Identifier helps track all actions performed by the user in a particular session.

任何访问ePHI信息的用户都应该是唯一可识别的。 为此，我们可以使用用户ID，电子邮件ID，客户ID或任何预定义的标识符。 唯一标识符有助于跟踪用户在特定会话中执行的所有操作。

If the request spans across multiple micro services, and distributed tracing is enabled, in that case there should be a mapping between the distributed tracing id and the unique identifier for the user.

如果请求跨越多个微服务，并且启用了分布式跟踪，则在那种情况下，分布式跟踪ID和用户的唯一标识符之间应该存在映射。

·紧急通道程序 (· Emergency Access Procedure)

In case of an emergency or an unforeseen outage the system a contingency plan must be in place to provide the ePHI information. Disaster recovery plans for each component must be in place, in order to avoid system unavailability. If this requires a manual intervention, then only required users should be provided access to perform those tasks.

如果发生紧急情况或不可预见的系统中断，则必须制定应急计划以提供ePHI信息。 必须制定每个组件的灾难恢复计划，以避免系统不可用。 如果这需要手动干预，则应仅向所需用户提供执行这些任务的权限。

·自动注销 (· Automatic Logoff)

Any user who logs into the application, should have a default inactive session timeout. If the user is inactive for that duration, user should be forced to perform an authentication on the subsequent calls. Both frontend and backend systems should adhere to this rule.

任何登录到该应用程序的用户都应具有默认的非活动会话超时。 如果用户在此期间处于非活动状态，则应强制用户对后续呼叫执行身份验证。 前端和后端系统都应遵守此规则。

·加密和解密 (· Encryption and Decryption)

The ePHI data should be encrypted during transit and also during persistence.

ePHI数据应在传输过程中以及在持久性过程中进行加密。

For the encryption during transit https protocol should be used. SSL Offloading should not be done at Load Balancer layer. If it is done, then the data should be re-encrypted from the load balancer to the app server.

为了在传输过程中进行加密，应使用https协议。 SSL卸载不应在负载平衡器层进行。 如果完成，则应将数据从负载均衡器重新加密到应用服务器。

During persistence, if the database provides a way to encrypt data before writing to storage, that should be enabled. This will ensure data is encrypted even at the backup disks and no unauthorized user can read ePHI data.

在持久性期间，如果数据库提供了一种在写入存储之前对数据进行加密的方法，则应启用该方法。 这将确保即使在备份磁盘上也对数据进行加密，并且任何未经授权的用户都无法读取ePHI数据。

If database does not provide an inbuilt encryption feature, then the same can be achieved through application layer encryption. Data can be encrypted before writing to the database and can be decrypted before presenting to the user. The encryption key of encryption algorithm should be changed after a certain period.

如果数据库不提供内置的加密功能，则可以通过应用程序层加密来实现相同的功能。 数据可以在写入数据库之前被加密，并且可以在呈现给用户之前被解密。 一定时间后应更改加密算法的加密密钥。

While writing logs any ePHI data should either be masked or encrypted. Even at the REST API URIs, if any ePHI information is preset, then that should be encrypted, so that it cannot be read while data transmission.

在写日志时，任何ePHI数据都应被屏蔽或加密。 即使在REST API URI处，如果预先设置了任何ePHI信息，也应该对其进行加密，以便在数据传输时无法读取它。

·数据保留 (· Data Retention)

HIPAA requires data retention for at least 6-7 years from the date of creation or last accessed, whichever happens to be latter.

HIPAA要求从创建之日或上次访问之日起至少保留6-7年的数据，以较晚者为准。

The data in the database should be persisted with inbuilt encryption. Even application access logs and system audit logs should be retained in order to identify users whose data has been compromised.

数据库中的数据应使用内置加密来保留。 甚至应保留应用程序访问日志和系统审核日志，以识别其数据已被泄露的用户。

If there are multiple HIPAA complaint services, we can think of building a dedicated system, which maintains the access and audit logs. At Walmart we have a centralized system, which retains all the application access and system audit logs. This helps us in monitoring and identifying compromised users’ info in case of a HIPAA breach.

如果有多个HIPAA投诉服务，我们可以考虑构建一个专用系统来维护访问和审核日志。 在沃尔玛，我们有一个集中式系统，该系统保留所有应用程序访问和系统审核日志。 这有助于我们在违反HIPAA的情况下监视和识别受感染用户的信息。

3.审计控制 (3. Audit Control)

Audit control requires system to have an audit report which will be helpful in analyzing system activity in case of a HIPAA breach. Audit/System log should be captured for all application servers, database, caching layer or any other components used in a HIPAA complaint service.

审核控制要求系统具有审核报告，这将有助于在发生HIPAA违规情况时分析系统活动。 应该为HIPAA投诉服务中使用的所有应用程序服务器，数据库，缓存层或任何其他组件捕获审核/系统日志。

In order to achieve this, we can decide on a strategy of replicating audit logs to a centralized log server at a regular interval. Even certain application access logs should be replicated to a log server. Then various reporting and monitoring jobs can run on this centralized data on a regular interval. In case of a HIPAA breach, this data can be used to track the users who were accessing the system during that time, also we can find out the users whose data was compromised.

为了实现这一点，我们可以决定定期将审核日志复制到集中式日志服务器的策略。 甚至某些应用程序访问日志也应复制到日志服务器。 然后，可以定期在此集中数据上运行各种报告和监视作业。 万一发生HIPAA违规，此数据可用于跟踪在此期间访问系统的用户，我们还可以找出其数据已被泄露的用户。

4.传输安全 (4. Transmission Security)

Any ePHI data transmitted over network should be safeguarded from unauthorized interception of information.

应保护通过网络传输的任何ePHI数据免遭未经授权的信息拦截。

Any emails or files which contains ePHI information should be encrypted before sending to clients. Https should be used to connect from client to server. If the body of the email or the attachment has ePHI information, that should be encrypted before sending the email.

任何包含ePHI信息的电子邮件或文件都应先加密，然后再发送给客户端。 Https应该用于从客户端连接到服务器。 如果电子邮件或附件的正文中包含ePHI信息，则应在发送电子邮件之前对其进行加密。

Many of the public email providers are not HIPAA compliant, so while sending HIPAA data over email, only a provider which is HIPAA compliant should be chosen.

许多公共电子邮件提供商不符合HIPAA，因此在通过电子邮件发送HIPAA数据时，仅应选择符合HIPAA的提供商。