The A to Z Technical Guide to Meet HIPAA Compliance

Our world has completely changed after the first computer was presented. IT solutions penetrated every aspect of our lives and altered them forever. With computers and other mobile devices, our life has become increasingly dynamic and fast. And this dynamic lifestyle requires timely and groundbreaking solutions to cope with the challenges of tomorrow.

This tech explosion has created a new niche in IT and Health industries – Healthtech. Health information technology incorporates the healthcare, information technology and business. The computerized healthcare information systems are expected to improve the management of health information, refine medical care, lower costs, increase efficiency, reduce mistakes, and increase security in the process of health information exchange between consumers, payers, providers, doctors, and patients. All these aspects together are significantly improving patient’s treatment, while also optimizing reimbursement for healthcare organizations.

How Digital Technology is Changing Healthcare

Due to revolution in Healthcare, medical professionals and other medical staff have more freedom and abilities when they do their practice online (e.g. use of electronic prescriptions, schedule appointments, and remote medicine). With the mobile devices they can do even more by creating electronic patient’s visits and notes. All these are trendy today and are critical for building contemporary solutions in the growing Healthtech industry.

The next great swap is that health information systems significantly change the collection and processing of the patient’s medical information. Today it is extremely important for medical staff to collect patient’s records, process them in readable format, and have them available on the different devices. It ensures more efficient and accurate care.
While all of these electronic features provide increased efficiency and mobility, from the other side they dramatically enlarge the healthcare data security risk. It’s common truths that your medical records shouldn’t be something that anyone can easily access and use for any purpose. If a patient feels unconfident to share his/her private information with a doctor as there are no assurances that it will stay private it can cause ineffective treatment.

As the result, to protect patients, their medical records and other sensitive information that is used in the care plans by doctors, hospitals and other healthcare entities, Department of Health and Human Services (HHS) designed The Health Insurance Portability and Accountability Act (HIPAA).

HIPAA is the official compliance document that establishes the standards a healthcare organization has to meet in order to better protect patient privacy. And every health information system under HIPAA must be appropriately designed to follow these rules in order to ensure the proper level of data protection.

Unfortunately, solving risks of electronic patient data is not always a top priority and many organizations don’t pay enough attention in order to meet these standards. And this is happening even nowadays when healthcare data breaches are on the rise and when it’s more important than ever for healthcare organizations to be proactive and think about how to implement HIPAA in EMR software.

The other thing that holds back HIPAA implementation is that many of us have read the HIPAA Security Rule Standards and Implementation Specifications but don’t fully understand how to execute the technical implementation of HIPAA.

So let’s break this down together.
In this article, you will find how to meet HIPAA compliance requirements and the provisions within the Act.

HIPAA Compliance Requirements

HIPAA requirements point out that technology teams have to keep Electronic Protected Health Information (ePHI) secure. Although, while HIPAA compliance requirements tell organizations that they must keep ePHI secure, the rule doesn’t obviously say how to do that.

We can say that HIPAA is an uncommon law: it makes a lot of recommendations “addressable” and only a few “required” items. What makes it more challenging is that in order to meet HIPAA compliance, EMR software development teams must take into account several aspects of the rules and evaluate if they can be within compliance, and, at the same time, empower the customers (hospitals, doctors, etc.) to meet their needs.

Basically to state that your EHR solution is HIPAA compliant you need to follow HIPAA Compliance Requirements Checklist including:

1. HIPAA Security Rules
2. HIPAA Privacy Rules
3. HIPAA Breach Notification Rules
4. HIPAA Enforcement Rules

Now, let’s move directly to the implementation of HIPAA compliance, its policies and procedures named as safeguards.

If you are a technical guy who is developing an EMR/EHR system you will need to focus on the Physical and Technical Safeguards that are described in the HIPAA Security Rule Standards. These two safeguards contain the majority of your TODO list.

Effectively every safeguard of HIPAA is “required” unless there is a justifiable reason not to implement the safeguard or an appropriate alternative to the safeguard is implemented that achieves the same objective.

The HIPAA Security Rule outlines specific regulations that must be applied in order to prevent breaches in the process of the creation, sharing, storage, and disposal of ePHI. And what’s important this rule applies to any system that has access (create, read, write, or modify) to the confidential patient data.

o let’s take a closer look at the mentioned safeguards.

Physical Safeguards (45 CFR 164.310)

Physical Safeguards is a guide to policies and procedures creation that aims to protect electronic systems and ePHI from potential dangers and unauthorized intervention. Each of the developed standards has to be documented as a written policy and accessible to all employees so they would understand the potential risks and necessary steps that should be taken to maintain patients’ privacy. These standards also determine how workstations and mobile devices should be secured against unauthorized access.

Standard 164.310 (a)(1): Facility Access Controls

• Procedures should be in place to establish Contingency Operations ((a) (2)(I)) plans that allow access to the physical office and stored data even during the emergency.
• A Facility Security Plan ((a) (2)(II)) needs to be well established to protect equipment that stores ePHI from unauthorized access and theft.
• Access Controls and Validation Procedures ((a) (2)(II)) should operate with such aspects as when, how and to whom access to equipment is granted.
• Maintenance Records ((a) (2)(IV)) should document modifications to the physical facility.

Standard 164.310 (b): Workstation Use

• Workstation Use policies need to specify the use, performance, and physical attributes of equipment and workstations where ePHI is accessed.

Standard 164.310 (c): Workstation Security

• Workstation Security should entail physical safeguards that govern who can access workstations and equipment where ePHI is accessible.

Standard 164.310 (d)(1): Device and Media Controls

• Disposal ((d)(1) (2)(I)) of hardware or equipment where ePHI is stored needs to be strictly managed.
• Policies should be in place to determine how and when ePHI should be removed from equipment or electronic media before Re-use((d)(1) (2)(II)).
• Hardware and equipment that has access to ePHI should be Accountable ((d)(1) (2)(III)) and tracked.
• Data Backup and Storage ((d)(1) (2)(IV)) procedures should entail the creation of exact copies of ePHI.

Technical Safeguards (45 CFR 164.312)

Technical Safeguards cover the technology that is used to protect ePHI and provide access to the data. They include things like encryption and decryption (NIST standards), audit controls, emergency access procedures, HIPAA file storage and more.

Standard 164.312 (a)(1): Access Control

• Employees should be provided with Unique User Identification ((a)(1) (2)(I)) in the form of a username or ID number that can be used to identify the person.
• Procedures should be in place that determines Emergency Access ((a)(1) (2)(II)) protocols and authorization.
• Systems that store ePHI should be provided with an Automatic Logoff ((a)(1) (2)(III)) function after inactivity.
• Encryption and Decryption ((a)(1) (2)(IV)) methods should be built into systems that store ePHI.

Standard 164.312 (b): Audit Controls

• Audit Controls must regularly monitor and store the system usage and ePHI access.

Standard 164.312 (c)(1): Integrity

• In order to ensure that ePHI hasn’t been accessed, altered or destroyed without authorization, a Mechanism to Authenticate ePHI should be built into the system.

Standard 164.312 (d): Person or Entity Authentication

• Person or Entity Authentication needs to be in place to ensure that only authorized users have access to appropriate data and ePHI.

Standard 164.312 (e)(1): Transmission Security

• Any ePHI that is transmitted electronically needs to be protected by Integrity Controls ((e)(1) (2)(I)) to ensure that it hasn’t been modified in the process.
• Any stored ePHI should be Encrypted ((e)(1) (2)(II)).

Now, as we know the main specific regulations that must be applied in order to prevent breaches let’s move to the implementation phase.

How to Implement HIPAA Compliance Plan into Practice

There is a large number of steps that should be done in order to turn your healthtech solution into a HIPAA compliant one. The scope of your work will depend upon the features you are going to develop within your solution and the way private health information is transmitted and presented.

Below are a few common cases that you may face during the process of your own HIPAA compliance implementation plan.

1. Implement “Access Control” requirements

Modern healthcare solutions are large systems that manage data with plenty of users accessing health data for various purposes within different organizations. And despite on significant progress in technological solutions in the field of information access control, the implementation of “Access Control” still remains a challenge due to the complex nature of data access: for diverse purposes and from the different devices. And, usually, users are granted wider access privileges in order to facilitate timely and effective treatment.

To implement access control you need to focus on two fundamental HIPAA requirements:

• One is assigning a unique user identificator (can be name or number) for identifying and tracking user identity. This is a fundamental aspect of any login and authentication method.
• The other is establishing procedures for gaining access to electronic health information.

And these requirements can be performed using Role Based Access Control, User Based Access Control etc.

Role Based Access Control (RBAC) can be implemented in case when you can strictly divide users into groups with a certain role and give each group appropriate access rights. Additionally to RBAC, we can implement more flexible access management mechanism – User Based Access Control (UBAC).

UBAC represents a list of privileges that can be assigned to a user and determines if the certain user has access to some piece of patient’s information, as well as what operations are allowed to do with that information. What’s more, your implementation can control access to the specific entity or specific URL in case of a web-based SaaS solution.

In order to implement a simple UBAC, you need to have at least two tables (which could be named ‘privileges’ and ‘user_privileges’). These tables can be created in relation/non-relation database or any other storage that is used.

Quick tip: The “privileges” – is a table where the specific privileges will be stored. The minimum of needed fields in ‘privileges’ table are:

• privilege_id – ID of privilege;
• privilege_access_to – contains name of entity/method or URL that should be under privileged access.

Another table is “user_privileges”. In this table, the privileges given to an appropriate user will stored. This table can have the following fields:

• user_id;
• privilege_id.

Here is an example of the possible implementation:

“Privileges” table

“User_privileges” table

The mentioned above example describes the case when the user #1 is granted the privilege to create, edit and delete appointments and user #2 can only view it. And the scheme described is the simplest way to ensure User Based Access Control feature in your software.

2. Implement “Person or Entity Authentication” requirements

Another essential component is Person or Entity Authentication, which is critical for every healthcare organization that aims to meet HIPAA compliance. In few words, these requirements cause to be necessary procedures that verify that the person who is asking the access to ePHI is the one who has appropriate privileges.

Although, it’s under discussion whether system must provide the strongest person or entity verification. The objective of the Person or Entity Authentication specification is to implement procedures to verify that a person is authorized to access the ePHI. These procedures can be implemented with the following four verification features proposed by HHS:

1. “biometric” identification system;
2. “password” system;
3. “personal identification number” (PIN);
4. “telephone callback” or a “token” system that uses a physical device for user authentication.

In these four rules, HHS names only general requirements and doesn’t stipulate the specific methods. Also, on the one hand, it provides the covered entities and business associates with the freedom in selecting and choosing the preferred authentication methods. (Although, this freedom doesn’t mean that the method you choose will ensure compliance or avoid serious risks and vulnerabilities.) And on the other hand, it leaves healthcare executives without specific guidance. So here are some tips from our developers that will help you during the Person or Entity Authentication implementation.

“Password” system

To implement password authentication you should ensure that the password entered by user meets the following guidelines:

• The password should be complex utilizing a combination of letters, numbers, and special characters and be between six and 10 characters or more so that it couldn’t be easily guessed.
• The password should never be based on the login name, actual name or any dictionary name.
• The password should be changed at least every six months or whenever the password becomes known to the other person. And current or previous passwords could not be reused.

The above guidelines can be implemented on different levels of your system. For example, the validation process of whether the password meets the requirements can be implemented on the register screen. The logic will validate the entered password and won’t pass users with unsecured passwords.

In addition, you can implement functionality that will control the password expiration. This logic will prevent users from logging in with an expired password and force them to change it. For example, user’s record in DB will have “password_expired_on” field. And when the date in password_expired_on will be greater or equal than the current date user will be prompted to change the current password.

In fact, when considering authentication solutions it is important to weigh the criticality and sensitivity of the protected information. Using a simultaneous combination of authentication mechanisms (called multifactor authentication) can help you mitigate the risks of bypassing authentication controls.

As an example of this approach can be the request of a fingerprint scan (biometric) with the further entering of a password. With this approach, a compromised password would be rendered useless since a fingerprint is required and a forged fingerprint alone would not achieve an attacker’s goals in case the password wasn’t right. Although this approach provides a high authentication level, at the same time you should care about the accordance of the level of assurance with the associated financial and performance costs.

3. Implement the “Transmission Security” requirements

This policy applies to ePHI while the data is transmitted across the electronic communications network, wireless networks, from tier to tier within an application, across wired or wireless connections. It applies not only to the transactions adopted under HIPAA, but to all individual health information that is maintained or transmitted. The security standard doesn’t require specific technologies to be used. Technology and solutions can vary from business to business, depending on the needs of an appropriate solution.

In our case, the first step is to ensure that your web-based solution is secured with an SSL certificate  (Secure Sockets Layer), so all input/output traffic is encrypted. In fact, each page that collects or displays protected health information (PHI), or which is used for user login, or which transmits authorization cookies, etc. must be encrypted by SSL. And what’s important, such pages can’t have an alternative insecure version of themselves; pages that people can access insecurely.

What’s more, use of SSL can meet HIPAA’s data transmission security requirements in terms of communication between the end user and your web solution. However, your SSL configuration must be strong enough to prevent encryption methods that are “too weak”.

Quick note: If you need to transfer patient data to and from payers or other medical organizations don’t use public FTP (File Transfer Protocol). For this purpose, the SFTP protocol can be used.

And don’t forget that with expected increase in the use of electronic transactions in healthcare, such as e-prescribing, and electronic communications via email, messaging between a physician and a patient, most covered entities will have a need in encryption implementation.

4. Disposal as a Requirement

“Disposal” means that the data can be permanently disposed of when needed. Yet, you will have to consider all the places where data can be backuped and archived, and you will need to ensure that all of those backups will expire and disappear.

Every place where the information is stored should be backuped and the copy of your data should be saved.

Of course, it helps if the data is encrypted in the backup. But if the backup is there and the keys to open the data exist, then it is not really “disposed of”. It is up to you to ensure that the hard drives containing ePHI are properly disposed of when you are no longer using them and determine how far you need to go to ensure data disposal in order to be HIPAA compliant.

5. The Data Backup and Storage Implementation

The next point that is important for you, when you develop a system that should follow the HIPAA compliance, is to look over the backup services. As a developer or product owner, you should understand how your solution will benefit from backup services in case of a disaster.

What you need to do is to ensure that all ePHI that are collected, stored and used within your solution are backuped. The reserved copy should be stored in a secure environment and according to the best practices, it should have several backups that are stored in different locations.

This approach helps to avoid data loss in case when something unpredictable happens with data in one physical location (for example, earthquake or fire in a datacenter). If you consider this moment you will be able to restore data from other locations.

Also, the copy should be readily retrievable if the hardware or electronic media is damaged. And don’t forget that scale and size of the data has an impact on the manner in which the implementation is carried out.

Nowadays this is not even a question of “why”. You must backup all your data as in today’s dynamic world server crash or database corruption would result in a significant data loss. Even if you will be able to recover data from yesterday’s backup.

One of the best practices of using this technique is to have the files’ recovery strategy as backup is useless if you can’t restore your fails. The backup and recovery functionality/scripts should be periodically tested and revised according to the contingency plans.

If you still hesitate here are some advantages of using a data backup service:

1. Your data is stored outside of the main system’s storage. This lets you breathe easy in the case of blackouts and malware.
2. Automatic data backup is a relief because you don’t have to remember to do this manually time to time. Backup is usually done overnight.

What you need to remember is that most of the web hosts provide this service only for information that is stored on their servers. If your web application sends information outside you must take care of this data so it would be also backuped or archived, and check whether those backups are available and accessible only to authorized users.

Please notice that ePHIs stored in backups must also be protected according to HIPAA compliance standards (security, authorization controls, etc.). And what’s important having a robust data backup and recovery solution in place may serve as the last line of defense for many companies striving to be compliant with the laws.

6. Integrity as a Feature

Unless the information that you collect and store are encrypted and/or digitally signed, there is no way to prevent it from being tampered with or to verify if tampering has happened. It’s up to your organization to determine if tamper-proofing of your data is needed and how to accomplish that in an optimal way. Generally, using PGP, SSL, or AES encryption can accomplish this very nicely and also address the next point.

7. Implement Encryption and Decryption 

In accordance with §164.306, a covered entity must implement a mechanism to encrypt/decrypt ePHI. So let’s check how we can do this in our healthcare application.

While HIPAA addresses the security and privacy of ePHI as a policy and procedure-oriented approach with no strict parameters, it is your responsibility to determine which type of technology to use. And when it comes to the question of sensitive data protection, encryption is typically considered to be the best practice. In short, data encryption involves the conversion of data into indecipherable symbols with the help of complex algorithms that require a security key to convert the data back into its original form and is very important in cases when data may be stored or backuped in locations available to users besides your staff.

If data encryption is necessary then you have to ensure that all collected and stored ePHIs are encrypted and they can only be accessed/decrypted by the person with the appropriate keys. This makes your data secure and protects it from unauthorized users (unless your special keys are stolen).

Other methods that can help you determine if you need encryption include completing a HIPAA risk assessment, performing a gap analysis to find out what you’re missing in your current security environment, and developing and documenting solutions to become more resilient to the risk of a data breach.

Here are few recommendations that will help you implement encryption:

• In order to protect ePHI and prevent a data breach, it’s a good practice to store the confidential data in a secure environment with the proper physical and network security.
• If a mobile device needs to store confidential information, file/folder level encryption and full disk encryption are acceptable to keep data safe.
• Don’t store the password to the PGP or S/MIME key in your system.
• Recommend your system visitors to enter the password and use cookies to keep the password from page to page.
• If you store ePHI in a MySQL database you should ensure that the password to that database isn’t stored in your system.
• If you need to implement even more security stages you can encrypt the data before saving it in the database.

Data can be encrypted with a single security key access or with separate keys for encryption and decryption (symmetric and asymmetric data encryption) and the level of security can be adjusted as appropriate based on the sensitivity of the data.

8. Implement Audit Controls

Covered entities are required to have in place audit controls to monitor activity on their electronic systems that contain or use electronically protected health information. In addition, they have to have a policy for regularly monitoring and reviewing of audit records to ensure that activity on those electronic systems is appropriate. Such activities should include login and logout, file accesses, updates, edits, and any security incidents.

In terms of audit control requirements, facilities must implement hardware, software and/or procedural mechanisms that record and examine activities within the information systems that contain or use ePHI.

Monitoring and reviewing of audit trails must be as close to real-time as possible so they would stay useful. As you all know, there is no benefit in discovering an outdated problem.

Also, what you need to remember is that outcomes of the covered entity’s risk analysis will be based on how the covered entity sets its policies and procedures. If a security incident occurs failure to exercise this audit control standard may be the proof of an inquiry that a covered entity had the capability to know what was occurring but failed to exercise corrective action timely.

In order to implement the least “Audit Controls,” you can use a separate table in your database or a special log file to log all actions (create, edit, delete, view) on any ePHI.

If you choose the first way it can be an “actions_log” table with the following fields:

• user_id – ID of the user who performed the action;
• entity_name – name of the entity (table in case of DB) on which the action is performed;
• record_id – appropriate entity/table row identificator;
• action_type – type of an action (create, edit, delete or view);
• action_time – the timestamp when action has been performed.

Here is an example of this implementation:

The thing to mention is that the technical capabilities of audit controls must be available in order to review the system activity. Employees at all levels must understand how often audits will take place, how the results will be analyzed, what sanction policies will be used, and where audit information will be stored.

9. Implement Automatic Logoff

As you might know, automatic logoff implementation will require the authorized user to re-enter a password to gain access to electronic protected health information. This feature will terminate a login session after a predetermined period of inactivity which should ensure that access is still secured in cases when someone walks away from a computer or system.

As it is an addressable specification, timeout and logoff features will depend on the size of a covered entity and the degree of access to electronic information system devices. As a benchmark, you may establish a 10-minute timeout period before the logoff capability locks the device and makes information inaccessible. In case your device is in the high-traffic area, you might need to set a timeout of 2 to 3 minutes. And devices in protected areas with controlled, limited access, such as a lab or an isolated office, could have longer timeout periods.

So how to implement automatic logoff?

Well, each platform has a specific way to implement this feature. For example, if you build a Java based application that will run inside the Tomcat container you can just add few lines of code in your web.xml configuration:

<session-config>
<session-timeout>30</session-timeout>
</session-config>

Note: Timeout settings will be suggested by the risk analysis based on the size of facility, location, and accessibility of EMR system devices. The covered entity should pay particular attention to the growing use of handheld devices that can be moved from one part of a covered entity to another as it affects its timeout strategy.

More read: AWS HIPAA Compliance: Best Practices Checklist

Other HIPAA aspects

1. Emailing and messaging

Any organization that deals with protected health information must ensure that all the required physical, network, and process security measures are in place and are followed. This, of course, includes such specifications as HIPAA compliant email.
So what does it mean?

The Privacy Rule allows covered healthcare providers to communicate electronically with their patients (through e-mails) but reasonable safeguards should be in place. Further, while the Privacy Rule does not prohibit the use of unencrypted e-mail for treatment-related communications between healthcare providers and patients, other safeguards should be applied to protect privacy, such as limiting the amount or type of information disclosed through the unencrypted e-mail.

But here’s a detail: emails that contain PHI (either in the body or as an attachment) have to be encrypted only if they are sent beyond a firewalled internal server. If a healthcare organization uses emails only as an internal form of communication or has an authorization form that a person should fill and send with information being unencrypted there is no need to implement this addressable safeguard.

Another advantage is that policies and procedures put in place will help you control how mobile devices are used within your healthcare organization.

Although, surveys show that in practice many medical professionals still use personal devices to send corporate emails, which is a way for hackers to steal data for unprotected devices. In this case, secure messaging solutions prevent this. They work by maintaining ePHI on a secure database and then allowing authorized medical professionals to access the data via downloadable secure messaging apps. Communications are channeled through a secure messaging platform that has administrative controls in place to monitor the activity of the authorized personnel.

In case you struggle and don’t want to implement this feature, you need to know that this decision will have to be supported by a risk assessment and documented. But I need to mention that many healthcare organizations have reported that implementation of secure messaging feature has increased the overall productivity by streamlining communications, increasing message accountability, and accelerating response times. And by the way, according to studies conducted in HIPAA compliant medical facilities, besides higher efficiency organizations noticed a higher standard of healthcare being delivered to patients.

So, are you still hesitating?

2. HIPAA and Mobile Platforms

Mobile health apps are popular with patients for tracking and monitoring health and fitness, and wearable devices have potential to revolutionize home healthcare. They can be used in conjunction with e-visits to provide home care services to patients at a fraction of the healthcare center visits.

On the other hand, for many organizations the rise of mobile devices means simplicity and efficiency and, at the same time, these devices present serious vulnerabilities in the data security plans.

But, as you know, if mobile devices aren’t properly secured, patient data could be stolen. And unfortunately, most healthcare providers that are using mobile devices don’t place appropriate privacy and security measures to secure patient data.

More recently, since the original legislation was passed security regulations have enacted in HIPAA to account for technological changes and different working practices in the healthcare industry. One of the most significant developments in recent years has been the growth of “Bring Your Own Device” policies which resulted in the possible risks that personal mobile devices present to the integrity of ePHI.

So let’s check how the healthcare industry can embrace the future of mobile devices and remain secure.

No matter what type of technology a healthcare provider uses, he is obligated to protect PHI. If a smartphone or tablet is used to access, transmit, receive or store information, it must have certain security precautions in place. Here are a few of the most important suggestions for mobile solutions:

• Mobile devices should be individually authorized to add, modify, remove, and access PHI.
• A password/pin authentication should be implemented.
• Mobile device storage should be encrypted.
• Mobile devices should only have a specific Wi-Fi Protected Access created for mobile devices. And making your mobile app work offline will help you do that without the threat of data loss.
• Use role-based access.
• Synchronization with your server should be implemented using secured remote access.

And don’t forget that patient portals have great potential and improve the interaction between care providers and patients, and cut down the unnecessary costs while helping to improve patient outcomes. The development of HIPAA compliant mobile app, compliant storage, and compliant medical web application solutions means that healthcare providers can take advantage of the benefits of new technology without running the risks.

The Implications of HIPAA to Healthcare Organizations and Patients

The implications of HIPAA to patients are that their healthcare information is treated more sensitively and can be accessed more quickly by their healthcare providers. Electronically stored health information is now better protected than paper records ever were, and healthcare organizations that have implemented mechanisms to comply with HIPAA regulations are witnessing an improved efficiency. This manifests as a higher standard of healthcare.

On the other side, healthcare organizations are not solely concerned with the standard of healthcare they can provide to individual patients. Healthcare organizations want to increase the services they can provide, want to raise the quality of care and improve patient safety through research. However, research is restricted by HIPAA and restricted access to ePHI has the potential to slow down the rate at which improvements can be made in the healthcare industry.

There is also a price to pay for improved data security. Implementing the necessary controls to secure ePHI can carry a substantial cost. Increasing funding for compliance has the potential to actually reduce the level of patient care, while the administrative burden that HIPAA compliance policy places further shortfall of resources.

But all the negative sides are small in comparison to huge advantages and a big number of threats.

Also, if data privacy and security are not addressed the Office for Civil Rights can issue fines for non-compliance. Preventable data breaches are likely to see considerable financial penalties issued. Under the penalty structure introduced by HITECH, violations can result in fines up to $1.5 million being issued by the OCR, while lawsuits can be filed by both attorney generals and the victims of data breaches.

Yet, the high probability of healthcare organizations to become targets for cybercriminals and the exorbitant cost of addressing data breaches (issuing breach notification letters, offering credit monitoring services and covering the OCR fines)  is far in excess of the cost of achieving full compliance. And while the initial cost of investment in the necessary technical, physical and administrative safeguards to secure patient data may be high the improvements can result in cost savings over time.

Organizations that have already implemented mechanisms to comply with HIPAA have seen their employee’s workflows streamlined, time spent on playing “phone tag” is reduced, and the workforce has become more productive by allowing healthcare organizations to reinvest their savings and deliver a higher standard of healthcare to patients.

HIPAA Compliance in Short

Creating adequate safeguards does not happen overnight. While it may seem overwhelming and time-consuming at first (due to HIPAA’s complex nature), the biggest obstacle to overcome is actually getting the entire process started.

As the guardian of patient health information, it is up to each healthcare organization to learn and understand the basic features of their IT assets and medical devices, what security mechanisms are in place, and how to use them.

There are a number of actions an entity can take to make sure that their EHR systems and IT assets are secure. Such measures leverage an integrated use of data loss prevention tools, intrusion prevention, anti-malware, file integrity monitoring, robust identity management and authentication programs, role-based access, and data security solutions.

Here are some specific actions your entity should consider while aiming to protect patient information:

• Install SSL certificate and dedicated IP address for your web application so that traffic to/from it could be encrypted in transit.
• Ensure that your IT solution cannot be accessed without SSL.
• Ensure that ePHI is never publicly available –users must login to access that content.
• Ensure that users with access to ePHI are having properly granted/revoked access by your HIPAA administrators. E.g. it should not be possible for someone to sign-up and get access without explicit review.
• Ensure that users have access only to the ePHI they need and should have access to.
• Implement a two-factor authentication.
• Ensure that there are good backups of your application and its content.
• Clearly and specifically lay out the roles of everyone involved with HIPAA compliance responsibilities in your organization.
• Ensure that access to ePHI is restricted and is based on an individual’s job roles and/or responsibilities.
• Conduct an annual HIPAA security risk analysis. This can involve regularly engagement with a trusted provider that can remotely monitor and maintain your network and devices to ensure ongoing security.
• Conduct regular risk assessments to identify vulnerabilities. This will help ensure the confidentiality and integrity of protected health information. It is important to remediate any identified risks and revise policies, if necessary to minimize risk.
• Mitigate and address any risk identified during your HIPAA risk analysis including deficient security, administrative and physical controls, access to environments where ePHI is stored, and a disaster recovery plan.
• Develop privacy policies. Healthcare organizations must develop, adopt and implement privacy and security policies and procedures. They must also make sure that they are documenting all their policies and procedures, including steps to take when a breach occurs. Make sure your policies and procedures match up to the requirements of HIPAA.
• Adopt email policies. “The Office of Civil Rights does not look too kindly on organizations who haven’t established policies regarding mobile devices and email communication”.
• Require user authentication, such as passwords or PIN numbers that limit access to patient information.
• Encrypt patient information using a key that is known or available only to authorized individuals.
• Incorporate audit trails, which record who accessed your information, what changes were made, and when they were made, providing an additional layer of security.
• Implement workstation security which ensures the computer terminals that access individual health records cannot be used by unauthorized persons.
• Adopt mobile device policies. Healthcare organizations should adopt strict policies regarding the storage of protected health information on portable electronic devices, and they should regulate the removal of those electronic devices from the premises. HHS has issued guidance regarding the use of mobile devices, and healthcare organizations should be familiar with it.

In conclusion, I can say that the development of a healthcare software solution that is under HIPAA compliance is not a trivial activity. There are many things to do and a lot of them are “up to you”.  Of course, just because any item is “up to you” it doesn’t mean that you can make whatever choice you feel like. You really need to consider carefully what is necessary and appropriate to suitably protect health information and the privacy of your users based on your application and how the patient data is used and transmitted.

What We Do

• Custom Healthcare Software Development
• Mobile Apps for Patients
• Medical Data Reporting and Visualization
• Revenue Cycle Management (RCM) Solutions
• Mobile Medical Solutions for Professionals
• Privacy & Security in Healthcare
• Mobile Medical Application Development
• Patient Portals and Engagement Solutions
• Medical Practice Management Solutions
• Healthcare Web Application Development
• AWS-Cloud Healthcare Development Services
• Electronic Medical Records (EMR) Software Development

If you are ready to start this way and make your EMR system HIPAA compliant but need the technical team to support your project, feel free to call Romexsoft team who has years of experience in Healthtech software development.