Healthcare mobile app testing services

What does healthcare mobile app testing cover?

The part of a health product that executes on hardware nobody in the regulated chain owns. Every other environment on this site belongs to someone with an obligation attached to it. A server is configured by the operator. A hospital workstation is issued by the organisation and can be reimaged. A device the manufacturer shipped left the factory in a state the manufacturer wrote down. A patient's phone was chosen by the patient, updated when the patient allowed it, shared with whoever the patient handed it to, and restored from a backup the patient set up years ago.

The Security Rule is written the other way round. section 164.302 obliges a covered entity or business associate with respect to electronic protected health information of a covered entity, so the duty follows the data rather than the equipment. Then section 164.306(b)(2) asks the entity, when choosing security measures, to take into account four factors, and the second of them is "its technical infrastructure, hardware, and software security capabilities". That possessive is doing the work: a handset is not its infrastructure, and it holds no inventory of one. The obligation still attaches to the data once it reaches such a device, and on what terms a test team may hold any of it is a question to raise at how we work with protected health information.

That has one consequence for a test suite and it decides most of the scope: the environment cannot be enumerated, so the thing that has to be produced is the written reasoning for the environment that was exercised, alongside the record of which handset states were driven. Absent that reasoning, a device list is a purchasing decision with test results attached.

The failures worth paying for are the ones the operating system causes rather than the ones the application throws.

• The app is terminated to reclaim memory and resumes into a restored screen drawn from a snapshot rather than from the record, so a value the user is reading was true when the app was last in the foreground.
• A biometric prompt returns success while the session behind it was ended server side, and the screen behind the prompt is still populated.
• A notification renders clinical content on a locked screen, in front of whoever is holding the handset.
• A system backup carries the app's local state onto a second handset, and the restore is performed by a person the record is not about.
• Battery saving defers a background sync, so a reading captured on the device never leaves it and no error is raised on either side.
• A system-wide font or display scale, set for a different application entirely, pushes a dose field or a units label out of the layout.
• The device clock is wrong, or the time zone is, and the entry is stamped with it.

An interface suite reports none of these, because each one happens between the payload and the person. The operator side of a patient-facing product, where the person driving the software was never trained on it, is covered in patient portal testing.

Which products does this apply to?

Any product whose user interface is installed on a device the manufacturer never touches. Three shapes recur.

A patient-facing companion app on top of a record system belongs here for everything the platform does between the API response and the screen. A telemedicine client belongs here for the parts of a consultation the operating system arbitrates rather than the media path itself. Software that is itself the device belongs here when it is distributed through a store, because the general computing platform then sits inside the product's system requirements.

A clinician-facing app on a member of staff's own phone is the same problem with a different owner. The organisation employs the user and does not own the handset, so the access controls are written against an environment it cannot configure and the workforce controls run against one it can.

Whether the software is a medical device turns on intended use rather than on the platform it was compiled for, and IEC 62304 and the classification question answers that where it belongs. This page assumes the answer is already written down, because it changes which of the standards below bind and none of what the handset does.

Which requirements does the testing close on a device you do not own?

The ones the Security Rule leaves to a decision, which is more of it than most scopes assume. The technical safeguards at 45 CFR 164.312 name five standards. Two of them, section 164.312(b), audit controls and section 164.312(d), person or entity authentication, carry no implementation specifications at all and are themselves required. The implementation specifications that would speak most directly to a handset are addressable.

HIPAA Security Rule provisions a healthcare mobile app puts under strain, each paired with what the phone does to that requirement.

What the phone does to the requirement	Where the requirement sits
The device stays unlocked in someone else's hand	164.312(a)(2)(iii) Automatic logoff, Addressable
Data at rest sits in storage the entity cannot inspect	164.312(a)(2)(iv) Encryption and decryption, Addressable
Other applications run beside yours on the same device	164.312(a)(1) Access control, which reaches "those persons or software programs that have been granted access rights"
Activity happens where the entity cannot read the log	164.312(b) Audit controls, which requires mechanisms that record and examine activity and names no events, no format and no retention period
The platform changes under a decision already made	164.306(e) Maintenance, with 164.316(b)(2)(iii) on updating the documentation

Audit controls are the row that catches product teams. The standard asks for mechanisms that "record and examine activity in information systems that contain or use electronic protected health information", and examine is the half a device-local log fails: a record that never leaves the handset cannot be reviewed, and 164.308(a)(1)(ii)(D) separately requires procedures to regularly review records of information system activity such as audit logs and access reports. A suite that asserts an event was written locally has tested the first verb.

The clause-level reading of the safeguards, including which of them are required and which are addressable, is in HIPAA testing requirements for software. Read from 164.302 to 164.318 in full, the rule returns no reference to penetration testing, vulnerability scanning, static or dynamic analysis, code review, test cases, test environments, multi-factor authentication, or any named external security standard or framework. Nothing in it can therefore be cited as the source of a specific control on a handset. What carries a control is the risk analysis at 164.308(a)(1)(ii)(A) and the written determination above, and both of those name the environment they were made against.

Which accessibility criteria only appear on a phone?

The ones WCAG 2.1 added over WCAG 2.0, which is where the version number stops being bookkeeping. WCAG 2.0 has 12 guidelines. WCAG 2.1 adds exactly one, Guideline 2.5 Input Modalities, and W3C states that the version was initiated to improve guidance for three groups, one of them "users with disabilities on mobile devices". HHS gives the same reason for choosing it in the section 504 rule: WCAG 2.1 Level AA "includes success criteria addressing the accessibility of mobile apps or web content viewed on a mobile device".

Twelve Level A and AA success criteria are new in 2.1 relative to 2.0. Eight of them are the ones a small touch screen exercises first:

Eight WCAG 2.1 success criteria new since WCAG 2.0 that a small touch screen exercises first, with the conformance level of each.

Criterion	Level
1.3.4 Orientation	AA
1.4.10 Reflow	AA
1.4.12 Text Spacing	AA
1.4.13 Content on Hover or Focus	AA
2.5.1 Pointer Gestures	A
2.5.2 Pointer Cancellation	A
2.5.3 Label in Name	A
2.5.4 Motion Actuation	A

A product already claiming WCAG 2.0 Level AA has 12 criteria to close to reach 2.1 Level AA, moving from 38 covered criteria to 50. A team that has been testing against 2.0 has therefore never run the four Level A criteria under Guideline 2.5 Input Modalities, the single guideline WCAG 2.1 added. Which legal instrument makes any of this binding on a given company, and which version each instrument names, is worked through in WCAG 2.1 Level AA accessibility requirements.

Touch target size is the criterion buyers ask about and it is not in the claim. 2.5.5 Target Size is Level AAA in WCAG 2.1, and the Level AA version, 2.5.8 Target Size (Minimum), arrived with WCAG 2.2, as did 2.5.7 Dragging Movements. Both the DOJ title II rule and the HHS section 504 rule incorporate the 5 June 2018 publication of WCAG 2.1 by reference, and DOJ says it decided not to adopt WCAG 2.2. So an obligation written to those rules does not reach target size, while W3C recommends 2.2 as the conformance target regardless of what an obligation names. A plan that names which of the two versions the screens were measured against answers a contract row that otherwise gets argued after signature.

A downloaded app raises a scoping question those rules do not settle for you. "Mobile applications" are defined at 28 CFR 35.104 as "software applications that are downloaded and designed to run on mobile devices, such as smartphones and tablets", and 45 CFR 84.84(b)(1) requires a recipient's mobile apps to comply with the Level A and Level AA "success criteria and conformance requirements specified in WCAG 2.1". The conformance requirements are written about web pages. 36 CFR part 1194 handles that mismatch explicitly, substituting "software" for "Web page" throughout the success criteria and conformance requirements for non-web software, and excusing non-web software from Conformance Requirement 3 Complete Processes. That substitution lives in the Section 508 standards, which bind agencies under E201.1 and adopt WCAG 2.0. A private developer working to the 2024 rules is pointed at WCAG 2.1 as written, so what counts as a page in an installed app is a decision to record before the first screen is measured.

One exception is shaped by file format rather than by screen. The exception at 28 CFR 35.201(d) covers "conventional electronic documents" that are about a specific individual and password-protected, and conventional electronic documents are defined at 35.104 as PDF, word processor, presentation and spreadsheet formats. An app that hands a patient a result as a downloadable PDF and an app that renders the same result as a screen sit on different sides of that line.

How do you evidence a use environment you cannot inventory?

By making the environment a written input and then justifying the one you tested in. IEC 62366-1 already treats it that way. Subclause 5.1, Prepare use specification, was amended so that the intended use environment is one of the listed elements, and the use specification is defined at 3.23 as a summary of the important characteristics related to the context of use, with the note naming the intended medical indication, the patient population, the part of the body interacted with, the user profile, the use environment and the operating principle as its typical elements. Note 3 adds that the use specification is an input to determining the intended use under ISO 14971:2019.

clause 3.20 then defines use environment as the "actual conditions and setting in which USERS interact with the MEDICAL DEVICE", and the note to it lists hygienic requirements, frequency of use, location, lighting, noise, temperature, mobility and degree of internationalization. Amendment 1 added social attributes to that note: team versus individual, chaotic versus calm, stress level and length of shift. Read against a handset, those are conditions the patient sets and the manufacturer records at best as an assumption. A usability test is defined at 3.19 as evaluation "with intended USERS within a specified intended USE ENVIRONMENT", so both ends of the definition have to be specified before a session counts.

The obligation lands squarely in the plan. Amendment 1 replaced list item e) of subclause 5.7.3, and it now requires a summative plan to state the test environment and conditions of use together with "a rationale for how they are adequately representative of the intended USE ENVIRONMENT", alongside how the participants represent the intended user profiles, the justification for grouping them into user groups, the definition of correct use for each hazard-related use scenario, and the method of collecting data. On a device the manufacturer does not select, that rationale is the artefact, and the count of handsets falls out of it.

Use error is defined at 3.21 in a way that puts the platform inside it. A note to that definition states that use errors can result from a mismatch between the characteristics of the user, the user interface, the task or the use environment. Two things are excluded from the term, and a test report has to respect both when classifying what it observed: an unexpected physiological response of the patient is not by itself a use error, and a malfunction of the device that causes an unexpected result is not one either. An event triggered by the platform therefore has to be classified before it can be counted, and the classification belongs in the report rather than in a reviewer's head. The analysis requirement at subclause 5.9, as amended, then asks the manufacturer to identify all use errors and use difficulties that occurred and to determine the root cause of any that can lead to a hazardous situation, with a use difficulty described in the new note as a close call, where a user almost commits a use error and recovers in time.

Information for safety carries its own test on a handset. Subclause 4.1.3 requires that where information for safety is used as a risk control measure, the manufacturer subjects it to the usability engineering process to determine that it is perceivable by, is understandable to, and supports correct use by users of the intended user profiles "in the context of the intended USE ENVIRONMENT". A warning delivered as a system notification is perceivable only where the user has permitted notifications, and permission is granted on the device rather than in the product. Subclause 4.1.1 sets the outer boundary of the process by naming the user interactions it has to address: transport, storage, installation, operation, maintenance and repair, and disposal, with the list stated as non-exhaustive. On a phone the manufacturer performs none of installation, update or disposal. The steps in IEC 62366-1 usability engineering set out the rest of the ten-subclause process those requirements sit inside.

What does a suite have to drive that a desktop run never reaches?

The states the operating system can impose while a clinical task is half finished. A suite that drives the app from launch to completion in the foreground has tested the path the platform does not interfere with.

Step 5 is the one that produces findings nobody has a ticket for, because a consumer backup service is outside every boundary the product's own threat model draws. Step 2 is the cheapest and the most frequently skipped: display scaling is set once, system wide, for reasons that have nothing to do with your app, and it reaches every layout you shipped.

When does this have to run again?

When the platform moves, which is a date neither you nor your customer sets. IEC 82304-1 separates the two events in its own numbering: subclause 4.5 states the system requirements, 4.6 is their verification, and 4.7 is updating them. A major operating system release moves the requirement first, and a suite that reruns 4.6 against unchanged requirements is testing last year's scope on this year's platform. The standard's post-market clause also gives decommissioning and disposal its own subclause at 8.5, which on an installed app means the uninstall path and whatever the handset keeps afterwards.

The Security Rule attaches to the same event from the other direction. section 164.306(e) requires an entity to review and modify its security measures as needed to continue providing reasonable and appropriate protection, and to update the documentation in accordance with 164.316(b)(2)(iii), which itself requires review and update "in response to environmental or operational changes affecting the security" of the data. An operating system that withdraws an API, changes a default or stops receiving fixes is an environmental change in the plain sense of that phrase. The written determination for each addressable specification was made against the old environment, and it names the environment it was made against.

Which platform changes reopen which evidence is a mapping, and it costs less to draw before a release than during one. A change to the storage or credential APIs reopens the addressable determinations. A change to the accessibility or layout stack reopens the WCAG results for every screen and every responsive variation. A change to background execution or notification delivery reopens the information for safety evaluation under subclause 4.1.3. Each row names the runs it triggers, which is what lets a re-test be scoped to a stated extent.

The regulatory position on the finished app belongs to the organisation that publishes it. What this work produces is a set of results, each naming the handset state and the platform release behind it, together with the written reasoning for why that set stands for an environment nobody in the chain controls.

Clause numbers, criterion numbers and section numbers on this page are carried from the standard pages they belong to, where each was read on 2 September 2026 against the eCFR text current to 31 August 2026, the WCAG 2.1 Recommendation, and the published contents and readable text of IEC 62366-1 Edition 1.1 and IEC 82304-1 Edition 1.0.