Appendix C - Detailed Business and Technical Requirements.xlsx
XLSX spreadsheet 79 KB Posted
- Attached to
- DOH Prescription Drug Monitoring Program
- Solicitation number
- RFP27007077
- Issued by
- Providence County, Rhode Island
About this file
This file is Appendix C of the Detailed Business and Technical Requirements for the Rhode Island Department of Health's Prescription Drug Monitoring Program (PDMP) implementation and operation. The appendix serves as a response template for vendors to address comprehensive requirements across multiple operational domains. The RFP solicitation (27007077) requires proposals due November 23, 2026 at 11:00 AM EST, with contract commencement anticipated for January 1, 2027 through April 30, 2028, followed by up to four optional 12-month renewal periods. The PDMP system must collect prescription data from authorized dispensers 24/7, support secure web-based access for up to 50,000 queries daily and 10,500 concurrent users, integrate with electronic health records and state health information exchanges, and provide advanced data analytics and reporting capabilities. Key functional requirements span data collection and submission, data management and validation, inter-state data exchange via PMPi and RxCheck, secure web services with role-based access controls, and comprehensive query and reporting functionality including mandatory compliance tracking and threshold-based alert generation.
Vendors must respond to each requirement using standardized response categories (Standard, Configurable, Tool, External, Change, or Not Met for business requirements; Met, Partial, Change, Not Applicable, Unknown, or Not Met for technical requirements) and indicate implementation effort levels (Small, Medium, or Large). The contract is a Firm Fixed Price agreement with prices remaining firm through September 31, 2030, subject to U.S. Department of Labor Consumer Price Index adjustments thereafter. The State retains all ownership rights to collected data and developed software. Vendors must provide annual SOC 1, SOC 2, or SOC 3 reports, maintain HIPAA and 42 CFR Part 2 compliance, execute a Business Associate Agreement, demonstrate minimum five years of state PDMP hosting experience, and secure required insurance coverage including $5,000,000 Technology Errors and Omissions and $5,000,000 Information Technology Cyber/Privacy coverage. The incumbent vendor is Bamboo Health, and the RFP evaluation will weight technical merit, cost (with lowest-cost proposals receiving 100 percent of cost points), and participation of Minority, Women, and Disability Business Enterprises.
View the file
Other files
Show all 11
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| Appendix C - Prescription Drug Monitoring Program (PDMP) Detailed Business and Technical Requirements |
| IMPORTANT: Delete this text and type your Vendor / Company Name here on the Bidder Instruction Page |
| SUMMARY & INSTRUCTIONS: |
| The requirements have been set up in a form for bidder response. It is understood that one system is unlikely to meet all requirements. |
| The text in this document may not include formatting such as the indented bullet lists, but the text is the same. |
| Most of this spreadsheet file has been protected. Portions for your response have been left available for editing. |
| This response must be submitted to Rhode Island Department of Administration, Division of Purchases in Excel format. |
| There are multiple tabs containing requirements in this spreadsheet which require response. |
| Tab 1: Data Collection and Submission |
| Tab 2: Data Management and Valdation |
| Tab 3: Data Exchange and System Integration |
| Tab 4: Secure Web Services and User Account Management |
| Tab 5: Project Management and Governance |
| Tab 6: Miscellaneous |
| Tab 7: MES Outcomes - CMS Required PDMP |
| Response Constraints |
| Responses are limited to those defined in the document Glossary. |
| Glossary |
| 1) RESPONSE |
| Please complete the RESPONSE column for each requirement row on each of the spreadsheet tabs listed above. |
| Click on the cell to the right of each requirement's text and select a RESPONSE from the drop down list. |
| The list of possible responses to select from and their definitions is listed on the Glossary Tab |
| Please read the definitions of the responses carefully and select the best answer for each requirement. |
| 2) LEVEL OF EFFORT |
| Read the definitions of the levels of effort carefully on the Glossary tab. |
| In the appropriate column, select from the drop down list, the level of EFFORT that you believe will be required to meet the requirement. |
| 3) NOTES / COMMENTS |
| If directed or if desired, add comments related to the requirements in the specified Notes/Comments column. |
| If you select TOOL as the response to a requirement, please identify the recommended tool(s) in the comments |
| There is a limited amount of space available for comments. You can widen the row heights if needed. |
| A text explanation of the response to every business requirement is not required. Use discretion when making explanatory notes. |
| Please add only important comments which clarify or add significant information to the response. |
Glossary
| Business Requirements Response | RFP Language / Glossary | Description |
| STANDARD | Standard feature of the system | Requirement functionality is considered to be standard in the core system and does not require any additional configuration. It is inherent in the deployment of the solution. |
| CONFIGURABLE | Configurable | Requirement functionality is considered to be configurable if the process is driven by data stored in tables and it can be created and modified through a structured user interface by entering information to discrete fields and selecting options via radio buttons, check boxes, and drop down lists. Configurable also includes standard reports available through the system or readily built within the system. Functionality is also considered to be configurable if code can be written, entered through a screen interface provided by the software, and the code can be called or triggered by a configurable function within the software. This type of custom code would be stored and maintained as part of the overall configuration of the software. |
| TOOL | Tool Integration | Requirement functionality would be met by using an external tool which can be readily integrated with the application via an exposed interface, or native database functionality such as triggers may be used to satisfy this requirement, or a report that would be built using a reporting tool outside the system but which references system data. |
| EXTERNAL | External Custom Code | In order to meet this requirement a pre or post process piece of custom code must be written and run outside the software. Data required by the process is readily available through an exposed application programming interface and/or the output of the external process can be readily consumed by the application. The custom code would be maintained & supported by the author or user of the code. |
| CHANGE | Core Change | In order to meet this requirement the Software Publisher would develop or edit the source software code within the product to meet this functional requirement. The code would be maintained either as an integrated part of the core application or as a known branch to the core application code. |
| NOT MET | Not Met | This requirement can not be met by the application product. |
| Technical Requirements Response | RFP Language / Glossary | Description |
| MET | Met / Meets | The software product as provided meets the requirement or installation can be configured in such a way as to meet the requirement. If there are multiple choices offered in the requirement or various ways the requirement can be met, please indicate in the comments which standard is adhered to or how the product meets the requirement. |
| PARTIAL | Partially Meets | The software product partially meets this requirement. Specify in the comments column what part of this technical requirement is not met by the software product as provided. |
| CHANGE | Core Change | In order to meet this requirement the Software Publisher would develop or edit the source software code within the product to meet this functional requirement. The code would be maintained either as an integrated part of the core application or as a known branch to the core application code. If the core change is on a known technical development roadmap, state that in the comments, tell us the estimated timeline, and provide a copy of the technical development roadmap document if you have one. |
| NA | Not Applicable | The product does not utilize this technology and therefore does not need to meet this standard. This choice is only acceptable where an "if" statement is included in the requirement. |
| UNKNOWN | Unknown | The bidder is unable to determine if the product meets this requirement or not. Please state in the comments why you chose this response. |
| NOT MET | Not Met | This requirement is not be met by the application product. |
| LEVEL OF EFFORT | DESCRIPTION | |
| SMALL | A single resource could accomplish the customization work in a time period measured in days. | |
| MEDIUM | Multiple resources working together could accomplish the customization work in a period measured in weeks. | |
| LARGE | A team of resources could accomplish the customization work in a period measured in months. |
Data Collection and Submission
| Requirement Number | Functional Requirements | Spec / Detail | Requirement | Response | Effort | Bidder Comments / Notes |
| 1.1 | Dispenser Guidance and Technical Assistance | The Contractor shall develop, publish, and maintain comprehensive instructions for statutorily authorized dispensers to ensure compliance with PDMP reporting requirements. | Technical | |||
| 1.2 | Continuous Prescription Data Intake | The Contractor shall ensure the system is capable of receiving electronic prescription information twenty-four (24) hours per day, seven (7) days per week, from all authorized dispensers. | Technical | |||
| 1.3 | Secure Submission Infrastructure | The Contractor shall implement and maintain a secure, high-availability mechanism for the collection and/or upload of prescription data. | Technical | |||
| 1.4 | Data Format Requirements | The Contractor shall require and support submission of data using the American Society for Automation in Pharmacy (ASAP) Telecommunications Format for Controlled Substances, Version 4.1 and Version 4.2, or any successor standard designated by RIDOH. | Business | |||
| 1.5 | Required Data Elements | The Contractor shall ensure the collection of the required minimum data elements for each controlled substance prescription transaction, as well as for other drugs of concern identified by RIDOH. | Business | |||
| 1.6 | Manual Data Entry via Secure Web Portal | The Contractor shall provide a secure web-based portal to support manual data entry and upload functionality for dispensers with low prescription volumes or limited technical capabilities. The portal shall be accessible 24/7 and must incorporate appropriate user authentication and audit logging. | Technical | |||
| 1.7 | Zero Reporting | The system shall permit dispensers to submit reports indicating zero controlled substance prescriptions dispensed during a specified reporting period. The Contractor shall compile and transmit a summary of such reports to RIDOH on a schedule defined by the Department. | Business | |||
| 1.8 | Aggregated Submissions from Common Ownership Entities | The system shall support joint data submissions from dispensers operating under common ownership. | Business | |||
| 1.9 | Dispenser Reporting Exemptions | The system shall allow the RIDOH PDMP Administrator to designate dispensers. | Business | |||
| 1.10 | Data Quality Validation | The Contractor shall implement automated and manual validation processes to ensure that all submitted data meets accuracy, completeness, and consistency standards defined by RIDOH. Data failing to meet these standards shall be rejected in accordance with Subtask 1.4, and dispensers shall be notified of necessary corrective action. | Technical | |||
| 1.11 | Submitter Notification and Data Correction | The Contractor shall: |
Provide timely notifications to dispensers when submitted data is found to be incomplete or inaccurate.
Clearly identify the data elements in error.
Support resubmission and correction workflows; and
| Ensure corrected data is reflected within the system in a timely manner. | Technical | |||
| 1.12 | Data Collection from RIDOH | Where applicable, the Contractor shall collect and ingest data provided by RIDOH regarding dispensers or controlled substance prescriptions subject to PDMP reporting requirements. The Contractor shall ensure secure transfer, integration, and proper attribution of such data. | Technical | |
| 1.13 | Waiver-Based and Paper Submissions | The Contractor shall provide a process, subject to Rhode Island Department of Health (RIDOH) approval, for the acceptance of waiver-based or paper submissions in extraordinary circumstances where electronic reporting is not feasible. | Business |
Data Management and Validation
| Requirement Number | Functional Requirements | Spec / Detail | Requirement | Response | Effort | Bidder Comments / Notes |
| 2.1 | Data Collection and System Hosting | The Contractor shall collect and load data into the PDMP database on a daily basis. |
All data shall be hosted on vendor-provided cloud-based servers, maintained in compliance with federal and state security standards.
| The system must support high availability and meet defined Service Level Agreements (SLAs) for data accessibility and system uptime. | Technical | ||
| 2.2 | DEA Registration Mapping | The Contractor shall collect DEA registration information and maintain an up-to-date DEA reference list to support accurate validation and translation. | |
| The system shall convert DEA registration numbers submitted to the PDMP into corresponding prescriber or dispenser names and addresses. | Business | ||
| 2.3 | NPI Number Mapping | The Contractor shall collect and process National Provider Identifier (NPI) numbers submitted to the system. | |
| The system shall convert NPI numbers to prescriber or dispenser name and address when available and store the converted data for analysis and reporting. | Technical | ||
| 2.4 | NDC Number Mapping | The Contractor shall collect and maintain a current reference source of National Drug Code (NDC) information. |
The system shall translate NDC numbers into drug name, strength, dosage form, and DEA-controlled substance schedule.
| This translation must occur both at the point of data import and retrospectively as updates to the NDC directory are received. | Business | ||
| 2.5 | Integrated Data Management and Analysis Tools | The Contractor shall provide integrated capabilities for data access, data management, and data cleansing. | |
| These functions shall be seamlessly linked with data mining and business intelligence tools to support advanced analysis. | Technical | ||
| 2.6 | Geocoding and Geographic Analysis | The Contractor shall ensure data can enable geocoding of patient, prescriber, and dispenser addresses. | |
| Data collected shall support spatial and geographic analysis to identify clusters or trends indicative of diversion, abuse, or emerging health issues. | Technical | ||
| 2.7 | Data Cleansing and Entity Resolution | The Contractor shall electronically cleanse, normalize, and standardize data to identify: |
Variations in names (e.g., nicknames, aliases);
Similar or duplicate addresses;
Slightly differing dates of birth; and
| Other demographic discrepancies. | Technical | ||
| 2.8 | Data Query and Search Functionality | The system shall support flexible, advanced search functionality across relational and multi-dimensional data. |
| Search criteria must support a wide range of filters, including but not limited to: patient demographics, prescriber ID, drug name or class, dispenser location, and geographic identifiers. | Technical | ||
| 2.9 | Data Retention and Purging | The Contractor shall implement automated processes to remove data in accordance with RIDOH’s retention policies. |
Retention policies are currently defined as follows:
Live Data: Retained for thirty-six (36) months after the prescription dispense date;
Archived Data: Retained for up to sixty (60) months total.
| The system shall support modifications to these parameters based on legislative or regulatory changes. | Business | ||
| 2.10 | Data Migration and Conversion | The Contractor shall convert and migrate active PDMP data from the existing system to the new platform. |
All live program data shall be preserved, including metadata and associated audit logs.
| Migration activities must be completed in accordance with the RIDOH-approved transition plan and data security protocols. | Technical | ||
| 2.11 | Dispenser Upload History Monitoring | The system shall include a mechanism for RIDOH staff to: |
View the upload history of any dispenser by timeframe;
Identify error rates and late submissions;
Detect trends in reporting behavior;
| Monitor zero prescription reports. | Technical | |||
| 2.12 | Upload Accuracy Auditing | The Contractor shall provide tools for verifying the accuracy of specific uploads, including mechanisms to compare submitted data against formatting, required field completion, and validation checks. | Technical | |
| 2.13 | Dispenser Upload Reporting | The system shall include configurable, on-demand, and scheduled reporting capabilities to display: |
Submission histories by dispenser;
Contact information for each reporting entity;
| Submission frequency and coverage by date range. | Business | ||
| 2.14 | Invalid or Incomplete Data Reporting | The Contractor shall provide reporting capabilities for RIDOH to identify and review prescription records that: |
Contain invalid or missing DEA, NDC, or NPI numbers;
Contain incomplete or incorrect prescription control numbers;
| Fail to meet minimum data quality thresholds established by RIDOH. | Business | |||
| 2.15 | Prescription Verification Automation | The Contractor shall implement an automated process for verifying prescription data fields, including prescription control numbers, in accordance with RIDOH policies and standards. | Technical | |
| 2.16 | Tracking and Auditing Waiver-Based or Paper Submissions | The Contractor shall implement mechanisms to track, flag, and audit waiver-based or paper submissions accepted under Subtask 1.13. | Technical | |
| 2.17 | Disaster Recovery Plan | Provide a disaster recovery plan for data pertaining to the database system in the event the system is unavailable due to human error, equipment failure, or a natural disaster. Please address any historical statistics on database system unavailability for other states (i.e., on average, how long is the database system down or otherwise unavailable on a monthly basis for reasons other than natural disaster). Describe how users will be notified in the event of down-time | Business | |
| 2.18 | Transition Activities | The Contractor must demonstrate prior experience with similar vendor-to-vendor transitions in PDMP or comparable health information systems (e.g., state-level HIE or controlled substance monitoring programs). In their proposal, vendors shall include: | ||
| • | A high-level transition approach, including assumptions about Bamboo Health's cooperation as the incumbent vendor (e.g., data access timelines) and any potential risks/mitigations. | |||
| • | Estimated costs associated with transition activities (e.g., joint planning, testing), broken out separately in the cost proposal. | |||
| • | References from at least one (1) prior transition project involving an incumbent SaaS vendor in a regulated healthcare environment. | |||
| RIDOH will facilitate initial introductions between the Contractor and Bamboo Health and may mediate any disputes to ensure timely completion. Failure to cooperate effectively with Bamboo Health may result in contract penalties, up to and including termination. The transition must align with the overall contract start date of approximately January 1, 2027, and be completed prior to full system go-live. | Business |
Data Exchange and System Integr
| Requirement Number | Functional Requirements | Spec / Detail | Requirement | Response | Effort | Bidder Comments / Notes |
| 3.1 | Inter-State PDMP Data Sharing (Inbound) | The Contractor shall propose an approach to inter-state connectivity for inbound data, whether via PMPi or RxCheck. |
The integration shall support:
Intrastate and interstate data exchange;
Authorized user queries to out-of-state PDMPs;
| Audit logging of all cross-jurisdictional queries and disclosures in accordance with applicable law and RIDOH policy. | Business | |||
| 3.2 | Inter-State PDMP Data Sharing (Outbound) | Receipt and appropriate handling of inbound PDMP queries from other states to share outbound data. Both PMPi and RxCheck must be supported pathways for outbound data-sharing. | Business | |
| 3.3 | Integration with Electronic Health Records (EHRs) and Pharmacy Dispensing Systems | The Contractor shall provide and maintain a connectivity solution that allows direct, standards-compliant access to PDMP data from within EHR and pharmacy management software systems. | Business | |
| 3.4 | Integration Support for State Health Information Exchange (HIE) | The Contractor shall collaborate with the state-designated HIE vendor to scope, plan, and implement PDMP integration with the HIE platform, and will deliver parse-able standards-based data to the HIE for uses allowable by law. | Technical | |
| 3.5 | API Queries | The Contractor's solution shall support inbound and outbound standards-based API queries. | Technical |
Secure Web Services and User Ac
| Requirement Number | Functional Requirements | Spec / Detail | Requirement | Response | Effort | Bidder Comments / Notes |
| 4.1 | Secure Web Portal Access | The Contractor shall provide a secure, browser-based website through which registered and authorized users may access the PDMP system and its associated applications. |
Access must be available twenty-four (24) hours per day, seven (7) days per week, with high availability and minimal downtime.
The contractor to notify RIDOH and all registered users of major outages, with regular status updates and estimated resolution times. Distinguish from security/breach notifications.
| Vendor must provide a highly available and fault tolerant architecture with the ability to scale based on customer demand. At minimum must accommodate at least fifty thousand (50,000) queries per day. | Business | ||
| 4.2 | User Authentication and Account Security | The Contractor shall authenticate all user registrations prior to the creation of system accounts. |
Authorized user groups shall include, but are not limited to: licensed dispensers, prescribing practitioners, designated agency personnel, and Rhode Island PDMP staff.
The system shall enforce the following user security features:
Unique user ID and password credentials;
Email and/or text-based verification during account registration;
Password expiration protocols as defined by the Rhode Island PDMP, with advance notification to the user;
Optional password change prompt at each login;
Self-service password reset functionality using security questions or secure email/text reset links;
Login/logout capabilities with session timeout controls;
Automatic account locking after a defined number of failed login attempts, including email/text notifications and user unlocking procedures;
| Full logging of unsuccessful access attempts and other anomalous behaviors. | Business | ||
| 4.3 | Privacy and Security Standards Compliance | The Contractor shall ensure full compliance with all applicable federal and state privacy and security laws and regulations, including HIPAA and related standards for confidentiality, access, and disclosure. |
The system shall support agency administrator-managed user registration workflows for designated agency personnel.
| The Contractor shall ensure full compliance with all applicable federal and state privacy and security laws and regulations, including the Health Insurance Portability and Accountability Act (HIPAA) and 42 CFR Part 2 governing the confidentiality of substance use disorder patient records. | Business | |||
| 4.4 | Scalability and Concurrent User Access | The system must support high volumes of concurrent users, with capacity for over 10,500 active registered users statewide. | Business | |
| 4.5 | User-Initiated Access to Reports | Registered users shall be able to initiate queries and receive automated reports through the secure portal without requiring manual intervention from Rhode Island PDMP staff. | Business | |
| 4.6 | Broadcast Communication and Alerts | The system shall provide the Rhode Island PDMP with the ability to broadcast alerts and notices to users via: |
Home page announcements;
Role-based message targeting;
| Geographic-based targeting. | Technical | ||
| 4.7 | Administrator Messaging to Dispensers and Uploaders | The system shall include a messaging feature to allow Rhode Island PDMP administrators to communicate directly with registered dispensers and uploaders. This feature shall include: |
Ability to compose or paste a message into the portal interface;
Automatic inclusion of all registered email addresses for each recipient;
Support for file attachments;
Option to select individual or all recipients using a “Select All” function;
| Confirmation message displayed upon successful delivery (e.g., “Message was sent successfully”). | Technical | ||
| 4.8 | Announcements and Role-Based Notifications | The system shall support a configurable announcements feature, enabling PDMP administrators to send direct messages to: |
All users;
Specific individuals; or
| Groups based on role or geographic parameters. | Technical | ||
| 4.9 | Data Breach Notification and Intrusion Detection | The Contractor shall be responsible for all data breach notification processes. The system shall: |
Comply with HIPAA notification requirements for prescribers, dispensers, RIDOH, and other applicable entities.
Include procedures and timelines for breach response and notification (Contractor must provide a sample policy).
Include technical mechanisms to detect system intrusion or unauthorized access attempts.
Enforce privacy protocols that protect confidential data and communications at all stages of storage and transmission.
| The Contractor shall also implement and document intrusion prevention and incident response protocols | Business | ||
| 4.9a | Data Breach Notification and Intrusion Detection | The Contractor shall establish and maintain procedures for handling unauthorized access, suspected data breaches, or security incidents. At a minimum, the Contractor must: |
Notify the RIDOH Privacy Officer, Bureau of Drug Control, and the Chief Information Security Officer immediately, and no later than twenty-four (24) hours, by telephone or email.
Conduct an initial investigation and secure any evidence related to the breach.
Provide a written incident report within three (3) business days of first learning of the breach.
Provide a subsequent report within seven (7) business days detailing the impact of the breach, corrective actions, future prevention measures, and timelines.
| Assist, including testifying if necessary, in any proceedings or hearings related to the incident. | Business | ||
| 4.10 | Delegate User Workflow and Account Management | The PDMP shall support a secure delegate workflow that prevents shared accounts and ensures proper supervisor approval and oversight: |
Delegates must provide their supervisor’s registered email address during registration.
Supervisors are notified of delegate registration and must approve the delegate’s account.
PDMP Administrators must be able to view delegate–supervisor relationships and approval status.
Once approved, delegates may perform patient searches on behalf of their supervisor and must select the supervisor prior to running a report.
Supervisors shall be able to view all delegate-run reports within their own patient request history.
Supervisors may deactivate a delegate account at any time.
| Both supervisors and delegates must have the ability to run reports identifying whose records were accessed and under which supervisor authority. | Business | ||
| 4.11 | Role- and User-Based Permissions | System permissions shall be configurable at both the role and individual user level. |
For example, a “Physician” role may be configured to access prescribing history reports, while a “Delegate” role may be restricted from viewing or generating such reports.
| The system shall also support overrides that allow permissions for a specific user to differ from others in the same role. | Technical | ||
| 4.12 | User Support and Helpdesk Services | The Contractor shall provide a toll-free telephone number and email address for Helpdesk services. |
Helpdesk support shall be available twenty-four (24) hours per day, seven (7) days per week, and 365 days per year.
The toll-free number must be staffed by personnel located within the United States.
All voicemails must be acknowledged and responded to within twenty-four (24) hours.
SLA expectations for (a) acknowledgment of requests within 2 hours, and (b) resolution or escalation within 24 hours.
Helpdesk support shall include assistance with:
Web-based submissions;
System navigation;
Report generation;
Password recovery;
Account access issues.
| Contractor shall implement tiered support levels, including escalation paths for technical issues, system access problems, data submission errors, and compliance reporting inquiries. | Technical | |||
| 4.13 | Data Encryption | The vendor will always be required to encrypt any State data both in transit and at rest that is in use by the vendor during the project and support after the project. This applies to any device that accesses State data in any fashion. | Business |
Queries, Reporting, Analytics
| Requirement Number | Functional Requirements | Spec / Detail | Requirement | Response | Effort | Bidder Comments / Notes |
| 5.1 | Report Download and Format Support | All system-generated reports shall be available for download in both PDF and CSV file formats. | Business | |||
| 5.2 | Dispenser Submission Audit Reports | The system shall generate an ad hoc audit report at the end of each defined reporting period identifying: |
Dispensers who failed to submit required reports; and
| Reports that were submitted but rejected. | Business | ||
| 5.3 | Ad Hoc Search and Correlation Functionality | The Rhode Island PDMP shall be able to perform ad hoc searches, correlations, and queries across all database variables, including: |
DEA numbers;
Patient demographics;
Drug classes; and
| Other metadata fields. | Business | |||
| 5.4 | Prescriber-Specific Queries | Prescribers shall have the ability to query data using their own DEA number to access records associated with their prescribing history. | Technical | |
| 5.5 | Usage Reporting and Audit Logs | The system shall track and report the number of registered user queries by user type (e.g., prescriber, pharmacist, dispenser). |
| On-demand audit reports shall be available for individual user activity. | Technical | |||
| 5.6 | Ad Hoc Report Creation | Administrators shall have the ability to create, edit, and delete ad hoc reports using any system-level field via an intuitive, graphical user interface. | Technical | |
| 5.7 | Data File Submission to RIDOH | Contractor shall provide to RIDOH identified, individual-level data files on a monthly cadence to support public health purposes. Files must be in .csv format and delivered via SFTP. | Business | |
| 5.8 | Automated Threshold Alert Reporting | The system shall generate threshold-based reports and alerts using configurable parameters, including but not limited to: |
Prescriber and Dispenser Volume Thresholds: Alert when a set number of prescriptions or interactions is exceeded.
Daily Active MME Threshold: Alert when morphine milligram equivalents (MME) exceed a defined daily value.
Opioid & Benzodiazepine Co-Prescribing: Alert when both drug classes are prescribed to a patient within a defined timeframe.
Methadone Daily Active MME Threshold: Alert when daily methadone MME surpasses a defined threshold.
| Opioid Consecutive Days Threshold: Alert when opioid prescriptions are filled for more consecutive days than allowed. | Business | |||
| 5.9 | Alert Generation for High-Risk Activity | The system shall be capable of automatically generating alerts to prescribers and dispensers when a patient is identified as exceeding defined threshold criteria. | Business | |
| 5.10 | User Account Deactivation | The system shall allow Rhode Island PDMP staff to deactivate the accounts of prescribers, dispensers, or other users who are no longer authorized to access the database. | Technical | |
| 5.11 | Ad Hoc Investigative Queries | The Rhode Island PDMP shall be able to perform ad hoc queries to fulfill requests from: |
Patients;
Professional licensing boards;
Law enforcement agencies (local, state, or federal); and
| Requests related to investigative, research, statistical, or educational purposes. | Technical | |||
| 5.12 | Educational Outreach Letters | The system shall allow for the generation of educational letters to prescribers and dispensers based on patient threshold exceedances. These communications shall be template-driven, customizable, and automatically tracked. | Business | |
| 5.13 | End-User Interactive Reporting | The system shall include access to a dashboard reporting module that includes: |
Pre-configured dashboards;
Customizable views;
Parameter-based filters;
| Role-based access. | Business | ||
| 5.14 | Advanced Report Authoring and Scheduling | End-user dashboards shall support drag-and-drop report generation by non-technical users. Pre-built dashboards/reports include (non-exhaustive list): |
Dispensations (by pharmacy/prescriber/time);
Gateway and PMPi request/response activity;
CDC and COAP grant metrics;
Login activity and registration tracking;
| Unsolicited report generation and disclosure maps. | Business | ||
| 5.15 | Pharmacy Management and Delinquency Tracking | The system shall include a Pharmacy Management module enabling Rhode Island PDMP administrators to: |
Identify pharmacies with recurring or unresolved data submission errors;
| Flag “delinquent” dispensers (e.g., those with outstanding errors or unsubmitted data beyond a set timeframe defined by RIDOH). | Business | ||
| 5.16 | Compliance Monitoring | A Compliance Reporting module shall be included to track: |
Rolling 30-day submission activity;
Number of pharmacies submitting vs. not submitting;
Record error rates and void rates.
| The module shall allow filtering and drill-down into detailed records, all of which must be exportable to Excel. | Business | ||
| 5.17 | Mandatory Use Compliance Tracking | The Contractor shall provide a solution that tracks mandatory PDMP query compliance. |
The system shall assess whether dispensations involving selected drug types were preceded by a PDMP query by the prescriber (or delegate) within a configurable timeframe.
Reports shall identify non-compliant transactions based on configurable logic aligned with Rhode Island law.
The compliance monitoring solution shall support state-configurable parameters to align with Rhode Island law and evolving policy requirements. At a minimum, these configurable parameters shall include:
Drug Classes: The ability to designate one or more controlled substance schedules or drug classes for mandatory PDMP query compliance monitoring.
Duration of Supply: The ability to configure thresholds based on prescription duration (e.g., number of days’ supply) for which mandatory queries must be enforced and monitored.
Prescriber Role: The ability to apply compliance monitoring by role (e.g., physician, nurse practitioner, delegate), with flexibility to add, remove, or modify roles as required by RIDOH.
These configurable parameters shall be adjustable by RIDOH administrators without requiring vendor intervention and shall be applied consistently across all mandatory use compliance reports and alerts. Business
MES Outcomes - CMS Required PDM
| Reference # | Requirement Name | CMS Required Outcomes | Default Metrics | Regulatory Sources | |
| 1 | |||||
| Qualified PDMP | Covered providers have near real-time access to: |
a. Information regarding Medicaid beneficiary prescription drug history.
b. The number and type of controlled substances prescribed to and filled for the covered individual during at least the most recent 12-month period.
c. The name, location, and contact information (or other identifying number selected by the state, such as a national provider identifier issued by the CMS National Plan and Provider Enumeration System) of each covered provider who prescribed a controlled substance to the covered individual during at least the most recent 12-month period. - Real-time access: Average time (in mins) to access a report on bene prescription drug history Section 1944(b) of the Act Section 5042 Medicaid PARTNERSHIP Act CMS FAQs-SUPPORT for Patients and Communities Act
| 2 | |||
| Workflow Integration | Providers can easily use the PDMP information through workflow integration, which may include electronic prescribing system for controlled substances. | --- | Section 1944(b) of the Act |
Section 5042 Medicaid PARTNERSHIP Act CMS FAQs-SUPPORT for Patients and Communities Act
| 3 | |||
| Data-sharing Agreements | The state has data-sharing agreements with all contiguous states to track patients, prescribers, and prescriptions across state lines. | - Provide copies of data-sharing agreements entered with contiguous states | Section 1944(b) of the Act |
Section 5042 Medicaid PARTNERSHIP Act CMS FAQs-SUPPORT for Patients and Communities Act
| 4 | |||
| Medicaid Program Access to PDMP | The state medical and pharmacy directors and any designee has access to the PDMP information in an electronic format based on data-sharing agreements in place (subject to state law). | - Provide a copy of the report of issues reported for designated users who could not or were denied access | Section 1944(b) of the Act |
Section 5042 Medicaid PARTNERSHIP Act CMS FAQs-SUPPORT for Patients and Communities Act
| 5 | ||
| Required Reporting | The state produces data for the reports that are required to be submitted in the Annual Report to HHS. | - Quantity of daily morphine milligram equivalents prescribed for controlled substances. |
- the number and Quantity of daily morphine milligram equivalents prescribed for controlled substances per covered individual.
- number of occurrences of data or privacy breaches of a qualified PDMP that includes the number of covered individuals impacted by each breach. Section 1944(e) of the Act Section 5042 Medicaid PARTNERSHIP Act 42 CFR 433.112(b)(15) CMS FAQs-SUPPORT for Patients and Communities Act
| 6 | ||
| Utilization and Quality Reports | The system produces reports to contribute to reports to HHS by the State Drug Utilization Review (DUR) Board and for program evaluation, continuous improvement in business operations, transparency and accountability, as well as identify patterns of fraud, abuse, gross overuse, excessive utilization related to limitations identified by the state, inappropriate or medically unnecessary care, or prescribing or billing practices that indicate abuse or excessive utilization among Medicaid physicians, pharmacists and enrollees associated with specific drugs or groups of drugs. | - Number of covered individuals concurrently prescribed opioids and benzodiazepines. |
- List of covered individuals who were prescribed opioids from multiple providers.
- number and/or percentage of opioid-related hospitalizations, ER visits, urgent care visits for covered individuals. Section 1944 (e)(1) of the Act Section 1927(g)(2)(B) and (g)(3)(D) of the Act Section 1004 of the SUPPORT Act 42 CFR 433.112(b)(15) CMS FAQs-SUPPORT for Patients and Communities Act Centers for Disease Control
Business
| Requirement Number | Functional Requirements | Spec / Detail | Requirement | Response | Effort | Bidder Comments / Notes |
| 9.1 | State Ownership | The State retains all ownership rights to the data acquired by the Vendor during the course of this agreement, and to any software that is designed and developed through this award. | Business | |||
| 9.2 | Contract Term and Work Schedule | The contract will be for approximately sixteen (16) months, with four (4) 12-month renewal options. The contract start date is estimated to be January 1, 2027. | Business | |||
| 9.3 | Contract Type | The contract is a Firm Fixed Price contract. | Business | |||
| 9.4 | Price Adjustments | Contract prices will remain firm through September 31, 2030 with adjustments based on the U.S. Department of Labor Consumer Price Index (CPI-U). | Business | |||
| 9.5 | Location of Work | The State will not provide workspace for the Contractor. | ||||
| Business | ||||||
| 9.6 | Third-Party Service Providers | The Contractor must provide annual SSAE SOC 1, SOC 2, or SOC 3 reports. | Business | |||
| 9.7 | Right to Inspect | The State may inspect areas of the Contractor's place of business related to the contract. | Business | |||
| 9.8 | Nondisclosure and Confidentiality | The Contractor must hold all confidential information in confidence and prevent unauthorized access. | Business | |||
| 9.9 | Vendor Access | The Vendor will have access to the State’s systems during the project and support after the project, adhering to State security policies. | Business | |||
| 9.10 | System Maintainence | Explain how database system patches, version updates, security updates, and software upgrades will be managed. | Business | |||
| 9.11 | Disability | All web-based initiatives must follow the W3C Web Content Accessibility Guidelines 2.1, Level AA (WCAG 2.1 AA), the international standard of technical requirements to ensure digital public services are accessible to everyone as required under the Final Rule of Part 84 of Section 504. Vendor shall confirm that the service will meet (or exceed) WCAG 2.1 AA compliance by providing a Voluntary Product Accessibility Template (VPAT). If a VPAT is unavailable, a detailed description of service compatibility with commonly used assistive technologies must be included along with a description of the process used to test for accessibility compliance acceptable to the State. | Business | |||
| 9.12 | Data backup | Vendor must provide a data back-up solution to restore data into the application with no data loss. | Business | |||
| 9.13 | Project Management and Governance | The Vendor shall provide a robust project governance including: |
-- A Project Management Plan submitted within 60 days of contract execution, detailing governance structure, milestones, deliverables, risks, and mitigation strategies.
| -- Where applicable, the vendor must describe the approach used to monitor, manage, and report all items that are included in the Service Level Agreements | Business | |||
| 9.14 | Experience | Require vendors to detail experience hosting a state PDMP for a minimum of five years. | Business | |
| 9.15 | Kickoff Meeting | Kick off meeting - The Vendor shall coordinate with the State project lead to schedule a kickoff meeting within 30 days of contract execution. The vendor's project manager shall facilitate the meeting. The project kickoff meeting agenda must include the following, at a minimum: | ||
| • | Introduction of the the Vendor’sproject team members and the State project team members | |||
| • | Establish mutual understanding and awareness of the project objectives, scope, governance, schedule, risks, and issues | |||
| • | Present templates for: o Project schedule o Status reports o Corrective action plans (CAPs) | Business | ||
| 9.16 | Biweekly reporting | Project Reporting (Bi-weekly and Monthly) - The Project Status Reporting deliverable is recurring for the term of the project. The offeror must, at a minimum, include monthly reporting of the following activities: | ||
| • | Dashboard of Project Related Activities that details at a minimum the following: | |||
| • | Project status | |||
| • | Key accomplishments | |||
| • | Key issues, risks, and/or decisions | |||
| • | Upcoming focus areas | |||
| • | Key project metrics | |||
| • | Outcomes based metrics to support Medicaid and State business priorities | |||
| • | Status of work completed against the Project Schedule | |||
| • | Vendor responsibilities for the next reporting period | |||
| • | The State responsibilities for the next reporting period | |||
| • | Escalated risks, issues (including schedule and budget), action items, and decisions | |||
| • | Disposition of logged issues and risks | |||
| • | Other areas as defined by the State Provide training for database system use by the Rhode Island Department of Health administrator(s). | Business | ||
| 9.17 | Point of Contact | The vendor will identify a client relationship manager who will serve as point of contact for the Rhode Island PDMP. This individual is responsible for providing timely support regarding PDMP activities outlined in this scope of work, including supplying request documentation and reporting. | Business | |
| 9.18 | Contract Personnel | Any change of the project team members named in the proposal must be approved, in advance and in writing, by the project director or procurement officer. Personnel changes that are not approved by the State may be grounds for the State to terminate the contract. Any vacancies in PDMP project manager staffing greater than 60 days must be reported directly to RIDOH project staff. | Business | |
| 9.19 | HIPAA | This system will collect personally identifying information (PII) and protected health information (PHI), and the vendor is required to sign a Business Associate Agreement as attached to this solicitation. | Business |
https://www.section508.gov/sell/vpat/
File details come from the government source that posted it. Updated .