mHealth App Development with an Eye on Health Data Security

Onix’s specialists decided to share their experience in regulatory-compliant health mobile app development while working on patient data security for a white-label solution for self-managed care and other mobile and web apps. Our recommendations concern:

 

• Studying all applicable local, national, and international regulations regarding user privacy and data protection before the mobile health app development starts

 

• Establishing a project team that can facilitate your mobile apps’ compliance and data security

 

• How they should address health data security issues at each project phase

 

• Testing best practices for mHealth app security

 

• A long-term strategy to ensure privacy and health data protection

 

Read on to learn the details! If you have any questions, please contact us! As a health tech company, Onix can provide experts for your project, improve your existing system’s security, or build your healthcare application from A to Z focusing on security.

 

The importance of secure mobile health app development

The prevalence of mobile devices and wearables and chronic diseases requiring remote patient monitoring drives active mobile healthcare (aka mHealth) app development.

 

Clinics and other stakeholders are actively integrating these apps, while more and more patients look for medical information and providers online, book doctor appointments and remote consultations, use drug delivery services, and more.

 

As a result, the mHealth market is predicted to grow at a CAGR of 24.6% until reaching $236,214.86 million by 2028.

 

Unfortunately, data security issues and stringent regulatory scenarios are identified as major challenges for mobile health app developers. The health industry remains one of the primary sectors targeted by cybercriminals.

 

They can use stolen medical records to obtain prescription drugs, file fraudulent insurance claims, bill patients for services they didn’t receive, or simply blackmail them, using sensitive information about their physical or mental health.

 

Protected health information (PHI) being compromised or even lost will result in financial and reputational damage and penalties for an organization that fails to ensure its security.

If you intend to build an mHealth app or website, you must incorporate the patients’ privacy and health data security into the entire software development lifecycle, from the initial analysis to ongoing maintenance.

 

This article is a series of tips on what you need to consider and do at every stage of the app development process:

 

1. discovery and planning
2. product design or redesign
3. front-end and back-end development, including quality assurance
4. maintenance and support

 

You may also download our checklist with tips on how to ensure your healthcare software security and data integrity. It may prove handy when you create your app or need to make sure your developers are building a secure and regulations-compliant product.

 

 

Harness the power of VisionOS app development to transform your healthcare software into a seamless and secure solution, providing peace of mind for both you and your users

 

Tip 1. Prioritize healthcare data security regulations

It’s critical to begin your mobile health app development with proper research, which includes research into all applicable national and international legislation regarding consumer privacy and PHI data security.

 

This will help your team design, engineer, and distribute an app that meets all requirements, minimizing the risk of litigation and financial penalties in the future.

 

NB. If you haven’t built mHealth products before, it may be beneficial to engage a specialized software development company right from the ideation phase.

 

They would be familiar with all the nuances, pitfalls, best practices, and technologies used in health mobile app development. Valuable insights will help you save much time and reduce risks.

 

Whether you need to study data protection regulations can be defined by checking the functions your app will perform.

 

If you are going to launch an app for healthcare education, diet and nutrition planning, fitness, yoga, or meditation, some treatment reminders, or other solutions that don’t require entering, processing, or exchanging very specific user data, you don’t need to worry about those regulations.

 

However, regional and international regulations should apply if your software qualifies as:

 

• Healthcare reference & database apps
• Clinical trial management software
• Hospital management software
• Hospital ERP (enterprise resource planning systems)  
• Professional and patient networking apps
• Doctor appointment & clinical assistance apps 
• Teledentistry apps 
• Patient tracking apps and even some mood-tracking apps, and much more 

So, once you have identified your app’s target market, start researching relevant legislation, standards, and best practices.

 

Different countries’ policies may vary even regarding what is protected health information and what isn’t. It’s also important to determine which regulations apply to the type of software you develop and the major points to consider. Here are several examples: 

 

The United States

In the USA, the Health Insurance Portability and Accountability Act (HIPAA) regulates how companies should guarantee the security of patients’ data and how it should be stored and transmitted between devices.

 

Any details relating to a person’s physical or mental health, condition, treatment, or payment for the treatment combined with any of the eighteen personal identifiers are considered patient PHI.

If a mobile healthcare solution collects, processes, stores, or transfers any HIPAA-protected health information, the developer must ensure HIPAA compliance. This applies to various software utilized in the medical industry, such as email providers and Internet platforms, cloud services, and other digital resources.

 

Learn more: A Guide to HIPAA Compliance for Software Developers

 

For example, when Onix was building a scheduler for clinic administrators and physicians, HIPAA compliance measures included:

 

• hosting the database and application on AWS
• configuring the generation of fake data for development and staging environments
• limiting access to the app by IP-addresses
• logging out inactive users after 15 minutes

 

 

Additional regulations may apply, such as:

 

• the U.S. Federal Trade Commission’s Health Breach Notification Rule

 

• guidelines from the U.S. Food & Drug Administration (medical device manufacturers and healthcare delivery organizations must follow FDA requirements to ensure their products, including mobile apps, meet a reasonable level of safety from cyber threats) 

 

• the California Consumer Privacy Act (if your app caters to California residents)

 

• the Children’s Online Privacy Protection Act

 

Canada

In Canada, the collection, use, and disclosure of personal data in the private sector are governed by the Personal Information Protection and Electronic Documents Act (PIPEDA).

 

Besides health insurance and healthcare providers, even employers, MedTech companies, marketing agencies, and retailers must be PIPEDA-compliant if their operations involve consumers’ personal data.

 

Under PIPEDA, personal information includes information about an identifiable individual in any form, such as:

 

• name, ID numbers, age, income, ethnicity, or blood type

 

• employee files, credit and loan records, medical records, healthcare billing information, the existence of a dispute with a merchant, and even intentions, e.g., to purchase something

 

• opinions, evaluations, comments, social status, or disciplinary actions

 

PIPEDA’s most critical part pertains to consumer consent. Organizations that manage an individual’s information, including health data, may only do so with their consent after that organization has detailed its purposes.

 

PIPEDA’s requirements are applicable in all provinces that do not have their own sustainable privacy laws yet. If you are going to create an app for Alberta, Quebec, or British Columbia, make sure to study the respective regulations of these provinces.

 

The European Union

In the EU, mHealth apps fall under the jurisdiction of the GDPR (meaning General Data Protection Regulation), whose goal is to protect the personal information of all EU citizens and residents.

 

It applies to any entity that processes such data or offers goods or services to such people, even if it is located outside the EU. 

 

‘Data processing’ encompasses the collection, recording, structuring, storage, modification, combination, retrieval, use, transmission, dissemination or otherwise making available, and even the restriction and destruction of data related to a natural person who can be directly or indirectly identified.

 

 

The GDPR generally requires that any such processing should be done lawfully, fairly, and transparently. It also restricts the processing of a person’s genetic and biometric data and data revealing their racial or ethnic origin, political opinions, religious beliefs, trade union membership, health, and sex life.

 

Healthcare apps should inform users why they collect their personal information and how they store and protect it. Users should be able to allow and decline the collection of certain types of data, require to delete all collected data, and get a report on which data had been collected and which was erased.

 

Some non-EU countries have also accepted the GDPR or adjusted them for their respective healthcare sectors. For example, Switzerland’s revised Federal Data Protection Act essentially adapted the GDPR requirements with a “Swiss finish” in some areas.

Meditation app developed by Onix for EU residents

 

The United Kingdom

In the UK, if healthcare software processes the personal data of users or patients, it must comply with three data protection laws:

 

• The GDPR, which even after Brexit continues to apply subject to some adaptations 
• The Data Protection Act 2018 (DPA)
• The Privacy and Electronic Communications (EC Directive) Regulations 2003 (PECR), to the extent relevant

 

Particularly, PECR imposes specific requirements for 

 

• electronic marketing, including calls, texts, and emails
• the use of cookies or similar technology that track information about people accessing an electronic service
• the security of public electronic communications services
• the privacy of consumers that use communications networks or services as regards directory listings, line identification services, itemized billing, and traffic and location data

 

 

Onix has developed an algorithm-driven platform where British cancer and post-cancer patients can support each other and access helpful educational resources. It was naturally important to make the users’ communications as confidential as possible under these conditions. For example:

 

• Members are presented only by the name and the first letter of the last name.

 

• At the registration, users fill out an onboarding survey with three optional blocks: general info, diagnosis, and treatment.

 

• In the profile settings, they can choose who can view each type of information: everyone, only friends, or no one except the user.

 

• They can also configure whether their name would appear in the search results or not.

 

• The system uses the survey data to calculate matches for the user and suggests adding each other as friends. It says “Your path is similar to this user’s; the similarity percentage is 91%,” but does not reveal which details are similar (e.g., profile – 85%, diagnosis – 98%, and treatment – 90%).

 

• Members can publish posts anonymously on the forum (after an administrator’s review and approval).

 

• Upon request to delete the account, all data, publications, and conversations pertaining to the user are deleted.

 

The client’s in-house team also included a cybersecurity specialist who configured access to the database and took other steps to ensure data security.

NowWhat – a platform for cancer and post-cancer patients developed by Onix

 

Asia-Pacific Region

The laws regulating health information in this region are rather close to the GDPR but include each region’s specific regulatory requirements, enforcement, and export regulations.

 

Here are some of the countries’ personal health data rules:

 

• South Korea – Personal Information Protection Act (PIPA)
• Japan – Act on the Protection of Personal Information (APPI)
• China – CyberSecurity Law
• Taiwan – Personal Data Protection Act (the PDPA)
• India – Digital Information Security in Healthcare Act (DISHA)
• Australia – Privacy Act

 

For example, the Privacy Policy of the Australian app for cancer patients’ caretakers that Onix currently works on follows the standards of both the Privacy Act and GDPR for the handling of personal data.

 

 

Tip 2. Assemble a team that can ensure your healthcare data security

It’s advisable to hire software developers or a dedicated team with a proven track record in compliant mHealth app development for the region where your app will be distributed. This will accelerate the development process and reduce the risk of non-compliance.

 

If you recruit offshore specialists or outsource your mobile health app development to a reliable agency altogether, you can also save money.

 

Moreover, such complicated development calls for a transparent partnership with an experienced healthcare app development company rather than one-time contractors.

 

 

NB. The design and development of medical apps also require industry-specific insights. It would be helpful to engage an expert (such as a doctor, RN, another specialist for whom the app is developed, or at least a medical student) and, if needed, a lawyer, from the project onset.

 

For an mHealth app development project, you will likely need:

 

• An Android developer, iOS developer, or cross-platform (Flutter or React Native) developer
• Web developer
• Server-side developer
• UX/UI designer
• 2-3 quality assurance specialists
• Project manager

 

 

When you are looking for a software dev team, besides considering their time zone and English proficiency, portfolio, previous client reviews, and, most importantly, niche experience, you should also:

 

• Ask for evidence of adherence to security standards, such as design documents, threat models, and security architecture diagrams.

 

• Demand proof of secure data processing, including the confidentiality, integrity, and availability of the stored, processed, and transmitted personal data.

 

• Evaluate the candidate’s awareness and understanding of threats to data.

 

• Ask about the controls to respond to familiar and newly discovered cyber threats.

 

• Ask them how they deal with multiple types of cyber-attacks and what security measures they take to prevent them.

 

• Evaluate their understanding of liability and examine their process for detecting and managing potential security breaches.

 

• Request documentation proving that they follow HIPAA and other regulatory compliance standards.

 

• Inquire about the support they provide during and after the app implementation.

 

Onix is an offshore healthcare software development company with a comprehensive range of services.

 

Besides mHealth applications, we specialize in building electronic health record (EHR) systems, telemedicine solutions, practice management systems, health information exchange (HIE), clinical decision support, and health data analytics.

 

Our experience and expertise ensures that your applications and information will be protected.

Example of HIPAA-compliant app development by Onix

 

Onix prioritizes the patient information and clinical data security in healthcare software we develop and compliance with applicable privacy standards. Our software developers:

 

• employ strict security measures, such as encryption protocols and secure storage

 

• have a deep understanding of the HIPAA and GDPR requirements and incorporate them into the development process

 

• are well-versed in healthcare IT interoperability and standards like HL7, FHIR, CDA, DICOM, ICD, and ICPC-2  

 

• are experienced in compliance with ISO 9001, ISO 27001, and SOC2 certifications

Example of SOC2-certified mobile app development by Onix

 

After the project timeline, budget, platform(s), monetization methods, and functionalities have been approved, an experienced and healthcare security-savvy team should

 

• design the optimal architecture for your app

 

• recommend app features that will facilitate compliance with regulations and protection of your users’ and business data

 

• explain the possibilities and limitations of cloud platforms and other third-party components regarding compliance with applicable national laws, if needed

 

• suggest the optimal technologies and services for your mHealth solution. 

 

Tip 3. Address health data security issues during the design and development stages

The main risk categories for mHealth apps are:

 

1. Inadequate design

The developers should ensure data security at all levels: the device, the network, and the data center.

 

2. User errors

Unfortunately, users’ habits and choices play a significant role in breaches. In 2023, 74% of breaches involved the human element, such as social engineering attacks, errors, or misuse.

 

3. Device vulnerabilities

A smartphone may be stolen or used by unauthorized persons who can access all apps on it.

 

The things to start with include:

 

1. Authentication

Strong password and authentication is a crucial security factor. Passwords shouldn’t be stored in plain text but salted and hashed for better encryption. Users should be able to reset forgotten passwords securely as well.

 

Multi-factor authentication should include information known only to the user, e.g., the password or PIN, or biometrics (facial recognition or fingerprints).

 

Customizing the white-label mobile app for cancer patients’ caretakers mentioned above, Onix’s specialists implement different authentication methods upon clients’ requests.

 

2. Privilege management

Implement the principle of least privilege. If hackers compromise your app, they still can’t do anything beyond what the app user normally does, e.g., elevate privileges to gain access to patient PHI.

 

3. Secure data storage and communication

The app shouldn’t store sensitive data on the device or in backups whenever possible. Sensitive information files must be protected using encryption stronger than native encryption on iOS or Android, if needed. Implement secure network transmission of sensitive data.

 

4. Compliance

For instance, HIPAA offers clear guidelines, such as 

 

• Any electronic protected health information (ePHI) must be encrypted before transmission. 
• The electronic patient PHI storage must be encrypted as well.
• The data has to be recovered and restored if needed. 
• Any ePHI is available for the authorized staff.
• The ePHI can’t be changed illegally. 
• The ePHI will be removed from the storage permanently if it is no longer needed. 
• The ePHI can be hosted only on services that have signed the Business Associate Agreement. If not, the data should be hosted on secure in-house servers.

 

A 2021 report found that the 30 most popular mHealth apps were highly vulnerable to API attacks that give unauthorized access to patient records and personally identifiable information (PII). The following basic vulnerabilities were identified:

 

• 77% of the tested apps contained hardcoded API keys, some which don’t expire, and 7% – hardcoded usernames and passwords. 7% of the API keys belonged to payment processors that warned against hard-coding their secret keys in plain text.

 

• 50% of the APIs did not authenticate requests with tokens.

 

• 50% of the records the researchers accessed contained names, social security numbers, addresses, allergies, medications, and other sensitive patient data.

 

• 100% of API endpoints were vulnerable to BOLA attacks, allowing the researcher to view the PII and PHI for patients not assigned to the researcher’s clinician account.

 

• 50% of the APIs allowed medical professionals to access other patients’ pathology, X-rays, and clinical results.

 

• A replay vulnerability let the researcher replay days-old FaceID unlock requests that enabled taking over other users’ sessions.

 

• 100% of the tested apps failed to implement certificate pinning, enabling the researcher to perform man-in-the-middle attacks to view and manipulate records.

 

The report recommended that mHealth developers adopt several steps to protect their customer data:

 

• Address both the app and API security: recognize the synthetic traffic to the API as an issue arising from bots and automated tools.

 

• Secure the development process and harden apps while providing run-time protection.

 

• Protect against X-in-the-middle attacks: Expired certificates can block apps and impact the user experience. However, certificate pinning does not affect performance and availability when done correctly.

 

• Improve visibility into controls: Organizations and developers should monitor the effectiveness of the implemented controls and adjust them to comply with HIPAA mandates and sustain data security and privacy.

 

Organizations building and using mobile apps should use the OWASP MASVS (Mobile Application Security Verification Standard) to reduce risk, demonstrate proof of controls, and streamline mobile healthcare application development.

 

However, NowSecure’s 2023 security benchmark analysis revealed that 95% of 6,000+ popular mobile apps, including mHealth apps, fail to meet at least one of the seven OWASP MASVS categories that cover the mobile app attack surface. The areas of highest failure rates are:

  

• 54% of mobile apps fail MASVS-NETWORK, exposing critical user information transmitted between the mobile app and backend systems over the Internet that could be remotely intercepted to garner company data, steal user credentials, profile backend attacks, phish users, and violate privacy mandates.

 

• 47% of mobile apps fail MASVS-PLATFORM, allowing theft of sensitive data through interprocess communication between other mobile apps and leaving the mobile app open to device-based attacks. 

 

• 43% of mobile apps fail MASVS-CODE, indicating improper coding practices, such as failure to validate information, use of insecure third-party libraries, and failure to use mobile app protections built into mobile OS and development languages.  

 

Some of the recommended actions to address these gaps in mHealth app security include

 

1. Reviewing the OWASP MAS project resources to understand mobile app security requirements and testing processes.

 

2. Establishing release policies across dev, DevOps, security, and compliance teams using OWASP MASVS requirements. 

 

3. Generating OWASP MASVS self-attestation reports or using third-party penetration testing attestation reports to demonstrate that the organization has taken proven measures.

 

mHealth app developers must:

 

• Follow secure development best practices laid out by the OWASP Software Assurance Maturity Model (SAMM) or NIST.SP.800-218 Secure Software Development Framework (SSDF) for secure architecture, design, and threat modeling
• Ensure that security measures are the priority
• Comply with policies and regulations
• Identify and address security issues that cybercriminals may target
• Test the mHealth app continuously as it is built and afterward 

 

Secure architecture and coding practices usually prevent common coding vulnerabilities, such as memory corruption flaws.

 

Developers should follow best practices, such as the OWASP SAMM and NIST SSDF, to avoid introducing these flaws in the first place, use anti-tamper mechanisms and robust data transfer protocols, and perform continuous security testing to discover and fix vulnerabilities throughout the development pipeline.

 

Read also: 10 Best Practices for FinTech Application Security in 2025

 

For instance, when developing an app for physician liaisons’ activity management and tracking in the Salesforce ecosystem, Onix’s specialists worked to fulfill all of the platform’s security requirements.

 

(Salesforce has its own list of requirements, such as covering at least 95% of the code with unit tests, without which it wouldn’t allow an app into its marketplace.)

Example of HIPAA-compliant mHealth app development by Onix

 

Read also: Salesforce Security Best Practices and Tips

 

The MASVS and MASTG (Mobile Application Security Testing Guide) focus on controls and technical test cases for app security assessments. You can also use the MASVS as a reference and input for a threat model to raise awareness of potential attacks.

 

You can use multiple frameworks for threat modeling, but the FDA playbook recommends the S.T.R.I.D.E. framework as a guide to help navigate the approval process. If your app qualifies as a medical device and therefore requires FDA approval, software security is integral to the approval process.

 

The app should implement measures to prevent and mitigate

 

S – Spoofing

T – Tampering

R – Repudiation

I – Information disclosure

D – Denial of service

E – Elevation of privileges

 

Apps based on cross-platform and hybrid frameworks may be susceptible to platform-specific vulnerabilities. The programmers should follow the security best practices of the framework they use.

 

Passwords, PII, financial information, and other sensitive information on a device should be protected by encrypting.

 

Apps that collect, store, or transmit PHI data should use cryptography according to industry best practices defined in external standards, such as NIST.SP.800-175B and NIST.SP.800-57. App developers should also follow best practices for key generation, storage, and protection.

 

The integrity of data in transit is typically ensured by encrypting it and authenticating the remote endpoint Transport Layer Security (TLS) certificate. However, using low-level APIs or third-party libraries may lead to disabling the platform’s secure defaults.

 

Mobile apps have many data entry points: the UI, IPC, network, and file system. By treating incoming data as untrusted input and properly verifying and sanitizing it before use, developers can prevent classical injection attacks like SQL injection, XSS, or insecure deserialization and bypass of security checks.

A client’s assessment of collaboration with Onix on mHealth app development

 

Tip 4. Test your mHealth app rigorously

The following DevSecOps (development, security, and operations) best practices will help safeguard protected health information:

 

• Establish a standards policy in pre-production

It will help developers understand how to code and security analysts – what to test. Creating a policy based on the OWASP MASVS helps ensure that a mobile app meets a baseline level of security. It should also be aligned with FDA and any other regulatory requirements.

 

• Continuously test new builds with automation

Developers who deploy continuous automated security testing directly into CI/CD can ensure the quality of their builds daily.

 

They can fix issues as they appear, decreasing the risk of security or privacy issues getting into production. Automation can cover 80%-90% of security testing requirements for high-risk mobile apps.

 

• Embed remediation info into ticketing systems

Just-in-time remediation instructions, code samples, training resources, and links to iOS and Android documentation embedded into security issue tickets help developers save the time and effort they’d spend searching for solutions otherwise. 

 

A medical app must pass through the highest quality assurance (QA) standards before publication. The earlier in the development cycle QA standards apply, the more secure code you will get.

 

Your mHealth product development team must deploy policy-based, continuous automated mobile app security testing in pipelines, feeding issues, and embedded remediation to developers to speed resolution.

 

A medical mobile app development team must address multiple QA aspects:

 

• Data security

Ensuring the code is free from malware and any recognized vulnerability, such as Common Vulnerabilities and Exposures, is critical. Security tests help identify and eliminate operating system and service vulnerabilities, application flaws, improper configurations, or risky end-user behaviors.

 

It is essential to test how data can be generated, stored, and modified on the server side. QA engineers must ensure that all secure data transition principles are implemented on the server and client sides.

 

• Data privacy and confidentiality

This includes the testing of the app’s authorization and access control measures. 

 

• Penetration testing

You can’t automate features like multi-factor authentication or CAPTCHA; a professional security analyst should periodically perform manual pen testing to verify the security of areas that automation can’t cover.

 

Regular pen testing using OWASP MASVS and OWASP MASTG and static and dynamic code analysis are necessary. For example, the mobile applications for cancer patients’ caretakers mentioned above periodically undergo penetration testing by external providers.

 

• Usability

This testing will help discover and fix any issues that may result in adverse user experiences or impact health outcomes. 

 

• Performance

Performance testing is crucial for healthcare apps that sustain high loads and allow users to perform their tasks under any circumstances.

 

Apart from these, there should be testing for compliance with relevant privacy acts, the app’s integration with third-party services and devices, etc.

 

Once you have thoroughly tested your mobile app, you may release it to the App Store or Google Play or distribute it to users on an ad hoc basis. An mHealth app for Android devices should obtain an App Defense Alliance (ADA) Mobile Application Security Assessment independent security review for the Google Play Data safety section.

 

Tip 5. Continuously improve data security in healthcare apps

Health mobile app development is an ongoing process. After the first release, the team should continuously iterate the product, gradually adding new features. Based on the collected user feedback and analytics, you need to plan for further app improvements, redesign, scaling, or expansion to more platforms or markets.

 

Regular testing for bugs and vulnerabilities is essential for data protection. Furthermore, you will benefit from optimizing your app’s user experience.

 

 

The team should also continuously monitor cybersecurity threats to the mHealth app.

 

Read also: How to Use Machine Learning in Fraud Detection

 

The software will require maintenance to keep up with technological advancements and future security vulnerabilities. A support team should constantly monitor critical metrics, receive alerts on resource usage and security threats, and ensure that up-to-date libraries are used to maintain security. 

 

The product team should also monitor data security in healthcare, e.g., annual “state of security” reports, vulnerabilities revealed by cybersecurity agencies, legislation developments, etc. 

 

Wrapping Up

Healthcare data security is one of the most critical issues you have to keep in mind while launching your own app. Firstly, it is an obligatory requirement of federal and international data protection regulations.

 

Secondly, the data vulnerability can lead to business losses and will have a negative impact both on the company’s reputation and internal processes.

 

For example, those who build solutions for the US or the European market need to meet the HIPAA or GDPR requirements, respectively. Patients, healthcare providers, and administrators need to be assured of security, privacy, and adherence to all governmental regulations even before downloading the app.

 

By applying proven technologies, you can prevent data breaches and other illegal activities around your patient PHI and otherwise improve your software and customer experience. 

 

If you’re interested in professional and secure mobile app development for healthcare purposes, please contact Onix. Our teams have been building mobile and cloud healthcare apps for years, always prioritizing privacy and data security.

 

We can offer modern solutions that perfectly fit your software, can ensure that the app will be functional, easy to use, and secure, and can resolve your most complicated problems.

 

FAQ

 

What is GDPR’s definition of ‘personal information’?

It’s virtually any data that relates to a natural person who can be directly or indirectly identified.

 

Besides obvious identifiers like the name, ID number, email address, location data, or online identifier, ‘personal information may refer to factors specific to an individual’s physical, physiological, mental, genetic, cultural, social, or economic identity.

 

Even pseudonymous data, if it enables relatively easy identification, may be ‘personal data.’ 

 

What is protected health information (PHI)?

PHI is defined as any patient’s information about the identity, medical history, laboratory results, insurance coverage, and other data that can be linked to a specific individual.

 

What is PHI in the United States?

Protected health information is made by the combination of data relating to a patient’s health, condition, or payment details for the provision of healthcare, with any of the 18 listed identifiers.