- This line was added.
- This line was removed.
- Formatting was changed.
REMS (Risk Evaluation and Mitigation Strategies) are drug safety programs that the FDA (Food and Drug Administration) can require for certain medications with potential for serious adverse side effects to help ensure the benefits of the medication outweigh its risks. REMS allows the prescribing of drugs that otherwise would not be available because of safety issues. Only a few drugs require REMS. REMS required actions vary with each drug or drug class (e.g., opioid).
FDA is championing and actively exploring innovative technologies to facilitate the completion of REMS requirements within the prescribers and pharmacists’ workflows. Under the auspices of the public HL7 CodeX FHIR Accelerator Community and through the REMS Integration Use Case, FDA is supporting the use of standardized application programming interfaces (APIs), like the open source and freely available HL7® FHIR® APIs, with pharmacy data standards, i.e., National Council for Prescription Drug Programs (NCPDP) SCRIPT, to integrate REMS into prescriber and pharmacy workflows. The use case ultimately aims to reduce REMS implementation burden, improve the quality of REMS data for feedback and evaluation, and optimize safe medication use and health outcomes.
For more background information about REMS, please see the following resources:
- Risk Evaluation and Mitigation Strategies | REMS | FDA
- Approved Risk Evaluation and Mitigation Strategies (REMS) (fda.gov)
- FDA REMS Public Dashboard
REMS Workflow Diagram
- There are a number of key stakeholders (Patients, Prescribers, Nurses, Office Administrators, Pharmacists, REMS Administrators and Pharmaceutical Manufacturers) who play an important role in the REMS workflow of prescribing a drug to the patient. This includes verification of completed REMS requirements and dispensing the drug to the patient. There currently is no unified way to share data between REMS stakeholders.
- Due to the lack of standardization and interoperability:
- There is difficulty in communication and coordination of efforts amongst stakeholders in the REMS workflows.
- The current processes used to implement REMS requirements are burdensome, costly and can impact patient access.
- REMS are not built into current workflows and the complexity of these programs leads to additional burden on stakeholders and the overall healthcare system.
- All of these challenges hampers communication and coordination amongst REMS stakeholders resulting in delays in therapy, potential decrease in access to REMS drugs, and inefficient patient care.
- REMS is integrated into prescriber and pharmacist workflows, allowing them to easily complete the necessary REMS requirements without having to open a separate portal or remember additional steps for handling a REMS
- REMS integration allows prescribers to be alerted that a drug requires REMS education and training and any additional clinical actions needed (e.g., monthly liver enzyme monitoring, lab tests, etc.) to adhere to the requirements of the REMS program without having to manually look up this information
- Prescribers are able to easily submit the necessary information in their current workflow, allowing them to fulfill or attest to REMS requirements
- Structured data is used for populating REMS requirements, helping to automate the process and reduce the burden of manual entry
- Capture of a completed REMS is integrated in a claim and documented in prescriber's clinical notes
- When a request is received to dispense a REMS drug, pharmacists are able to easily confirm, within their current workflow, that REMS requirements have been met
- Pharmacists are able to easily look up data that prescribers submitted and which has been verified for certification by a REMS Administrator
- Patients receive or are administered the REMS drug in a timely manner with minimal effort or burden on their part
- Create an interoperable, efficient, and effective REMS ecosystem. This interoperable ecosystem would be established via a standards-based technical framework for REMS integration into workflows. This will enable data sharing, reduce stakeholder burden and cost, increase access to REMS drugs, and optimize patient care for therapies that require a REMS.
- All REMS stakeholders are able to access the right data at the right time in order to carry out their tasks efficiently and effectively
- REMS workflow is accurate, timely, and easy for stakeholders, allowing for more time spent with the patient and ultimately an improved experience, improved patient care and outcomes
- Patients are able to access REMS drugs as part of their care
- In the future, standardization of REMS data could support REMS assessment reports, along with evaluation and updating of REMS over time in a data driven manner
REMS Proof-of-Concept Prototype
MITRE and FDA are working together to develop an open source proof-of-concept prototype that leverages data standards and technology to integrate REMS into the health care system, with a focus on stakeholder workflows. The aim for this prototype is to demonstrate the art of the possible with technical REMS integration and to help drive conversations with the community around opportunities to enhance REMS.
The current iteration of the prototype (REMSv0.1213) builds upon previous prototype releases (prescriber workflow, prescriber/pharmacist interaction, and REMS administrator workflow) and focuses on:
- Test Launching of the SMART on FHIR application with the Logica Sandbox demonstrating a SMART launch
- Integration of the prototype with the Logica Sandbox for cds-hooks
- Differentiation of UI of card links depending on if a link is to a PDF or is a SMART App link for improved user experience
- Removal of duplicate VSAC caching code in rems-admin
- Functionality to support order-select hook in rems-admin
- Completed full stack testing of Docker in Windows environment
- Prepopulation of patient status forms
- Request Generator UI/UX Updates
- Hide Cards UI at start and show number of cards loaded
- Update patient selection functionality
- Updated button and information box display based on Patient, MedicationRequest, or QuestionnaireResponse selected
- Update of tagging of different releases for consistency
- Update of GitHub main branches to now only allow authorized merges into production branches
- Use of ETASU status to determine which links to return in CDS Hooks card
- Research of SMART on FHIR dependabot changes
- Documentation Updates
- Renaming of repositories
- REMS to rems-admin
- crd-request-generator to request-generator
- Fixes to the following bugs/issues:
- Fixed SMART on FHIR application questionnaire filter button
- Fixed SMART on FHIR application tabs bug
- Fixed issue with PIMS hot reloading in developer Docker environment
- Fixed version issues in rems-setup docker-compose file
- Fixed PIMS “No Orders” bug
- Fixed Keycloak admin and timeout issues
- SMART on FHIR application:
- Rearrangement of user interface to place the patient information on the left
- Send order-select CDS Hook when choosing MedicationRequest
- Removal of hard coded URLs in all repositories
- Implementation of HTTPS in the PIMS repository, REMS server, Keycloak 3rd party authentication server, test-ehr, and request generator for secure network communication utilizing encryption standards
- Update of Keycloak authentication server to newer release
- Documentation of all environment variables
- Update of the workflow to allow for submitting patient status forms at a regular interval
- Fixes to the following bugs/issues:
- Fixed bug where PIMS “View ETASU” button on a “picked up” order changes the order state
- SMART on FHIR application:
- Implementation of HTTPS
- Documentation Templates and Rules (DTR) questionnaire migration for the SMART on FHIR application
- Completion of work to make the SMART on FHIR application more configurable.
- Functionality to allow for the SMART on FHIR application to launch with Test-EHR context
- Functionality to launch the newly integrated DTR in the SMART on FHIR application from the Request Generator
- Functionality to use env-var to read in .env files
Any and all feedback on the prototype is welcome!
Instructions for setting up the prototype: https://github.com/mcode/rems-setup/blob/main/SimpleSetupGuide.md
The REMS integration proof-of-concept prototype leverages existing DaVinci burden reduction specifications as a starting point. In particular, the prototype uses the Documentation Templates and Rules (DTR) andCoverage Requirements Discovery (CRD) implementation guides (IGs) as a basis for the prototype. The REMS ecosystem has unique requirements which will drive standards development activities for REMS integration. These may represent new standards, and/or expansions upon existing specifications.
The following are links to the code repositories used in the prototype:
- rems-setup: https://github.com/mcode/rems-setup/releases/tag/0.1213
- pims: https://github.com/mcode/pims/releases/tag/0.1213
- request-generator: https://github.com/mcode/crd-request-generator/releases/tag/0.1213
- rems-admin: https://github.com/mcode/REMSrems-admin/releases/tag/0.1213
- test-ehr: https://github.com/mcode/test-ehr/releases/tag/0.1213
- smart-on-fhir-app: https://github.com/mcode/rems-smart-on-fhir/releases/tag/0.1213
- rems-cds-hooks: https://github.com/mcode/rems-cds-hooks/releases/tag/0.1213
- cql-to-fhir-library: https://github.com/mcode/cql-to-fhir-library/releases/tag/0.1213
The mcode/REMS repository is licensed under Apache License 2.0.
Anchor rttd public project plan rttd public project plan
Use case identification
Convening of use case members
Outcome: Use case identified with consensus on end goal (i.e. live pilot in a real environment)
Plan out high-level project plan, deliverables, success measures, high level timeline, key stakeholders, etc.
Growing the REMS CodeX Community
Outcome: Project plan with phases/objectives defined and timelines with consensus from the REMS CodeX community
Develop test environment with synthetic patients (sandbox environment developed in house or using vendor test environment)
Outcome: Readiness to integrate with external systems
Begin integrating with a health system/target site
Outcome: Readiness to pilot
Execute real world pilot using health system's actual infrastructure, real interface, and real patients
Outcome: Real world pilot results
Capture lessons learned, ideas for future enhancements, etc.
Outcome: Roadmap for future enhancements
Risk Evaluation and Mitigation Strategies - REMS (Member page)
REMS Public Calls (Registration link provided for each call below)
Past public webinar (October 11, 2022): Challenges and Opportunities for REMS Integration, Innovation, and Modernization
REMS Prototype Demos
REMS Engagement Value by Stakeholder
REMS Use Case Page Navigation
Use Case Team
|Use Case Coordinator|
If you'd like to learn more about this use case, please contact email@example.com
Food and Drug Administration (FDA)