ESBD_File_345474_1.28_RFP_rOIS_SOW_12.14.23_MJ.pdf

The University of Texas MD Anderson Cancer Center

Request for Proposal (RFP) Statement of Work (SOW) Radiation Oncology Information System (rOIS)

Table of Contents

1.0 GENERAL

2.0 BACKGROUND

3.0 OBJECTIVES:

4.0 MINIMUM REQUIREMENTS:

4.1. GENERAL:

4.2 FUNCTIONAL ROIS SPECIFICATIONS:

4.3 TECHNICAL INFORMATION TECHNOLOGY (IT) ROIS SPECIFICATIONS:

4.4. ADMINISTRATIVE ROIS SPECIFICATIONS:

5.0 PROFESSIONAL SERVICES:

6.0 SUPPLIER PRESENTATIONS/PRODUCT DEMONSTRATIONS & ROIS ACCESS IN

TEST ENVIRONMENT:

1.0 General

The University of Texas M.D. Anderson Cancer Center (MD Anderson) requests proposals from qualified and experienced suppliers to provide an enhanced Radiation Oncology Information System (rOIS). MD Anderson is seeking to acquire a robust rOIS that will incorporate people, processes, and technology critical to the success of MD Anderson’s mission.

The selected supplier will provide an enterprise-wide Radiation Oncology Information System (rOIS) that comprehensively supports clinical processes, clinical research, billing/administration, and workflows across the entire Radiation Oncology (RO) division.

2.0 Background

The University of Texas M.D. Anderson Cancer Center in Houston, Texas, celebrating eight decades of Making Cancer History™, is one of the world’s most respected institutions devoted exclusively to cancer patient care, research, education, and prevention. Created by the Texas Legislature in 1941 as a component of The University of Texas System, MD Anderson continues to rank among the nations’ top cancer hospitals in U. S. News and World Reports ‘America’s Best Hospitals’ survey since its inception 15 years ago.

MD Anderson was one of the first three federally designated comprehensive cancer centers established by the National Cancer Act of 1971.

The team approach to cancer care, pioneered at MD Anderson, has been strengthened by consolidating specialty clinics into multi-disciplinary care centers that allow patients to receive ambulatory care and treatment in a single location.

MD Anderson is an institution renowned worldwide for its continuing accomplishments in cancer research. Clinical research activities continue to grow as part of MD Anderson’s mission to conduct high-impact, and internationally recognized cancer research.

Currently, the RO division maintains a rOIS that works in concert with MD Anderson’s Electronic Health Record (EHR) system (i.e., Epic). The current rOIS’s capabilities include, but are not limited to:

2.1. Management of radiation treatment plans and delivery.

2.2. Provide a structured location for radiation prescriptions and link them to the treatment plans.

2.3. Ensure precise delivery of treatment.

2.4. Provide tools for image review for daily image guidance to Providers.

2.5. Provide context specific communication for delivery of radiation therapy.

2.6. Provide automated billing process.

2.7 Provide patient, staff, and equipment scheduling within RO division.

Institutional Radiation Therapy Demographics – FY23 Radiation Therapy Demographic(s) Approx. count – FY23

Patients 11,000 Treatments 155,000

Currently, MD Anderson’s RO division comprises of radiation delivery and ancillary machines as listed below:

Machine Type In- Use/Projected at MDACC Number Elekta microselectron 11 Varian Truebeam 20 Varian Truebeam w/HDMLC 6 Varian Ethos 1 Hitachi Gantry 7 Hitachi Fixed Beam 1 Elekta Versa 2 Elekta Unity 1 Varian 2100 (21EX) 1 CT Simulators 12 Varian CT On Rails (21EX) 2 MRI Simulator 2 Brain Lab ExacTrac 4 Vision RT 6 C-Rad 15 Elekta Gamma Knife 2

3.0 Objectives:

The engagement objectives shall include but not limited to:

3.1. Selecting a product that provides capabilities to enable continuous improvement to operational and patient safety features.

3.2. Selecting a product that reduces requirements for application integration solutions for third (3rd) party solutions to integrate the rOIS with other clinical systems.

3.3. Selecting a product that provides support for modern open standard interfaces, Application Programming Interface (API) or direct database access, and sufficient metadata to support optimization for Findability, Accessibility, Interoperability, and Reusability (FAIR) data management.

3.4. Selecting a product that provides capability to streamline billing and reconciliation processes for billed and unbilled charges.

3.5. Selecting a product that enhances user experience, reduces time/effort for common tasks, enables safe and sustainable integration with Artificial Intelligence (AI)/Machine Learning (ML) tools.

3.6. Selecting a product that provides customizable workflow management.

3.7. Selecting a product that provides streamlined communications for patient related items including configurable notifications of pending tasks.

3.8. Selecting a product that provides improved efficiency for clinicians, business operations and IT, enabling an increase in patient volume without the need for additional staff.

3.9. Selecting a product that is sustainable and scalable to meet growing patient needs across multiple institutions and evolving IT environments and requirements.

3.10. Selecting a product that conforms to MD Anderson’s vision and all Radiation Oncology requirements, and that enables MD Anderson to meet demands of its patient population.

3.11. Provides state of the art approaches for cybersecurity.

4.0 Minimum Requirements:

4.1. General:

4.1.1. rOIS must allow at least 400 concurrent users in its initial implementation, without performance impact, and be configurable and expandable to allow for additional users as requested by MD Anderson (expect 10% growth per year).

4.1.2. rOIS must have the ability to generate standard and customized dashboards and reports ideally using generally available data visualization tools such as Power BI.

4.1.3. rOIS must have the ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the Food and Drug Administration or other accrediting agencies.

4.1.4. rOIS must support Integrating the Healthcare Enterprise (IHE) Treatment Delivery Workflow-II when this standard is released.

4.1.5. rOIS must support contextual, role-based access control(s); allow user(s) to have multiple roles.

4.1.6. rOIS must provide user(s) role-based access to Protected Health Information (PHI) and treatment data and multi-site users ideally implemented through active directory groups to enable separation of duties requirements.

4.1.7. rOIS must fully Integrate with MD Anderson’s EHR system to allow fee schedules, physician calendar, patient registration, patient financial clearance status, appointments, and scheduling updates to be real-time interfaced between Epic and the rOIS.

4.1.8. rOIS must be commercially available and in general release (not an alpha and/or beta product).

4.1.9. rOIS must be wholly owned product of vendor (must not be produced, developed or supported by a third-party reseller of software, or services).

4.2 Functional rOIS Specifications:

Functional rOIS specifications shall include, but not be limited to the following:

4.2.1. Connect to MD Anderson’s machines to provide the following:

4.2.1.1. Patient-facing timeouts for simulation(s) and treatment(s) will be available by EHR barcode/ID recognition for patient identification, with relevant timeout checklist(s).

4.2.1.2. Recording and verifying radiation dosage(s).

4.2.1.3. Support of commercially available technologies available on MD Anderson’s treatment units.

4.2.2. Capability to allow manual input/recording of treatment data not automatically captured.

4.2.3. Track and resume interrupted (partial) treatments including Volumetric Modulated Arc Therapy

(VMAT) and scanned beam protons.

4.2.4. Allow for Quality Assurance (QA) and troubleshooting of treatment plan(s) before delivering treatment to patient(s):

4.2.4.1. Not be included in patient(s) dosimetry tracking.

4.2.4.2. Include in patient record(s).

4.2.5. Track appropriate approvals and signatures on documents.

4.2.6. Accept imaging information, including spatial registration objects (SROs) and have them available for review as soon as they are received from the treatment unit, even if the treatment session is still open.

4.2.7. Export any imported digital object (dicom, pdf, etc.) with no modifications.

4.2.8. Support auto-forward of any imported digital objects with rules based on digital object type and originating system.

4.2.9. Control treatment field changes by user rights and require secondary sign-on.

4.2.10. Provide a mandatory acknowledgment at the time of treatment when anything has been altered in the treatment information that requires approval.

4.2.11. Provide real-time reporting of delivered treatment fields within a few seconds of that data being passed to the rOIS.

4.2.12. Provide notification(s)/warning(s) at given points in the patient’s treatment (i.e., notice when patient reaches certain dose level).

4.2.13. Provide a mandatory acknowledgment if second radiation treatment is within six (6) hours of first radiation treatment (i.e., BID).

4.2.14. Provide the ability to prevent treatment if required treatment documentation is not approved (i.e., the prescription, field parameters, plans).

4.2.15. Provide the ability to prevent treatment for any alteration to prescription dosage until acknowledged at the point of treatment delivery.

4.2.16. Third-Party Applications and Systems:

The rOIS must integrate/interact with the following applications and systems:

4.2.16.1. Electronic Health Record Systems (i.e., Epic).

4.2.16.2. Treatment Planning Systems (TPS) (e.g., Raystation, Eclipse, etc.).

4.2.16.3. Inhouse systems that use HL7 RESTful API and direct database queries into the rOIS.

4.2.16.4. Evercore – Vendor Neutral Archive (VNA) that is used as a Picture Archiving and

Communication System (PACS) for RO in addition to storing other patient specific digital objects.

4.2.16.5. Hitachi Worklist Manager.

4.2.16.6. SAP Business Object Business Intelligence suite.

4.2.16.7. Iguana (HL7 Interfaces).

4.2.16.8. Citrix.

4.2.16.9. Iris (in-house electronic whiteboard).

4.2.17. Treatment Plan Management:

The rOIS shall include, but not be limited to the following:

4.2.17.1. Receive treatment plans from TPS(s) via Digital Imaging and Communication in Medicine

(DICOM).

4.2.17.2. Have a means for importing, displaying, editing (minimally adding notes) and approving documentation (pdfs and/or other standard file formats) associated with each treatment plans, patient and/or course of therapy.

4.2.17.3. Provide real time access to treatment delivery data and active prescriptions via API or direct data base access including linkages to the original DICOM treatment plan.

4.2.18. Calendar:

4.2.18.1. Integrated calendar to proactively manage patient schedules.

4.2.18.2. Integrated calendar to proactively manage machine/location schedules.

4.2.19. Reports/Dashboards:

Reporting requirements shall include, but not be limited to following:

4.2.19.1. Robust and streamlined reporting capability.

4.2.19.2. Interactive reporting (i.e., dashboards, standard reports, advanced reports, custom reporting that allow drill-down and traceability functions, improve utilization, etc.).

4.3 Technical Information Technology (IT) rOIS Specifications:

Technical IT rOIS specifications shall include, but not be limited to the following:

4.3.1. Provide option to control user access and security by being able to authenticate users against

Active-Directory, Lightweight Directory Access Protocol (LDAP), or Azure (if Cloud based).

4.3.2. Provide minimal footprint installation for general users (Citrix, VDI, Browser Based, etc.).

4.3.3. Receive prescriptions from third party system(s).

4.3.4. Support patient identifiers shared with other systems including bar codes used for patient identification (i.e., Epic wristbands must be accepted).

4.3.5. Support both generic and patient specific device tracking with a flexible interface (bar code, RFID, QR, etc.).

4.3.6. Display preview of the images and documents without the need of opening the image or document.

4.3.7. Insert notes into the patients record (i.e., planner information, CT slices #).

4.3.8. Support messaging to various parties within the application including individuals and groups.

4.3.9. Support comprehensive messaging to patients via integrations with Epic’s Mychart.

4.3.10. Workflow Management:

4.3.10.1. Provide workflow management capability.

4.3.10.2. Handle multi-step process to track/monitor patient progress through the appointment

(i.e., arrival, process step, completed).

4.3.11. IT Integration Requirements:

IT Integration rOIS requirements/specifications shall include, but not be limited to the following:

4.3.11.1. Compatibility with standard interfaces for e.g., HL7, Fast Healthcare Interoperability

Resources (FHIR), Admit Discharge and Transfer (ADT), and/or Epic’s System Interface Unit (SIU) and Design for Test (DFT).

4.3.11.2. Support integration with third-party enterprise systems via Application Program Interface (API) and/or Web services. Current third-party enterprise systems include, but not be limited to following: (listed as follows)

4.3.11.2.1. Hitachi’s worklist manager and patient imaging system.

4.3.11.2.2. Iguana (messaging Interface to Epic used by MDACC).

4.3.11.2.3. Vison-RT.

4.3.11.2.4. C-Rad.

4.3.11.2.5. ExacTrac.

4.3.11.2.6. Brachytherapy, TPS and delivery units.

4.3.11.2.7. Gamma Knife.

4.3.11.3. Import/export documents, information, and data including automatic routing rules.

4.3.11.4. Provide user role-based access controls and security.

4.3.11.5. Allow feature for multiple user roles.

4.3.11.6. Provide a configurable search capability to identify patients via characteristics

(demographics, dose history, diagnosis, etc.).

4.3.11.7. Provide an audit trail feature that tracks all users who edit the data.

4.3.11.8. Ensure data access/reporting does not interfere with rOIS operations.

4.3.11.9. Provide availability for real time access to discrete data elements (small queries, single patient, single machine schedule, etc.).

4.4. Administrative rOIS Specifications:

Administrative rOIS specifications shall include, but not limited to the following:

4.4.1. Charge Capture:

4.4.1.1. Display patient code summary in dashboard for technical and professional charges.

4.4.1.2. Ensure technical and professional charge capture can be done separately at the patient level as well as at the Service/Department level for a single or multiple charge codes.

4.4.1.3. Edit and/or void multiple charge lines at the patient level and/or service/department level.

4.4.1.4. Display in charge capture summary four (4) fields of Diagnosis (Dx) and four (4) boxes of

Modifiers.

4.4.1.4.1. Populate patients’ primary and secondary insurances in charge summary.

4.4.2. Financial Clearance:

4.4.2.1. Comprehensive capability/functionality to alert/notify (for e.g., cancellations, no shows, machine down, late evening and/or weekend treatments, insurance authorization, self or fully funded, third-party funded, discharge etc.).

4.4.2.2. Utilize technology based on a self-learning algorithm to auto-capture treatment planning charges after treatment plan is approved in the patient code summary or equivalent.

4.4.2.3. Track efforts not captured by billing codes.

4.4.3. Clinical Trials:

4.4.3.1. Ability to auto-track clinical trial(s) for RO division. Auto-tracking shall include, but not be limited to:

4.4.3.1.1. RO division’s role as Principal Investigator.

4.4.3.1.2. Clinical trial(s) includes radiation component.

4.4.3.2. Ability to generate clinical trial(s) exception(s)report(s).

4.4.4. Provider Calendar:

4.4.4.1. Ability to integrate with provider calendar.

5.0 Professional Services:

MD Anderson desires that proposer(s) provide a complete catalog of professional and other services to support their proposed rOIS, if available. Such services shall include but not be limited to implementation, integration, training, support, maintenance, etc.

5.1. Implementation Service(s):

5.1.1. Proposer(s) shall provide an implementation methodology and approach, including all available implementation service-level options.

5.1.2. Proposer(s) shall provide a hierarchy and profile of implementation team members, including assigned tasks and subsequent durations.

5.1.3. Proposer(s) shall provide an implementation timetable for training, software maintenance, and technical support.

5.1.4. Proposer(s) shall identify the amount of input and resources that MD Anderson will need to provide for implementation and ongoing support/maintenance.

5.2. Customer Service Levels and Support:

5.2.1. Proposer(s) shall have support availability options for MD Anderson end users and administrators during normal business hours, and on an as needed, emergent basis.

5.2.2. Proposer(s) shall have a comprehensive problem response and resolution methodology. Such problem response and resolution methodology shall identify standard and urgent support hours, methods of reporting problems, methods of providing support, major downtime, etc.

5.2.3. Proposer(s) shall have an end user and administrator training methodology and approach including user training, regular user conferences and workshops, and training media (web-based, manuals, etc.).

6.0 Supplier Presentations/Product Demonstrations & rOIS Access in Test Environment:

After evaluation of the RFP written proposals has been completed, MD Anderson will identify a shortlist of proposers for on-site or remote supplier presentations/product demonstrations. Specific instructions for supplier presentations/product demonstrations shall be provided to the shortlist of proposers.

Upon completion of supplier presentations/product demonstrations, MD Anderson will identify a shortlist of proposers for evaluation of the system in a test environment. Shortlisted proposers shall provide MD Anderson access to a fully developed rOIS in a test environment hosted from the proposer’s site, so that a select number of MD Anderson users may log in remotely, over the internet, to experience the rOIS concurrently.