Testing a HealthTech App Before Launch: What to Get Right

Test a HealthTech app in four engineering areas before launch: access control, so only the right person reaches a patient's data; audit logging, so every access and change is recorded; consent, so data is used only as agreed; and encryption in transit. These you can test. Whether the product meets HIPAA, GDPR or another regime is a separate legal question.

This is general engineering information, not compliance or legal advice; confirm your obligations with your compliance adviser. If you would rather have the engineering tested for you, see how RAITHub would test this below, and pair any build with a compliance partner.

What can you actually test, and what needs an adviser?

Keep the two apart. QA can prove that your access rules, audit log and consent logic behave as designed. It cannot make a product "compliant": compliance is an obligation on your organisation, decided with a professional. The HealthTech page states the same plainly, and RAITHub has built a healthcare scheduling app for a client but has not shipped a regulated health product.

Area	What QA can prove	What needs your adviser
Access control	Only the right role and the right relationship reach a patient's record	What roles and relationships the regime requires
Audit logging	Every read and change of sensitive data is recorded and cannot be edited	What must be logged and for how long it is retained
Consent	Data is used only where consent is recorded, and withdrawal takes effect	What consent is legally valid and when it is required
Encryption	Traffic uses TLS; data at rest is encrypted where configured	Which encryption and key-management standards apply
Data subject rights	Export and deletion produce the right data and leave nothing behind	Which rights apply and the lawful timelines

How do you test access control for patient data?

Access control is the highest-risk area, because one bug can expose many records. Broken access control is A01, the top risk, in the OWASP Top 10:2025. Health apps add a twist: access is not just about role, but about relationship. A clinician may read their own patients, not every patient. Write a matrix that includes the relationship, then test the "Refuse" cells with two accounts per role.

Action	Patient	Treating clinician	Other clinician	Admin
Read own record	Allow	Allow, own patients	Refuse	Per policy, logged
Read another patient's record	Refuse	Only if treating	Refuse	Per policy, logged
Write a clinical note	Refuse	Allow, own patients	Refuse	Refuse
Change own role	Refuse	Refuse	Refuse	Allow
Export patient data	Own only	Per policy	Refuse	Per policy, logged

Test every cell through the API, not the screens, because the screens hide what the API still allows. OWASP calls the cross-record case broken object level authorization (OWASP API1:2023). The defensive auth plan in full, including the self-promotion and session tests, is in testing login, roles and data access, and the isolation hunt is in users can see another tenant's data.

How do you test audit logging?

A health app usually needs a record of who accessed what, and that record has to be trustworthy. Test that the log is written and that it cannot be quietly changed.

• Read a patient record as a clinician, then confirm an audit entry exists with the actor, the record, the action and the time.
• Change a clinical note and confirm both the change and its author are logged.
• Try to edit or delete a log entry through the API. It must be refused; audit logs should be append-only.
• Confirm a failed access attempt is also logged, not only successful ones.
• Confirm the log does not itself leak data it should not, for example a full record body where an identifier would do.

An append-only, hash-chained log design is covered in designing an audit log customers trust.

How do you test consent and data-subject rights?

Consent is logic with legal weight: test that the logic behaves, and leave the legal validity to your adviser.

• Record a consent, then confirm the data use it covers is allowed and an uncovered use is refused.
• Withdraw consent and confirm the covered use stops on the next request, not at the next login.
• Run a data export for a patient and check it contains their data and only their data.
• Run a deletion and confirm the data is gone from the primary store and from derived copies such as search indexes and backups where your policy requires.

How do you test encryption and transport?

• Confirm every endpoint is served over TLS and that plain HTTP redirects or is refused.
• Confirm sensitive data is not written to application logs, error trackers or analytics.
• Confirm tokens and session cookies are flagged secure and HTTP-only, and expire sensibly.
• Confirm data at rest is encrypted where your infrastructure and policy require, and that keys are not in the repository.

These checks confirm the engineering is in place; they are not a certified security assessment.

Buy, build or hire this testing?

Option	Choose this when	Trade-off
A certified health-IT platform or EHR module	You need a vendor that already carries certifications and attestations	You test integration, not the core; licensing and lock-in apply
Your own Playwright and SQL suite	A developer can own the access matrix, audit and consent tests	Lowest cost to run; you design the relationship-based access tests yourself
A certified penetration test and compliance auditor	A customer, regulator or BAA requires a formal report or attestation	Necessary for sign-off; broader and more costly than functional QA
A managed QA plan or a one-off pre-launch audit	You want access, audit, consent and transport tested end to end as engineering	An outside dependency; it is not a certified assessment, and keep the tests in your repository

Doing the engineering tests yourself is realistic: plan 4 to 6 days for a developer who knows the stack. The main risk of going alone is testing role but not relationship, so a clinician can reach a patient who is not theirs.

Why RAITHub for this

• Access control and audit logging are everyday work. Sundor Skin, a B2B platform RAITHub built, runs 146 PostgreSQL tables under row-level security with a hash-chained audit log and 530+ tests. RAITHub has also built a healthcare scheduling app for a client.
• Tests at the database, the API and the screen, so access is proven where it is enforced.
• Honest limits. This is engineering QA, not compliance. RAITHub has not shipped a regulated health product, its security testing is application-level against OWASP guidance and is not a certified penetration test, and it holds no SOC 2 or ISO 27001 certification. Confirm your legal obligations with your compliance adviser.

When you don't need us

• Your app holds no patient data, for example a public information site. Use the general pre-launch checklist.
• You have a QA engineer and a compliance partner already covering this.
• You need a certified assessment or a BAA. That needs a certified vendor and your adviser; RAITHub provides neither.

How RAITHub would test this

• Scope: agree the roles, the relationships and the sensitive data on a free 15-minute call; you confirm you are authorised to have the app tested.
• Plan: a risk map of access, audit, consent and transport, with a test for each.
• Test: the access matrix including relationship rules, audit append-only behaviour, consent and withdrawal, export and deletion, and transport security.
• Deliver: a ranked bug report with reproduction steps and a suggested fix, plus the access and audit tests as automated tests in your repository.
• What you receive: the report, the tests and a handover note. IP is yours; an NDA is standard. This is engineering QA, not a compliance attestation.

The audit is fixed-price, quoted in writing after the call. See QA as a Service, security testing, and the HealthTech industry page. To book it, ask for a pre-launch QA audit.

General information only; confirm compliance obligations with your adviser. Documentation checked on 10 October 2026.

Frequently asked questions

What should you test before launching a HealthTech app?

The engineering you can prove: access control including the clinician-patient relationship, audit logging, consent and data-subject rights, and encryption in transit. Start with access control, since one bug there can expose many records.

Can QA make my health app HIPAA compliant?

No. No app is compliant on its own; compliance is an obligation on your organisation, decided with a compliance professional. QA can prove your access rules, audit log and consent logic behave as designed, which supports a programme but does not certify it. Confirm your obligations with your adviser.

How do you test access to patient data?

Write a matrix that includes the relationship, not only the role, then test each cell through the API with two accounts per role. A clinician should reach their own patients and be refused another clinician's patients; test the refuse cases explicitly.

How do you test an audit log in a health app?

Perform a read and a change, confirm an entry is written with actor, record, action and time, and confirm a failed attempt is logged too. Then try to edit or delete an entry through the API; it must be refused, because the log should be append-only.

Is application-level security testing enough for a health product?

It is useful but not sufficient for sign-off. Application-level testing against OWASP guidance finds functional access and data bugs. A certified penetration test and a compliance auditor are separate and may be required by a customer, regulator or BAA.

Has RAITHub shipped a regulated health product?

No. RAITHub has built a healthcare scheduling app for a client and has not shipped a regulated health product. For a regulated build, pair RAITHub's engineering with a compliance partner and a certified assessor.