•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
An upload test passes. The patient still receives the wrong information.
A patient uploads a prescription, opens the file, and sees no error. The automated test passes because the upload completed successfully.
On the screen, though, the dosage is cut off. The same risk appears in other document workflows. A lab report renders without its reference range. OCR changes “180 mg/dL” to “100 mg/dL.”
A notification exposes medical information on the lock screen. An unauthorized user downloads a document through a copied link. These failures do not always stop the workflow.
They change the information a patient or clinician receives. Testing prescriptions, lab reports, insurance documents, and referral letters requires more than checking whether a file is uploaded. Your tests must verify document accuracy, readability, accessibility, privacy, authorization, and recovery behavior.
This guide explains how to build a reliable test strategy for sensitive documents in mobile healthcare apps.
Use synthetic prescriptions, lab reports, insurance records, and referral letters. Do not use real patient information in test files, screenshots, videos, logs, or analytics events. Create test files with fictional patient details and controlled values. Use various file types, such as:
Use files of various sizes (big and small). Use files containing:
Use files that represent the expected behaviors of the application. Anticipated values can vary within a file. For example, within a source document, a value of “0.5 mg” can be anticipated. Expected application behavior can vary based on the value, the unit associated with the value, and the role(s) within the application that is/are permitted to view the value.
Be cognizant of variation within documents of the same type.
For prescription documents, the variation can include the name of the medicine, the strength, the dose, the route of administration, the frequency, and instructions.
For laboratory documents, variation can include the name of the test, the value, the unit, the reference range, the collection date, and a flag.
For insurance documents, variation can include the name of the insurance company, the ID of the policy, the date the coverage begins and ends, and the status of the coverage.
For referral documents, variation can include the name of the person to whom the document is referenced, the person who signed the document, and the date the document was signed.
Explicitly state the fields that are required. Do not create field requirements that do not exist.
Just because a document uploads successfully, does not mean that the document can be used to complete a task. Ensure that the application correctly interprets and renders documents. Check each page and element of a document, including text, images, symbols, and tables. Test the application’s ability to render documents of varying sizes and in different orientations. Test the application’s ability to render different fonts at various sizes. Check for:
Raise the font size to the largest available size. See if any important information, like the date, time, dose, instruction or warning, is hidden behind the smaller font size. In general, a screen should fail the test if the user is left with many questions and is left to make inferences about the missing information.
Compare OCR output to the Source Document and ensure:
The same compared values on a screen may represent different values in reality (could be a range). If the app says a value is unreadable, trigger a manual review by a clinician, require explicit re-entry with safeguards, or reject the document. Do not let the user guess the value. Verify that the safely corrected values are kept for subsequent reviews.
Review alignment of results, units, and reference ranges. If a result is incorrect or out of range, a value in a different range may be shown. For example, a value that should be displayed in milligrams (mg) may be shown in micrograms (mcg).
Use the proper range for the report and patient. Do not use the same range for all lab tests. Do not interpret a missing range as a normal value. For each boundary, use a value that is below, at or above, and test for expected flags.
Check the explanation and next step for flags that indicate the value is too high (or low). The test in no way substitutes its judgment for a physician’s judgment. Trending of lab test data requires three or more test dates.
Lab test data should be tested for missing test values and changes in unit of measure prior to performing a trend analysis. Lab test data should be plotted in the order in which it was obtained. A line on a trend chart should be plotted accurately against established reference ranges.
Do not label data trajectories as clinical improvements unless the application is strictly regulated and cleared as Software as a Medical Device (SaMD) operating on approved clinical guidelines.
Mobile document workflows often fail. Turn off Wi-Fi to prevent an upload. Background the application and wait for the application to time out and reconnect. Repeat the workflow. Perform a forced application reset. The test should verify:
Both the app and the server have the most up-to-date, pertinent information to the case and a clear next step. An unsupported or unreadable document should be rejected and a next step should be provided. An oversized image should be automatically resized and provide the next step.
The app should display a processing state if there are still extracts being processed by OCR. Empty fields should not be displayed, as that would imply that extraction has been completed. Empty fields should be identified and displayed accordingly by the app.
Supported mobile devices with operating systems across all versions should be tested. Additionally, both Android and iOS devices should be tested. The app should be tested while zoomed and in both light and dark modes.
The app should be tested to determine if content is understood while the screen is rotated to other orientations. There should be sufficient color contrast between the background and text of status indicators. Urgent and important information should be contained in the text and not solely dependent upon graphic representations. Text should be displayed in a logical order and in a format understood by a screen reader.
If keyboard accessibility is supported, it should be determined if focus is moved to hidden or unavailable content. It should also be determined if focus is lost after an invalid input. It should also be verified that all actions are supported by the keyboard.
If the app supports downloads or exports, verify every exported field against the source and the on-screen version. Check patient identifiers, dates, values, units, ranges, instructions, page count, diagrams, charts, and guidance. Open the downloaded file in a separate viewer and check for:
The exported document should follow the same access rules as the document inside the app.
Verify that the uploaded document is pertinent to the correct patient. When a document is uploaded using account A, the document should be inaccessible to account B even if account B uses a copied download link or the server’s direct download link. Test the document’s authorization at the server and the user interface (UI).
Test caregiver permissions and access revocation if the product supports these features. Check cached documents and other areas of the product that temporarily store or allow access to product documents.
Test the lock screen, app switcher and other areas that allow access to protected health information. Consult the OWASP Mobile Application Security Verification Standard for other types of tests. Remove protected health information from testing artifacts.
Test the completed document’s existence on the server and other stored attributes using the API.
Test rendering of data and other aspects of the UI. A perfectly rendered UI might mask underlying data corruption or missing server-side validation, allowing an invalid value to still be set by the server.
Drizz allows product teams to write test cases in English and test mobile applications on real devices. Further, tests can be run on simulators and real devices.
Drizz shows the automation flow in several steps. First, the flow is simulated on a device. Finally, Drizz captures video of the flow being simulated. Automation flow videos, step-level screens and videos, and other pertinent artifacts are posted on the product web page and are run evidence.
One type of test is to describe a flow to the test team like the following: “On the synthetic lab report, locate the result for glucose. Ensure that the value, unit, and range, as well as the flag and editing guidance, are displayed.”
Use this type of test to validate user flows and visible elements of the application. Keep validation of editable and non-editable fields in the application and interaction with the server to authorize/validate changes in the stored data in the API/back end of the application.
It is outside the scope of this type of test to prove the correctness or accuracy of the measured lab data. The test only validates if the application displays the value in question along with the related information, if any, in the correct format.
Intentionally add controlled failures to the test environment:
If the above are found in the test environment, the test must be stopped. Block all tests if an unauthorized document is requested, an urgent action is missing, or medical information is exposed. Save all evidence of a test failure.
Testing of the application should determine if the application is securing and preventing unauthorized access to restricted data and if the application is protecting the privacy of the patient.
The testing should determine if the application is enforcing range restrictions. Drizz provides the capability to perform test authoring in English. Tests can be executed on a physical device or emulator. Tests can capture evidence of mobile application interactions, including video of the mobile application.
The combined capabilities of Drizz and other tools enable testing of mobile application interactions with protected health information and testing of integrity, accuracy, and authorization of data.
©Drizz 2026 • All Rights Reserved
