Ask a practice manager what it takes to connect a lab and a pharmacy to the same health information exchange endpoint, and the honest answer is: two separate jobs, not one. A lab result feed and an e-prescribing connection are built on two different messaging standards that were never designed to be interchangeable. Knowing which standard governs which feed — before a vendor quote arrives — is what keeps an onboarding project from stalling on a scope mismatch.
Two Different Problems, Two Different Standards
HL7v2 is the standard that carries lab results. It is a text-based, pipe-delimited format — segments like MSH (message header), PID (patient identification), OBR (observation request), and OBX (observation/result) are strung together with the | character separating each field. The message type most commonly used for a lab result is an Observation Result message, referred to in interface work as an ORU message. HL7v2 is decades old, unglamorous, and still dominant: it remains the standard used by the large majority of U.S. healthcare organizations for clinical data exchange, including lab orders and results.
NCPDP SCRIPT solves a different problem: electronic prescribing. It is the U.S. industry standard that governs how a new prescription, a renewal request, a change request, or a cancellation moves between a prescriber, a pharmacy, and a payer. Unlike HL7v2’s pipe-delimited segments, SCRIPT messages are XML-based. They carry prescription-specific data that a lab feed has no reason to touch — pharmacy identifiers, Dispense As Written codes, prior-authorization support, and routing information that tells the message which pharmacy system should receive it.
Side-by-Side: What Each Standard Actually Does
| HL7v2 (lab feeds) | NCPDP SCRIPT (pharmacy feeds) | |
|---|---|---|
| Message format | Text-based, pipe-delimited segments | XML-based |
| Primary message types | ORU (result), ORM (order), ADT (admit/discharge/transfer) | NewRx, RxRenewalRequest, RxChangeRequest, CancelRx |
| What it carries | Numeric results, reference ranges, clinical observations | Prescription data, pharmacy routing, medication history |
| Federal mandate tied to it | No single universal mandate — adoption is near-universal by convention | CMS mandates SCRIPT for Medicare Part D e-prescribing |
| Endpoint on the other side | A lab’s results interface or the exchange’s record locator | A pharmacy’s dispensing system, reached through a SCRIPT-certified network |
What This Means When You’re Actually Onboarding a Feed
The practical consequence is that "connect our practice to the exchange" is not one onboarding project — it’s at least two, run in parallel with different endpoints, different testing cycles, and often different vendors on the other end. A lab feed onboarding typically means interface-engine work: mapping the sending lab’s HL7v2 segments to what the receiving system expects, then running test messages until the OBX result segments parse cleanly. A pharmacy feed onboarding is a different exercise entirely — it usually means enrolling with a SCRIPT-certified e-prescribing network rather than building a point-to-point interface, because pharmacies are reached through a shared prescribing network rather than one-off connections.
Practices that assume the same team, timeline, or contract can cover both often discover the gap only after the lab feed goes live and the pharmacy connection is still stuck in enrollment. Budgeting and staffing these as two distinct workstreams from the start avoids that surprise.
Four Questions to Ask Before Signing Off on an Onboarding Quote
- Which standard is this feed actually built on? If a proposal for a lab connection mentions XML message bodies, or a proposal for a pharmacy connection mentions pipe-delimited segments, something in the scoping is wrong.
- Who owns the interface engine work? HL7v2 mapping is typically a one-time build-and-test cycle against a specific sending lab’s segment layout, not a recurring subscription.
- Is the pharmacy side enrollment or a custom build? A SCRIPT connection almost never needs a bespoke interface the way a lab feed does — it needs the practice’s system enrolled and certified against the network’s own SCRIPT version.
- What version of SCRIPT is being used, and does it clear the 2028 deadline? A pharmacy connection quoted against an older SCRIPT version is a connection that will need to be redone before the compliance date arrives.
Why a Clinic Connecting to an Exchange Needs Both, Not Either
An exchange’s value comes from presenting a complete record, and a complete record needs both halves. HL7v2 supplies the clinical side — results, orders, encounter data. NCPDP SCRIPT supplies the medication side — what was prescribed, changed, or cancelled, and where it was filled. A record that has lab results but no medication history (or vice versa) still leaves a clinician guessing, which is exactly the gap duplicate testing and medication errors come from. This is also why the SCRIPT mandate carries extra weight for controlled substances: CMS has set a hard compliance date of January 1, 2028, for practices to be running SCRIPT version 2023011 for Part D e-prescribing, which means the pharmacy side of this equation is not optional for any practice billing Medicare.
Neither standard is going away, and neither one substitutes for the other. A vendor who says they’ll "handle interoperability" without naming which side of this — the HL7v2 lab pipe or the SCRIPT pharmacy pipe — they’re actually building is a vendor worth a follow-up question.
The Bottom Line
Labs speak HL7v2. Pharmacies speak NCPDP SCRIPT. A clinic sits in the middle needing both, and treating them as one undifferentiated "interoperability" line item is the most common way an onboarding timeline slips. Scoping each feed against its actual standard, and its actual endpoint, is what keeps the project honest before the first invoice arrives.