What is HIPAA certification and what is the background for it? Why HIPAA certification for Medical Mobile Apps is that necessary? How to get HIPAA certification? How to make sure that health information is 100% secure? What you should take into consideration if you deal with m-Health App Development? All these questions boggle the minds of software vendors and healthcare providers. Here we’ll try to answer these questions and explain the features of GDPR / HIPAA (HSS) certification process.
Background: Why There’s So Much Information Around?
We live at the turn of digital devices era. These devices seem to emerge only a short time ago, it’s been only a bit more than 70 years since the first germanium transistor had been manufactured, and only 50 years since digital stream was invented (starting with Apollo 11 mission), but even during this short period of time digital technology has deeply penetrated our lives.
For 10 years in a row the integration of digital world into daily life of people has grown exponentially, thanks to invention of social media for news and photo sharing. Now digital technology is the basic one for such industries as trade, science, entertainment and TV. Digital technology and social media has even got across to healthcare industry as wearables and medical apps, dare I say it, went really viral.
Many users are used to store their personal data in digitized form which leads to the development of ocean of software and digital devices by people and for people. And the number of those is still growing. The range of those solutions includes desktop software, mobile apps, electronic digital gadgets and digital assistants like Siri, Alexa, Cortana and Alice. Here we should also mention intelligent virtual assistants (IVA) and medical virtual Assistants (MVA), that help people monitor their health, for example Sensely, and virtual assistants for doctors, that help them navigate patients’ EHRs and manage medical documentation, such as Dragon Medical Assistant by Nuance and Suki. The majority of IT solutions and digital devices use personal data to identify the owner and get access to his funds via credit cards, here we mean digital payment systems, such as PayPal, LiqPay, IPay, etc.
Most of the mentioned devices and apps store information on public type media – social media and cloud storages, which are powerful industrial computers and vast sets of storages incorporated into a single network with common and unified user interface – for people and application programs, mobile devices, client-side software, and finally the devices in themselves. This invention was named the IoT (Internet Of Things).
At this point every mobile device, gadget or IoT device vendor (Apple, Samsung, Blackberry, etc.) uses Cloud as a tool for reliable and safe information storage, data timing and communication between devices; and social media as a tool for user identification. All mentioned above make things easier for people, yet there’s a dark side, too: people started depriving themselves of privacy and saved attackers from troubles with stealing their confidential information to get financial data or other details for blackmail or public humiliation (that case often leads to psychological breakdowns or sometimes even suicides).
Today 75% of digital device or software users (consumers) all around the globe directly or indirectly use these technologies of data transmission between devices that way pushing up the demand for software and/or gadgets and cloud technologies.
Governing Laws for Software Development Business
Facing the first problems of growing number of apps and violations some 20 years ago governments made successful attempts to start regulating the spread of various private information to protect the rights of citizens and business organizations and to control dissemination of derogatory information in cyberspace. These regulations were HIPAA (Health Insurance Portability and Accountability Act of 1996 of Public Law 104-191), and – a bit later – the requirements and standards for electronic data transmission and storage known as HL7 and GDPR. Today HIPAA refers to healthcare domain and covers almost any software, which is used in healthcare industry. GDPR represents a set of generalized rules for data handling and storage and data access arrangement. In 2013 NIST CSF was enacted, which is a more categorized and the most dynamically developing framework for cyber security promotion. Let us have a closer look at these regulators.
Data Processing Regulators and Compliance Tools
According to the information available in public domain, here are the details on these regulators and common data transfer format.
· GDPR (General Data Protection Regulation) (EU) 2016/679 ("GDPR") is a regulation in EU law on data protection and privacy for all individuals within the European Union (EU) and the European Economic Area (EEA). It also addresses the export of personal data outside the EU and EEA areas. The GDPR aims primarily to give control to individuals over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU.
Replacing the Data Protection Directive 95/46/EC, the regulation contains provisions and requirements relating to the processing of personal data of individuals (formally called data subjects in the GDPR) inside the European Union, and applies to an enterprise established in the EU or - regardless of its location and the data subjects' citizenship - that is processing people’s personal data inside the EU. Controllers of personal information must put in place appropriate technical and organizational measures to implement the data protection principles.
"Data protection by design and by default", means that business processes that handle personal data must be designed and built with consideration of the principles and provide safeguards to protect data (for example, using pseudonymization or full anonymization where appropriate), and use the highest-possible privacy settings by default, so that the information is not available publicly without explicit, informed consent, and cannot be used to identify a subject without additional information stored separately. No personal data may be processed unless it’s done under a lawful basis specified by the regulation, or the data controller or processor has received an unambiguous and individual confirmation of consent from the data subject. The data subject has the right to withdraw this consent at any time.
GDPR is a transparent and independent format but belongs to stored context.
· HIPAA (Health Insurance Portability and Accountability Act of 1996). To improve the efficiency and effectiveness of the healthcare system, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), Public Law 104-191, included Administrative Simplification provisions that required HHS to adopt national standards for electronic health care transactions and code sets, unique health identifiers, and security. At the same time, Congress admitted that advances in electronic technology could violate the privacy of health information. Therefore, Congress included into HIPAA regulations that mandated the adoption of Federal privacy protections for individually identifiable health information.
o HHS published a final Privacy Rule in December 2000, which was later modified in August 2002. This Rule set national standards for the protection of individually identifiable health information by three types of covered subjects: health plans, health clinics, and health care providers who conduct the standard health care transactions electronically. Compliance with the Privacy Rule was required as of April 14, 2003 (April 14, 2004, for small health plans).
o HHS published a final Security Rule in February 2003. This Rule sets national standards to protect the confidentiality, integrity, and availability of secured electronic health information. Compliance with the Security Rule was required as of April 20, 2005 (April 20, 2006 for small health plans).
o The Enforcement Rule provides standards for the enforcement of all the Administrative Simplification Rules.
o HHS enacted a final Omnibus rule that implements a number of provisions of the HITECH Act to reinforce the privacy and security protections for health information established under HIPAA, finalizing the Breach Notification Rule.
So, basically, to get a HIPAA certified app, you have to confirm that it follows all aspects of HIPAA rules. Though, it is better to say about compliance, as the official HIPAA Journal says “there is no official, legally recognized HIPAA compliance certification process or accreditation… HIPAA compliance is an ongoing process”. HIPAA has Administrative Requirements, that relate to staff. To be compliant with these HIPAA certification requirements, you must have correct policies & procedures in place, also it’s necessary to complete a risk assessment every year, to train employees on HIPAA (and have appropriate documents to prove this), sign Business Associate Agreements (BAA) with partners and hosting providers (the ones that store protected health information), assign a confidentiality officer (who will control the following of policies and procedures). There are also Technical Requirements, that are directly related to the software. There are requirements to ensure that all protected health information (PHI), stored outside the healthcare organization (i.e. in the cloud), is fully encrypted end-to-end. With all of this, your cloud hosting provider must sign BAA ensuring that your servers are kept behind physical safeguards.
HIPAA and GDPR are the laws, that define obligations of vendors and set recommendations and guidelines for those who develop and use software, however the actual implementation of the requirements is guaranteed by the framework adopted not so long ago, in 2013-2017. This framework is NIST SCF, which is based on both European and American regulators and provides necessary tools to ensure the compliance.
NIST SCF. The National Institute of Standards and Technology (NIST) launched the project by convening private- and public-sector organizations and individuals in 2013. Published in 2014 and revised during 2017 and 2018, this Framework for Improving Critical Infrastructure Cybersecurity has relied upon eight public workshops, multiple Requests for Comment or Information, and thousands of direct interactions with stakeholders from across all sectors of the United States along with many sectors from around the world.
The Framework focuses on using business drivers to manage cybersecurity activities and considering cybersecurity risks as part of the organization’s risk management processes. The Framework consists of three parts:
- the Framework Core,
- the Implementation Tiers,
- and the Framework Profiles.
The Framework Core is a set of cybersecurity activities, outcomes, and informative references that are common across sectors and critical infrastructure. Elements of the Core provide detailed guidance for developing individual organizational Profiles. Through use of Profiles, the Framework will help an organization to align and prioritize its cybersecurity activities with its business/mission requirements, accepted risks, and resources. The Tiers provide a mechanism for organizations to view and understand the characteristics of their approach to managing cybersecurity risk, which will help in prioritizing and achieving cybersecurity objectives.
The Framework offers a flexible way to address cybersecurity, including cybersecurity’s effect on physical, cyber, and people dimensions. This applies to technology-relying organizations, whether their cybersecurity focus is primarily on information technology (IT), industrial control systems (ICS), cyber-physical systems (CPS), or connected devices more generally, including the Internet of Things (IoT). The Framework can help organizations in addressing cybersecurity as it affects the privacy of customers, employees, and other parties. Additionally, the Framework’s outcomes serve as targets for workforce development and evolution activities.
Think Different: Software, Gadgets and Digital Devices
The growth rate of software and digital devices in combination with the requirements for information spread control resulted in the development of different protocols for various groups and categories of software.
At the moment there are 7 basic categories of software, digital devices, and gadgets:
Platforms and controls – these include the class of software and devices for desktop and network infrastructure that allow users to control software and devices, their components and peripherals, including the elements of cyber security.
Educational and reference - these include the class of software and devices that are used in educational process or serve as search or reference data catalog. This does not apply to reference and training information for the app itself.
Home and presentation - software, content or devices that are designed exclusively for home use or on private presentation platforms.
Content management systems and presentation as well as platforms for public and private communication – this group includes the systems for content generation and discussion thread management. This category refers to official product channels, app stores, media content players and file viewers, web browsers and human performance organization tools.
Line of Business Applications – these are the apps developed exclusively for business. This group includes SAP application, business contact management systems, delivery (and tracking chain and manufacturing task management systems, software and device development tools, data access control systems and CMS, and healthcare apps, as well as various digital technical equipment for the above mentioned subgroups.
Product development and delivery services – this group includes software and devices that facilitate development of other solutions and their delivery. Thus, as a rule, the software group deals with NAICS activity and classification of goods.
Software Public Documents Are the Prerequisite for Compliance
The state of things in digital world, the presence of software and gadget classification along with the sets of requirements for them - all of that is a good motivation for development of numerous commercial Indy projects or Indy companies, that are in the process or already have embedded solutions, directly or indirectly, for the technologies mentioned above. This fact takes a lot of the hard work in drawing up legal and public documents for the developed product and makes it possible to determine the responsibility of digital device, gadget or software vendor to end users. This also provides insights into of product launch strategies for commercial use.
Depending on the software category being developed, there are different safety regulations, however, they can be referred to one of the two main categories of regulators: GDPR and HIPAA. Thus, regardless of the category, which software, gadget or digital device is belonging to, you have to execute at least 5 main documents, that describe the relationship between vendor and end user as well as the declared conditions of product applicability:
1. WHITE PAPER. This type of documents describes the problems solved with the product, defines its class and general concepts used by the product, and provides general and accurate information about licensing rules and product manufacturer.
2. EULA (End User License Agreement). This document establishes the legal relationship between the end user and the manufacturer.
3. System Requirements and Functional Specification. This document describes a comprehensive list of claimed product scope, designed capability, and, most importantly, complete product specifications, application severity index (for physical devices and gadgets), IPX rating.
4. Cybersecurity Requirements. Main document which sets out a compliance list with the NIST CSF, GDP(R),HIPAA/HSS regulators, etc.
5. The document which describes device/gadget risk/toxicity level. This type of documents include various safety requirements such as the level of materials toxicity, electrical safety requirements, etc.
Respect the Information, Arrange It Properly and Differentiate Access to It
Yuriy Chudinov, Software Architect at Archer Software (photo) gives his recommendations based on his own experience in development of HIPAA compliant software.
When it comes to the stage of app operation during its life cycle, it is necessary to understand and distinguish sensitive (confidential) and non-sensitive data, security level data of the system and operational audit data. Distribution of digital information usually involves 4 basic actions:
· Data Storage. Involves data storage in external, internal storages or cloud storages. Depending on whether data is confidential or not, it has to be confirmed by authentication certificate and/or be encrypted with special digital security key.
· Data Search and Transmission. Involves data transfer in formatted files through digital network or using portable data storage devices in the specified data format. There are readable data formats (HTML|XML|JSON|TEXT) and unreadable by human (binary-coded). There are additional sensitive data requirements - it must be saved in CDA, EMR and other formats outlined by HL7 or NIST SCF frameworks.
· Local Digital Data Processing. Involves any data handling procedures within the ecosystem product. If such ecosystem is a distributed one and processes sensitive data, the transfer and temporary data storage has to meet GDPR protocol requirements.
· Representation and Printout. Involves data formalization for human processing.
Sensitive (confidential) data is the distribution or disclosure of information, that may result in direct or indirect financial or physical loss. Vendor bears direct administrative and/or financial responsibility for loss, disclosure or compromise of sensitive data, therefore such data processing through the system must be properly organized and also comply with the main regulators of sensitive data processing, namely NIST CSF, HIPAA HSS, and GDP(R).
Non-sensitive data is the rest of the information circulating in the application ecosystem. For non-sensitive data it’s quite simple: vendors organize data storage, representation, processing and transfer the way they think it will fit in their discretion.
System security level data is a special group of product operational data used to access the rest of information circulating in the system. This group of data includes:
- User account IDs and security groups
- Security descriptors of operation system objects
- Authorization and authentication tokens and login/password pairs
- Claim tokens and tickets for groups and users
- Encryption and authorization certificates
Operational audit data is a special type of data that directly indicates which user account performed an action, associated with the data inside the system (initialization of any function within the system: changing, copying, printing, deleting or just accessing or transferring access rights to any unauthorized accounts in the system). As a rule, audit data is generally confidential, but the main regulator for this type of information is GDPR.
Expert Opinion: Keep Your Data Safe
Regardless of whether the data requires an adequate level of compliance with data processing regulators, there is a set of core and basic rules for digital data processing organization.
1. Store system security data separately from operational data; it is better to use external secured authorization servers.
2. Store audit data in a separate Database that nobody has access to, except for application layer role, and the access to data retrieval is performed using dual authorization.
3. Make sure you don’t mix confidential and insensitive information in one storage and your digital data extraction modules must be equipped with automatic data signing mechanisms with data transfer certificates, and, depending on the data requirements, encrypt them with a separate encryption certificate.
4. Establish and maintain clear and layer data access hierarchy and provide each application role with only the amount of data necessary for its efficient operation with minimal and sufficient access to confidential data.
5. Do not use temporary folders of operational system or publicly available folders to store sensitive data. Be sure to store data in the folder accessible only for the user who launched the application.
6. Do not store data in temporary folders longer than necessary, and when deleting data, use software functions that perform physical data deletion and not moving data to recycle bin.
7. If an application deals with critical sensitive data, make sure that the application is launched by user on behalf of isolated system user who does not have an operational system profile (user can’t log in to the system) and stores data only on behalf of such a user, i.e. any other user can get data only on demand and when having corresponding access right. (For example, we’ve got a user in a data-digital system, which has certain privilege and a completely autonomous and encrypted folder for intermediate and temporary file storage; also we’ve got ordinary users Mary, Bob, and Alex, at that Mary is a Windows administrator, Bob and Alex – ordinary Windows users. The app is launched using digital data, it provides indirect access (through our application) on behalf of users Mary, Bob, and Alex and compiles a register of data access with the help of these users. But none of them has access to data at the level of operational system.)
8. If your application transmits data through a network, use data encryption during data transfer and provide the authentication modules with user whitelists, that you can quickly withdraw and prevent leakage if anything happens.
If data processing in the product ecosystem is regulated by any of the regulators mentioned above, the application must be checked for compliance with the regulators requirements on a regular basis or when launching a new version. This function is performed by a specialist - DPO (Data Protection Officer) specially assigned by an inspection authority (EEA or CFR), being licensed to perform such inspections. Upon completion of the verification, a product use mandate is issued.
There Is Always a Strict Compliance Development Cycle Behind HIPAA or GDPR Compliant Software
As noted above, the regulators pose strict requirements not only for application processing and storage of data, but also for the development and verification cycle of applications themselves and its further support at the customer’s side. The figure below shows a generic cycle of an application delivery.
- Main features of the application development and delivery cycle
- Among the key operation features of every delivered version of an application there are such rules:
- A developer should never have access to real certificates of application authenticity.
- A data base or a test kit must not include any HIPAA data, but it must be equivalent to real data set in terms of size and structure allocation.
- An application build must undergo a completely automated assembly cycle and launch units and integrated tests with complete a full report dump.
- An application must not require maximum privileges for operation (extend Partial Trust| Medium Trust compatibility levels).
- Every application module must be signed with an original development authenticity certificate.
- All operations related to application setup must be performed by an automated installer capable to operate in 2 modes: user and admin setup.
- Application documentation must include complete list of installed components and their versions, as well as comprehensive description of file structure and a complete list of means for registering problems in the stated format. It is important for analyzing the leakage of HIPAA information.
- At every system update, the system must support a complete reset and configuration using installable file, that can be analyzed by a person to define information leak possibility.
- The application must be connected to an independent and secure password changing service mechanism. It is not recommended to have the function of changing the password in the system accessible for the user without additional verification of the previous password.
- Application being installed must not contain any master passwords from dev-environment.
To get a HIPAA certificate for a medical mobile app, you have to undergo several stages of certification and, as a rule, this process includes not only various checks of the software itself, but also the checking whether the end user is ready to follow information processing rules and software use. For this purpose, the software vendor must provide the end user with unequivocal and comprehensive instruction, train end users and client’s IT service staff to use application properly. For your convenience there is a basic checklist for HIPAA certification that includes all software history and comments. It should be noted that all of these requirements are also applicable for GDPR compliance.
Summing up, using simple methods of data processing and sorting, we can develop high-level data protection systems for reliable processing and storage of medical data. If you have any questions about HIPAA compliance for health applications, contact Archer Software’s professional team via email@example.com.
The compliance revision table below shows the list, which can help you check whether your software and business processes are compliant with HIPAA regulations. Keep in mind that HIPAA compliant software development process is a continuous one: you must ensure that each new version of your product is consistent. Each row in the table allows you to assess the compliance level and track any changes in versions. Our experience shows that accurate maintenance of such a table allows smooth compliance control of software during the whole development cycle.
|Awareness and Education|
|Has your software provider had any awareness, education or training on HIPAA regulations and compliance?|
|Does everyone who has access to Protected Health Information (PHI) have awareness, education and training on HIPAA regulations and compliance? (This includes 3rd party hosting services)|
|Has your software provider set written standards for the handling of Protected Health Information?|
|Does your software provider keep updated on HIPAA legislation and/or any changes to HIPAA legislation?|
|Will your software provider sign a HIPAA Business Associates Agreement?|
|Will your software provider sign a specific Service Level Agreement (SLA ) to ensure all the standards are met?|
|Does your software provider store Protected Health Information (PHI) outside facility or store data in unprotected file formats?|
|Does your software provider continually test your hosting centre for HIPAA compliance ? (back-up, recovery, access and control)|
|How often does your software provider test their data recovery?|
|Can your software provider enable retrievable exact copy of Protected Health Information?|
|Can your software provider prepare a detailed list of access to information and management tools upon request? Including all individuals access to Protected Health Information and set controls to regulate that access|
|Does your organization implement policies and procedures to address the final disposition of any data stored?|
|How long is data backed-up and stored by your software provider before it is disposed of?|
|Does your software provider enable and check the record of data disposal?|
|Does your service/product provide procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information?|
|Does your service/product use electronic mechanisms to confirm that Protected Health Information has not been altered or destroyed in an unauthorized way?|
|Does your service/product implement policies and procedures to protect electronic secured health information from inappropriate alteration or destruction?|
|Has your software provider gathered, reviewed and compared your current billing forms, policies, and procedures with the HIPAA Electronic Claims Transaction and Code Set regulations?|
|Privacy and Security|
|Does your service/product implement technical security measures to guard against unauthorized access to electronic secured health information that is being transmitted over an electronic communications network?|
|Does your product/service implement procedures to verify that a person or organization requesting access to Protected Health Information (PHI)is declared?|
|Does your product/service assign a unique name and/or number for tracking and identifying users' identity?|
|Does your product/service allow users to obtain necessary Protected Health Information during an emergency?|
|Does your product/service implement electronic procedures that terminate an electronic session after a predetermined time of inactivity?|
|Does your product/service encrypt data at rest and in motion in accordance with NIST standards?|
|What is your organization's policies regarding a data leakage?|
|Have you developed or revised current consent forms for patients according to HIPAA guidelines?|
|Does your organization use a separate database and web servers for production?|
|Has your software provider been independently audited against the OCR HIPAA Audit Protocol?|