How do you test pharmacy software and e-prescribing?

What is under test between the prescription and the medicine?

The gap, and everything that changes inside it. A prescriber signs an order in one system. A pharmacy receives a transaction, decides what to hand over, and records what it handed over. Somebody then gives the medicine and records that too. Nothing in that sequence guarantees that the three records agree, and no single application owns all three.

The regulation splits the work the same way, which is useful because it tells a test plan where the seams are. The clinical criteria at 45 CFR 170.315(a) list computerized provider order entry for medications at (a)(1) and drug-drug, drug-allergy interaction checks for CPOE at (a)(4) as two separate paragraph letters. Electronic prescribing sits somewhere else again, in the care coordination group at (b)(3), with real-time prescription benefit at (b)(4). Ordering a drug, checking it, transmitting it and pricing it are four scopes, and a suite that tests the first as though it covered the others is testing a quarter of the path. What each of those criteria obliges a certified module to do is set out on the ONC certification criteria a product is tested against.

Two properties of pharmacy data make this harder than an ordinary form. The payload carries a number with a unit, so a defect can change the dose while the message stays valid and nothing is rejected anywhere. And the order is not final: it can be changed, cancelled, renewed and refilled after it was signed, so the record under test keeps moving after the test case that created it has passed.

Which records are you reconciling, and what are they called?

Three, and HL7 v2 gives each of them its own message code. HL7 Table 0076, the list of message type codes, carries RDE as "Pharmacy/treatment encoded order message" and RAS as "Pharmacy/treatment administration message", and the comment property on each entry places both in chapter 4, Order Entry. Table 0003's entry for trigger event O01 reads "ORM - Order message (also RDE, RDS, RGV, RAS)", so five message codes share one trigger event. That leaves the message code as the only thing separating an order from a dispense and from an administration.

The naming is not stable across HL7's own publications, which is worth knowing before an interface specification is read literally. Table 0076 displays ORM as "Pharmacy/treatment order message" while chapter 4 heads the same message "ORM - general order message", and the Table 0076 comment for ORM reads "4 - Deprecated". An interface built on ORM traffic is built on a deprecated message whose label depends on which HL7 page the author had open. How to hold that kind of local agreement steady across two endpoints is the subject of the order of work for an HL7 v2 interface test, and this page does not repeat it.

The ordered, dispensed and administered records in pharmacy software testing, each with the question it answers and the assertion a test makes on it.

The record	The question it answers	The assertion
Ordered	What did the prescriber sign, in what quantity and unit	The signed order, read back after the transaction was accepted
Dispensed	What did the pharmacy hand over, and how much of the order remains	The dispensing record, plus the quantity still outstanding on the original
Administered	What was given, to whom, at what time	The administration record, matched to the patient and to the order it came from

A discrepancy between any two of these is a finding, and a test that reads only one of them cannot produce it. The commonest live example is a partial fill: the order says one quantity, the dispensing record says a smaller one, and the outstanding balance on the original is either recalculated or silently lost.

On the FHIR side the maturity markers decide how stable a medication test suite can be. MedicationRequest carries FMM 3 in R4, and so does AllergyIntolerance. Neither is among the eleven resources of the 145 in the R4 index that carry the Normative marker, while Patient and Observation both are. The resources holding the drug and the allergy are therefore Trial Use, and the patient they hang off is settled. HL7 also records that the R4B release confined its changes to three modules, one of which is Medication Definition, with "extensive resource additions, renames and removals". A medication test suite is therefore pinned to a release in a way a patient test suite is not, so the release string a server declares belongs on the environment sheet beside the endpoint.

How do you test the number and the unit it arrived in?

At the point of entry, because a unit defect that reaches the transaction has already stopped being visible. Two of the prescribing requirements are written tightly enough to become test cases without translation.

section 170.315(b)(3)(ii)(E) reads: "Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (that is, not cc)." That is a negative case with a named forbidden value, and it is testable in one field. section 170.315(b)(3)(ii)(F) governs the written form of the number. It obliges the product to insert a zero before the decimal point for amounts less than one, and to disallow trailing zeroes after a decimal point, when a user prescribes medications. Those are two separate cases. A quantity entered as .5 has to come back as 0.5, and a quantity entered as 5.0 has to come back without the trailing zero.

Step 5 is where most of these cases earn their place. A field that displays 0.5 correctly and transmits .5 has passed the interface conformance run and failed the requirement, because the two assertions are made at different points on the path.

The quantity also has a second life inside the claim, under a different rule with a different trigger. 45 CFR 162.1102(d) states that the Quantity Prescribed field, numbered 460-ET, "must be treated as required where the transmission meets both of the following: (1) Is for a Schedule II drug, as defined in 21 CFR 1308.12", when the transmission uses the retail pharmacy drug claim standard. That requirement took effect on 21 September 2020, and the same wording appears at 45 CFR 162.1302(d) for referral certification and authorization and at 45 CFR 162.1802(d) for coordination of benefits. One field, conditionally required, with the condition sitting in a drug schedule maintained under a different title of the CFR. A test that supplies only non-scheduled drugs never reaches the branch.

What happens to a refill when the original changes?

It has to survive, and the standard names the transactions that move it. section 170.315(b)(3)(ii)(A)(3) lists ten transaction groups a user must be able to perform, including "Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse)", "Request and respond to cancel prescriptions (CancelRx, CancelRxResponse)", "Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse)", "Receive fill status notifications (RxFill)" and "Request and receive medication history (RxHistoryRequest, RxHistoryResponse)".

Read as a state machine rather than a checklist, that list is the test plan. Each named transaction moves a prescription that already exists, and the interesting cases are the orderings nobody drew.

• A renewal request arrives after the original was cancelled.
• A change response arrives after a fill status notification for the original quantity.
• A cancellation arrives for a prescription that has already been partly dispensed, so the outstanding balance and the cancellation disagree.
• A medication history response is requested while a change is still outstanding, so the history contains a version of the order that no longer applies.

Three of the ten groups exist purely to tell the sender what happened: "Relay acceptance of a transaction back to the sender (Status)", "Respond that there was a problem with the transaction (Error)" and "Respond that a transaction requesting a return receipt has been received (Verify)". Silence is a fourth outcome and it is not in the list, which makes it the case worth building deliberately. Hold a response back and assert what the sending system decides the prescription's state is while it waits.

The last group, at roman numeral (x), covers electronic prior authorization: PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse and PANotification. The rule text attaches a condition to it: "These transactions are required if using the standard in Sec. 170.205(b)(2)." A product moving to the newer standard therefore acquires nine more transactions to test on the day it moves, and the move has a fixed date.

Which dates are already fixed in the plan?

Four, all of them in operative regulation text rather than in guidance.

Four fixed dates in 45 CFR 170.315(b)(3) and 45 CFR 162.1102 that change which NCPDP standards pharmacy software may use, with the change on each.

Date	What changes
31 December 2027	Last day 45 CFR 170.315(b)(3)(ii)(A)(1) permits the standard at 45 CFR 170.205(b)(1) or (2)
1 January 2028	45 CFR 170.315(b)(3)(ii)(A)(2) permits only 45 CFR 170.205(b)(2); the adoption of the older standard expires the same day
14 August 2027	45 CFR 162.1102(e) adds a second NCPDP retail pharmacy guide pair alongside the existing pair for claims
14 April 2028	45 CFR 162.1102(f) drops the older pair, leaving the newer one alone

The two prescribing paragraphs name their standards at 45 CFR 170.205(b). Sub-paragraph (1) is the "NCPDP: SCRIPT Standard Implementation Guide; Version 2017071", whose adoption "expires on January 1, 2028"; sub-paragraph (2) is the "NCPDP SCRIPT Standard, Implementation Guide, Version 2023011". Real-time prescription benefit at 45 CFR 170.205(c)(1) names the "NCPDP Real-Time Prescription Benefit Standard, Implementation Guide, Version 13".

Two consequences follow for a product that is certified or wants to be. 45 CFR 170.550(g) obliges a certification body to certify a module to (b)(4) whenever the module is presented for certification to (b)(3), so real-time prescription benefit arrives with electronic prescribing whether or not it was in scope. And the Base EHR definition at 45 CFR 170.102 adds "(b)(4) on and after January 1, 2028" to the criteria a Base EHR must hold. A pharmacy roadmap that treats 2028 as distant has two independent obligations landing in the same January.

The claim side moves on its own dates and they do not line up with the prescribing side. Between 14 August 2027 and 14 April 2028 two NCPDP pharmacy versions are simultaneously adopted for retail pharmacy drug claims, which means a dual-version regression window rather than a cutover. Choosing what to re-run inside a window like that is the general problem set out in selecting a regression set in regulated software.

How do you prove an interaction check ran at all?

By making it leave a record, because the two outcomes look identical on screen. A check that ran against a full allergy list and returned nothing produces the same quiet screen as a check that never fired, and no user can tell them apart.

The decision support criterion supplies the timing rule. section 170.315(b)(11)(i) reads: "Interventions provided to a user must occur when a user is interacting with technology." The data those interventions run on is enumerated at section 170.315(b)(11)(iii)(A): Problems; Medications; Allergies and Intolerances; at least one demographic in (a)(5)(i); Laboratory; Vital Signs; Unique Device Identifier(s) for a Patient's Implantable Device(s); and Procedures. Eight data classes, each with its own arrival time, and the rule fixes the moment the intervention has to happen.

That combination produces the hardest case in pharmacy testing. An allergy recorded after the order was signed is data the check did not have when the rule required it to run. The test asks what the system does next: whether the order is re-evaluated, whether anybody is told, and whether the evidence of either decision exists a week later. Build the case as a sequence with the allergy arriving second, and assert on the record, not the screen.

The clause that turns this into an artefact is in the Security Rule. 45 CFR 164.312(b), audit controls, requires mechanisms that record and examine activity in information systems that contain or use electronic protected health information, and 45 CFR 164.308(a)(1)(ii)(D) obliges the entity to regularly review what those mechanisms recorded. Neither names an event list, so the testable question is local: does the interaction check appear as an entry that a reviewer can find and attribute. We do not need production PHI to test. Environments run on synthetic and de-identified data. Whoever inside the client organisation has to approve that arrangement will want the rest of the answers first, and they are set out on how we work with protected health information.

One more clause belongs here because it applies to the dispensing record rather than the order. 45 CFR 164.312(c)(1) requires policies and procedures "to protect electronic protected health information from improper alteration or destruction". A dispensing record that can be edited in place, with the earlier value gone, fails a reconciliation against the administration record and leaves nothing to reconcile against.

Note also that the older clinical decision support criterion is no longer live. section 170.315(a)(9)(vi) reads: "The adoption of this criterion for purposes of the ONC Health IT Certification Program expires on January 1, 2025." Test plans written against (a)(9) point at an expired criterion, and the live one is (b)(11).

Which codes does the medicine carry, and which version of them?

More than one version at once, which is the part that surprises teams. 45 CFR 170.207(d)(1) names RxNorm for medications and retains three releases side by side: the full update release of 4 December 2023 at (d)(1)(i), with the releases of 5 July 2022 and 8 September 2015 retained at (d)(1)(ii) and (iii). A partner answering with a code from a retained release is answering correctly, so a mapping test that recognises one release grades a valid answer as a defect.

Diagnosis coding enters pharmacy work at the point where a drug caused harm. The ICD-10-CM guidelines state at Section I.A.4: "The 'X' is used as a placeholder at certain codes to allow for future expansion. An example of this is at the poisoning, adverse effect and underdosing codes, categories T36-T50. Where a placeholder exists, the X must be used in order for the code to be considered a valid code." Those categories are exactly where a medication error is recorded, and a validator that strips or omits the placeholder rejects the correct code.

Which release to validate against is settled by 45 CFR 162.1000. Paragraph (a) ties the medical data code sets to the moment care was given; paragraph (b) ties nonmedical code sets to the moment the transaction was initiated instead. Two anchors, two clocks, and a system using one clock for both is wrong on one of them. What that costs across a code set changeover is worked through on testing ICD-10 code handling.

What does the work leave behind?

Five records, each written because somebody asks for it once the software is dispensing.

The medication reconciliation sheet holds one row per test drug, with the ordered quantity and unit, the dispensed quantity, the administered quantity, and the query that read each of the three. It is the evidence that all three records were read on the same run.

The quantity and unit case log records every entry-point case from the six steps above, with the value entered, the value stored and the value transmitted. Three columns, because the requirement can pass at one and fail at the next.

The prescription state matrix maps each transaction group named at section 170.315(b)(3)(ii)(A)(3) against the prescription states it was exercised from, including the state where no response came back. Empty cells in this matrix are the untested orderings.

The interaction evidence record holds, for each interaction check case, the entry the system wrote and the query that retrieved it. Include at least one case where the check ran and found nothing, because that is the case the record exists to distinguish.

The code set version sheet names every code system in the payload, the release validated against, and the date rule applied to it. Date it against the build, so a later reader knows which code set a passing result describes.

Those five belong to one product. Where the same work runs against partner systems that somebody else operates, the register and version matrix that sit above it are scoped as testing an exchange against the partners it runs with. Where the prescribing feature lives inside a record system, the failures that sit in the chart rather than at its boundary are covered on testing an EHR or EMR platform.

Sources for this page: the certification criteria, transaction lists and vocabulary versions were read from the eCFR text of 45 CFR part 170; the pharmacy claim standards and their dates from the CFR text of 45 CFR part 162; the message type codes and their labels from the HL7 v2 tables and product briefs; the resource maturity markers from the FHIR R4 resource index; the placeholder rule from the ICD-10-CM official guidelines; and the audit, integrity and activity review clauses from 45 CFR part 164 subpart C. Each was checked against its primary source on 2 September 2026.

What goes wrong most often?

Each item below passes a unit test on the component that produced it and fails once the three records are read together.

• The suite asserts on the transaction and never on the dispensing record, so a partial fill leaves an outstanding balance nobody checked.
• A quantity is validated on entry and reformatted on transmission, so the zero before the decimal point required by section 170.315(b)(3)(ii)(F) is present on screen and absent on the wire.
• Only non-scheduled drugs appear in the fixtures, so the conditional Quantity Prescribed requirement at 45 CFR 162.1102(d) is never reached.
• Refill and renewal cases all start from a clean original, so no case exercises a renewal that arrives after a cancellation.
• The absence of an interaction alert is graded as a pass, and no entry is retrieved to show the check ran.
• An allergy recorded after the order was signed produces no re-evaluation and no record of the decision not to re-evaluate.
• A mapping test accepts one RxNorm release, so a partner answering from a release retained at 45 CFR 170.207(d)(1)(ii) is reported as a defect.
• A poisoning or adverse effect code is validated with the placeholder X removed, so a correct code is rejected at categories T36-T50.
• The code set is validated against today's release, although 45 CFR 162.1000(a) ties the medical data code sets to the moment the care was furnished.
• Prior authorization is left out of scope because it is out of scope today, although nine of its transactions become required with the standard adopted on 1 January 2028.
• The dispensing record is editable in place, so a reconciliation against the administration record has no earlier value to compare with.