How Drizz Validates Prescription Screens with 10+ Required Fields on Every Build

Somewhere in your health app, a prescription screen is missing a doctor's registration number. Your functional tests pass. Your E2E suite is green. The prescription looks fine on the Pixel 8 your QA team tests on.

But on a Redmi Note 11 with large font accessibility settings, the registration number is pushed off screen by a longer-than-usual doctor name. The field exists in the element tree. Appium says it's there. The patient can't see it. The pharmacist rejects the prescription. The patient doesn't get their medication.

That missing field isn't a UI bug. It's a legal violation. In India, the Telemedicine Practice Guidelines require every digital prescription to display: doctor's full name, registration number, qualification, clinic address, patient name, age, gender, date, medicine name (generic and brand), dosage, frequency, duration, special instructions, and a digital signature or verification mark. Missing any one makes the prescription legally invalid.

Most health app QA teams check this manually. One person. Eyeballing the screen. On one device. Before every release. They miss things. Especially on the 47th prescription they've reviewed that day.

This guide shows how Drizz automates prescription compliance validation visually, reading every required field the same way a pharmacist reads it, on every build, across every device, without a single selector.

For the complete health app flow map, see The Complete Guide to Consumer Health App Flows. For the foundational context, see What Makes Healthcare App Testing Different.

Key Takeaways

• A digital prescription has 10+ legally required fields. Missing any one makes it invalid and unacceptable at pharmacies.
• Most health app QA teams validate prescriptions manually because Appium can't reliably verify information-dense screens where 10+ elements must all be present, correctly formatted, and visually readable.
• Appium needs 10+ separate selectors to validate a prescription. Each selector breaks when the prescription component is redesigned, the field order changes, or the layout adjusts for different screen sizes.
• Drizz reads the entire prescription screen visually in one test: "Verify doctor name, registration number, qualification, patient name, date, medicine name, dosage, frequency, and duration are all visible." One test. All fields. Every build.
• The ROI is immediate: replace a manual QA person spending 2-3 hours per release checking prescriptions with an automated visual test that runs in 30 seconds on every build across 5+ devices.

What Fields Must a Prescription Display?

Every digital prescription in India must include these fields per the Telemedicine Practice Guidelines and state medical council regulations:

A prescription missing field #2 (registration number) is rejected at pharmacies. A prescription missing field #10 (dosage) is clinically dangerous. A prescription where field #12 (duration) is truncated on a small screen means the patient doesn't know when to stop taking the medication.

How Most Teams Test Prescriptions Today

The Manual Approach (Most Common)

A QA person opens the app after a teleconsult, navigates to the prescription screen, and visually checks that all required fields are present. They do this on one device, in one screen orientation, with one set of test data.

Problems:

• Human fatigue: field #13 gets missed on the 30th prescription reviewed that day
• Single device: the prescription renders fine on a Pixel 8 but truncates on a Samsung Galaxy A14
• Single data set: a doctor with a 45-character name breaks the layout, but the test doctor has a 12-character name
• No CI integration: prescriptions aren't validated on every build, only before major releases
• No audit trail: there's no record of which fields were checked, when, and on which device

The Appium Approach

# Validate prescription fields - Appiumassert driver.find_element(AppiumBy.ID, "com.app:id/doctor_name").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/reg_number").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/qualification").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/clinic_address").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/patient_name").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/patient_age").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/prescription_date").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/medicine_generic").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/medicine_brand").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/dosage").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/frequency").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/duration").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/instructions").is_displayed()assert driver.find_element(AppiumBy.ID, "com.app:id/digital_signature").is_displayed()

14 selectors. 14 potential breakage points.

Problems:

• Every redesign breaks everything: When the prescription component is rebuilt next quarter (new design system, new layout, new component library), all 14 element IDs change. 14 selectors to update. 14 places where the test breaks with "NoSuchElementException" that takes 30 minutes to debug per selector.
• is_displayed() lies: Appium's is_displayed() returns True if the element exists in the element tree and has non-zero dimensions. It doesn't verify the element is actually visible on the current viewport. A registration number pushed below the fold by a long doctor name returns is_displayed() = True while the patient can't see it without scrolling.
• No visual context: Appium verifies elements exist individually. It can't verify they render together as a coherent, readable prescription. A registration number overlapping the qualification text passes both individual element checks but fails as a readable document.
• Maintenance cost at scale: A health app with 5 prescription templates (general consultation, specialist, follow-up, pharmacy refill, lab referral) needs 14 selectors x 5 templates = 70 element assertions. Each template redesign breaks 14 assertions.

How Drizz Validates Prescriptions

One Test. All Fields. Every Build

Navigate to completed consultation
Open prescription screen
Verify doctor's name is visible
Verify registration number is visible
Verify qualification is visible
Verify clinic name and address are visible
Verify patient name is visible
Verify patient age is visible
Verify date is visible
Verify medicine name is visible (generic and brand)
Verify dosage and strength are visible
Verify frequency is visible
Verify duration is visible
Verify special instructions are visible if prescribed

This test reads the prescription screen the same way a pharmacist reads it: top to bottom, checking that every required piece of information is present and readable on the rendered screen.

What Drizz Catches That Appium Misses

Truncation on small screens: A doctor's registration number is "KMC/2019/MH/45678" on a Pixel 8 but shows as "KMC/2019/M..." on a Galaxy A14 with large font settings. Appium says the element is displayed. Drizz sees the truncated text and flags it because the full registration number isn't readable.

Overlapping text: A doctor with the qualification "MBBS, MD (Internal Medicine), DM (Cardiology), FACC" has a qualification string that overflows into the clinic address line. Both elements exist in the tree. Both pass is_displayed(). But on screen, the text overlaps and neither is readable. Drizz sees the overlap.

Missing fields after redesign: The design team removes the clinic address field from the prescription template, thinking it's optional. Appium tests break with "NoSuchElementException" and QA spends an hour determining if this is a bug or an intentional change. Drizz test says "Verify clinic address is visible" and fails with a clear reason: "Expected clinic address but field is not present on the prescription screen." The failure is self-explanatory.

Font and rendering issues: A custom font fails to load on certain devices, falling back to a system font with different metrics. Text that fit in one line now wraps to two, pushing the duration field below the fold. Appium doesn't see font rendering. Drizz sees what the patient sees.

PDF vs in-app consistency: Many health apps offer prescription download as PDF. The in-app display shows all 14 fields, but the PDF generator misses the digital signature. Drizz can validate both: the in-app screen AND the downloaded PDF rendering.

Cross-Device Validation

The same Drizz test runs on:

Pixel 8 (flagship, large screen)

Samsung Galaxy A14 (budget, smaller screen)

iPhone 15 (iOS layout differences)

Redmi Note 11 (MIUI, custom font rendering)

Samsung Galaxy A54 (mid-range, popular in India)

‍

One test file. Five devices. Every required field validated visually on each. No per-device locator adjustments. No per-platform element IDs.

CI/CD Integration

On every build:

  1. Complete a test teleconsultation

  2. Navigate to generated prescription

  3. Run prescription validation test across 5 devices

  4. Any missing or truncated field = build fails

  5. AI failure reasoning explains exactly which field is missing and on which device

Total execution time: approximately 30-45 seconds per device. A 5-device validation completes in under 3 minutes. Compare this to 2-3 hours of manual checking per release.

The Maintenance Comparison

The ROI for Health Tech Teams

What You're Spending Today

A manual QA person spending 2-3 hours per release checking prescriptions across 2-3 devices:

• At 2 releases per week: 4-6 hours/week on prescription validation alone
• At 12 INR/min QA cost: approximately 2,880-4,320 INR/week, 12,000-17,000 INR/month
• Plus the risk of human error on the 30th prescription review of the day

What Drizz Replaces

• Automated prescription validation on every build (not just releases)
• 5+ devices per run (not 1-2)
• 30-45 seconds per device (not 30-60 minutes per manual review)
• Screenshot evidence for compliance audits
• AI failure reasoning that tells you exactly which field is missing and where

The CTO Conversation

"We currently have a person manually checking prescriptions before every release. They check on 1-2 devices. They miss things when they're tired. We have no audit trail for compliance. Drizz automates this: every field, every device, every build, with screenshots as evidence. The manual person now focuses on new features instead of repeating the same 14-field check twice a week."

Frequently Asked Questions

Can Drizz verify that the registration number is correct (not just present)?

Drizz validates that the registration number is visually present and readable on screen. Verifying that the number itself is correct (matches the doctor's actual registration) requires API-level validation against the medical council database. The recommended approach: API tests validate data correctness, Drizz validates visual presentation.

What about prescriptions with multiple medicines?

A prescription with 3 medicines has 3 sets of fields (medicine name, dosage, frequency, duration for each). Drizz validates: "Verify 3 medicines are listed, each showing name, dosage, frequency, and duration." The test scales with the prescription without adding more selectors.

How does Drizz handle prescriptions in regional languages?

Drizz's Vision AI reads text in the language rendered on screen. If the prescription displays medicine names in Hindi or regional scripts alongside English, Drizz verifies both are present. It validates that text renders without garbling, truncation, or character encoding issues across languages.

Does this work for PDF prescriptions as well?

Yes. Drizz can open a downloaded prescription PDF on the device and validate the same fields visually. This catches discrepancies where the in-app display shows all fields but the PDF generator misses one.

How many prescription templates does a typical health app have?

Most health apps have 3-5 prescription templates: general consultation, specialist referral, follow-up (shorter format), pharmacy refill (no new diagnosis), and lab/test referral. Each template should be validated independently since they display different field combinations.