Implementing NCPDP SCRIPT REMS Transactions: An InfoWerks Pilot Report & Practitioner’s Guide

In 2024 the NCPDP Foundation awarded InfoWerks a grant to demonstrate how the REMS transactions added to the NCPDP SCRIPT Standard^© in May 2022 could be put to practical use in the live pharmacy workflow — pre-dispense, real time, and at the point of decision. This document is the deliverable of that grant. It describes what we built, who we built it with, how we tested it, what we learned, and how any pharmacy management system, exchange platform, or REMS administrator can replicate what we did using the same standard.

It is intentionally written from InfoWerks’s vantage point. It is not a normative standards document — those are owned and published by NCPDP. This is a working report from the team that did the build, written for the next team that wants to  Implement electronic adjudication of REMS transactions.

We are grateful to the NCPDP Foundation for funding this work and to our pilot partners — CVS Specialty and Syneos — for making it real.

— Jeff Deitch, CEO, InfoWerks Data Services

 

1. Executive Summary

Risk Evaluation and Mitigation Strategies (REMS)  is the FDA’s safety program for medications whose benefits and risks require active management. For more than two decades, the day-to-day operation of REMS has run on phone calls, faxes, portals, and PDF attestations. NCPDP added REMS transactions to its SCRIPT Standard^© in May 2022 to provide a structured, electronic alternative; uptake on the pharmacy side has been slow.

The pilot described in this guide demonstrated end-to-end use of those transactions in three phases between October 2024 and July 2025:

• Pharmacy Management System (PMS) — CVS Specialty: detect a REMS-eligible dispense and originate a REMSRequest.
• Exchange Platform (EX) — InfoWerks RxREMS Navigator: validate, route, and relay.
• REMS Administrator (RA) — Syneos: evaluate enrollment and certification status and reply with a REMSResponse containing either a REMS Case ID or a denial reason.

The pilot validated the round trip publicly at NCPDP’s Collabor8 Proof of Concept Workshop on July 8, 2025 (Scenario 4) and confirmed that the SCRIPT REMS transactions are sufficient to support pre-dispense, in-workflow REMS adjudication for both authorized and denied cases.

This guide reports the build and offers a step-by-step path any integrator can follow to do the same.

 

2. About InfoWerks

InfoWerks is a healthcare data interoperability company that has been moving pharmacy data — securely, accurately, and at scale — since 1997. Our work historically centers on data conversions between pharmacy management systems and on dependable, vendor-neutral integration between pharmacy, clinical, and administrative systems. The RxREMS Navigator built for this pilot extends that integration practice into the REMS exchange role.

Project lead: Jeff Deitch, CEO & Founder, InfoWerks. Jeff has been a contributing NCPDP member for more than three decades and currently serves on NCPDP’s Board of Trustees, Strategic Planning Committee, and as Board Liaison to the Innovation Subcommittee. He co-chairs NCPDP’s PTI accelerator Task Group.

 

3. Background and Motivation

3.1 Why REMS Is Hard Today

REMS workflows are still primarily manual and weakly integrated. Published studies have documented:

• Health systems taking three weeks to three months to implement a new REMS program.
• Pharmacies needing up to 160 hours to onboard a single REMS drug.
• Patient-level delays of 3-27 days for lenalidomide at a single safety-net hospital, with 10.9% of patients delayed more than two weeks.
• Delays as short as three days correlating with readmissions and increased cost.
• Documented equity impacts (e.g., the mifepristone in-person dispensing requirement).

These are the patient-facing consequences of an industry that runs a safety program through PDFs and portals.

 

3.2 Why the SCRIPT REMS Transactions Matter

The May 2022 update of the NCPDP SCRIPT Standard^© added REMS transactions specifically to allow pharmacies, REMS administrators, and intermediaries to exchange the REMS-relevant information electronically and in real time. The opportunity is to make the REMS check part of the dispense workflow, not a parallel manual process. The constraint to date has been adoption: there has been little to no uptake on the pharmacy side, so the transactions exist but have not been demonstrated end-to-end in live operation.

 

3.3 What This Pilot Set Out to Prove

The grant proposal made one core promise: produce a working, non-proprietary demonstration that the SCRIPT REMS transactions can be used by a pharmacy to verify REMS requirements before dispensing, and document it well enough that other PMSs, exchanges, and REMS administrators can adopt the same approach. This guide is that documentation.

A second, deliberate intent: take advantage of being purpose-built. The legacy switch-based REMS approach that existed previously was an adaptation of payer claim adjudication infrastructure to REMS purposes and was abruptly removed from the market in 2020. Our approach is built around the clinical workflow rather than the claims workflow, and is built for the REMS use case from the start.

 

4. Actors and Roles

Three system roles participated in the live exchange. The Pharmacy Management System (PMS) originates the transaction; the Exchange Platform (EX) is the integration point that handles validation, routing, and relay; the REMS Administrator (RA) is the decision authority.

4.1 Pharmacy Management System (PMS) — CVS Specialty (pilot)

Responsibilities:

• Detect that the prescription being processed is for a REMS-controlled product
• Generate a SCRIPT-conformant REMSRequest containing patient, prescriber, pharmacy, and product details
• Receive and process the resulting REMSResponse (authorization or denial) in the pharmacist’s workflow

 

4.2 Exchange Platform (EX) — InfoWerks RxREMS Navigator

Responsibilities:

• Accept an inbound REMSRequest from the PMS over a secure, authenticated channel
• Validate message structure, schema conformance, and required fields
• Identify the correct REMS Administrator for the submitted NDC and route the request
• Relay the REMSResponse back to the originating PMS
• Provide structured error responses where the request cannot be processed

 

4.3 REMS Administrator (RA) — Syneos (pilot)

Responsibilities:

• Evaluate the REMSRequest against the program rules and the current enrollment / certification state of the patient, prescriber, and pharmacy
• Return a REMSResponse with either a REMS Case ID (authorization) or a structured rejection reason
• Maintain transaction logs sufficient to support compliance and audit

 

5. Supported Use Cases

5.1 Core Functional Use Cases Validated

• Pre-dispense REMS compliance check. The PMS asks, in pharmacist-readable terms, “may I dispense this REMS drug to this patient?” The RA replies with either an authorization (containing a REMS Case ID) or a denial (containing a structured reason).
• Authorization with Case ID return. When the patient, prescriber, and pharmacy are all in good standing for the program, the RA returns the REMS Case ID, which the PMS records.
• Structured denial. When any condition is not met, the RA returns a denial reason the pharmacist can act on — for example, missing patient education, pharmacy not certified, prescriber NPI not found.
• Error handling and retry logic. Schema, transport, and routing errors are reported back to the PMS with standardized codes so the originator can correct and resubmit, retry transient failures, or escalate to the RA.

 

5.2 Real-World Scenarios Tested

The pilot exercised the full range of conditions an RA must distinguish:

• Pharmacy deactivated
• Pharmacy certified
• Prescriber not found
• Prescriber deactivated, for a new REMS program (FNRP – Female of Non-Reproductive Potential) patient
• Prescriber certified, FNRP patient
• Prescriber deactivated and pharmacy pending (enrollment attempted but incomplete)
• Prescriber certified, but NPI mismatch (returns “prescriber not found”)
• Patient enrolled, FNRP patient
• Patient disenrolled
• Patient pending (enrollment attempted but incomplete)

Each scenario produced the expected REMSResponse outcome, and the rejection reasons surfaced cleanly to the PMS for pharmacist action.

 

6. The Workflow

The pre-dispense REMS check runs in real time inside the existing pharmacy workflow:

• The pharmacist initiates a dispense for a medication the PMS recognizes as REMS-controlled.
• The PMS authenticates against the EX (OAuth 2.0) and posts a REMSRequest.
• The EX validates the message envelope, schema, and required fields, identifies the RA responsible for the submitted NDC, and forwards the request.
• The RA evaluates the request against the program rules and current enrollment / certification state and returns a REMSResponse.
• The EX relays the REMSResponse back to the PMS.
• The PMS surfaces the result — Case ID or structured denial reason — to the pharmacist, who completes or holds the dispense accordingly.

This is the workflow validated as Scenario 4 at NCPDP’s Collabor8 Proof of Concept Workshop on July 8, 2025.

 

7. Testing and Validation

The pilot proceeded in three deliberate phases. Each gated the next.

7.1 October 2024 — Initial Prototype Testing

Goals: prove the message structure and the internal routing.

• Verified XML structure compliance for REMSRequest and REMSResponse against the SCRIPT Standard schemas.
• Tested internal routing PMS → EX → simulated RA.
• Identified gaps in error handling and retry-edge cases. Most error paths needed clearer rejection codes than the first cut allowed.

 

7.2 January 2025 — Controlled Partner Testing

Goals: live message exchange with the real partners.

• Live exchange between CVS Specialty (PMS), InfoWerks (EX), and Syneos (RA).
• Validated prescriber lookup logic, REMS enrollment responses, and system timeouts.
• Captured example REMSRequest and REMSResponse transactions with edge-case rejection logic. Selected examples are reproduced in the References section of this guide.

 

7.3 July 8, 2025 — Live Connectathon (NCPDP Collabor8)

Goals: real-world system-to-system testing under external observation.

• Scenario 4 (PMS → EX → RA → EX → PMS round trip) validated in front of external observers at NCPDP’s Collabor8 event.
• Results confirmed successful flow for both REMS authorization and denial routing.

 

8. Edge Cases We Hit and Solved

Most of the difficulty in REMS integration is in the seams. The following are the edge cases the pilot deliberately exercised. None are exotic; all of them surface in production traffic.

8.1 Invalid or Non-REMS NDC

If the submitted NDC is not part of any REMS program, the EX should reject the request at routing time with a standardized error code so the PMS can correct and resubmit without involving the RA.

 

8.2 Incomplete Patient Requirements

If a patient has not completed the REMS-required actions (education, consent, periodic re-attestation), the RA must deny with a clear, actionable reason — not a generic failure — so the pharmacist knows exactly what is outstanding.

 

8.3 Mismatched or Invalid Prescriber/Pharmacy Credentials

Invalid NPIs, deactivated prescribers, and non-certified pharmacy IDs must produce specific, recognizable rejections (e.g., “Prescriber Not Found”, “Pharmacy Deactivated”). Generic “denied” is not enough — remediation depends on knowing which credential failed.

 

8.4 REMS Administrator Platform Downtime

If the RA is offline or unreachable, the EX must detect the condition and return an appropriate error to the PMS distinguishable from a business-logic denial. Retry logic must be available for transient errors so the PMS can recover automatically when the RA returns.

 

8.5 Multi-Program Drug Conflicts

Some products participate in more than one REMS program. When the request is ambiguous, the RA must identify which program applies and respond accordingly. A future enhancement we recommend: an EX-level lookup that lets a PMS query the available programs for a given NDC before initiating the request.

 

9. How to Replicate This — Implementation Guide

This section is the practical “how to do what we did.” It is written for pharmacy technology vendors, system integrators, and internal IT teams.

9.1 Step 1 — Decide Your Role

Identify which of the three roles you are implementing:

• PMS: you originate REMSRequest and consume REMSResponse.
• EX: you accept REMSRequest, validate, route to the correct RA, and relay REMSResponse.
• RA: you receive REMSRequest, evaluate against program rules and current enrollment state, and emit REMSResponse.

Each role has different conformance obligations. The sections below cover the PMS and EX paths most directly; RA implementations should additionally hold to their specific program manuals.

 

9.2 Step 2 — Onboarding and Credentials

To exchange with an EX, you will need:

• Onboarding credentials (client ID and client secret) provisioned by the EX
• A sandbox endpoint with known test patients, prescribers, pharmacies, and products
• The list of REMS programs supported by the EX you are exchanging with

 

9.3 Step 3 — Authentication

Authenticate against the EX using OAuth 2.0 Client Credentials.

POST https://login.microsoftonline.com/<tenant-id>/oauth2/token

grant_type: Client_Credentials
client_id: <your-client-id>
client_secret: <your-client-secret>
resource: api://<application-id>

The response includes a bearer token, its expiration, and the resource it authorizes. Cache the token until shortly before its expiry; re-acquire on need rather than per-call. (See Appendix A for a worked example.)

 

9.4 Step 4 — Build and Send a REMSRequest

Send the REMSRequest to the EX over HTTPS POST, authenticated with the bearer token from Step 3.

POST https://apim-infowerks-gateway.azure-api.net/api/remsrequest
Authorization: Bearer <token>
Content-Type: application/xml

The request body must conform to the NCPDP SCRIPT Standard^© schemas (transport.xsd, structures.xsd, ecl.xsd, datatypes.xsd, and the relevant transaction schema). The minimum content of a REMSRequest is patient demographic identity, prescriber NPI, dispensing pharmacy NCPDP ID, and the product NDC. See Section 10 for the field-level table.

 

9.5 Step 5 — Process the REMSResponse

Two outcome shapes are possible:

• Body contains a REMSCaseID. Record it against the dispense.
• Body contains a structured rejection — ErrorCode plus human-readable description. Surface the description to the pharmacist; do not collapse to “denied.”

Treat envelope-level errors (<Error> block at the message level) as distinct from program-level denials. The first should trigger correction-and-resubmit; the second should trigger pharmacist action.

 

9.6 Step 6 — Test and Validate

Before going live:

• Run the full set of scenarios listed in Section 5.2 against the sandbox.
• Exercise every edge case in Section 8 against the sandbox.
• Log every request and response in full. REMS is a regulated workflow — assume audit.
• Confirm with the EX and the RA that your sandbox conformance is good before any production credentials are issued.

 

9.7 Step 7 — Going Live

Move to production only after conformance has been confirmed. Operate with the same logging discipline as the sandbox. Maintain a runbook for the RA-downtime case (Section 8.4) so on-call pharmacy staff know what the PMS will surface and what the manual fallback looks like.

 

10. Field-Level Reference

The fields below are the core elements exchanged. Full schema is owned and published by NCPDP; see the NCPDP SCRIPT Standard^©, External Code List^©, and Data Dictionary^© on www.myncpdp.org for the authoritative definitions.

Field	Message	Description	Type	Required	Notes
`Patient/Name/FirstName`	`REMSRequest`	Patient’s legal first name	String	Yes	Must match REMS enrollment record
`Patient/Name/LastName`	`REMSRequest`	Patient’s legal last name	String	Yes	Standardized formatting recommended
`Medication/Drug/NDC`	`REMSRequest`	NDC for prescribed drug	String	Yes	Must be on the REMS program product list
`Prescriber/NPI`	`REMSRequest`	Prescribing provider’s NPI	String	Yes	Used to verify prescriber certification
`Pharmacy/NCPDPID`	`REMSRequest`	Submitting pharmacy’s NCPDP identifier	String	Yes	Must be certified or pending for REMS participation
`REMSCaseID`	`REMSResponse`	Unique case identifier confirming REMS authorization	String	Conditional	Returned only when authorized
`ErrorCode`	`REMSResponse`	Standardized rejection reason	String	Conditional	Returned when request is denied or fails validation

 

The NCPDP schema set the pilot used:

Schema	Purpose
`transport.xsd`	Envelope structures and top-level elements for each transaction
`structures.xsd`	Common, reusable domain structures
`ecl.xsd`	Vocabulary constraints for a business transaction
`datatypes.xsd`	Small, static, reusable structural components (e.g., `PostalCode`)
`script.xsd`	SCRIPT domain transactions
`specialized.xsd`	Business domain transactions

 

11. Error Handling Reference

The pilot identified and exercised the following error conditions at the envelope and routing layers. Each produced a standardized response the originator could act on.

• The message tag is missing the xsi:noNamespaceSchemaLocation
• The xsi:noNamespaceSchemaLocation attribute contains an invalid value.
• The message tag is missing any version attribute.
• The version attributes do not have a consistent valid value.
• The specified XSD file version is unavailable.
• The To element is missing the ZZZ qualifier in the header tag.
• Invalid 11-digit NDC provided in the To
• Request failed in XML parser error.
• Request failed in XSD validation.
• The NDC is not available to route the request to a REMS administrator.
• Received error from REMS administrator.
• REMS administrator server refuses to fulfill the request or is unavailable.
• REMS administrator response fails XSD validation.

A representative response envelope:

<?xml version=”1.0″ encoding=”UTF-8″?>
<Message DatatypesVersion=”2025011″ TransportVersion=”2025011″
TransactionDomain=”SCRIPT” TransactionVersion=”2025011″
StructuresVersion=”2025011″ ECLVersion=”2025011″
xsi:noNamespaceSchemaLocation=”transport.xsd”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<Header>
<To Qualifier=”C”>77777777</To>
<From Qualifier=”ZZZ”>66215050115</From>
<MessageID>c7b3f6f535cd4b0f87f547097be43638</MessageID>
<SentTime>2025-04-24T07:18:30</SentTime>
<SenderSoftware>
<SenderSoftwareDeveloper>Infowerks</SenderSoftwareDeveloper>
<SenderSoftwareProduct>RxREMSNavigator</SenderSoftwareProduct>
<SenderSoftwareVersionRelease>1</SenderSoftwareVersionRelease>
</SenderSoftware>
</Header>
<Body>
<Error>
<Code>900</Code>
<DescriptionCode>210</DescriptionCode>
<Description>Unable to process transaction. Please resubmit.</Description>
</Error>
</Body>
</Message>

 

12. What Worked, What We Would Do Differently

A short list of lessons we learned in the build that may save the next team time.

1. Build the error catalog before the happy path. Most of our second-phase rework was because the rejection codes were not specific enough for pharmacist action. Specific beats elegant.
2. Treat the EX layer as opinionated routing, not a passthrough. The EX’s job is more than relay — it is also the place where invalid envelopes get rejected fast, and where NDC-to-RA routing logic lives. Build it that way from the start.
3. Make the auth token caching strategy explicit. Naïve token-per-request worked in testing and failed under load. Cache the token to its expiry minus a small buffer.
4. Log every transaction in full, in both directions. REMS is regulated. The cost of logging the bytes is trivial compared to the cost of not being able to reconstruct an exchange.
5. Co-design the response surface in the PMS UI. A structured denial that the pharmacist sees as a generic “denied” is no better than the manual workflow it replaces. The PMS partner needs to render the denial reason where the pharmacist will act on it.

 

13. Future Directions

The same standards-based pattern this pilot exercised has direct application to neighboring high-touch clinical workflows:

• Pre-dispense gene-drug interaction checks fit the same request/response shape.
• Digital therapeutics. Authorization-to-dispense checks for prescription digital products.
• Specialty pharmacy verification more broadly, including coordination with electronic prior authorization.
• Querying REMS program participation in advance of dispense (the multi-program ambiguity case described in Section 8.5).

Each of these is a candidate for the next pilot.

 

14. Acknowledgments

This work was funded by an NCPDP Foundation Grant to InfoWerks. We thank the NCPDP Foundation for the grant and the NCPDP Foundation Board for its review and stewardship.

Pilot partners:

• CVS Specialty — Pharmacy Management System
• Syneos — REMS Administrator

This document references the NCPDP SCRIPT Standard^©, External Code List^©, and Data Dictionary^©. Those publications are owned by NCPDP. For the authoritative standards, see www.ncpdp.org.

 

15. About InfoWerks

InfoWerks Data Services, LLC is a healthcare data interoperability company founded in 1997 and headquartered in the United States. Our practice covers pharmacy data conversion, archive, and integration; healthcare provider data services (HPOAssure); and exchange platforms — of which the RxREMS Navigator built for this pilot is an example.

Contact:

• Jeff Deitch, CEO: jeff@infowerks.com
• General: info@infowerks.com
• infowerks.com

 

16. References

• S. Food and Drug Administration. *Risk Evaluation and Mitigation Strategies | REMS.* 
• Duke-Margolis Center. *Final Meeting Summary: REMS Integration Workshop.* 
• Barlas S. *FDA Intensifies Drive to Reduce REMS Burdens.* P&T. 2016 Feb;41(2):103-19.
• Pai JS et al. *Improving Delays in Obtaining Lenalidomide at a Large Safety Net Hospital.* Blood. 2021;138 (Supplement 1):1925.
• Tsourounis C, Ghomeshi KK. *Delayed Clozapine Prescription in an Elderly Man with Dementia.* AHRQ PSNet, July 2019.
• Sarpatwari A et al. *Patient and Caregiver Experiences With and Perceptions of REMS Programs With ETASU.* JAMA Network Open. 2022;5(1).
• Thompson A et al. *The Disproportionate Burdens of the Mifepristone REMS.* Contraception. 2021;104(1):16-19.

 

Appendix A — Worked OAuth 2.0 Token Example (Sanitized)

Request:

POST https://login.microsoftonline.com/<tenant-id>/oauth2/token

grant_type:    Client_Credentials
client_id:     <client-id>
client_secret: <client-secret>
resource:      api://<application-id>

Response (sanitized):

{
“token_type”: “Bearer”,
“expires_in”: “3599”,
“ext_expires_in”: “3599”,
“resource”: “api://<application-id>”,
“access_token”: “<JWT>”
}

In production, treat client_secret and access_token as confidential credentials.

 

Appendix B — Sample REMSRequest/REMSResponse Pairs

Production-style samples (with PHI elements removed) are available from InfoWerks on request and were demonstrated live at the July 8, 2025 NCPDP Collabor8 workshop.