procure.ohio.gov  · Web viewDescribe in depth the system capability to capture dental care to...

Click here to load reader

  • date post

    09-Jun-2018
  • Category

    Documents

  • view

    214
  • download

    0

Embed Size (px)

Transcript of procure.ohio.gov  · Web viewDescribe in depth the system capability to capture dental care to...

Supplement 1

ODRC Electronic Health Record (EHR) System

Scope of Work

Scope of Work / Requirements Overview

The Ohio Department of Rehabilitation and Correction (ODRC) is seeking an integrated, statewide Electronic Health Record (EHR) solution. The scope of services required includes data migration from the current EHR and implementation of Contractor EHR solution to include: project management, business transformation management, systems analysis and design, development, testing, training, implementation, integration/interfacing of other systems, stabilization, transition, operation and maintenance, and enhancement. Training of and knowledge transfer to the ODRC staff is required throughout the Project. To the extent possible, the ODRC wants a commercial-off-the-shelf (COTS) software solution. However, some level of customization may be necessary to fulfill the requirements of this scope-of-work. The ODRC is very interested in achieving a Contractor hosted or cloud based solution but will need to also consider plans and pricing for a customer hosted solution.

This document is provided in MS Word format to allow the Offeror to provide an inline response to the requirements as described in the base RFP. A check mark indicates where responses are required.

The outline for this scope of work is as follows. The scoring section of the RFP is tied to sections and components of this Supplement.

I. Mandatory Requirements

II. Work Plan: Project and Implementation

III. Staffing Plan

IV. Training Plan

V. Technical Requirements

VI. Clinical Requirements

If none of the Offerors are able to comply with a requirement or condition, ODRC reserves the right to amend that specification or condition.

I. MANDATORY REQUIREMENTS

The following are mandatory requirements for this proposal. Offerors not meeting these requirements may be eliminated from the evaluation process.

1. Successful Implementation

Offeror has successfully implemented an EHR system within a secure setting (examples federal, state prison, local jail, etc.). Provide supporting documentation, including the types of facilities, locations served, number of patients / users, etc. Also include contact information for key individuals that can serve as a reference. The Offeror is encouraged to provide multiple instances for this requirement.

Provide the appropriate form from Attachment Seven.

2. Certification

The CMS Medicare and Medicaid EHR Incentive Programs provides meaningful use criteria which establishes the requirements for providers to show they are using Certified EHR Technology (CEHRT) in ways that can be measured significantly in quality and quantity. The ODRC EHR must be certified to enable interoperability with other health care providers EHR technology, and the ODRC also believes it is critical for an EHR to be federally compliant with this standard as a show of commitment to quality healthcare. Therefore, provide supporting documentation that demonstrates Offeror certification as described in each point below:

The EHR technology proposed by the Offeror must be CEHRT in accordance with the definition provided in 45 CFR Part 170.102 required for Stage 1 and Stage 2 of meaningful use in calendar year 2014 and subsequent years.

If the Offerors CEHRT or any third-party CEHRT proposed by the Offeror is presently only certified for the 2011 Edition EHR certification criteria, Offeror must provide proof that certification to the 2014 Edition certification criteria is in progress, the date certification will be completed, and affirmation in writing the upgrade to the 2014 Edition of its proposed products is included in its cost proposal (i.e., there will be no additional costs to the ODRC for the upgrade beyond what is included in the cost proposal).

Offeror must provide a list of the EHR technology products proposed, including product name, product version, and the Certified Health IT Product List (CHPL) Product number, so the Department can verify Offerors response.

Offeror must agree to maintain certification of its products at the levels required for provider participation in the Medicare and Medicaid EHR Incentive Programs.

Provide the appropriate form from Attachment Seven.

3. ODRC Ownership of EHR Data

Offeror acknowledges the ODRC has full ownership of all data in the EHR and agrees that all ODRC data will be returned to the ODRC if the contract is terminated for any reason. Return of the data includes providing data in an industry standard format, current at the time, either to the ODRC or to an ODRC designated Contractor and assisting with any required data verification and transfer to ensure data is complete and useable.

Provide the appropriate form from Attachment Seven.

II. Work Plan: Project and Implementation

Contractor Best Practices

The contractor must provide a comprehensive project and implementation plan for consideration with GANNT chart showing the steps and projected length of time to complete each implementation step for approximately 28 institutions, 2500 users, and 50,000 patients. The Project plan should require conversion from existing EHR to new EHR by 6/30/19. The following elements must be addressed as part of the plan:

The Contractor must provide services that meet or exceed the RFP requirements through application of industry best practices in all components of the ODRC EHR Project. As the Project progresses, ODRC may elect to leverage best practices resulting from market trends, emerging technologies, technology advancements, alternative processing approaches, new tools, methodologies or business processes. As service improvements and advancement opportunities arise, the Contractor must present those opportunities to ODRC for consideration and approval.

As the Contractor strives to be a leader in the market and offer continuous upgrades to their systems and services, changes to the solution, to accommodate the improvements, may be deemed by the Contractor to add value to the ODRC EHR solution. In those circumstances, most especially when the changes could alter cost, computing capacity, server density or drive efficiencies, the State may make reasonable changes within the general scope of the Project. The State will do so by issuing a written order under this Contract describing the nature of the change (Change Order). Additionally, if the State provides directions or makes requests of the Contractor without a change order, and the Contractor reasonably believes the directions or requests are outside the specifications for the Project, the Contractor may request a Change Order from the State. The parties will handle such changes as follows: The Contractor will provide pricing to the State. The State will execute a Change Order once it and the Contractor have agreed on the description of and specifications for the change, as well as any equitable adjustments that need to be made in the Contractor's Fee or the performance schedule for the work. Then within five business days after receiving the Change Order, the Contractor must sign it to signify agreement with it. See page 39, of the base RFP, for additional comments related to Contract changes. Change Orders and IDAs will be executed as amendments to the Contract.

Innovations and Value-Added Components

In addition to ODRC requirements, ODRC seeks creative and innovative solutions driven by information, technology, flexibility and talented resources. ODRCs focus is on establishing a seamless, streamlined, technological enterprise solution by reducing and optimizing tools and systems. Therefore, ODRC requires a solution that has value-added components and demonstrates a commitment throughout the engagement to continuous improvement, reliability and customer service daily, providing ODRC with the best value/competitive pricing for the proposed solution and related services.

In responding to this section, Offerors must provide a detailed narrative that describes other innovative solutions and value-added components that may not be covered within the RFP requirements as well as the benefits ODRC will realize.

Project Development Lifecycle

The following section provides guidance to Offerors on ODRCs anticipated approach to Project Management and the Project Development Lifecycle practices to be applied for this Contract. Offerors must propose a comprehensive project approach which, as the expert in the Solution being proposed, can be different but must encompass all Project requirements and deliverables demonstrated in ODRCs approach. The following depicts ODRCs suggested phased approach to the Projects lifecycle at a high level:

Project Development Lifecycle

Note: ODRC is interested in an iterative approach that leverages contemporary methods, tools and techniques for the delivery of the Project. Objectives and Requirements for each phase will be presented in turn. Based on ODRCs priorities that factor cost, ability to migrate to the new operating environment, integrations and conversion considerations and other factors, this Supplement includes a minimum set of phase gate requirements for each phase, which are contained later in this Supplement. The Offeror is strongly encouraged to provide its approach based on its own demonstrable success and experience that would lead to most cost-effective and low-risk implementation of the Solution that meets the RFP requirements. The associated implementation plan must clearly distinguish between Contractor software components that are immediately available for configuration/deployment (Configurable Components) and those that require customization/extension by the Contractor (Customization Components) for a fully integrated ODRC EHR Solution.

Tasks, Roles, and Responsibilities

The following contains the list of tasks and the roles and responsibilities for ODRC and Contractor in line with the anticipated project development lifecycle as well as the Offeror Cost Summary Proposal workbook. For purposes of the Project, Perform means that the party assigned the task has the duty and ultimate responsibility to take all appropriate steps to complete or facilitate the identified task unless otherwise provided for between the parties, subject to the Supporting party completing its interdependent responsibilities. The term, Support means that the party has the duty and responsibility to provide ancillary support or assistance which may be necessary to enable the party providing the Perform task to complete that task unless otherwise provided for by the parties.

Key Tasks

State

Contractor

INITIATE

Work Plan: Project & Implementation Management - Conduct Project kick-off meeting

Support

Perform

Staffing Plan: Confirm dedicated staff and onboard resources

Support

Perform

Identify ODRC stakeholders and manage expectations

Perform

Support

Create and maintain a Communication plan

Perform

Perform

ANALYZE

Work Plan: Project & Implementation Management Plan - Create a Work Breakdown Structure (WBS)

Support

Perform

Work Plan: Project & Implementation Management Plan - Review Deliverables, manage ODRC / Contractor approvals

Support

Perform

Work Plan: Project & Implementation Management Plan - Create/Maintain project plan, prepare & conduct project meetings, create project status reports

Support

Perform

Work Plan: Project & Implementation Management Plan - Determine viability or need of customizations

Perform

Perform

DESIGN

Work Plan: Design Configuration Build

Support

Perform

Work Plan: Design Interface replication with Contractor EHR

Support

Perform

Work Plan: Network Infrastructure needed for hosting model

Support

Perform

Monitor & report schedule / scope changes; obtain ODRC approval

Support

Perform

BUILD

Work Plan: Configuration Build Completion including interface structure

Support

Perform

Training Plan: Development of training plan and all associated training materials based on configuration build

Support

Perform

TEST

Work Plan: Testing & Quality Assurance Design Build

Support

Perform

Work Plan: Testing & Quality Assurance Interface Structure

Support

Perform

DEPLOY

Work Plan: Data Migration from existing EHR to Contractor EHR

Support

Perform

Training Plan: Training Support to achieve implementation before 7/1/19

Support

Perform

Work Plan: Production Deployment & Implementation before 7/1/19

Support

Perform

RUN

Ensure optimal performance of EHR post-implementation

Perform

Perform

ODRC Staff Commitment to the Project:

ODRC Program Manager - Provides oversight of all projects related to the ODRC Core System program and ensures the overall program goals are met. The ODRC Program Manager will be the single point of contact for contractual and project related matters.

ODRC Technical Network / Infrastructure Lead Provides guidance to ensure the solution meets any applicable ODRC and State OIT infrastructure requirements; works collaboratively with the Contractor regarding network and other infrastructure framework needs.

(2) ODRC Technical Database / Support Leads - Provides database guidance and support to facilitate overall program goals and implementation.

(3) Core Subject Matter Experts / Business Team Leads Provide clinical, work flow, and data/reporting, design and expertise based on assigned service area

Requirements and Custom Development

The contractor must be able to review and refine the EHR requirements submitted by the state with respect to their product and submit a System Requirements Document for State Approval. It must be demonstrated how this will fit into the larger project and implementation plan.

To the extent possible, the ODRC EHR is expected to be Out-of-the-Box configurable by an authorized ODRC system administrator and customizable by the Contractor, per ODRC specification. ODRC realizes that customizations may be necessary to provide a fully functional integrated EHR. For any State-approved customizations the following conventions apply:

No customization may introduce a systems performance issue, bottleneck or processing delay in the implemented EHR;

No customization may invalidate, negate or minimize any warranty or maintenance requirement as agreed to between ODRC and current third-party providers that support the current State Systems; and

No customization may be constructed in such a manner as to confound, add complexity to, or create technical burdens that would impact a future upgrade of ODRCs HER.

ODRC acknowledges that certain customizations/extensions and/or integrations/interfaces may be required due to the nature of its business and the various demands of an environment that includes a complex set of interfaces. When the customizations impact business process(es), the following apply:

The Contractor must advise ODRC on process, policy, and if applicable, revised code changes that would fulfill the requirements using Out-of-the-Box or configured functionality prior to the design and implementation of any customization;

For any new customizations proposed after Contract award, the Contractor must obtain written approval from ODRC to design, develop and implement these customizations prior to proceeding; and

The Contractor must seek to implement approved customizations in a supportable and upgradeable manner.

Design

The contractor must provide a design document that includes a system design and technical architecture design for the Project inclusive of hardware configurations, storage, database, operating systems, software, interface/middleware and other technical documents.

Because the ODRC has requested as part of this proposal that the Offeror propose solutions for both Contractor and customer hosted scenarios, this element of the Project should be submitted for both situations.

With regards to customizations, enhancements, and extensions to the proposed software, the following requirements shall apply and govern the design and implementation / build activities:

Wherever possible, the contractor must implement the solution using out-of-the-box delivered functionality;

Customizations, if approved by ODRC in writing, must be designed in such a manner as to not void any software publisher warrantees, not introduce any performance issues or bottlenecks to the as delivered software, and be developed in such a manner as to not preclude or overly complicate upgrades to future versions of the software; and; and

Any incompatibilities or considerations arising from design or implementation activities that violate the previously mentioned considerations are required to be presented to the ODRC in writing for approval.

Data Exchange and Interface Development

The ODRC uses a variety of Contractors for services that require interfacing with the EHR. This interface structure must be replicated within the new EHR.

The EHR must have the capability to exchange data with these systems both in real time using industry standard web services and/or in batch using FTP and/or SFTP.

The infrastructure provided for the data exchange must be scalable for future ODRC needs.

Describe if the Offeror recommends an interface HL7 engine. The ODRC currently utilizes the Interfaceware Iguana engine for this purpose.

Describe the data exchange logic or provide the technical documentation that is shared with customers who need to exchange data with the EHR.

Describe how interfaces would be hosted if the ODRC is Contractor hosted do they also provide and support the interface servers or not?

Describe the ability of the Offeror to replicate and/or improve upon the current EHR interface structure utilized by the ODRC as outlined in the table below:

Describe the development and implementation plan the Offeror will utilize to ensure the ODRC is fully interfaced as needed with the EHR to achieve an implementation date by 6/30/19.

Describe Offerors ability to interface to other EHRs in particularly EPIC, which is utilized by the ODRCs largest healthcare partner, the Ohio State University Medical Center. Describe ability to interface with the Ohio Health Information Exchange, (HIE), Clinisync.

Entity Interfacing

Uses Iguana Yes/No

Current EHR eClinicalWorks

Comments

ODMHAS Pharmacy

Kalos/CIPS

NO

eClinicalWorks

Pharm. Interface Server

Will be activated 2018 for CPOE and EMAR

LabCorp

Lab Orders

Lab Results

NO

eClinicalWorks

Lab Interface Server

In use

DOTS

Department Offender Tracking System

Inmate Demographics, housing, and status data

YES

eClincalWorks

Production Interface Server

In use

Candelis ImageGrid

PACS/RIS

Radiology schedule

Radiology reports

YES

eClinicalWorks

Production Interface Server

In use

Mid-Ohio Radiology

Radiology reports

YES

eClinicalWorks

Production Interface Server

In use

Trident/MobileX

Radiology Reports

YES

eClinicalWorks

Production Interface Server

In use

OSU Procedure Reports

Provider notes and diagnostic reports

YES

eClinicalWorks

Production Interface Server

In use (note: this is an FTP exchange of PDF reports. OSUMC utilizes EPIC but we have not activated a direct interface to EPIC

Data Migration

The project and implementation plan proposed by the Offeror must describe the plan for migrating data from the existing ODRC EHR to the Offerors EHR, utilizing industry standards for data migration, to achieve an EHR implementation date of 6/30/19. Offeror must demonstrate that it has successfully completed data migration for past customers of comparable size and complexity.

Configuration Build

The configuration / build tasks must implement the approved designs of the EHR solution. The ODRC is committed to taking on an increasing role in the implementation activities over the duration of the project and will provide the necessary IT and business resources for the implementation. The implementation plan should include process for finalizing the configuration build and should include the interface structures.

Testing and Quality Assurance

As part of the project and implementation plan the contractor is responsible for completing the required testing to ensure that the solution is ready for ODRC User Acceptance Testing (UAT) processes. Prior to testing the contractor must provide a System Test Plan and include outcomes of the testing in a System Test Results Document. The ODRC requires that the contractor complete sufficient unit, system integration, regression, load, and performance testing prior to submitting the solution for UAT. The contractor must identify, track, and resolve all defects that surface during its testing.

1. User Acceptance Test (UAT) Plan:

The contractor must develop the UAT plan including test scenarios, scripts, end-user participation requirements, schedules, and sign-off criteria with the ODRC.

2. User Acceptance Testing Support Tasks:

a. The contractor must support ODRC UAT as follows:

Develop UAT test scenarios, scripts, cases, and procedures with ODRC;

Coordinate UAT execution and acceptance procedures with the appropriate ODRC participants;

Review changes, fixes, and enhancements with the participants in the UAT;

Correct identified defects and non-conformities in accordance with the acceptance process and; and

Record and report the UAT execution results including comparing actual test results to expected results to validate the success of each test script.

Once UAT is completed, the contractor must provide a UAT Results Document certifying that the above activities are completed to the satisfaction of the ODRC.

Deployment Readiness, Production Release and Implementation

The Contractor must work with the ODRC to execute the production deployment and roll-out of the EHR solution to the ODRC production environment. The Contractor must include a project and implementation plan that addresses cutover from legacy systems with little to no disruption to ODRC users. The Contractor must comply with any applicable State-required implementation and deployment procedures. The Contractor must provide business user support through acceptance of the EHR solution.

The Contractor may submit the EHR solution for acceptance once the EHR solution performs as specified, designed and built to ODRC's satisfaction within a 30-day period.

In the event that any "Critical" or "Urgent" item (or any critical blocking issue) occurs during this 30-day acceptance period, this 30-day period may be extended, at the sole discretion of ODRC, for a period commencing upon satisfactory resolution of the issue in the production environment.

The Contractor must designate a problem as "critical" if the Software is functionally inoperable, the problem prevents the Software from being used in production mode or there is significant potential for data integrity problems. The Contractor must classify a problem as "urgent" if the underlying problem significantly degrades the performance of the Software or materially restricts the ODRCs use of the Software in a production mode. A problem also will be considered urgent if a commonly used feature often generates application errors, causes the Software to freeze, locks up the computer on which the Software is running, or otherwise routinely does not work as intended. Classification of a problem as urgent rather than critical assumes that the ODRC still can conduct business with the Software.

During the acceptance period, warranty, maintenance and support the Contractor must:

Address any software defects, gaps, omissions or errors that are discovered in the Contractor's work as they pertain to operation in a production environment;

Resolve any configuration, performance or compatibility issues that arise as a result of migration of the Contractor's work to a production environment; and

Assist with production issue triage, root cause and remedy analysis and wherever possible propose workarounds, fixes, patches or remedies (code-based, procedural or environmental).

The Contractor plan should indicate support time-frames for response and resolution to critical or urgent issues as outlined in this section.

Any Support call that is not resolved must be escalated to the Contractor's management. This escalation process must be a mutually agreed to process involving the Contractor and the ODRC.

The Contractor should describe any and all warranties provided tied to release of the production environment for deployment.

The implementation of the Contractors system occurs within this task. At a minimum, the Contractor activities of this task include the following:

System Implementation Plan

The System Implementation Plan must demonstrate to ODRC how the Contractor will deploy the system. The plan, at a minimum, must detail the Contractors approach for coordinating the following:

Technical preparation and system changeover activities;

Development of an implementation activities checklist; and

Deployment schedule.

System Implementation Certification

The Contractor must provide a written System Implementation Certification Statement that certifies that the system is ready for implementation. The Certification Statement must confirm:

All system and user acceptance testing is complete;

The production environment has been prepared in accordance with the Contractors requirements;

All user and system supports are in place;

All Security measures are in place; and

Training is completed.

Upon acceptance of the System Implementation Certification Statement by ODRC, the Contractor may promote the system to a production environment

Present System for Final Acceptance

Upon completion and acceptance of the Implementation, and successful completion of the performance period, the Contractor must present the system to ODRC for acceptance. The system presented for final acceptance must account for all required functionality, features and performance requirements.

Documentation

The Contractor must develop and provide all System and User Documentation at the time the system is presented for final acceptance. The Contractor must provide electronic copies of the documentation for the system in a format that allows ODRC to create electronic references to the documentation from its policy and procedure documentation. The documentation must include all manual and system processes and procedures.

Contractor Hosting

ODRC desires hosting by the Contractor as a preferred solution. As part of the project and implementation plan describe in detail the Offerors hosting services within the context of the project plan. The ODRC will need hosting for up to 1200 concurrent users at approximately 30 different locations at any given time. Please include the following elements:

Describe location of Offeror hosting site(s) that would be utilized for the ODRC program and commitment to meet State of Ohio requirements that all applications / data are hosted in the continental United States of America.

Describe performance monitoring and uptime commitment.

Describe how Offeror hosting meets or exceeds industry standards for EHR hosting.

Describe how patches, updates, maintenance, and fixes, are applied to production environment to minimize interruption of services.

Describe change management process.

Describe how the application can be made accessible in a consistent limited IP range for users working on the ODRC network with access occurring through ODRC internet filtering software.

Describe how the application can be made accessible to users working outside of the ODRC network (telehealth providers in other states, specialty care providers such as OSU, etc).

Provide requirements or recommendations for bandwidth from any particular accessing location and/or based on user volume by site.

Describe the disaster recovery capability and processes in place such as: physical location of redundant data centers, frequency of scheduled backups, if backups are stored in a secure off-site location, time to restore the system and use of system during these times.

Describe how frequently you perform trial runs of your disaster recovery plan.

Provide plan to implement the Offeror EHR utilizing Contractor hosting services by 6/30/19.

Change Management Plan

The Change Management Plan documents and tracks the necessary information required to effectively manage project change from project inception to delivery. The Change Management Plan is created during the Design Phase of the project. Its intended audience is the project manager, project team, project sponsor and any senior leaders whose support is needed to carry out the plan.

ODRC requires any request for any change in Services or Project Scope must be in writing; this includes requests for changes in project plans, scope, specifications, schedule, designs, requirements, Service deliverables, software environment, hardware environment or any other aspect to the work. The Contractor will not be obligated to perform tasks related to changes in time, scope, cost, or contractual obligations until ODRC and the Contractor agree to the proposed change. ODRC provides suggested change management process and required form to be incorporated in Offerors proposal.

ODRC is providing Offerors a sample format for change management processes at a minimum to incorporate in their response to provide reassurance to ODRC leaders and stakeholder a delivered solution will include necessary process for facility acceptable project changes.

Step

Description

Generate CR

A submitter completes a CR Form and sends the completed form to the Change Manager

Log CR Status

The Change Manager enters the CR into the CR Log. The CRs status is updated throughout the CR process as needed.

Evaluate CR

Project personnel review the CR and provide an estimated level of effort to process, and develop a proposed solution for the suggested change

Authorize

Approval to move forward with incorporating the suggested change into the project/product

Implement

If approved, make the necessary adjustments to carry out the requested change and communicate CR status to the submitter and other stakeholders

Project Reporting

The Contractor must meet the following project reporting requirements:

Weekly project report (due by close of business each Friday) must provide details on work accomplished/completed, work scheduled, information about schedule changes and any issues/problems encountered and resolutions proposed/implemented.

Monthly Service Level Report as defined in Supplement 5.

The deliverables defined in this section include:

Project and Implementation Management Plan (completed and approved deliverable)

Configuration Build Completion (completed and approved deliverable)

Testing and Quality Assurance (completed and approved deliverable)

Data Migration from Existing EHR to Contractor EHR (completed and approved deliverable)

Interface Replication, Validation, and Implementation (completed and approved deliverable)

Production Implementation/Deployment before 7/1/19 (completed and approved deliverable)

Provide the Work Plan as a complete document that incorporates all the requirements in this section under the Work Plan tab as defined in Attachment Three: Requirements for Proposals.

III. STAFFING PLAN

The Offeror must submit a comprehensive staffing plan designed to achieve the project and implementation plan. The staffing plan must address the following elements:

Contractor Staffing Responsibilities

The contractor staffing responsibilities are critical to the success of the Work Plan for Project and Implementation. All contractors are expected to work in partnership with their ODRC counterparts. For each staff person referenced below, the ODRC will have the same equivalent to work in partnership with the contractor. At a minimum, the contractors staffing plan must include the following key Project personnel and responsibilities along with names/resumes.

Provide names and resumes of staff with an explanation of how contractor staff and plan submitted meet the requirements outlined in this section.

1. On-site Project Manager (PM) The contractor PM must work on location at ODRC to provide project management oversight of the Project through successful implementation. duties and requirements are:

a. Given the importance of this position, the ODRC does not want to experience turnover of the individual assigned, as this may hinder the Project. Therefore, it is important to ensure the correct individual is designated from the beginning.

b. Pricing should clearly indicate the cost of this individual in a separate line item so it is distinguishable from larger software costs

c. Serves as liaison between the ODRC and Contractor resources

d. Creates and manages the Project plan and schedule with ODRC input

e. Manages any other contractor team members involved on the Project

f. Manages issues, risks, and any obstacles the Project may face

g. Point of escalation for Project issues

h. Manages the deliverable acceptance process

i. Utilizes any necessary quality control processes in monitoring project

j. Qualifications:

i. Experience as the PM on implementation projects of similar size and scope within the past 3 years

ii. Project Management certification preferred

iii. Include name and resume

2. Assigned Functional Lead(s) The functional lead(s) must provide business process and subject matter expertise for the proposed software implementation. Contractor may propose a single functional lead for or multiple functional leads depending on business need.

a. Lead design, business analysis, configuration, work-flow, security design, development, and testing

b. Qualifications:

i. Experience as the lead on implementation projects of similar size and scope where the application is currently in production

ii. Experience conducting design sessions for software implementation

iii. Experience on an implementation project where the management modules were integrated

iv. Hands-on experience with the proposed EHR solution management

v. Include names and resumes

3. Assigned Technical Lead(s) The technical lead must provide technical subject matter expertise for the proposed software implementation.

a. Leads the technical team in designing the necessary technical architecture to support the software.

b. Leads the technical team for inbound/outbound interface development, reports, conversions, extension, enhancements, quality control, and testing.

c. Leads the installation and administrative configuration of the software.

d. End-to-end technical implementation, coherency of the implemented modules within the broader context of the proposed software.

e. Center point of communication for all technical matters concerning the application.

f. Qualifications experience as the technical lead on the proposed software implementation projects of similar size and scope where the application is currently in production.

g. Include names and resumes.

The requirements of this section must result in staffing sufficient to achieve EHR implementation/deployment prior to 7/1/19.

Provide the Staffing Plan as a complete document that incorporates all the requirements in this section under the Staffing Plan tab as defined in Attachment Three: Requirements for Proposals.

IV. TRAINING PLAN

Training Plan

The contractor must provide a comprehensive training plan for the Project based on the functional and technical components of the system. The training plan should address or contain the following elements:

1. Training for system administrator and administrative team which will comprise approximately 15 staff to include but not limited to:

Technical training and installation

Application monitoring and troubleshooting

System integration and modifications

Account creation / termination

Interface monitoring and maintenance

Report creation and modification

2. Since ODRC will likely use a Train-the-Trainer model to reach all end-users, the Contractor training provided will be for the Super Users. There will be approximately 35 ODRC staff to be trained as Super Users;

3. The contractor must provide a training environment to remain available prior to and after implementation to manage ongoing training needs;

4. Training should consider that the ODRC is on an existing EHR, so the conversion is from EHR to EHR as opposed from paper records to EHR;

5. Training materials should be provided and may include but are not limited to:

Manuals (printed and/or available online)

Videos

Short task guides

Training materials specific to different modules or disciplines, e.g. what dental staff need to know may be very different than what mental health staff need, etc.

ODRC must review and approve training materials prior to the start of training

The contractor must provide the rights or a mechanism by which the ODRC can replicate training materials as needed internally to sustain training due to staff turnover

The Deliverable defined in this section includes:

Cost of all Training Support and associated materials through implementation/deployment (completed and approved deliverable)

Provide the Training Plan as a complete document that incorporates all of the requirements in this section under the Training Plan tab as defined in Attachment Three: Requirements for Proposals.

V. TECHNICAL REQUIREMENTS

1. Software Licensing

Describe the Offerors system for software licensing to include:

Provision for perpetual software licenses for all Commercial Software necessary to meet the requirements of this RFP. Include the Offerors methods for licensing users.

In the current ODRC EHR approximately 500 provider licenses (for users who can prescribe medications and/or diagnose independently) are owned, supported, and maintained. The ODRC has approximately 2700 total users.

In the event the accepted EHR solution is customer hosted, describe ability to provide an agency license meaning all ODRC employees with a need to access and use the software may do so. It also means all third parties involved in related activities, such as the ODRC's contractors, suppliers, third party administrators, managed care organizations, and employers covered by the ODRC's programs, to the extent that such access supports the ODRC's governmental and business functions. An Agency license also gives ODRC the right to copy the Key Commercial Software and run and use multiple instances of it, for the above purposes, if reasonably necessary to facilitate the authorized use of it, provided the ODRC owns or controls the computers on which the Key Commercial Software is installed. The ODRC may also copy the software for use on computers owned and controlled by third parties, if the purpose of doing so is to facilitate disaster recovery, emergency needs, including testing and training for such purposes, and to permit a third party to host the Key Commercial Software on behalf of the State in an outsourcing arrangement. This agency license also gives ODRC the right to provide the authorized individuals described above access to the Key Commercial Software remotely through a browser or client software and an Internet or similar connection for all uses and purposes identified above.

If applicable, describe any differences in licensing structure between Contractor hosted and customer hosted scenarios.

Respond to this section here, incorporating all requirements and descriptions.

2. Software Support and Maintenance

Describe the Offerors system for provision of software support and maintenance. Describe any warranties associated with the software.

Respond to this section here, incorporating all requirements and descriptions.

3. Desktop Software Requirements

List any browser plug-ins, add-ons and Active-X components required by the proposed solution. Does software use active directory?

List any third-party software applications, such as office automation applications, image display tools, and graphics packages required by the solution.

Respond to this section here, incorporating all requirements and descriptions.

4. Desktop Hardware Requirements

List the desktop system requirements such as processor speed, memory required, video cards needed for the EHR to function properly.

Describe Offeror software compatibility with the following specifications utilized by the ODRC:

Functions on a Windows 7.64 bit and Windows 10 Desktop Operating System.

Functions with Microsoft Internet Explorer 11 or newer or the latest version of Google Chrome.

Functions for ODRC users whose access is limited to that of Standard User in the User Account Control (UAC) setting on their ODRC desktops.

Respond to this section here, incorporating all requirements and descriptions.

5. Upgrades and Patches

Describe the frequency of, and process for communicating, system changes such as patches, functionality changes or version upgrades.

Describe the process for making changes available to users in a test environment for review before the changes are implemented in the hosted EHR.

Respond to this section here, incorporating all requirements and descriptions.

6. Application Security

Describe key application security features such as, role-based access controls, logs of system activity by user, system timeouts for inactivity, etc. Indicate if role-based security applies down to the field level or applies only at the screen level.

Describe capabilities to ensure staff and provider notes cannot be edited after finalized / locked, for security and legal purposes.

Describe ability to capture staff and patient signatures in the record.

Describe ability of software to restrict access to an individual patient record both by user and by patient. Examples include:

Does the system allow for restricting access to released or deceased patients based on user profile?

Does the system allow a user to be assigned to specific institutions or facilities without the ability to see patients at other facilities?

Is there a read-only mode?

Respond to this section here, incorporating all requirements and descriptions.

7. System Security

If Contractor hosted, Contractor must provide a secure environment for the application, data and any hardware and software, including servers, network and data components.

Describe security controls in place relative to external connections to the Internet such as intrusion detection and countermeasures that shall detect and terminate any unauthorized activity prior to accessing the EHR or its data.

Describe the firewall(s) used and how they will protect against network intrusions

Describe the virus protection process.

Describe physical security measures such as securing all data on a secure server, in locked data cabinets within a secure facility.

Describe where and how data encryption is employed, including but not limited to, encrypted data at rest, tables, and attributes.

Describe the process for notifying the ODRC in the event of a computer system security breach which did or could impact ODRC data.

Respond to this section here, incorporating all requirements and descriptions.

8. Audit Requirements

Describe what reports and/or analysis tools are available to support an audit of user activity in the system. For example:

Alerts on policy or work-flow violations;

Exception events;

Peak, low, average usage statistics by institution;

User activity audits to show date, time, and duration of activity by patient, work-station and/or IP;

Respond to this section here, incorporating all requirements and descriptions.

9. Interoperability

A. Describe capability the system has for uploading and associating data files (Microsoft-Word, comma delimited, etc.) to patients. These files will include test results, scans of outside provider records, transcription files, radiology images etc.

B. Describe the level of mobile device application support of the EHR, to include but not be limited to, Apple iOS and Android devices. Also describe plans to add additional interfaces or other technologies into the system in the future.

C. Describe all canned interfaces that the Offeror has available with healthcare entities, other EHRs, and/or devices.

D. Describe integration with voice-to-text speech recognition software such as Dragon, by Nuance.

Respond to this section here, incorporating all requirements and descriptions.

10. Support System / Help Desk

Currently the ODRC utilizes a system that features an internal support team that fields technical issues / concerns from all 2500 users. This team acts as a filter, and they in turn contact the Contractor support system as needed for issues they cannot resolve on their own. This ODRC support team is a higher tier level of support and is manned by database administrators.

However, the ODRC is interested in the feasibility of having the Contractor provide the totality of EHR support to all users, particularly in the scenario where the EHR is Contractor hosted. In this instance, users would contact the Contractor support system directly for assistance. Therefore, if the Offeror provides tiers of support or varying support packages, please provide an overview of each, what each includes.

Fully describe end user support packages available to the customer as follows:

Help desk hours of operation, response times based on urgency of need, and after hours contact procedures.

Describe the types of user needs the Contractor support system handles.

Note if self-help or knowledge base options are available to users.

Describe how the Contractor ensures their help desk staff are trained and knowledgeable about product utilization and work-flows.

Describe qualifications / profession of individuals the Contractor utilizes on their help desk.

Describe how a customer can escalate a support case if unsatisfied with the response.

Describe any internal processes the Contractor utilizes to solicit customer feedback on quality of support services e.g., calls, surveys, ratings.

Describe data or reporting that the Contractor is able to provide to clients regarding support service volume, type, time, and resolution.

Physical location of Contractor help-desk services in the United States. Any provision of services that is off-shore requires a waiver from the State of Ohio executive order and a waiver is not common or guaranteed.

Respond to this section here, incorporating all requirements and descriptions.

11. User Input and Feedback

Describe the availability of local and national user groups and user conferences available to users of the proposed EHR. Describe the process for users to supply input to future product releases.

Respond to this section here, incorporating all requirements and descriptions.

12. Telehealth Integration

Describe capabilities for integration of telehealth technology into the EHR.

Describe any system requirements necessary for telehealth integration.

Describe recommended and/or compatible devices needed to utilize telehealth features of the EHR.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

13. Kiosk Integration

Describe capability for integration of kiosks that enable patients to submit requests to for a healthcare appointment.

Describe any system requirements necessary to use Offerors kiosks.

Describe recommended and/or compatible devices needed to utilize kiosk features.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

14. Ease of Use / User Friendly Features

Describe the features of your system that enhance ease of use, efficiency and productivity for the user. These might include:

Speed of use and response time for electronic transactions;

Typefaces and fonts that are easy to read;

Meaningful use of color and shading;

Allow for sizing of workspace view;

Simplicity (clear and clean screen design, lack of visual clutter, concise display of information);

Natural and intuitive screen navigation;

Use of spell check where appropriate;

Simple and intuitive organization of EHR components;

Static sort criteria in workspaces;

Ability to set default facility by user to avoid continual facility selection;

Ability to assign users to one or multiple facilities;

Screens organized by meaningful relationships (e.g. lab results are displayed with a medication list);

Minimal steps (cursor clicks or keyboard strokes) to accomplish tasks or navigate screens;

Preservation of context (minimal visual interruptions such as screen changes or dialogue boxes);

Minimal use of modes (such as viewing mode versus text entry mode);

Efforts to minimize scrolling or use of exploding menus;

Use of default values or auto-completion of data;

Forgiveness (i.e. mistakes can be changed and/or recovered);

Allows for use of special characters (ampersand, apostrophe, etc) in text fields; and

Merge (example patient has two inmate identifiers over time and records need merged) and un-merge (a record was mistakenly or electronically merged) features are well thought out in terms of correctional healthcare.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

VI. Clinical Requirements

1. Problem List and Summaries

Describe capabilities for creating, maintaining, updatingpatient problem lists.

Describe capabilities for providing summaryscreens that display a patients essential medical, dental, behavioral health, and/or demographicinformation.

Describe the ability to capture, display, and track advanced directives.

Describe capabilities for documenting special status / need such as suicide risk, suicide watch, bottom bunk requirement, etc.

Describe capabilities for providing work (or task) lists thatshow items needing completion or review such as lab/diagnostic results, reports, items needing signature and follow-up items.

Describe any standard reporting capabilities for problem lists / summaries.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

2. Screenings and Transfers

Describe capabilities for intake / reception screening for medical, behavioral health, and dental.

Describe capabilities for handling intra-system transfers between institutions.

Describe capabilities for managing hospital admissions, out-to-court offenders, and transitional control offenders.

Describe screenings and capabilities for conditions such as tuberculosis, HIV, sexually transmitted diseases (STDs), pap smears, mammograms, prostate and/or testicular exams, tetanus, Hepatitis A and B, Hepatitis C, influenza, etc.

Describe any standard reporting capabilities for screenings and transfers.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

3. Patient Data

Describe the patient portal and how it functions within the application.

Describe capabilities for recording and displaying patient allergies and adverse reactions, including both medicationsand non-drug agents.

Describe capabilities for tracking and managing chronic disease across the lifespan. Examples would be diabetes and hypertension, among many others.

Describe capabilities for documenting vital signs (what are the variations for documenting vital signs, graphical displays, automatic BMI calculation, etc.).

Describe capabilities for documenting and displaying immunizations across the lifespan.

Describe use of anatomical images for charting.

Describe capabilities to document wound care and include the ability to incorporate wound photos, acceptable file formats, etc.

Describe capability to graph clinical parameters over time (e.g., lab, vital signs including BMI).

Describe capability to document Abnormal Involuntary Movement Scales (AIMS) for patients on psychotropic medication.

Describe capability to document or complete any standardized psychological, intelligence, or other behavioral health related testing (Examples: MMPI, TABE, etc.).

Describe any unique features for treatment of addiction to drugs or alcohol.

Describe capability to scan relevant clinical documents from community and off-site providers for integration into the appropriate place in the medical record.

Describe any standard reporting capabilities for patient data.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

4. Conducting Groups and Rounds

Describe capabilities for documenting medical and behavioral health rounds in a segregation or treatment unit. Is there a mechanism to document these brief visits in a rapid and efficient manner for a large number of patients?

Describe capabilities for scheduling and documenting group activities such as mental health treatment or programming. Are there capabilities to rapidly input data into the record ofmultiple offenders?

Describe the ability to manage caseloads of patients by staff person/user.

Describe any standard reporting capabilities for groups and rounds.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

5. Mental Health Treatment Plans

Describe capabilities for documenting patient treatment plans to include goals, interventions, progress, and outcomes.

Describe capabilities to capture patient progress on treatment plans over time.

Describe any standard treatment plans the program has for behavioral / mental health.

Describe system capability to create site-specific care plans, care protocols, and guideline documents by an authorized administrator. (templates).

Describe the ability to document a meeting of a multi-disciplinary treatment team with the patient.

Describe any standard reporting capabilities for treatment plans.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

6. In-patient Care and Infirmaries

How does the program manage infirmary or in-patient facilities?

Describe features related to in-patient bed admissions and discharges, and tracking of same.

Describe any graphical displays of room and bed set-up if available. Does the system allow you to click a room / bed to drill down on patient care?

Describe ability to assign beds to staff or providers.

Describe ability to document care for activities of daily living (ADL) as is typically provided by nursing aides or in a long-term care (LTC) facility. (Examples include bathing/showering, toileting, turning and turn schedules, brushing teeth, etc.).

Describe system capabilities to capture hospice or end-of-life care.

Describe system capabilities to capture in-patient mental health care.

Describe any standard reporting capabilities for in-patient care / infirmaries.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

7. Discharge Process

Describe process for discharging patients from the EHR.

Describe Offeror experience automating the discharge process via interface with inmate tracking software.

Describe capabilities for discharge planning, includinggeneration ofreferrals and alerts to staff who need to complete steps in the discharge planning process.

Describe and provide report samples of discharge summaries that may be provided to the patient or to other jurisdictions and health care providers.

Describe any standard reporting capabilities for the discharge process.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

8. Dental Health Services

Is a subcontracted entity used for the dental module or is it an integrated module? Describe the integration with the EHR.

Describe the method of documenting the oral examination and how it is displayed.

Describe the use of forms, progress notes and use of digital radiography within the system.

Describe how Dental scheduling is incorporated in the system.

Describe in depth the system capability to capture dental care to include tooth diagrams, care planning, and CPT codes. Is the dental module integrated into the EHR version being proposed as part of the Offerors solution?

Describe any standard reporting capabilities for dental care.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

9. Optometry Services

Describe ability to document optometry services including any special templates or unique features.

Describe any standard reporting capabilities for optometry care.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

10. Podiatry Services

Describe ability to document podiatry services including any special templates or features unique to same.

Describe any standard reporting capabilities for podiatry care.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

11. Physical Therapy Services

Describe ability to document physical therapy services including any special templates or features unique to same.

Describe any standard reporting capabilities for physical therapy care.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

12. Nutrition Services

Describe ability to document nutrition services.

Describe ability to establish, regulate, and track, special diets.

Describe ability of the system to issue diet cards or meal tray cards.

Describe any standard reporting capabilities for nutrition services.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

13. Dialysis Services

Describe ability of system to capture dialysis care including any special templates or features unique to same.

Describe any standard reporting capabilities for dialysis care.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

14. Pregnancy and Gynecologic Care

Describe ability or features specific to pregnancy management and gynecologic services.

Describe any standard reporting capabilities for pregnancy and gynecologic care.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

15. Pediatric Care

Describe any pediatric-specific program features.

Describe any standard reporting capabilities for pediatric care.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

16. Respiratory Therapy and Ventilator Care

Describe any program features for documentation of respiratory therapy.

Describe any program features specific to care of a patient on a ventilator.

Describe any standard reporting capabilities for ventilator care.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

17. Correctional Specific Health Care Concerns

Describe any features utilized to capture annual physicals.

Describe system capabilities for management of care for patients in restraints.

Describe system capabilities for management and care of a patient on a hunger strike.

Describe system capabilities or past use for sex offender treatment services.

Is the Offerors proposed EHR solution identical to the community version or is it unique to correctional health care? What are the distinctions between the two?

Describe any standard reporting capabilities unique to correctional health care.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

18. Terminology

1. Describe capability to integrate and use ICD 10 and CPT codes for diagnosis and treatment.

1. Describe capabilities for using nursing terminology for diagnoses, interventions and outcomes.

1. Describe capabilities for using DSM-5 psychiatric diagnoses.

1. Describe any standard reporting capabilities specific to standardized terminology.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

19. Scheduling Patient Appointments

Describe how patient requests for health care are generated, routed, tracked and documented. Can patients submit requests electronically? How do requests lead to sick call appointments?

Describe scheduling capabilities, including those for medical, dental, behavioral health, nursing, specialty appointments (optometry, podiatry and chronic diseases) and ancillary services (laboratory and X-ray).

Describe the flexibility of the scheduling package in terms of appointment types, length of time of appt., availability, moving/reassigning dates of appointments, deleting appointments, tracking off-site appointments and rescheduling.

Describe how the program can manage off-site specialty care and surgery scheduling at health care entities outside of the ODRC.

Describe how the program manages appointment reconciliation.

Describe how the program can accommodate a central scheduling group that schedules specialty care for all institutions.

Describe any standard reporting capabilities for scheduling and patient visits.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

20. Order Entry

Describe the provider order entry system and how orders are routed from entry by a provider to execution of the order. Include medications, diet orders, lab tests, x-ray, orders to nursing, referrals to other providers and requests for utilization review.

Describe capabilities for providers to use / generate order sets to streamline the order entry process.

Describe capabilities for providing alerts to providers as they enter orders, such as drug allergies, drug interactions, therapeutic duplication, dosage outside of recommended range and drug food interactions.

Describe program capacity for managing utilization review or internal approval processes for specialty care, non-formulary medications, surgeries, or diagnostic procedures. The ODRC State Medical Director, State Psychiatric Director, and State Dental Director oversee a robust collegial review /utilization review program. All of the above examples are ordered around the state yet require central approval and scheduling.

Describe system capabilities for associating a diagnosis code with any order.

Describe any standard reporting capabilities related to ordering in the EHR.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

21. Results Posting for Diagnostic Services

Describe how lab, x-ray, procedure, or diagnostic results come to the attention of the ordering provider(s). This assumes an interface is in place for these services and the result has crossed it to ODRC successfully. What is the process, features, and work flow from that point?

Describe the capabilities to incorporate ECG tracings, Spirometry, point-of-care testing, and other on-site diagnostic testing into the EHR.

Describe capabilities for notification of providers of any new laboratory or diagnostic results in the chart.

Describe ability to display both radiology reports as well as stored DICOM images from the customers PACs.

Describe any standard reporting capabilities for results posting.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

22. Alerts

Describe system abilities to provide alerts to staff regarding patient care.

Describe ability to provide notifications or alerts based on user role.

Examples of some alerts desired are as follows:

Crisis watch,

Suicide attempt,

Heat precautions,

Hunger strike,

Abnormal vitals or diagnostic results,

Special diet, and

Adverse events.

Describe any standard reporting capabilities related to alerts.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

23. Clinical Decision Support

0. Provide a description of any clinical decision support systems provided with the EHR that would provide assistance in diagnosis and/or appropriate treatment.

0. Describe the systems capability for facilitating communication between health care staff within the application (electronic messaging or an inbox) and security features.

0. Describe any discipline-specific templates that support clinical practice, including but not limited to primary care, psychiatry, or any other specialty area of health care.

0. Describe any product integration with web-based support subscriptions such as Up-to-Date or Lippincott Nursing Advisor.

0. Describe any incorporation of health guidelines for clinical decision support of preventive care such as United States Preventive Services Task Force (USPSTF) recommendations.

0. Describe any type of clinical rule engine that allows EHR administrators to establish clinical rules based on local policy or health care standards.

0. Describe any standard reporting capabilities related to clinical decision support.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

24. Patient Education

0. Describe capabilities for provision of patient education, including printing of appropriate material for medications, immunizations, medical or mental health conditions, oral hygiene, discharge planning etc.

0. Describe if there is ability to create, review or edit patient education materials.

0. Describe language alternatives to English for education materials.

0. Describe capability to link patient education to patient care plans.

0. Describe or list any canned education materials provided.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

25. Reporting: Healthcare Business Intelligence (HBI) / Data Mining / Predictive Analytics

0. Describe system capabilities to provide standard management reports by facility, health care service areas and across disciplines/specialties.

0. Describe capabilities to develop continuous quality improvement (CQI) auditing and reporting.

0. Describe capability to ensure that CQI data and reports are not included in routine exports of the patient health record (CQI data is protected).

0. Describe ability to provide ad-hoc reports that can be written by ODRC staff independent of Contractor assistance.

0. Describe formatting available for reports generated. Example: Word, PDF, Excel, etc.

0. Describe ability to print / export portions or all of the health record to both paper and electronic file format such as PDF, for external record requests. Is this a system feature or does it require special drivers or modules to achieve?

0. Describe any back-end reports that would be useful to system administrators to manage the EHR program.

0. Describe any canned reports the Offeror has designed as part of a reporting suite.

0. Describe ability of system to provide predictive analytics.

0. Describe any dashboard features available for administrators or clinicians.

0. Describe any services the Offeror provides in terms of design and implementation of a robust HBI program for customers.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Provide the Reporting response as a complete document that incorporates all of the requirements in this section under the Reporting tab as defined in Attachment Three: Requirements for Proposals.

26. Forms

0. Describe the use of forms or templates in your system.

0. Describe the ability to incorporate ODRC forms and/or encounter templates into the system with and without Contractor assistance.

0. Describe the ability to capture signatures on forms.

0. Describe the ability to restrict who can edit the structure of forms and templates (i.e., only an administrator, etc.).

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

27. General Pharmacy

0. Describe system ability to support a controlled formulary.

0. Supports interface with pharmaceuticals and supplies, with maximum and minimum inventory levels as well as reorder levels.

0. Support a perpetual inventory for pharmaceuticals and supplies, setting minimum and maximum levels by items as the auto reorder point.

0. Supports a large daily volume of prescription order processing of >3000 per day.

0. Supports the ability to interface with automated dispensing cabinets such as Pyxis.

0. Supports robust reporting, including but not limited to DEA controlled drug dispensing data, drug specific and AHFS therapeutic category dispensing data, on/off formulary usage, prescriber-and site-specific drug utilization, etc.

0. Supports activities related to a Contract Pharmacy or Covered Entity for 340B Pharmacy Program.

0. Support the use of unique identifiers using a bar code or other methods for monitoring inventory levels.

0. Supports ability to generate barcodes (such as NDC number or Prescription number).

0. Support the use of TALL Man lettering as defined by the FDA.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

28. Computerized Physician Order Entry (CPOE)

0. Describe capability to electronically transmit medication orders directly to designated pharmacy (CPOE) via interface, in this instance to Kalos / CIPS software.

0. Describe any certifications or approvals held by the Offeror for their system to manage CPOE/EMAR, with particular emphasis on the Ohio Board of Pharmacy and any pertinent Federal requirements.

0. Describe technology used or supported to ensure security of the medication ordering process such as dual factor authentication, RFID readers, badge scanners, fingerprint recognition, etc.

0. Describe any associated peripherals recommended for use with the system uses to safely achieve secure medication order transmission.

0. Describe capability to automatically discontinue orders on a specified date.

0. Describe ability to view and sort a patient profile by varying fields (drug name, written date, stop date, etc.).

0. Does system support ability to flag duplicate therapy and recognize drug-drug, drug-food, drug-disease, drug-age, drug-herbal interactions, as well as alerting to pregnancy and lactation precautions?

0. Supports ability to recognize and alert for low and high dose regimes.

0. Supports ability to recognize and alert for potential adverse reactions or allergies.

0. Describe capabilities for supporting a pre-approval process for restricted or non-formulary medications, including review/approval by an approver prior to filling a prescription.

0. Describe capability for ordering complex medication scenarios to include but not limited to: nitroglycerin, steroid tapers, sliding-scale insulin, and PRN medications.

0. Describe any standard reporting capabilities related to pharmacy and CPOE.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

29. Electronic Medication Administration Record (EMAR)

0. Describe capabilities for electronic documentation of administration of medications to patients. Include capabilities for recording, tracking and auditing medication administration records.

0. Describe methods used to make the process of medication administration rapid and efficient with a minimum of mouse clicks, textentryfieldsand/or screens.

0. Describe the process formedication renewals and/or refills, including any alerts that indicate refills are needed.

0. Describe capabilities for distinguishing between nurse dispensed medications and medications self-carried by patients.

0. Describe capabilities to support off-line module for administration of medication in case of network/internet failure.

0. Describe ability to generate a paper Medication Administration Record (MAR) as back-up to the EMAR.

0. Frequently in correctional healthcare a patient will have self-carry medications ordered, commit a rule violation or go into segregation, and have their medications collected and nurse dispensed. Describe capabilities to switch a medication order from self-carry administration to nurse dispensed administration without requiring a new order.

0. Describe system capabilities for nurses administering medications to record them as administered, refused with reason, and held for clinical reason.

0. Describe capability for administration of complex medication scenarios to include but not limited to: nitroglycerin, steroid tapers, sliding-scale insulin, and PRN medications.

0. Describe ability to record pertinent vital signs that must be assessed prior to administering a medication, e.g., pulse with digoxin, blood glucose with insulin.

0. Describe system capabilities for monitoring and reporting patient compliance percentages with medications.

0. Describe capability of using bar code or other methods to scan and register offender identification badges when administering medications.

0. Describe any standard reporting capabilities related to medication administration and EMAR.

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

30. Intra-venous (IV) Medication Ordering and Administration

0. Describe system, features, and support for IV medication ordering.

0. Describe system, features, and support for IV medication administration.

0. Describe capability and process for ordering and administering complex IV therapy to include but not limited to:

Vancomycin,

Total Parenteral Nutrition (TPN),

Blood Transfusions, and

Chemotherapy.

Describe any standard reporting capabilities related to IV medication ordering and administration

Please describe in this table the level of effort required to implement all requirements in this section in the proposed EHR system

Standard little effort

Configuration medium effort

Customization significant effort

Respond to this section here, incorporating all requirements and descriptions.

Initiate

Analyze

Design

Build

Test

Deploy

Run

ODRC Electronic Health Record (EHR) Scope of Work

Page 36

Generate CR

Report Status

Log Updated Status

Implement CR

Authorize CR

Evaluate CR