Healthcare Domain Testing

What is healthcare domain testing?

Healthcare domain testing is software testing that checks health applications against the real rules of clinical care, coding, billing and data exchange. Testers draw on workflows such as admission and discharge, code sets such as ICD-10-CM and message standards such as HL7 v2, FHIR and X12 to design realistic cases.

The difference shows up in the test cases. A generic tester checks that an appointment can be booked. A domain-aware tester checks what happens to the appointment, the referral and the eligibility check when the patient's insurance changes the day before the visit.

Domain knowledge does not replace test automation. It decides what gets automated, which edge cases get seeded into test data and which results need a clinician's eye.

Which clinical workflows should testers learn first?

Testers should start with the workflows that create, move or close a patient's record, because most other features hang off them. Learn each one end to end, including the corrections and reversals that happen in real clinics.

• Registration and identity: New patient, returning patient, duplicate detection and merge. Test what happens to appointments, results and messages when two records become one.
• Scheduling to check-in: Booking, rescheduling, no-show and walk-in. Test that cancelled visits release their slots and do not leave open encounters behind.
• Admission, transfer and discharge: For inpatient and observation stays, test transfers between units, cancelled admissions and discharges that are reversed.
• Orders to results: A lab or imaging order placed, collected, resulted, corrected and acknowledged. Test that a corrected result replaces the original visibly and notifies the ordering clinician.
• Medication lifecycle: Prescribe, modify, discontinue and reconcile. Test that a discontinued medication disappears from active lists but stays in history.
• Referrals and care transitions: Outbound referral, inbound acceptance and the summary that travels with the patient. Test the case where the receiving side never responds.
• Charge capture to claim: Visit documented, charges coded, claim built and payment posted. Test that a late documentation change updates or holds the claim.

Each workflow has a happy path and several correction paths. The correction paths are where defects hide, because demos and scripted test runs rarely exercise them, while real clinics meet them routinely.

Code sets every healthcare tester meets

Healthcare software stores codes, not words, and the code sets change on their own schedules. Testers need to know which code set each field uses and how updates reach the product.

• ICD-10-CM: Diagnosis codes for claims and problem lists. Test that the product accepts codes valid on the date of service and rejects codes that are not yet valid or have been deleted.
• CPT and HCPCS: Procedure and service codes for billing. Test modifiers, units and the pairing of a procedure with the diagnosis that supports it.
• LOINC: Lab test and observation codes. Test that local lab codes map to LOINC and that unmapped codes are flagged rather than dropped.
• SNOMED CT: Clinical terms for problems and findings. Test that a problem list entry keeps its code when displayed with a friendlier label.
• RxNorm and NDC: Medication concepts and package codes. Test that a pharmacy dispense with an NDC links to the prescribed RxNorm concept.

Date logic matters most. CDC's National Center for Health Statistics states that FY 2027 ICD-10-CM codes apply to services from 1 October 2026 through 30 September 2027, and that the release replaces the FY 2026 April 1 update. A claim for a September visit coded in October must still use the codes valid in September.

Build a small regression set around each code set update: one code added, one deleted, one with a changed description, each tested on both sides of the effective date.

How do interface messages change what testers check?

Interface messages carry the workflow between systems, so testers must check the message as well as the screen. A correct screen with a wrong outbound message is still a defect, often a worse one because nobody sees it until a partner complains.

• HL7 v2 ADT: Admit, transfer, discharge, update and merge events. Test that each workflow step in the product sends the right event, in the right order, with the patient and visit identifiers the receiver expects.
• HL7 v2 orders and results: Order messages out and result messages back. Test corrected results, cancelled orders and results for orders the product never sent.
• FHIR APIs: Resources such as Patient, Encounter, Observation and MedicationRequest. Test that searches return only what the caller's scopes allow and that updates keep version history.
• X12 claims and remittance: 837 claims out, 835 remittance back, and 270 and 271 eligibility checks. Test that a denied or partly paid claim posts correctly and shows the reason.

Claim formats are fixed by regulation. Under 45 CFR 162.1102, the HIPAA standard for professional claims is the ASC X12N 837 Health Care Claim: Professional, version 005010X222. Test files should follow that implementation guide, because a clearinghouse will reject anything that does not.

Keep a library of real-shaped messages from each partner, with identifiers replaced by synthetic ones. Replaying them after every interface change catches regressions that hand-built samples miss.

Which roles and permissions need domain-aware tests?

Access in healthcare follows care relationships, not job titles alone, so role tests must reflect who is treating whom. A tester needs to know which roles exist in a clinic and what each one should and should not see.

• Care team access: A nurse can open patients on her unit or panel, not every patient in the system.
• Front desk and billing: Staff who schedule or bill see demographics and insurance but not full clinical notes.
• Proxy access: A parent sees a young child's record, but access rules change as the child reaches the ages the organization's policy sets.
• Sensitive records: Behavioral health, substance use treatment and reproductive health records may carry extra restrictions. Test that they are hidden or flagged where the policy says so.
• Emergency access: A clinician outside the care team can open a chart in an emergency, with a recorded reason and a follow-up review.

Write these as a matrix of role, patient relationship and action, and test both the allowed and the refused cells. The refused cells are the ones a security reviewer will ask about.

How do you build domain knowledge in a QA team?

Build it on purpose, with time set aside, rather than hoping testers absorb it from tickets. These steps work for a team starting from general QA experience.

• 1. Shadow real work: Have each tester observe a clinic session, a billing team or a support call queue, with permission and no access to identifiable data.
• 2. Draw the workflow maps: Turn each core workflow into a diagram with every correction path, and have a clinician or billing lead review it.
• 3. Keep a team glossary: Define terms such as encounter, order, result status, claim adjustment and merge in the team's own words, linked to the code set or standard behind each.
• 4. Build patient personas: Create a set of synthetic patients with realistic histories, such as a newborn, a patient with many chronic conditions and a patient with two insurance plans.
• 5. Add a domain review step: Before a test plan is approved, a subject matter expert reads it and adds the cases a real user would hit.
• 6. Learn from production: Read support tickets and incident reports each sprint and turn every domain defect into a new regression case.

AI assistants can help testers draft cases or explain an unfamiliar message segment, as long as they work only with synthetic data. They do not replace the domain review in step 5, because a confident but wrong explanation of a clinical rule is hard to spot without experience.

Domain test cases that generic QA misses

• Cancelled discharge: The discharge is reversed, but the product has already closed the encounter and sent a discharge summary.
• Merge after results: Two patient records merge after results arrived on both, and some results stay attached to the retired record.
• Corrected result after acknowledgment: The clinician acknowledged the first result, the lab sends a correction, and no new alert appears.
• Retro insurance change: Coverage is updated after the visit, and the claim still goes to the old payer.
• Code valid on the wrong date: A diagnosis code accepted for a visit date before the code took effect.
• Proxy access past the age cutoff: A parent keeps full access after the child reaches the age where policy limits it.
• Silent outbound failure: The screen shows a saved order, but the outbound message was rejected and nobody was told.

Add these to the regression suite as named cases. Each one needs domain knowledge to write, and each one is invisible to a suite that only follows the happy path through the screens.

How Agnotic can help

Domain gaps in testing usually show up as partner complaints and billing rework, long after release. Agnotic Technologies helps health product teams close those gaps: workflow maps with correction paths, code set regression sets, interface message libraries, role matrices and a domain review step built into the test process.

Through a healthcare fractional CTO engagement, Agnotic can set this up alongside the client's QA team and hand it over once the team runs it on its own.

Sources

• CDC NCHS: ICD-10-CM files, FY 2027 release and effective dates
• 45 CFR 162.1102: Standards for health care claims or equivalent encounter information