A HIPAA compliant app can provide easy accessibility for users. When developed precisely, they can deliver just as much professional support as in-person doctor or practitioner visits.
However, apps containing personal patient information must follow strict HIPAA guidelines for proper, rigorous compliance. If you’re looking for help or need assistance, you should only speak with experts possessing a deep background in the creation of healthcare applications.
Before we elaborate upon developmental practices, we will drill down on HIPAA basics, look at the law, and discuss what could happen if it’s violated. Refer to the table of contents if you want to skip ahead.
Table of Contents
What is HIPAA?
HIPAA is the abbreviation for the Health Portability and Accountability Act established in 1996 by the US Congress. This act provides security provisions and data privacy to ensure protection from tampering, fraud, and misuse of medical records with the simultaneous aim of simplifying administrative tasks.
HIPAA supports American workers and their families with transferring and continuing their healthcare insurance coverage in case of job loss or transition. This act regulates the use of healthcare information on electronic billing and other processes, ensuring confidential facilitation.
What is PHI?
Protected Health Information (PHI), under US law, is any information in a medical record that can be used to identify an individual that was created in the course of providing a healthcare service e.g diagnosis or treatment. When building mobile web or mobile HIPAA compliant app, it is critical to keep this information locked down and secure.
What are the HIPAA laws?
Privacy Rule
The HIPAA Privacy Rule protects medical records and other sensitive patient health related information. This rule applies to health plans, health care clearinghouses, and health care providers that handle their payments electronically. The rule designates various safeguards to segregate vulnerable health data and set barriers to the use of patient information without their consent.
While the rule protects the user from unauthorized third-party usage, the Privacy Rule gives patients more control over their health records by granting them full access. Patients have the ability to review their own records, make copies, and inquire about any changes.
Security Rule
The HIPAA Security Rule mandates the integrity of patients’ digitally stored, protected health information by enforcing administrative safeguards that ensure confidentiality and security. The Security Rule encompasses the protections included in the Privacy Rule by addressing the technical and nontechnical safeguards that HIPAA compliant entities must execute to secure protected health information (PHI).
A HIPAA compliant app must assess their security risks; even organizations that use certified electronic health record (EHR) technology. Administrative, physical, and technical safeguards must be addressed to fully comply with the Security Rule and record all of the stated measures.
Administrative Safeguards - The administrative components are really important when implementing a HIPAA compliance program
Technical Safeguards - Technical safeguards outline what your HIPAA compliant app must do while handling PHI. There are both required and addressable elements to these safeguards.
Physical Safeguards – The Physical Safeguards really have to do with who has access to PHI data and how that access is managed. HIPAA compliant hosting companies (such as TrueVault, AWS, Firehost and Rackspace) handles much of the requirements.
Omnibus Rule
The purpose of the Omnibus Rule is to implement Health Information Technology (HIT) actions for Economic and Clinical Health Act mandates. The act is a segment of the American Recovery and Reinvestment Act of 2009 and is available for the Electronic Health Record adoption and meaningful use incentives.
The Omnibus Rule merges the following four mandates:
• Modification to HIPAA Privacy and Security rules requirements
• Unites HIPAA and HIPAA HITECH
• Additional requirements for data breach notifications and penalty execution
• The approval of regulations commensurate to the HITECH Act’s breach notification rule
The Omnibus Rule enforces regulations that will:
• Supervise the usage of patient information in marketing
• Require healthcare providers to report data breaches even when not considered harmful
• Order Business Associates and subcontractors to comply with HIPAA and ensure that they are liable for their data breaches.
Enforcement Rule
Should a rule be broken, the Enforcement Rule addresses how any resulting investigations are executed. After the authoritative officers have decided on the severity of the breach, appropriate fines will be issued to those found responsible.
Breach Notification Rule
If a data breach is discovered, the Breach Notification Rule mandates that the entity notify the Department of Health and Human Services (DHHS). The announcement must occur within 60 days of the discovery for circumstances involving 500 or more people.
The patients whose information has been breached must also be notified within 60 days. When more than 500 patients’ data has been infringed, a media notice to a local news outlet must be issued.
Who must comply with HIPAA regulations?
Any provider of medical or health care services that transmits health information in any form must comply with HIPAA compliant app regulations. If you are in doubt whether this applies to your company, check the list below:
Covered Entities
Covered entities are any businesses, such as health care providers, health plans, and clearinghouses, that hold patient files.
Covered Health Care Providers
• Chiropractors
• Clinics
• Dentists
• Doctors
• Nursing homes
• Pharmacies
• Psychologists
Health Plans
• Company health plans
• Government programs, such as Medicare and Medicaid
• Health insurance companies
• Health maintenance organizations
Health Care Clearinghouse
• Billing services
• Community Health Management
• Repricing companies
• Value-added networks
Business Associates
Business associates are the people operating an organization that performs various functions on behalf of a covered entity that has access to PHI. A business associate also includes subcontractors responsible for creating, receiving, handling, or facilitating health information.
• Accreditation
• Billing
• Claims processing
• Consulting
• Data analysis
• Financial services
• Legal services
• Management administration
• Utilization review
What happens if I violate a HIPAA law?
Your punishment for breaking HIPAA rules will depend on the severity of the violation, along with various factors taken into account, such as:
• Whether the violator did due diligence to fix the violation
• If there was malicious intent
• Nature of the offense
• Damage caused by the violation
• Number of patients impacted
• If the criminal provision of HIPAA was violated
• If the perpetrator knowingly violated HIPAA rules
Breaking HIPAA laws can have negative impacts on your personal and professional reputation. The HIPAA laws hold violators responsible for the abuse of a patient’s medical records with civil and criminal penalties.
There are four possible consequences for breaking HIPAA rules:
• Internal discipline
• Termination of employment
• Official sanction
• Criminal charges resulting in fines and / or incarceration
User rights under HIPAA
Medical Records
The Privacy Rule gives patients permission to examine, analyze, and acquire copies of their medical information and billing records handled by healthcare providers that are covered by the Privacy Rule.
Employers and Health information in the Workplace
Under the Privacy Rule, health plans and health care providers are subject to a particular ordinance when sharing medical information with an employer.
If you work for a covered health plan or health care provider, the Privacy Rule won’t be applied to your employment records. In addition, it will protect your medical or health plan information when you are a patient of the provider or a member of the health plan.
Personal Representative
Personal Representatives can be appointed by a patient to make healthcare decisions for them. The personal representative is allowed to examine records and receive a copy of the patient’s health information.
Family Members and Friends
The Privacy Rule does not allow health plans or health care providers to reveal patient health information to family members or friends unless they are a personal representative.
The provider is only able to share this information under the following circumstances:
• They are part of your health care plan or are connected to the payment of your health care
• You grant the healthcare service provider permission to do so
• You do not disapprove of sharing the records
• The provider uses their best judgment and deems it unobjectionable
Court Order
If the patient has a court order, under HIPAA, covered healthcare providers may reveal your protected health information. The provider or health plan may only share the records that were presented in the court order.
Subpoena
Before responding to the subpoena, providers and plans must ensure that the party made a feasible attempt to notify the subject about the information in regards to the request. They must also search for a qualified protective order for the data from the court. As long as the notification requirements of the Privacy rule are met, providers and plans may share health information with a party issuing a subpoena.
Most common mistakes by HIPAA compliant apps
Third-parties with malicious intent can derive PHI from your HIPAA compliant app through various ways if the proper practices aren’t in place. Check out the following mistakes entities often make so that you can be prepared.
Lost devices
Any device used at a clinic for practice purposes has the possibility of containing protected health information. You may not think about it, but PHI can be in your emails, messages, or even in the contact list of a device.
Mobile phones, tablets, or laptops are exposed to theft because of their size and mobility. If covered entities aren’t applying the correct encryption and security procedures to their devices, people’s PHI is at risk.
Here are a few safeguards that can be applied to protect your personal and work devices:
• Create strong passwords
• Enable encryption on all of your devices
• Activate remote wiping
• Enable a Firewall
These are just a few security measures that can be applied to ensure basic security measures for your HIPAA compliant app. Read what HealthIT.gov recommends for protecting health information on mobile devices.
Hacking
Hacking incidents related to Healthcare are happening every day. People are finding new ways to uncover PHI, forcing covered entities to be on their toes and pounce on any vulnerabilities.
The majority of attacks happen through unpatched software. Hackers have the ability to access health information due to the fact that entities are failing to update their software in a timely manner.
Here are a few tips that can be applied to help secure your device:
Use strong and unique passwords for every device
Install software patches promptly, and ensure your database is up-to-date
Scan for viruses regularly
Conduct a risk assessment
HealthIT.gov offers a Security Risk Assessment Tool that will conduct a risk assessment of your software.
Incorrect disposal
Under HIPAA, you are required to protect the privacy of PHI in any form. Health information can come in paper form, bottle form, electronically, and in various other ways.
Several major organizations have been guilty of improperly handling patient information and have faced major punishments. The HIPAA Privacy Rule requires that entities take serious measures when disposing of PHI and have created a set of rules for doing so.
Here are the rules for disposing of patient health information:
For PHI in paper records, shredding, burning, pulping, or pulverizing the records so that PHI is rendered essentially unreadable, indecipherable, and otherwise cannot be reconstructed.
Maintaining labelled prescription bottles and other PHI in opaque bags in a secure area and using a disposal vendor who is a business associate to pick up and shred or otherwise destroy the PHI.
For PHI on electronic media, clearing (using software or hardware products to overwrite media with non-sensitive data), purging (degaussing or exposing the media to a strong magnetic field in order to disrupt the recorded magnetic domains), or destroying the media (disintegration, pulverization, melting, incinerating, or shredding).
Further, covered entities, business associates, and subcontractor BAs must ensure that their workforce members receive training on and follow the disposal policies and procedures of the organization, as necessary and appropriate for each workforce member. See 45 CFR 164.306(a)(4), 164.308(a)(5), and 164.530(b) and (i). Therefore, any workforce member involved in disposing of PHI, or who supervises others who dispose of PHI, must receive training on disposal. This includes any volunteers. See 45 CFR 160.103 (definition of “workforce”).⁴
If you have any questions, visit this link from hhs.gov about the disposing of PHI.
HIPAA compliant app development practices
Running Production, Test, and Development contexts in a HIPAA secure environment can be expensive and time-consuming to deploy and maintain. Check out some of our best practices that will help you confidently develop fully compliant HIPAA applications.
Development Environments
Users should leverage Heroku and AWS for their development environments while making sure to develop, deploy, and test first. Otherwise, you have the possibility of significantly diminishing your product’s development cycle.
Test Environments
You must put data through a trial process to avoid exposing PHI in the test environment. Write tools that de-identify production data in your test environment, so you can test before it hits production.
Production Environments
For production environments, additional security comes with a cost; deploying code will take longer, and accessing the data in the database will be nuanced, as you may have to use something like the partible toolbar in conjunction with ssh and postures to see the transactional data.
B2B Solutions
For B2B solutions, data integration with your client for either eligibility files or EMRs needs to be considered at the architecture stage. You do not want to build your data integration solution as part of your web app or REST web service component!
File Transferring
Typically, large files should be transferred via the SSH File Transfer Protocol (SFTP). When a customer deposits a file into your SFTP account, decrypt it using a program that provides cryptographic privacy and authentication for data communication like Pretty Good Privacy (PGP). Extract, transform, and load (ETL) the data into your middleware with all communication going through HTTPS.
If you pull from the customer’s SFTP, the process is reversed. The client creates a named account for you using your private key. Then, pull the eligibility data at a specified interval. When the download is complete, the process is performed just like the file transfer protocol (FTP).
REST Web Services
The customer invokes REST Web Services to update data with all traffic encrypted via Secure Socket Layers (SSL).
Third-party Integrations
Third-party integrations can be onerous, in terms of compliance. Before mingling with third-parties, you need to read the Business Associate Agreements (BAAs).
Email – Most email providers are not HIPAA compliant, e.g. SendGrid, while certain email providers are compliant, e.g. MailGun, which is offered for free.
SMS – Most SMS message providers do not fall within HIPAA guidelines. PHI must be encrypted in transit, which makes this modality difficult. Secure Messaging is compliant when the communication is going over Transport Layer Security (TLS) to a secure machine, but this may not work when engaging with patients.
Video Chat –Video communication can provide patients with live clinical support. Some HIPAA compliant options include OpenTok or Janus webRTC – AugMedix.
HIPAA compliant app security
EHRs and Healthcare Data Security
Depending upon the ambition and function of your app, you will assume some responsibility for managing the PHI of your users. If your app is fairly ‘light-touch’ and makes use of simple data gleaned from monitoring devices such as Fitbit or the Apple watch, you probably don’t have too much work to do in terms of understanding your role as a Data Controller.
The Federal Trade Commission (FTC) website is a good place to start if you are totally new to building a HIPAA compliant app that handles consumer data - you can find a wealth of information here and suggestions on how to ensure data security for your customers.
Security is something that you need to consider from the start. As you design your app, your choices about which tools, APIs, and services to use must be top priority. You will also want to test rigorously to ensure that those services deliver the level of security expected.
Encryption
The next things you’ll want to consider are data encryption, permission and access restrictions, and containment. But briefly, these are best practice processes in maintaining the safety and security of PHI, especially in Clinical endpoints where there is a Bring Your Own Device (BYOD) policy.
When Clinicians and patients are using their own devices to access healthcare data, there is increased potential for security breaches. Even if you have ensured that your app is hosted on a HIPAA compliant cloud platform, patient data that is accessed from mobile devices is likely stored remotely.
The information is usually sent to smartphones or mobile devices from a server located in a secure facility, behind firewalls. Information that travels wirelessly and is stored within mobile devices can still pose a security risk if left unencrypted. It is a mobile healthcare security best practice to encrypt sensitive health information both while it’s being transferred, and when it’s at rest. This will help mitigate any leakage and offer strong data protection to ensure ongoing compliance.
Development Environments
Mobile devices must follow access control processes and procedures similar to restrictions seen within the world of desktops and laptops. This means that only users with appropriate authorizations can gain access to protected data on mobile devices, and only IT has adequate tools to audit and manage all users’ permissions.
While most healthcare professionals use their mobile devices for a mix of personal and business purposes, it’s challenging for IT to implement restrictions without causing end users to feel locked out of their devices. It is critical that mHealth apps that capture patient data stay isolated and protected from other tools or apps within mobile devices to avoid putting patient data at risk.
To solve this issue, many hospitals and Fortune 500 companies have implemented app and data containment. This is done by running mobile apps separately from all other apps to prevent sensitive data from being copied or penetrated. Creating and implementing this separation between personal data and healthcare data reassures IT that patient data can be protected with the right BYOD policy.
HIPAA Access Control
Unique User Identification (Required)
Emergency Access Procedure (Required)
Automatic Logoff (Addressable)
Encryption and Decryption (Addressable)
Unique User Identification (Required)
“Assign a unique name and/or number for identifying and tracking user identity.”
A unique user identifier allows an entity to track specific user activity when that user is logged into an information system. It enables an entity to hold users accountable for functions performed on information systems with EPHI when logged into those systems.
Emergency Access Procedure (Required)
“Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.”
Access controls are necessary under emergency conditions, although they may be very different from those used in normal operational circumstances. Covered entities must determine the types of situations that would require emergency access to an information system or application that contains EPHI.
Automatic Logoff (Addressable)
“Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.”
Automatic logoff is an effective way to prevent unauthorized users from accessing EPHI on a workstation when it is left unattended for a period of time.
Encryption and Decryption (Addressable)
“Implement a mechanism to encrypt and decrypt electronic protected health information.”
If information is encrypted, there would be a low probability that anyone other than the receiving party who has the key to the code or access to another confidential process would be able to decrypt (i.e., translate) the text and convert it into plain, comprehensible text.
A few things to note
When your production environment is locked down, time lags can occur in the following issues:
• Deploying new code
• Accessing the database for monitoring purposes
• Tracking the log files
• Bringing up machines that have crashed
Make sure your mobile application is in accord with the following indications to guarantee compliance:
• All network communication should run through SSL
• Try to store as little PHI on the mobile device as possible
• When data is stored on the mobile device, PHI needs to be encrypted with Advanced Encryption Standard (AES-256)
• Avoid inserting PHI into your push notifications
• Verify that your app is not a medical device that requires Food and Drug Administration (FDA) approval
Does this project or initiative involve application/software development practices?
If the response is ‘NO’ to the above question, do you have access to the source code for applications in scope for this service?
Do you follow a documented Software Development Life Cycle (SDLC) for application development and enhancement?
You can follow Scrum – Agile Software Development methodology.
Does the SDLC include a security risk assessment?
Software quality assurance process includes a review of required security standards providing encryption, penetration testing, social engineering, and the latest OWASP vulnerabilities.
Has the application code been scanned for application vulnerabilities?
You can use WhiteHat Security.
Is a formal release management procedure followed to manage the release of new or modified code?
You can use Hudson for CI. New code can initially be deployed to development as a container. After unit tests are passed, run through QA. Once QA is passed, roll it out to staging. You may want to establish a different set of criteria to roll it out to production.
Do you have escrow arrangements for the relevant application(s)?
We recommend Iron Mountain.
Are application security assessments conducted before the system is implemented?
You can run penetration tests on staging code before being deployed to production, and also do security code reviews.
Have any other external reviews been carried out on this application?
You can contract with Clearwater Compliance for a quarterly review.
Is user access to the application protected by encryption?
Your user access should be built according to AES-256.
Is there a formal process for authorizing new users and for removing accounts when access is no longer needed?
New user accounts are granted to HR managers and end users. Organizations are expected to notify clients if there has been a change in employment or status for an administrator with access.
Is there a formal process for authorizing new administrator accounts?
Administrator accounts will be authorized on a very limited basis by a super administrator and only to those who require it.
Does the application enforce a password policy?
The password management is the same as that of your internal protocol.
Is there a formal procedure for password resets?
You can enable the user to reset their password if they provide the answer to a set of security questions that they complete upon signup. If the user is not able to complete these questions, then they must go to their sysadmin to reset the password.
Are passwords protected in the application using encryption or a one-way hash function?
You can use AES-256 encryption algorithm.
Are there controls in place to prevent other clients from accessing the company’s data or database?
For a multi-tenant solution, you can offer two phase authentication to enable a client to only access their own data. For a single-tenant solution, you can offer dedicated application servers and databases.
Are cryptographic controls used to protect information in this application?
You can leverage the attr_encrypted gem to encrypt PHI fields in the db. The type of encryption is aes-256-cbc. You can also have a number of other encryption measures in place, including encrypted database backups.
Does the application require any exchange of data files with the company or the company’s clients?
You can communicate in two different manners; either via a web service that leverages Oauth, or you can do SFTP of files back and forth. You can prefer for these files to be PGP encrypted.
Does the website associated with this project or initiative use session-based cookies?
You can leverage the Devise Ruby Gem.
Does the website associated with this project or initiative collect IP addresses?
You can collect IP addresses, whitelist security, and even store the IP addresses encrypted in the database.
HIPAA Compliance Done Right
AllCode has 10+ years of experience developing web and mobile healthcare applications tailored around HIPAA compliance. We can help you plan, develop, and deploy your healthcare application so that your developers don’t have to focus on time-consuming regulations.
Recent Comments