HIPAA-compliant Software Development – Complete Guide

This article is dedicated primarily to HIPAA-compliant mobile app development but may be of interest to any healthcare provider or software developer.

 

Smartphones and wearables are widely used for telehealth, and even hospitals and insurance companies’ adoption of mobile devices is growing. Simultaneously, as data breaches become more problematic, the developers of healthcare apps for mobile and wearable devices (mHealth) should increasingly focus on patients’ data security and privacy.

 

In the U.S., they are regulated by HIPAA (meaning Health Insurance Portability and Accountability Act of 1996). It governs the management, storage, and transmission of protected health information (PHI). Since September 2013, all doctors, hospitals, insurers, and other entities that deal with PHI have been obliged to follow HIPAA guidelines to ensure compliance.

 

 

Healthcare app developers are primarily preoccupied with the HIPAA Privacy and Security Rules published by the Department of Health and Human Services (HHS). The first requires protection for certain electronically stored or transferred health-related information. The second outlines the safeguards whose implementation is necessary for HIPAA compliance.

 

The efforts of software developers and others to meet the national standards set in the Rules are overseen by the HHS Office for Civil Rights (OCR). There is no governmental structure responsible for formal HIPAA certification of organizations and products, but it spawned a whole industry encompassing HIPAA training, audits, consulting, legal assistance, and more.

 

This article offers advice on how a healthcare or health insurance app can meet HIPAA requirements so that it becomes popular and profitable and doesn’t subject you to the OCR sanctions. Many of the tips will be relevant for apps targeting other countries as well.

 

The first step is to understand all applicable terms and whether HIPAA software requirements apply to your mHealth app in the first place.

 

Applications that Require HIPAA Software Compliance

The need for HIPAA compliance is determined based on two criteria:

 

1. the type of information an application produces, shares, or stores
2. the type of entity the software deals with or is intended for

 

1. Information

The healthcare software domain interacts with two types of information:

 

I. Сonsumer health information (CHI).

This type includes data that apps can gather even from a fitness tracker, e.g., heart rate readings, the number of steps walked, calories burnt, etc.

 

II. Protected health information (PHI).

PHI consists of health data and personal identifiers. The first type of data relates to a patient’s physical or mental health or condition and to payments for the healthcare. This encompasses doctor bills, emails, lab test results, MRI scans, and other data generated, utilized, or disclosed when healthcare services are provided. Health data also includes information related to patients’ healthcare insurance coverage and even geolocation details that locate a person within a territory smaller than a state. 

 

The mere fact that an individual has received medical services may count, but health data becomes PHI only in combination with personally identifiable information.

The rule of thumb is: if an application collects, processes, stores, or transfers any PHI, HIPAA software compliance is mandatory.

 

2. Entities

According to Privacy Rule, two types of organizations should seek HIPAA compliance:

 

I. Covered entities

Covered entities include:

 

• hospitals, clinics, nursing homes, pharmacies, private practices, dentists, psychotherapists, chiropractors, or other healthcare providers for whose financial and administrative transactions HHS has adopted a standard; 

 

• health plans, such as health insurance companies, health maintenance organizations, company health plans, government programs like Medicare and Medicaid, and the military and veterans health care programs;

 

• clearinghouses that act as middlemen between the healthcare providers and insurers and process non-standard health information received from both. 

 

An application designed for use by a covered entity, such as communication between doctors and patients, will be most likely subject to the regulation. HIPAA software requirements may apply even to apps that deal with hospital employee records and education records for medical institutions.

 

II. Business associates

These persons or organizations collect, store, process, or transfer individually identifiable health information as part of a service to, or on behalf of, a covered entity. This category comprises attorneys, accountants, billing firms, software vendors, hosting/data storage, email, and encrypted email services, healthcare app developers, and other third parties that may handle patients’ data even unintentionally.

 

When in doubt as to the laws and regulations to follow, these instruments may prove useful:

 

• Mobile health apps interactive tool
• Covered entity guidance
• Security risk assessment tool

 

Anybody who qualifies as a covered entity or business associate must:

 

• Implement the appropriate administrative, physical, and technical safeguards according to the HIPAA Security Rule to ensure the confidentiality, integrity, and security of electronically transmitted PHI (ePHI).
• Minimize the use and sharing of PHI to the extent required to accomplish the intended task.
• Minimize the number of entities and individuals who can access patient information and implement employee training focused on protecting such information.
• Sign a business associate agreement (BAA) with each party that has access to its PHI to ensure that the PHI will be appropriately safeguarded.

 

Now, let’s focus on HIPAA software requirements that are critical for web and mobile app developers.

 

 

Requirements for HIPAA-compliant Software Development 

Software developers and IT vendors that deal with HIPAA-covered entities and PHI should strive to implement all applicable administrative, physical, and technical safeguards mentioned above. 

 

For example, the physical data standards apply to the physical access to ePHI that is stored in the cloud, remote data center, on-premise server, and even PCs, laptops, tablets, or smartphones. They require protection of the back-end, a network for data transfer, and ensuring that ePHI cannot be compromised if mobile devices are hacked, lost, or stolen.

 

Nowadays, much of the burden of physical security standards has been taken over by HIPAA-compliant cloud hosting companies like Amazon Web Services (AWS), Firehost, Rackspace, or TrueVault. Other aspects are handled by software developers’ internal rules regarding access to PHI and access management. You can find basic information relating to administrative safeguards and physical data security here.

 

This article is primarily focused on HIPAA information technology requirements that distinguish the development of HIPAA-compliant mobile apps from other types of software. The modifications in the development process, app features, and design are mostly related to the technical safeguards – the ideal workflow an app must follow in handling ePHI.

 

 

 

The applicable requirements and best practices can be divided into three groups:

 

1. Access control requirements:

• Assigning unique user identification code/number/name for tracking user identities 
• Established procedures for getting access to required ePHI in case of an emergency, e.g., power failure
• Verification of the identity of a person that requests access to ePHI via a password or PIN, smart card, key, or biometric data
• Automatic termination of a computer’s or device’s work after a certain period of inactivity
• Encryption and decryption of ePHI data at all stages

 

2. Transmission security:

• Security measures for eliminating the chances of undetected data modification by unauthorized persons
• Encrypting ePHI during transmission wherever required

 

3. Audit and integrity standards:

• Hardware, software, and procedural mechanisms for recording, tracking, and checking the work of systems that handle ePHI
• Policies, procedures, and solutions that protect ePHI from unauthorized modification or destruction

 

The technical safeguards determine the mechanisms used to secure and control access to ePHI that can be shared between or stored on servers and devices. For example, the technical policies for HIPAA compliance require the encryption of ePHI at rest and in transit once it leaves the organization’s internal firewalled servers. In the event of a data breach, it will preclude bad guys from deciphering, reading, and using this data.

 

Before we delve into the specifics of HIPAA-compliant app development, it will be useful to recollect why businesses put up with the increasing complexity and cost of HIPAA compliance.

 

The Growing Need for HIPAA Compliance

What is HIPAA compliance all about? The benefits for healthcare providers and patients, such as identity theft prevention, are undeniable. The stringent regulations also urge developers to adopt a far-reaching and innovative approach to infrastructures and solutions, making them more competitive. However, the main goal of businesses and institutions is to minimize the financial risks.

 

HIPAA compliance mistakes come at a high price: the penalties for bypassing the HIPAA compliance rules and regulations start from $120 per violation and can reach $1,806,757 per year. 

 

The leading causes of security breaches reportedly included:

 

1. hacking and IT incidents
2. unauthorized disclosure
3. loss or theft of devices

 

Each person whose data was exposed makes a separate case. For example, in 2021, a health insurer agreed to pay $5,1 million to settle a breach that affected nearly 9,4 million records.

Image source

 

For startups, such consequences of non-compliance in healthcare data protection can prove deadly. Luckily, even beginners can leverage the wealth of knowledge amassed over the years.

 

The following recommendations are relevant to healthcare providers, insurers, health tech companies, and other entities bound to ensure HIPAA compliance.

 

Best Practices for Organizations to Promote HIPAA Compliance

 

1. Adopt the minimum necessary rule

This best practice can be formulated as follows:

• Do not collect more data than you will need
• Don’t store data for longer than is required for your work

 

An entity that gathers and keeps superfluous information not only fails HIPAA standards but also wastes resources on this data storage and protection. Continually assess how much information your app actually needs to operate and bring value to the users. 

 

According to the HIPAA Privacy Rule, no person should see more information than their job requires. (The rule also specifies the patient’s rights to view and grant or restrict access to their own information.)

 

HIPAA compliance is easier to achieve when all trackable user data is cloud-based and stored in secure servers. Eliminate unnecessary collection and storage, track only the data that you really need, and exclude from your analytics any data that may violate HIPAA rules. Limit the sharing of PHI to the minimum required to accomplish the intended tasks.

 

2. Separate the PHI

Figure out which of the data can be categorized as PHI and see what PHI you can avoid storing or transferring through your app.

 

It’s recommended that all patients’ health data should be kept in a separate database, away from other app data. That way, you can avoid constantly encrypting and decrypting every byte.

 

3. Involve the personnel

Teach your employees to identify cyber-attacks, take the necessary proactive and reactive measures, and report incidents. You also need a sanctions policy in place, should employees bypass HIPAA compliance rules.

 

Designate a security and privacy officer to take precautions for securing all data handled by the organization and to guide employee behavior accordingly. They should systematically assess the risks and detect the organization’s vulnerabilities and other factors that jeopardize the availability, confidentiality, and integrity of the PHI. 

 

4. Perform an initial risk analysis

First of all, determine where PHI comes from and where it is stored, maintained, and transferred. Find out what security threats existing vulnerabilities pose and try to estimate their potential impact, as well as the impact of a possible data breach. Prioritize the risks to address.

 

Scrutinize the existing security practices and their application. Define the most suitable audit controls for your systems that contain or use ePHI.

 

Share the risk analysis report across the organization, discuss it with competent persons, and develop an actionable plan including protective measures and alleviation of the identified issues.

 

5. Reduce risks and fine-tune the processes 

Eliminate non-conformities progressing from minor to major issues. You may start with implementing two-factor authentication, sign a BAA with your backup provider, then organize relevant HIPAA training for the employees, and so on.

 

6. Dispose of PHI properly

PHI that is no longer needed should be erased. As long as a copy of such PHI remains in one of your backups, the data isn’t considered “disposed of.” Archived and backup data can also hide in photocopiers, scanners, MRI or ultrasound machines, laptops and other portable devices, memory cards, USB flash drives, DVDs/CDs, flash memory in motherboards and network cards, ROM or RAM, and even floppy disks. 

 

Developers should take measures to dispose of all the unused data in a safe, non-retrievable manner. They should also properly destroy the media that contain PHI before throwing or giving them away. In flash-based memory drives, such as USB sticks, data is spread over the media, making it difficult to erase sensitive information with regular data destruction software. Manufacturer utilities, such as Samsung Magician, can do the job.

 

7. Make HIPAA compliance a long-term strategy

Your organization and software products will keep evolving, and so should their security. 

 

Focus on the HIPAA requirements from the initial stages of your mHealth app development and check if you need to comply with any other privacy and security regulations before you set off.

 

 

Document all your efforts to protect PHI throughout the development process and beyond.

 

Regular technical and non-technical evaluations of such efforts will be required. The regulator has published an audit protocol that can help you assess your HIPAA compliance.

 

Set up procedures for monitoring HIPAA issues as you go. You will need to track PHI access, detect security issues, regularly reassess the effectiveness of security measures, and estimate the potential risks to compromising ePHI.

 

For each release of your app, provide specifications, plans to test its security, and their results. 

 

It may be beneficial to employ network monitoring software. As a minimum, such tools can track logins into the system and, at maximum, automatically provide compliance reports.

 

The following chapter will describe some app features supporting compliance with HIPAA and technology that software developers can leverage to implement such features.

 

Features and Solutions for HIPAA-compliant App Development

The minimum list of features that are essential to HIPAA-compliant products includes the following:

 

1. Data access control 

Any system that stores PHI should restrict viewing and alterations to the information. 

 

Role-based access control allows app developers to implement those restrictions by granting to groups of users, e.g., doctors, lab technicians, or administrators, privileges essential to their jobs.

 

Another way to accomplish this is to assign a unique ID for identifying and tracking the activities of each user accessing your system. Then, you can grant each user a set of privileges allowing them to view or modify specific data, and then regulate access to individual database entities and URLs.

The simplest form of user-based access control consists of two database tables: the list of privileges with their IDs and the distribution of those privileges to individual users. In the above case, a doctor (user ID 1) is entitled to create, view, and update medical records; the lab technician (user ID 2) can only update them.

 

After assigning privileges, app developers need to enforce regular authentication and preclude access to the system without authentication.

 

Blockchain technology may also prove helpful for the prevention of tampering with patients’ data. 

 

2. Person and entity authentication

Several HIPAA-compliant ways to implement proof of identity are recommended:

 

• Password or Personal Identification Number (PIN). To reduce the risks of data breaches due to weak or stolen passwords, healthcare apps should:

 

• require passwords that consist of at least eight characters, including capital letters, numbers, and special symbols, and excluding the commonly used vocabulary words and combinations, such as “password,” “qwerty,” or “123456”
• preclude the use of the username variations
• prevent password reuse

 

An app may check these requirements on the signup screen and decline weak passwords.

 

• Biometrics (e.g., fingerprint, face ID, or voice patterns). For a better authentication process and user experience, it’s helpful to offer fingerprint authentication: it will protect sensitive data if a device is lost or stolen.

 

• Physical means of identification, e.g., smart card, key, or token.

 

Multi-factor authentication combining a secure password/PIN with other verification methods reinforces an app’s security. The second element can be anything from a one-use security code received via SMS to a biometric scanner. The idea is simple but effective: if hackers obtain a user’s password, they’ll also have to steal their device or fingerprints to access sensitive data.

 

• A digital signature. Hackers can get between the user’s device and your servers and access the PHI without compromising the account, which is known as session hijacking. Re-entering the password when signing off on a document would prove the user identity.

 

Other ways to ensure that only authorized personnel can access the data include regular change of passwords by employees and access control audits. 

 

3. Access during emergencies

An emergency occurs when a natural or man-made disaster disrupts the operations of essential services and networks. However, healthcare providers should be able to access and protect ePHI under all circumstances.

 

Neither should authorization get in the way of aiding patients in an emergency. For example, a doctor may need to urgently view a patient’s records. It’s reasonable to allow authorized users to access any data they need when the situation requires so while the system automatically notifies several other people and launches a review procedure.

 

4. Automatic logoff

A system containing or using PHI should automatically terminate a session after several minutes of inactivity in the app. This protects PHI in the case a user loses their device while logged in. To continue, a user would have to re-enter their password or be verified in another way. 

 

5. Encryption/decryption

The encryption of all data and communications with the apps is the best way to ensure PHI integrity. iOS and Android devices tend to store data on disks when the network is offline. Whether at rest locally on smartphones, stored with a SaaS or cloud server, or traveling between apps and servers, all data needs encryption. Even if hackers steal patient data, it will make no sense to them without the decryption keys.

 

If your app asks for sensitive user data, you need to embed a system for automatic encryption of all the data, whether it is stored locally or transmitted to a central server.

For the encryption of data stored in the software system – backups, databases, and logs – experts can leverage RSA and AES algorithms and encrypted databases like SQLCipher.

 

For the end-to-end encryption of data during transmission, you can use services like AWS’ Amazon S3 or Google Cloud that run Transport Layer Security 1.2. TLS can be enough by itself, but AES 256-bit encryption can fortify it further.

 

Gmail doesn’t provide the necessary protection for PHI sent via emails. If you send emails beyond your firewalled server, they need to be encrypted. Browser extensions, the OpenPGP encryption method, or a HIPAA-compliant email service like Paubox that can do the job.

 

All parties should also encrypt the hard drives of all devices that contain PHI. Encryption tools like BitLocker for Windows or FileVault for Mac OS can do this.

 

6. Secure PHI transmission 

To protect the PHI that circulates over the network and between the system’s different tiers, app developers also need secure connections and protocols.

 

To this end, they should force HTTPS at least for the signup screens, all pages containing PHI and authorization cookies, and ideally for all communications. This secure communication protocol encrypts data with TLS.

 

App developers need to get an SSL certificate from a trusted provider, properly install it, and make sure to use a secure SSH or FTPS protocol for sending PHI-containing files instead of the regular FTP.

 

During client-server data transfers, when the data has to be transmitted in the body of the POST requests, the system may first encrypt them on the sender’s side and decrypt on the receiver’s side. This helps prevent man-in-the-middle attacks.

 

For data in transmission, using SSL-enabled endpoints with Amazon S3 is the best option. Some features include EC2 AMI Creation or Snapshotting.

 

When the information is in transit between a device and server, you can use modern cipher suites and TLS to handle data on the move. When the devices operate in untrusted networks such as public Wi-Fi, the app can use the certificate pinning process.

 

The developers also need to embed a Virtual Private Network (VPN) for greater file security during data transfers. Another level of certification is Health Level 7 (HL7) which provides data transfer guidelines among healthcare providers.

 

Make sure your app doesn’t send any push notifications or other automatic messages containing PHI.

 

Apps should also avoid

• the transmission of PHI via SMS and MMS because they are not encrypted
• transmitting PHI via emails (or at least limit the information that can be shared this way)
• leaking the data into backups and log files that are vulnerable when using SD cards on Android devices.

 

Once the data has landed in the server storage, the provisions around the key rotation, key management, encrypted backup, and audit logging come into play. 

 

7. Data backup and storage

Backups are essential for data integrity. Multiple copies have to be safely stored in several different locations, but only of those pieces of data that you absolutely have to keep. Avoid storing or cacheing PHI whenever possible, e.g., users’ geolocation data (other than state-level).

 

All information with a high or medium risk of data compromise should be backed up daily and stored in a secure facility.

 

The backups themselves and the cloud services that healthcare apps are connected to should also comply with HIPAA security standards. Major cloud providers, such as AWS, Aptible, Datica, Google Compute Engine, and TrueVault, help a lot by offering out-of-the-box HIPAA-compliant back-end, backup, and recovery services.

 

Continuously log your system’s downtime and any failures to back up the PHI; test the system regularly to prevent recovery failures. 

 

The app should automatically sync data between a local device and central servers so that a user doesn’t always have to stay connected to a network for accessing data.

There also should be an option for patients to erase their data from the system, including remote removal from a lost mobile device.

 

8. Audit controls and activity logs

For the organizations to know who, when, and where accessed, modified, or deleted PHI from their system, it’s essential to record each time a user logs in and out, their IP Address, point of entry, and what exactly data was accessed. The system should store and present these activity logs in a comprehensible format.

 

For recording all user-data interactions, developers may use a five-column table in a database or a log file. These columns should be:

 

• user_id. The unique identifier of a user who interacted with PHI
• entity_name. The entity with which the user interacted. (An entity represents some real-world concept in your database, such as a health record)
• record_id. The entity’s identifier
• action_type. The nature of interaction (create, read, update, or delete)
• action_time. The precise time of interaction

 

The app architecture should incorporate systems that enable security providers to access detailed logging information. Periodic audits of the activity logs should help discover if any users abuse their privileges to access PHI. It’s helpful to set up emergency alarms for detected anomalies or abnormal system behavior.

 

AWS CloudWatch is excellent at keeping a record of access to PHI. It allows for viewing the access data as graphs, running constant analytics, and stringent HIPAA security risk profiling.

 

Regarding the AWS levels of access, AWSCloudTrail may be recommended. It will help you record the data (AWS API Calls). AWS Config will let you handle AWS Resource inventory, configuration history, and configuration change notifications.

 

9. Extra security for mobile devices

Smartphones and tablets present additional risks because they can be easily stolen or lost, compromising sensitive information that was stored or accessible on the devices.

 

To prevent this, you can include into your onboarding or send via emails the instructions for users to use screen lock, full-device encryption, and remote data erasure capabilities on their Android or iOS devices.

 

Many physicians use personal smartphones to send health information. A secure messaging platform within your app will mitigate this risk. Another solution is encrypted password-protected portals where patients can read messages from their doctors without actually any PHI in them (e.g., “Dear User, you’ve got a new message from [redacted]”).

 

Even though all the above solutions together can’t guarantee your app’s absolute security, their implementation should convince an auditor that you’ve done enough to protect patient records and other sensitive information in compliance with the HIPAA requirements.

 

Further Tips on How to Build HIPAA-compliant Apps

The entire software development process should occur with an eye on fulfilling government requirements for healthcare applications. 

 

Hire experts

If you don’t have enough expertise or experience in HIPAA-compliant software development, it’s always better to hire third-party experts to advise you, review your existing app architecture, audit your entire system, and analyze your current preparedness.

 

A qualified HIPAA or security specialist will help you understand what kinds of data you deal with qualify as PHI. This may be the first step to a new app development, allowing to design the future database properly. The expert can also advise on what kind of data you can avoid sharing through your mHealth app and define the security requirements for it.

 

 

Outsourcing healthcare software projects to an agency with a corresponding track record also can solve this problem while saving costs. Experienced healthcare app developers will build your product faster, and the hourly rates of remote developers are often considerably lower than in the US. This is a bonus both for startups and established health tech companies and healthcare providers.

 

Another good practice is to outsource testing to a third party that can audit your app developers’ work by running all necessary tests.

 

Upon release, you can periodically hire professionals to audit your app’s infrastructure and code.

 

Use third-party solutions that are already HIPAA-compliant

Instead of trying to build a HIPAA-compliant app from scratch, it’s reasonable to take maximum advantage of high-quality third-party solutions and ready-made infrastructure that are already HIPAA-compliant. This is called IaaS – Infrastructure as a service – and dramatically saves time, money, and effort.

 

Leading hosting providers take responsibility for security while storing or managing PHI data, and you won’t have to worry about signing a BAA with them. AWS and TrueVault are good examples of HIPAA-compliant technology you can use for healthcare software development.

 

Continually monitor, maintain, and test your mHealth app’s security

Establish a long-term strategy for monitoring all HIPAA-related aspects of your healthcare app.

 

Even a minimum viable product (MVP) requires thorough testing with fake users and data to ensure security, particularly the gateways and authorization processes. Then, you will need to perform testing and validate your app’s security after every update. Test it both statically and dynamically, consult with experts, and make sure the documentation is up to date.

 

Maintenance is another ongoing process. Libraries, tools, frameworks, and third-party services are constantly being updated. Make sure you are using the latest version to prevent operation issues and security breaches.

 

Here are some more tips on how to deal with mobile apps:

 

• Use an efficient privacy policy that clearly explains how you treat the patients’ health data.
• Follow secure mobile development best practices, such as OWASP Mobile Top 10.

 

Final Words of Wisdom

In 1996, the U.S. Congress enacted HIPAA, meaning, among other things, to help protect patient information from theft and fraud. Nowadays, the consequences of non-compliance may be disastrous and the penalties for violating HIPAA may reach $1.8 million per year. 

 

To minimize these risks, a healthcare company can hire a third-party agency to audit or consult them, provide the appropriate instruction, and even issue a corresponding certificate. However, remember that being HIPAA-certified does not equal being HIPAA-compliant; it means only that a company has completed a training course on becoming compliant. Moreover, OCR doesn’t recognize any third-party HIPAA certification either.

 

Finally, third-party services may be useless if you engage them after building your software without proper administrative and technical policies for HIPAA compliance; addressing these requirements from day one is the wisest.

 

Infrastructure should be set up to ensure safe collection, storage, and transfer of sensitive information and to prevent its unauthorized or accidental alteration. Measures like access authorization combined with distinct user roles and access rights to different app features, data encryption, and regular backups are indispensable when building HIPAA-compliant software.

 

Whether it is mHealth, SaaS, eCommerce, or FinTech application development, Onix will safeguard the users’ data under any conditions. Our team has a track record in building apps that meet all applicable federal and international security and privacy requirements.

 

Please feel free to book a free consultation if you have questions about your product’s HIPAA compliance, application development process, or outsourced design and development services.

 

 

FAQ

 

How to hire HIPAA-compliant software development consultants?

You can look for specialists on job sites and freelancer platforms, such as Upwork, or contact agencies specializing in information security, including HIPAA compliance – software development advice should fall within the scope. Alternatively, when communicating with a potential outsourcing partner, you can ask whether they have knowledgeable software engineers on board. 

 

Where are HIPAA-compliant software developers located?

Naturally, it will be the fastest and easiest to find them in the U.S. However, given the scale of IT outsourcing nowadays, it’s possible to build HIPAA-compliant apps virtually in all corners of the world. Your chances of hiring such experts are likely the highest in major outsourcing destinations, such as India, Malaysia, Singapore, the Philippines, Mexico, Brazil, Argentina, Romania, or Ukraine. 

 

Can you set up a dedicated team for developing a HIPAA-compliant app?

Yes. Onix-Systems offers dedicated full-time teams on flexible employment and pricing terms, always focusing on regulatory compliance and intellectual property protection.

 

 

How many HIPAA-compliant apps has Onix released to date?

Onix-Systems counts nearly a dozen such products on its track record.