2020 Healthcare Software Security Regulations: Guide to HIPAA and NHS

Healthcare software development is one of the main tendencies of 2020, and there is nothing to be surprised about. Given the experts’ forecasts, the COVID-19 pandemic is here to stay, and, thus, the telehealth and MedTech industries will continue growing at a tremendous pace. Sure enough, the telehealth domain was well off without the pandemic. Whereas now, it is going to develop even faster as the latest market analysis claims that the global Medtech market will reach the point of 17.2 billion by the end of 2025, which is an average compound annual growth rate (CAGR) of 24.1%. The stats are impressive, and so is the future of the telehealth industry.

Too many developers with brilliant projects in the pipeline stumble upon the same barrier — the legal codes of their target markets regulating every aspect of the product, from UI/UX to app’s architecture. Medical software developers fail to understand why their ideas may be hanging in the balance due to a single law provision. The answer is clear to understand: this is the world of sensitive data that we live in, and any healthcare software should make their products become HIPAA compliant and NHS certified. That is why, in this article, we will discuss the HIPAA and NHS regulations — the two landmark regulatory systems for healthcare software developers.

Why We Need Them

There are a lot of reasons why a healthcare software developer needs to stick to, let’s say, HIPAA guidelines. The laws and regulations mentioned above represent the legal basis for the successful functioning of your app. Given the increased sensitivity of people’s data, security in healthcare became a central concern in the United States and the United Kingdom — the two biggest markets of the telehealth industry.

Every company, eager to provide healthcare security solutions for those markets, has to stick to the patient data security provisions laid out in HIPAA and NHS regulations. Here comes a stepwise guide to how to be a HIPAA and NHS compliant healthcare software developer.

HIPAA Compliance and Certification

The U.S Congress adopted the Health Insurance Portability and Accountability Act in 1996 — the time when the Internet had nothing in common with healthcare; talking about HIPAA and Electronic Medical Records as mutually related concepts was complete nonsense. However, the updated HIPAA features a myriad of guidelines to follow if you want your software to be compliant and thus eligible for use on the United States territory. Following thorough research, we have boiled the list down to five main points adhering to which will give you the HIPAA Compliance Certificate.

1. Audit Control

The Obama administration 2009 HITECH Act that fixed the HIPAA loopholes in the development of health information technology regulations. It has mandated external audits of every single healthcare software platform aimed to ensure that the software in question is compliant with the HIPAA patients’ information safety provisions.

As a result, the first thing that a product has to have to meet the HIPAA compliance requirements is a logging infrastructure that does not resist regulatory compliance. For example, you can use AWS’ CloudTrail to log the API calls, and when the audit time comes, these tools will bring you the evidence of compliance.

2. Access Control

The products must help medical organizations obtain control over the information access modes. The end-users are to be able to control who and when has access to information, and the access control requirement must be paid specific attention.

Under the Technical Safeguard Standard of HIPAA’s Administrative Simplification Security Rule, there are four essential features to be embedded into the product’s access control:

• Unique user identification patterns;
• Personnel/role-based authorization;
• Automatic log-off;
• Emergency access;

Developers have to carefully analyze the roles of each end-user to develop the personnel-based authorization feature. For example, nurses might not have the same access to patients’ PHI as doctors would. Meanwhile, doctors should not have the same amount of information about the patient’s solvency as the hospital’s administrator does. Working out the system of personnel-based access is crucial to developing HIPAA compliant software.

3. Centralized Identity Management

Authorizing users and defining their identity is another core requirement for developing HIPAA compliant software. Software developers have to devise the ways their products are going to track the logins, log-offs, users’ activity, sessions, and changes in the profiles. Nonetheless, the security measures are not to hinder the users’ experience and needs. Sometimes, inefficient EMR software development can lead to lamentable consequences. For instance, a doctor must be able to access the files needed within a matter of seconds, as there might be a crucial decision pending due to the information logged in the EMR system.

4. PHI and Sensitive Data Encryption and Decryption

As a matter of fact, HIPAA does not directly require the encryption of PHI. Nonetheless, reassuring your clients that their patients’ data is being protected in a due manner is essential in modern software development. Regardless of whether it is the data at rest or in transit, encrypt it using the purpose-design approach as it will prevent any probable case of patients’ data loss, and thus eventual financial risks and liabilities. All the data within the system must be encrypted and decrypted only by authorized personnel with corresponding digital keys.

5. Data Transmission Security

While HIPAA is not requesting any particular data transmission security measures, they are clearly laid out in the HITECH Act. Ensuring data transmission security is a core practice in modern healthcare software development, as it prevents unauthorized access to electronically transmitted data, which, in fact, is the primary HIPAA requirement. Thus, consider building your products with TLS and SSL certification and do not forget about object keys where needed.

Of course, the full list of HIPAA requirements is way more extensive, and the applicable provisions can be defined based on the specific properties of your product. But, following these five major rules shall definitely help your product reach its target markets.

Dental HIPAA

Dental clinics worldwide are now joining the process of EMR and EHR reintegration to help healthcare systems efficiently manage patients and their doctoral referrals. As a result, following the dental HIPAA compliance requirements is a rule that they must follow. There are three major categories to divide HIPAA into when it comes to talking about dental clinics: administrative, physical, and, of course, technical.

The latter does not differ a lot from the overall EMR HIPAA compliance regulations. Protecting the patients’ data and ensuring its encryption, decryption, and personnel authorization is a must. If you want to have a somewhat realistic look at applying the HIPAA provisions to a real project for a network of dental clinics from the UK, check our Dental Referrals case study.

NHS Compliance and Certification

Developing healthcare software for British markets is quite a complicated process, as the UK National Health Service is quite picky when it comes to Whereas in the United States, your product has to be HIPAA compliant and get an FDA certification, in England, for example, there are a lot more legal boxes to tick before launching your product.

You must embark upon four steps when developing software for Continuous Healthcare (CHC) organizations in the United Kingdom. While scrutinizing the complete NHS CHC checklist might be a long and tedious process, reaching the healthcare regulations and compliance standards is undoubtedly worth it.

1. Eligibility Check

Every piece of healthcare software in the United Kingdom is subject to registration on the NHS Apps Library. Getting there envisions quite a lot of boxes to tick off, including the NHS Health App Assessment Standards and the NHS Digital, Data and Technology Standards. Meanwhile, make sure that:

• The app is publicly available on AppStore or GooglePlay;
• The product users can contact the developer directly;
• The product is not NHS branded;
• The product’s interoperability testing has been conducted, given the product’s need to connect to other NHS service;
• If the product falls under the classification of a medical device, it must hold a corresponding certificate;
• If the product requires a healthcare professional operator, the developer must provide his or her name and healthcare professional registration status;
• The developer must be registered with the Care Quality Commission on a request;

Also, there are legal limitations to the type of the developer’s ownership registered. It must be either an Ltd by shares or guarantee, an Unltd., an LLP, a Community Interest Company, and Industrial and Provident Society, a Royal Charter, a Public Body, or a Charitable Organization.

2. Register the Details

The NHS requires a lot of information from developers about the organization itself and the product that they submit for legal assessment. Even though this is a standard procedure to follow, you might want to know more about the questions that you can expect from the NHS:

• The developer’s registered address;
• Contact information of the person conducting the assessment;
• Information regarding the developer’s Care Quality Commission registration;
• The healthcare direction the software addresses;
• The software target audience;
• The software price;

As soon as this phase is over, the NHS assigns a technical assessor to the product, and hence the third step of gaining your product’s NHS compliance certificate begins.

3. Technical Assessment

This is the main stage of your product’s assessment, as this is where it is being tested for compliance with the NHS patients’ data security standards. The NHS has broken this process down into seven separate stages to ensure that no detail is left behind.

• Providing the Outcomes Evidence

The assessor’s first task is to make sure that the app is actually doing what it is supposed to do. For example, if the app is designed to improve the patients’ well-being, the developer will inevitably be asked questions about the coded process of performing this task. Finally, the fiscal, clinical, and behavioral benefits of using the software will be questioned.

• Clinical Safety

Patients are the end-users of the NHS, and their safety is of the utmost importance. This is the stage when the app’s inability to harm the patient is proven. For example, if the app is meant to remind the patients about medication, the developers must prove that there won’t be any discrepancies in the process. Meeting the clinical risk management standards laid out in the Health and Social Care Act of 2012 is a requirement for every developer.

• Data Protection

All the information collected by the app must be handled in a safe, lawful, and fair manner. Thus, pursuing the UK Data Protection Act of 2018, the developer is obliged to provide details on the data repository and inform users of their right to control the way their information is used.

• Security

At this stage, the security assurance of the app or platform is tested. The app’s ability to rightly categorize and manage the patients’ data is checked. The confirmation of the app’s compliance with Open Web Application Security Project standards is the finalization point here.

• Usability and Accessibility

Making sure that the app is understandable and easy to read is also a priority. The app must feature the accessibility features, such as customizable button size, etc. All the commands must be understandable to users and no extra actions are allowed, unless users are given a choice of whether to proceed with further action or cancel it. At this stage, the product is being tested for compatibility with the Web Content Accessibility Guidelines 2.1 and the International Organization for Standardization requirements.

• Interoperability

The NHS is an intertwined system with a lot of departments and digital platforms, cooperating to resolve the patients’ issues efficiently. Therefore, the app’s aptitude to connect with a patient’s medical record or collect data from another device is tested. The product’s API is verified by an independent third party representative who can provide an unbiased evaluation of its interoperability. Also, the apps that exchange data are being checked for compliance with the NHS Open API policy, which renders the exchange process simple, yet efficient, and secure.

• Technical Stability

When talking about healthcare software, it must be understood that human lives might be at stake. This phase envisions the analysis of the app’s code testing process by the developers. This helps identify the probable technical problems and the developer’s strategy to eliminate them. Here, developers here must show that the users can report any technical issues related to the product. A new assessor is being allocated to the developer in order to conduct the functional assessment of the developer’s testing practices.

4. Publishing the App

Once the product passes all the checks and tests, its details are published on the NHS Apps Library. Nonetheless, there are still some requirements for the developers to follow even after the app has been published.

• Any significant update to the software is subject to disclosure to NHS;
• Any changes to the DAQ will be relayed to the developer with a corresponding request to change the product according to the new requirements.

The HMS Software Compliance Principles

Regardless of whether it is the United States or the United Kingdom that you want to launch your product in, you should stick to some general Hospital Management System Development requirements, especially if your product is related to EMR and EHR domains.

• The system must be easy to understand for any medical employee;
• The UI/UX aspect must be understandable and easily accessible;
• The personnel access principle must be the core one;
• All the personal data must be encrypted;
• The software must demonstrate the potential for improving the clinical practices in the hospital;

Let’s Sum It Up

One can clearly see that following HIPAA and NHS regulations is a justifiable requirement. Ticking off the HIPAA security checklist, as well as following the NHS security assessment process, must be every healthcare software developer’s major priority. We will definitely dig deeper into this topic, including HIPAA cloud security, FDA security requirements, extended list of NHS healthcare data compliance requirements, and GDPR guidelines, as this is a vital topic to discuss.