- Please refer to CMS.gov for more information regarding Medicare Part D electronic prescribing requirements and sign up to receive the latest announcements.
- The NCPDP SCRIPT Version 2017071 Implementation Guide supports:
- REMSInitiationRequest and REMSInitiationResponse
- REMSRequest and REMSResponse
- Each transaction supports a particular step in the REMS process:
- The REMSInitiationRequest transaction is used by the prescriber to initiate the REMS process, by notifying the REMS Administrator of the patient and the medication for which REMS authorization is being requested, along with the prescriber’s information and other related details.
- In the REMSInitiationResponse transaction, the REMS Administrator indicates the information needed from the prescriber to determine approval or denial of the authorization. In some cases, the REMS Administrator indicates to the prescriber that REMS authorization is not required for the requested medication and patient. The REMSInitiationResponse is for the medication (name, strength, dosage form) indicated in the REMSInitiationRequest. The REMS Administrator should not respond for an equivalent to the medication (e.g., generic product equivalent to brand product) indicated in the REMSInitiationRequest.
- The prescriber system gathers the requested information by presenting questions for the prescriber to answer and/or by extracting information from the patient’s electronic medical record using the coded references associated to the question. The information is sent to the REMS Administrator in the REMSRequest transaction. This occurs in both the solicited and unsolicited models.
- The REMS Administrator determines whether authorization can be granted and provides the determination to the prescriber in the REMSResponse transaction. In some cases the REMSResponse transaction may indicate the REMS Administrator needs additional information in order to make a determination.
- The Food and Drug Administration Amendments Act (FDAAA) of 2007 (Public Law 110-85) enables the Food and Drug Administration (FDA) to require a REMS from a pharmaceutical manufacturer if the FDA determines that a REMS is necessary to ensure the benefits of a drug outweigh the risks associated with the drug. The currently approved REMS programs vary in levels of complexity. Typically, a Med Guide and Communication Plan is required, but some also require Elements to Assure Safe Use (ETASU). The large majority of existing REMS programs are for drugs dispensed through specialty pharmacies, clinics, and hospitals, but as REMS become more common, they may ultimately have a greater impact on retail-based products.
- The impact of REMS is twofold. First, REMS with ETASU may require the pharmacist to verify prescriber, patient, and/or pharmacy enrollment in a registry and, in some cases, verify or check certain information, such as laboratory results. Second, all REMS, including those without ETASU, must fulfill FDA-approved reporting requirements. Each REMS program must also include a program assessment schedule that examines the program’s effectiveness on intervals approved by the FDA as part of the overall REMS program. The results of these assessments are submitted to the FDA as part of the ongoing evaluation of REMS program effectiveness.
- Both the prescriber and the REMS Administrator must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.
- See NCPDP projects in the Interoperability Proving Ground.
- Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery.
- Authentication Enforcer – Centralized authentication processes.
- Authorization Enforcer – Specifies access control policies.
- Credential Tokenizer – Encapsulate credentials as a security token for reuse (e.g., SAML, Kerberos).
- Assertion Builder – Define processing logic for identity, authorization and attribute statements.
- User Role – Identifies the role asserted by the individual initiating the transaction.
- Purpose of Use – Identifies the purpose for the transaction.
Submitted by firstname.lastname@example.org on 2021-09-29
NCPDP CommentsNCPDP SCRIPT Standard, Implementation Guide, Version 2017071 update Implementation Maturity from pilot to Production.