fda rems programs list · rems drugs list
FDA REMS Programs List: ETASU, Duties and Integration
October 15, 2026
25 min read
A 2026 FDA REMS programs list with 68 current programs, verified participant duties, ETASU classifications, and a practical EHR integration and audit-evidence matrix.

- 01FDA reported 68 current REMS programs at the October 15, 2026 access date. These are descriptive program counts, not drug counts, safety rankings or a trend series.
- 02Certification, enrollment, monitoring and authorization require separate operational records. Prescriber status does not establish facility enrollment or dispensing eligibility.
- 03HL7's REMS FHIR guide addresses provider workflows and leaves detailed pharmacy interactions outside its scope. Published standards do not establish universal production adoption.
- 04A clinical result, a submitted form and an accepted authorization represent different events. Integration records should preserve their evidence, timing and decision ownership.
- 05Maintain a versioned requirements registry, verify current approved materials and separate approval dates from implementation dates. Unknown control fields remain explicit until sourced.
Executive Summary
The official FDA REMS programs list is maintained through REMS@FDA and FDA's public dashboard. The accessible reports page showed 68 current programs when accessed on October 15, 2026. ([1]) FDA reported 56 programs with elements to assure safe use (ETASU), or 82%, and 12 communication-plan-only programs, or 18%. ([1]) These are descriptive program counts, rather than drug counts, safety rankings or a trend series. This report supplies the current program-name index, a selected participant-duty crosswalk and an integration matrix for implementation teams.
The central finding is that certification, enrollment, monitoring and authorization need separate operational records. CAMZYOS requires prescriber certification, pharmacy certification and patient enrollment. ([2]) ([3]) SPRAVATO certifies healthcare settings and pharmacies, with patient enrollment applying to outpatient treatment. ([4]) ([5]) LEMTRADA requires a healthcare facility to enroll separately from its prescriber. ([6]) A platform organized around a single “REMS registered” field would obscure these distinctions. The detailed crosswalk identifies the actor, required evidence and transaction checkpoint for each selected example.
Integration options also have defined boundaries. HL7's published US Medication REMS FHIR guide, version 2.0.0, STU 2, addresses provider workflows. ([7]) It supports structured interactions and form exchange, while detailed pharmacy interactions sit outside its scope. ([8]) NCPDP separately documents REMS observation elements in SCRIPT transactions. ([9]) These standards support implementation planning; they do not establish universal production adoption. The proposed matrix identifies triggering events, source evidence, record ownership, exchange direction and audit artifacts.
The editorial date is October 9, 2026, but no historical snapshot for that date was recovered. Current findings are labeled with the later access date. FDA updates the dashboard weekly, although its exact refresh timestamp was unavailable during retrieval. ([10]) Complete downloadable version records were also unavailable, so whole-inventory counts by certification or enrollment duty are withheld. The operational conclusion is to maintain a versioned requirements registry and verify the current approved document before configuring each workflow. The dashboard's stated descriptive limits guide interpretation of the inventory.
Current REMS programs reported by FDA at the October 15, 2026 access date
Share of current programs with ETASU: 56 programs; FDA's rounded percentage
Share of current programs with communication plans only: 12 programs; FDA's rounded percentage
Introduction and Background
A useful FDA REMS programs list connects each program to the people, evidence and decisions it governs. Risk Evaluation and Mitigation Strategies (REMS) can impose different requirements on prescribers, dispensers, healthcare settings and patients. The observed instructions assign different duties to individuals, facilities and pharmacies. A portfolio platform therefore needs a program-specific rule model. ([6]) ([11])
The practical audience includes program owners, pharmacovigilance and medical-information leaders, specialty pharmacies, patient-services teams and architects. Their decisions concern certification, enrollment, monitoring submissions, authorization and records. For example, CAMZYOS separately requires prescriber certification, pharmacy certification and patient enrollment, while SPRAVATO organizes important responsibilities around certified treatment settings. ([2]) ([3]) ([4])
This report supplies a complete current program-name index and a deliberately bounded operational crosswalk. The full index records observable ETASU presence and explicit shared-system designations. The detailed crosswalk covers selected programs whose participant instructions were retrieved. Its blank or unestablished fields are evidence gaps, never permission to bypass a control.
The editorial publication anchor is October 9, 2026; research access occurred October 15, 2026. These are report dates. No historical dashboard snapshot for the earlier date was recovered. Current observations are consequently labeled by access date, and approved-document dates are identified separately.
The consultancy perspective is operational. IntuitionLabs describes enterprise implementation and integration among its services; this report applies that perspective to evidence movement and system boundaries. ([12]) It provides workflow analysis for organizational implementation. Program-specific clinical decisions belong with the treating professionals and the current approved materials.
Methodology and Source Control
The source hierarchy starts with REMS@FDA, then the current approved REMS document, then participant materials and official program websites. The Congressional Research Service explains that FDA database accessibility varies with scope, data types and search capabilities, and explicitly points readers to the REMS dashboard alongside the approved-program database. ([13]) ([14])
FDA's documented data model separates REMSID, the program key, from VersionID, the version key. It also defines flags for current approval, release, movement to a shared system, ETASU, prescriber certification, dispenser certification, patient enrollment and training. These are useful join fields. Their documented existence does not mean this research successfully downloaded their underlying records. ([15])
A maintainable inventory should retain the following fields:
- Identity: FDA program key, display name and covered products.
- Version: version key, approval or revision date and effective operational date.
- Status: current approval, release and movement to a shared system.
- Participants: prescriber, dispenser, setting, patient and applicant. The roles model should preserve their distinct identities. ([16])
- Controls: certification, enrollment, training, monitoring and authorization. For example, Qsymia's certification process identifies an authorized representative and training assessment. ([17])
- Evidence: source document, exact requirement location and retained artifact. HL7 describes storing a DocumentReference in the patient record. ([18])
- Verification: retrieval date, verification owner and unresolved questions.
- Change history: previous value, new value and the decision approving implementation. The inventory should also preserve routing to the correct administrator. ([19])
These are proposed inventory-design fields. FDA's schema establishes several underlying identifiers and flags; the evidence and implementation-governance fields are analyst recommendations.
Three retrieval limitations matter. The interactive dashboard returned an unusable shell, and the permitted fallback could not retrieve it. The downloadable data route also failed to supply the complete version records. Individual program records and several approved documents remained accessible. Therefore this report uses the current FDA list for population membership and clearly identified document or program-site evidence for duties.
A weekly maintenance process should capture the published list, compare keys and versions, retrieve changed approved materials, and review changes before updating operational rules. Because the dashboard timestamp was unavailable, a refresh job should record both retrieval time and the source's own timestamp whenever exposed. Retaining the source file and its checksum is a recommended audit practice.
FDA expressly says the dashboard is descriptive and is not intended for trend analysis or cross-comparisons. Accordingly, the calculations below describe one observed population and a selected verification sample. They do not measure changes over time or compare the safety of products. ([20])
Capture the current published list and record retrieval time and the source timestamp whenever exposed.
Compare program keys and version keys to identify changes requiring review.
Retrieve changed approved materials before updating the requirements registry.
Review changes before updating operational rules, preserving version history and approved implementation dates.
“An individual prescriber's status does not establish a facility's enrollment, a submitted monitoring form does not establish an accepted dispensing decision, and product identity alone does not establish the correct program route.
Active FDA REMS Program Inventory
Table 1 is the current FDA program index, accessed October 15, 2026. Every row belongs to the currently approved list. Y means presence was directly captured; N means ETASU absence was captured; ? means the field was not established. In the shared-system column, only affirmative designations were captured. A question mark does not mean a single-product program. The common official record source for every row is FDA's current list. ([21])
| Program | ETASU | Shared system established |
|---|---|---|
| Adasuve | Y | ? |
| Alvimopan Shared System REMS | Y | Y |
| Aqvesme | Y | ? |
| Aveed | Y | ? |
| Bildyos | N | ? |
| BKEMV | Y | ? |
| Blenrep | Y | ? |
| Boncresa | N | ? |
| Bosaya | N | ? |
| Bosentan | Y | Y |
| Brixadi | Y | ? |
| Buprenorphine Transmucosal Products for Opioid Dependence (BTOD) | Y | Y |
| Camzyos | Y | ? |
| Conexxence | N | ? |
| Copiktra | N | ? |
| Elrexfio | Y | ? |
| Empaveli | Y | ? |
| Enoby | N | ? |
| Epysqli | Y | ? |
| Fabhalta | Y | ? |
| Filspari | Y | ? |
| Fintepla | Y | ? |
| Hepzato | Y | ? |
| Isotretinoin iPLEDGE | Y | Y |
| Jubbonti | N | ? |
| Juxtapid | Y | ? |
| Lemtrada | Y | ? |
| Lenalidomide | Y | Y |
| Lumryz | Y | ? |
| Lynozyfic | Y | ? |
| Mifepristone | Y | Y |
| Miudella | Y | ? |
| Myalept | Y | ? |
| Myqorzo | Y | ? |
| Nexplanon | Y | ? |
| Opioid Analgesic REMS | ? | ? |
| Ospomyv | N | ? |
| Osvyrti | N | ? |
| Palforzia | Y | ? |
| Palynziq | Y | ? |
| Phentermine and Topiramate Extended-Release Capsules | Y | Y |
| Piasky | Y | ? |
| Ponlimsi | N | ? |
| Probuphine | Y | ? |
| Prolia | N | ? |
| PS-Pomalidomide | Y | Y |
| Qsymia | Y | ? |
| Siliq | Y | ? |
| Sodium Oxybate | Y | Y |
| Spravato | Y | ? |
| Stoboclo | N | ? |
| Sublocade | Y | ? |
| Tecvayli and Talvey | Y | ? |
| Thalidomide REMS | Y | Y |
| Tolvaptan for ADPKD Shared System REMS | Y | Y |
| Transmucosal Immediate-Release Fentanyl (TIRF) Products | Y | Y |
| Turalio | Y | ? |
| Tyruko | Y | ? |
| Tysabri | Y | ? |
| Ultomiris and Soliris | Y | ? |
| Vanflyta | Y | ? |
| Vigabatrin | Y | Y |
| Voydeya | Y | ? |
| Xiaflex | Y | ? |
| Xywav and Xyrem | Y | ? |
| Zenbexus | Y | ? |
| Zilbrysq | Y | ? |
| Zyprexa Relprevv | Y | ? |
The index covers programs, rather than a unique-drug count. Product names, ingredients and program names should remain separate entities in an implementation database. Several products can be covered by one operational program: the PS-Pomalidomide site, for example, explicitly includes POMALYST and generic pomalidomide products. ([22])
The question mark on the Opioid Analgesic row preserves an uncaptured row-level observation. FDA's aggregate ETASU count is available separately; it is not used to manufacture that missing cell. Likewise, shared-system membership should be populated from the actual flag or approved record, rather than inferred from a recognizable product name.
Table 2 adds the operational crosswalk. P means prescriber, D means pharmacy or dispenser, H means healthcare setting, and Pt means patient. “Not established” describes this research's evidence boundary. The cited links are opened official documents or operational sources. All rows were verified during the same research access date; a linked operational page is not represented as the latest approved REMS document.
| Program | Participant certification or enrollment | Testing, monitoring or documentation | Dispensing or administration check | Official source |
|---|---|---|---|---|
| CAMZYOS | P and D certified; Pt enrolled | Echocardiography and patient-status documentation | Authorization for each prescription | Approved document ([23]) |
| SPRAVATO | H and D certified; outpatient Pt enrolled | Monitoring form; setting records | Verify outpatient enrollment and receiving-setting certification | Approved document ([24]) |
| Xywav and Xyrem | P and D certified; Pt enrolled | Documented safe-use conditions | Certified central-pharmacy distribution to enrolled patients | Official prescriber brochure ([25]) ([26]) |
| Lenalidomide | P and D certified; Pt enrolled | Counseling checklist and prescription documentation | Separate prescription authorization and dispensing confirmation | Official pharmacy guide ([27]) ([28]) |
| FINTEPLA | P and outpatient D certified; Pt enrolled | Cardiac monitoring and patient-status submissions | P certification and Pt enrollment/authorization | Official outpatient-pharmacy form ([29]) |
| Tolvaptan for ADPKD | P and D certified; Pt enrolled | Hepatic monitoring and patient-status forms | Authorization for each outpatient prescription | Official shared-system program ([30]) |
| Thalidomide REMS | P and D certified; Pt enrolled | Counseling, surveys and confirmation records | Document dispensing confirmation number and date | Approved document ([31]) |
| Isotretinoin iPLEDGE | P and D enrolled and activated | Detailed testing controls require current-material review | Active program participation required | Official program ([32]) ([33]) |
| PS-Pomalidomide | P and D certified; Pt enrolled | Pregnancy-test verification where applicable | Prescription authorization plus D confirmation | Prescriber instructions ([34]) ([35]) ([36]) |
| PALYNZIQ | P and D certified; Pt enrolled | Documented education and safe-use conditions | Verify documented conditions before dispensing | Official program ([37]) ([38]) |
| LEMTRADA | P, H, D and Pt enrolled | Baseline-lab, status and infusion forms | H enrollment is separate from P enrollment | Official program and forms ([39]) ([40]) |
| Tysabri / TOUCH | P, infusion sites, associated pharmacies and Pt enrolled | Pre-infusion checklist | Confirm current patient authorization before infusion | Official TOUCH instructions ([41]) ([42]) |
| Qsymia | D certified; other actors not established here | Authorized representative, training and assessment | Certified-pharmacy distribution | Official pharmacy instructions ([11]) ([17]) |
| Tecvayli and Talvey | P certification checked by dispensing actor | Additional duties require current-document review | Authorization under the documented first-fill-by-that-dispensing-entity condition | Manufacturer medical information ([43]) |
The crosswalk is an implementation starting point. Its purpose is to expose differences worth modeling, including site enrollment, patient authorization and separate prescription-versus-dispensing numbers. It is not a substitute for a complete requirement extraction from each current approved document.
Participant Duties and ETASU
Elements to assure safe use (ETASU) are statutory categories, not interchangeable workflow labels. The underlying statute distinguishes the following controls. ([44])
- A, prescribers: particular training, experience or special certification. ([44])
- B, dispensers: special certification for pharmacies, practitioners or healthcare settings that dispense. ([44])
- C, settings: dispensing only in specified healthcare settings. ([44])
- D, safe-use evidence: documentation or other evidence that required conditions are met. ([44])
- E, monitoring: specified monitoring for patients using the drug. ([44])
- F, registry: enrollment of patients in a registry. ([44])
Patient enrollment in a portal should not automatically be coded as statutory F. The approved CAMZYOS document explicitly lists A, B, D and E. The approved SPRAVATO document lists B, C, D, E and F. These examples show why a formal statutory classification belongs alongside the observed operational duties. ([23]) ([24])
For patients, the inventory should distinguish registration, acknowledgment, counseling and continuing eligibility. PALYNZIQ requires enrollment and documented safe-use conditions; the program specifically includes education and availability of epinephrine among those conditions. The operational requirement is evidence that the applicable conditions were met, with clinical counseling handled by the responsible professionals. Qsymia's site separately emphasizes certified-pharmacy access, demonstrating another participant-focused distribution control. ([11]) ([45]) ([46])
For prescribers, certification can involve an application, training and a knowledge assessment. FINTEPLA requires a submitted prescriber knowledge assessment and enrollment form. ([47]) LEMTRADA specifies an eight-question assessment and separately requires the prescriber's healthcare facility to enroll when it dispenses or administers the product. ([48]) ([6]) An individual credential should therefore not populate the setting's eligibility field.
For pharmacies, counseling and authorization are separate objects. Lenalidomide instructions require a confirmation number before dispensing and an Education and Counseling Checklist. The PS-Pomalidomide guide likewise requires the pharmacy's confirmation number. A prescriber's authorization should remain a distinct field from the dispenser's confirmation. The prescribing workflow includes its own certified-prescriber participation in PS-Pomalidomide. ([34]) ([49]) ([36])
For healthcare settings, event timing matters. SPRAVATO's program overview specifies submission of the outpatient Patient Monitoring Form within seven days after every dose. ([50]) TOUCH requires its pre-infusion checklist to be submitted within one business day of the visit. ([51]) A system should preserve the administration event, submission deadline and receipt acknowledgment separately.
For sponsors and program administrators, the evidence burden includes maintaining the program's operational infrastructure and records. The approved Thalidomide REMS requires a validated, secure participant database. SPRAVATO's approved document requires public access to a database of certified settings and pharmacies. These are concrete requirements in those documents, rather than universal capabilities inferred for every REMS. ([31]) ([24])
- Prescribers and pharmacies require certification; patients require enrollment.
- Obtain authorization for each prescription.
- The approved document lists statutory ETASU categories A, B, D and E.
- Healthcare settings and pharmacies require certification; patient enrollment applies to outpatient treatment.
- Verify outpatient enrollment and receiving-setting certification.
- The approved document lists statutory ETASU categories B, C, D, E and F.
Patient enrollment in a portal should not automatically be coded as statutory F. Formal statutory classifications and observed operational duties belong alongside each other.
System Interactions and Audit Evidence
A REMS integration should identify the triggering event before choosing an interface. Health Level Seven International (HL7) publishes the US Medication REMS Fast Healthcare Interoperability Resources (FHIR) implementation guide, version 2.0.0, Standard for Trial Use 2 (STU 2), dated November 17, 2025. It focuses on provider ordering and encounter workflows. Publication of a standard does not establish adoption by every program or electronic health record (EHR). ([7]) ([52])
The guide combines clinical decision support (CDS) Hooks, Substitutable Medical Applications and Reusable Technologies (SMART) App Launch, and REMS information carried in prescriptions using the National Council for Prescription Drug Programs (NCPDP) SCRIPT standard. Its detailed pharmacy interactions are outside the guide's scope. NCPDP separately describes observation elements added to REMS transactions in SCRIPT version 2023011. ([53]) ([8]) ([9])
Table 3 maps verified duty patterns to proposed system capabilities. It is an analyst-designed integration matrix. “System of record” identifies the recommended owner for that evidence type, subject to the actual program's operating model. Directions and retained artifacts are implementation recommendations; the citations establish the underlying duty or standards pattern.
| Trigger and actor | Duty and common capability | Source evidence | Recommended system of record | Exchange direction | Recommended audit artifact |
|---|---|---|---|---|---|
| Certification application, P or D | Identity, portal, training and assessment | Completed assessment and enrollment instructions ([47]) ([17]) | REMS administrator for certification status | Participant to administrator; status returned | Submitted form, assessment version, decision and timestamp |
| Patient enrollment, P/designee and Pt | Portal and case management | Enrollment/status documentation ([3]) ([45]) | REMS administrator for program enrollment | Care team to administrator; acknowledgment to care team | Signed or acknowledged enrollment, case identifier and receipt |
| Prescription finalized, P | EHR decision support and form launch | Order-sign trigger pattern ([54]) | EHR for order; administrator for REMS case | EHR to administrator, with structured response | Order reference, request context and returned task/case |
| Monitoring review, P | Lab feed and case management | FINTEPLA status form; tolvaptan monitoring resources ([55]) ([56]) | Clinical system for result; administrator for accepted status | Clinical evidence to authorized reviewer; status to administrator | Result provenance, review record, submitted form and acknowledgment |
| Prescription prepared, D | Dispensing authorization and portal | Confirmation or authorization requirement ([49]) ([30]) | Administrator for authorization; pharmacy for dispense | D query to administrator; authorization returned | Request/response, authorization number, time and rule version |
| Dose administered, H | Monitoring workflow and case management | SPRAVATO monitoring form and TOUCH checklist ([50]) ([51]) | Setting for encounter; administrator for received form | Setting to administrator | Administration time, completed form, submission time and receipt |
| Staff training completed, pharmacy | Training records and audit log | FINTEPLA pharmacy staff-training documentation ([57]) | Pharmacy training record | Training evidence to designated pharmacy representative | Staff identity, training version, completion record and review |
| Completed REMS application workflow, provider system | Document storage and structured forms | DocumentReference and QuestionnaireResponse patterns ([18]) ([58]) | EHR for stored reference; administrator for submitted response | App to administrator; document reference to EHR | Response identifier, document version and storage acknowledgment |
The important architectural distinction is between a clinical result, a submitted form, and an accepted authorization. They represent different events and can arrive at different times. For example, FINTEPLA's pharmacy instructions require confirmation that the prescriber is certified and the patient is enrolled and authorized. A laboratory-result feed alone does not establish those other conditions. ([29])
Identity is another boundary. The Centers for Medicare & Medicaid Services (CMS) warns that issuance of a National Provider Identifier (NPI) does not validate licensure or credentials. Use an NPI as an identifier, and maintain separately sourced program-certification status with its provenance. ([59])
A practical design review should ask:
- Routing: which administrator owns the requested program or case? HL7 describes intermediary routing. ([19])
- Authority: which response constitutes the program's dispensing decision? Lenalidomide uses a pharmacy confirmation number. ([49])
- Freshness: how long is evidence usable under the specific program? PS-Pomalidomide documents prescription-supply and refill constraints. ([60])
- Failure handling: where are rejected, incomplete and timed-out submissions worked? HL7 allows a query of the individual patient's REMS process status. ([61])
- Reconciliation: how are duplicate submissions and delayed acknowledgments resolved? Multiple HL7 workflow hooks should avoid duplicate provider requests. ([62])
- Retention: can the organization reconstruct the evidence available at the decision? FINTEPLA's pharmacy form includes recordkeeping commitments. ([57])
These are engineering review questions, rather than claims that a single retention period or interface applies across the portfolio.
Data Analysis and Evidence
FDA's accessible Reports & Data Files page reported 68 current REMS, of which 56, or 82%, included ETASU and 12, or 18%, were communication-plan-only programs, when accessed on October 15, 2026. ([1]) The displayed percentages are FDA's rounded figures. These are program counts, not counts of products, prescriptions or participants.
The complete index above contains the same number of program rows. Its uncaptured Opioid Analgesic ETASU cell remains unknown, even though the aggregate is reported. Keeping row-level uncertainty separate from a published aggregate prevents a reconciliation check from becoming invented source data.
Current whole-population counts for prescriber certification, dispenser certification, patient enrollment and training could not be calculated because the version-record export was not obtained. Those schema definitions are not measurements of populated values. Readers planning capacity should request and reconcile the actual current records before using these dimensions as portfolio totals.
A smaller calculation is possible from the six-program verification sample, calculated from the corresponding sourced rows in Table 2: CAMZYOS, SPRAVATO, Lenalidomide, FINTEPLA, Xywav/Xyrem and Tolvaptan for ADPKD. The initially read FDA records and the operational sources retained in Table 2 establish dispenser certification and patient enrollment in each, with SPRAVATO's enrollment requirement applying to outpatients. Five list separate prescriber certification; SPRAVATO assigns the relevant certification duties to settings and pharmacies. These are direct counts from the selected records, with no population estimate. ([23]) ([24]) ([27]) ([29]) ([26]) ([30]) The Lenalidomide guide is dated December 2022 and remains linked by its official resource page; its date is not represented as a current approval date. ([28])
The sample also exposes timing dimensions that a portfolio count would obscure. FINTEPLA's instructions specify cardiac monitoring every six months during treatment and once three to six months after discontinuation. ([71]) TOUCH separately describes treatment authorization every six months. ([72]) PS-Pomalidomide additionally limits prescriptions to a 28-day supply, without automatic refills. ([60]) Similar intervals and quantities refer to different activities and cannot safely share an undifferentiated “next REMS due” field.
Likewise, Tolvaptan for ADPKD's Patient Status Form is submitted every three months for the first eighteen months, then every six months. ([73]) That reporting schedule should remain distinct from the underlying clinical monitoring schedule. LEMTRADA's setting enrollment renews every two years, adding a participant-credential lifecycle to the patient-event model. ([74])
For measurement, recommended denominators include required authorizations, due monitoring submissions, applications awaiting review and credentials due for renewal. Report completion against those explicitly defined obligations. Do not combine patient, pharmacy and setting counts into an apparent completion rate without defining what each counted unit represents.
Implications and Future Directions
The near-term opportunity is a controlled requirements registry linked to the systems carrying out the work. HL7 describes REMS administrators maintaining enrollment and certification repositories, and intermediaries routing requests to the correct administrator. These are useful patterns for separating an enterprise view from the program's own authoritative status. ([16]) ([19])
Standards scope should remain visible in procurement. HL7 places patient-directed enrollment and additional EHR/pharmacy interactions in its future-scenario discussion. Those passages support roadmap questions, rather than claims of generally available production capabilities. The guide also advises distinct purposes for multiple workflow hooks so they do not create duplicate provider requests. ([75]) ([62])
Structured regulatory submission is a separate workstream. FDA's guidance specifies Structured Product Labeling (SPL) for REMS document submissions, and its technical conformance guide provides standardized language for common requirements. These resources concern submitted REMS content. They do not establish that a program exposes a real-time enrollment, laboratory or dispensing interface. ([76]) ([77])
An implementation checklist should therefore cover:
- Reconcile identity: program key, product mapping and participant identifiers. Treat the NPI as an identifier with defined limitations. ([59])
- Verify authority: current approved document and relevant operational materials. Requirements can be distributed across prescriber and pharmacy resources. ([34])
- Separate roles: individual, organization, dispensing site and patient. LEMTRADA explicitly separates facility enrollment. ([6])
- Model conditions: eligibility, monitoring, authorization and evidence independently. FINTEPLA identifies patient-status documentation and treatment authorization. ([55])
- Confirm channels: documented portal, phone, fax or supported interface. Eligible lenalidomide pharmacies can obtain confirmation numbers through its portal. ([78])
- Test timing: renewal, submission deadline and effective-date transitions. LEMTRADA requires periodic facility-enrollment renewal. ([74])
- Exercise exceptions: unresolved matches, duplicate events and delayed responses. The HL7 case number can help the pharmacy reference a REMS case. ([79])
- Retain evidence: source version, submitted artifacts and accepted decisions. FINTEPLA's pharmacy form includes dispensing and training recordkeeping. ([57])
The CAMZYOS document is a practical reminder that channels can remain mixed: it requires dispensing authorization online and by phone, and supports enrollment/status processes online and by fax. Procurement should ask for the supported channel and evidence receipt for each workflow. ([23])
IntuitionLabs describes authoritative information sources, identity, permissions and accountable operation in its information-layer approach. ([80]) Applied here, those are useful design principles for connecting participant workflows to their source requirements. The implementation objective is traceability from a current rule to the evidence and decision it produced. For pharmacy workflows, the NCPDP transaction scope and supported version should be confirmed with the actual implementation. ([9])
Conclusion
An operational FDA REMS inventory needs several linked layers: current program membership, product coverage, participant responsibilities, the conditions attached to a transaction, and the evidence retained after completion. This report provides the current program-name index and a sourced operational crosswalk while exposing the fields that require further document extraction.
The examples show why certification, enrollment and authorization deserve separate records. An individual prescriber's status does not establish a facility's enrollment, a submitted monitoring form does not establish an accepted dispensing decision, and product identity alone does not establish the correct program route. Maintaining those distinctions makes reconciliation and change review more precise.
The appropriate next step is to reconcile the portfolio against the live FDA records, extract each applicable current approved document, and assign ownership for every required event. System selection can then follow a concrete workflow: who acts, what evidence they provide, who accepts it, which decision follows, and what record remains.
The access-date and completeness boundaries are part of the asset's usefulness. Population counts describe the observed list. Sample counts describe only the verified sample. Unknown control fields remain explicit until sourced. A weekly refresh process, version history and approved implementation dates can turn that bounded inventory into a maintainable operational reference.
About IntuitionLabs
Build practical AI for pharma and biotech with IntuitionLabs. We help life-science teams turn complex information and workflows into useful software, governed knowledge systems and AI tools.
IntuitionLabs is an AI consulting, custom software development and data engineering firm serving pharmaceutical, biotechnology, medical-device and other life-science organizations. We work with clinical, regulatory, medical-affairs, commercial, quality and IT teams to connect technology decisions with the work people need to accomplish.
AI consulting and adoption
Our AI enablement services cover readiness assessments, use-case selection, governance and policies, team workshops, adoption measurement and ongoing advisory support. We help organizations structure the information layer behind AI: source material, context, permissions and maintained knowledge that make generated answers useful and reviewable. Private LLM inference and hosted AI options support teams evaluating how to operate AI with appropriate control over their data and infrastructure.
Software, data and life-science workflows
IntuitionLabs develops custom software for pharma and biotech, integrates enterprise systems, and builds data engineering and business intelligence solutions. Areas of focus include AI agents, regulatory research, medical writing, medical affairs, CMC information, competitive intelligence and clinical-document workflows. Our eTMF intelligence work includes cross-system reconciliation and inspection-readiness support.
Enterprise platforms and regulated delivery
We provide Veeva services, application support, managed services, integrations and custom applications, alongside enterprise content work involving platforms such as Egnyte. For regulated workflows, our services include GxP enablement, computer-system validation and software development addressing 21 CFR Part 11 requirements. The applicable controls, validation responsibilities and acceptance criteria are defined for each engagement.
Work with IntuitionLabs
Explore AI enablement, pharma and biotech software development, data engineering and BI, and Veeva services. Contact IntuitionLabs to discuss your workflow, information sources and implementation needs.
IntuitionLabs publishes educational research to help life-science teams make informed technology decisions. Coverage of a product or organization does not imply a client relationship, endorsement or partnership.
Sources / 80

Need Expert Guidance on This Topic?
Let's discuss how IntuitionLabs can help you navigate the challenges covered in this article.
I'm Adrien Laurent, Founder & CEO of IntuitionLabs. With 25+ years of experience in enterprise software development, I specialize in creating custom AI solutions for the pharmaceutical and life science industries.
The information contained in this document is provided for educational and informational purposes only. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the information contained herein. Any reliance you place on such information is strictly at your own risk. In no event will IntuitionLabs.ai or its representatives be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from the use of information presented in this document. This document may contain content generated with the assistance of artificial intelligence technologies. AI-generated content may contain errors, omissions, or inaccuracies. Readers are advised to independently verify any critical information before acting upon it. All product names, logos, brands, trademarks, and registered trademarks mentioned in this document are the property of their respective owners. All company, product, and service names used in this document are for identification purposes only. Use of these names, logos, trademarks, and brands does not imply endorsement by the respective trademark holders. IntuitionLabs.ai is an AI software development company specializing in helping life-science companies implement and leverage artificial intelligence solutions. Founded in 2023 by Adrien Laurent and based in San Jose, California. This document does not constitute professional or legal advice. For specific guidance related to your business needs, please consult with appropriate qualified professionals.
Related Articles

AI-Powered Clinical Trial Recruitment: Cardiology & Obesity
Analyze how AI clinical trial recruitment addresses enrollment bottlenecks. This report examines Iterative Health's $77M expansion into cardiology and obesity.

AI Patient Recruitment for Clinical Trials: Platform Guide
Review AI patient recruitment platforms for clinical trials. Compare EHR integration, federated networks, and patient-facing software for trial matching.

CTMS Dashboards: KPIs and Metrics for Clinical Trials
Review how modern CTMS dashboards track clinical trial KPIs. This guide explains operational metrics for enrollment, site performance, and data management.