Attachment_2_-_IDIQ_SOO_-_Amendment_2_0002.pdf

HEALTH INFORMATION TECHNOLOGY

MODERNIZATION PROGRAM

RFP No. 140D0421R0050 Attachment 2: IDIQ Statement of

Objectives (SOO) – Amendment 2

IHS Heal th IT Modernizat ion Program 2

Table of Contents

1.0 Purpose

2.0 Background

2.1 The Indian Health Care System

2.2 Health Information Technology at IHS

2.3 Health IT use by Tribes and Urban Indian Health Programs

2.4 The IHS Health IT Modernization Initiative

3.0 Scope

3.1 Scope of Acquisition

3.2 Scope of Services Supported

3.3 Out of Scope

4.0 Health IT Guiding Principles

5.0 Solution Capabilities

6.0 Solution Objectives

6.1 Usability of Solution Capabilities

6.2 Planning and Implementation of Solution Capabilities

6.2.1 Health IT Modernization Readiness and Mitigation Analyses

6.2.2 Go-Live and Post-Go-Live Support

6.3 Training

6.3.1 End User Training Plans

6.3.2 System Training and Certifications

6.4 Data Management

6.4.1 Conversion and Migration

6.4.2 Data Management Plan

6.4.3 Data Analytics and Reporting

6.4.4 Data Archiving

6.5 Interoperability

6.5.1 Regulatory Compliance

6.5.2 Standards Based

6.5.3 Consuming and Displaying Patient Data

6.6 Quality Assurance and Testing Strategy

6.7 Operations and Support

6.7.1 System Operations

IHS Heal th IT Modernizat ion Program 3

6.7.2 Service Delivery and Support

6.7.3 Change Control and Solution Governance

6.7.4 Continuity of Operations

6.8 Cybersecurity and Access

6.8.1 Secure Software

6.8.2 Security Controls

6.8.3 Security and Privacy Compliance

6.9 Project Management

6.9.1 Capital Planning and Investment Control

6.9.2 Section 508 Compliant Materials

6.9.3 Contract Personnel

7.0 Period of Performance

8.0 Place of Performance

Appendix A – Clinical and Business Processes

Appendix B – Clinical Data Flow and Interfaces Context

Appendix C – Provider and/or Facility Metrics

Appendix D – Definitions Appendix E – HIT Modernization Program Management Plan (PMP) Appendix F – HIT Modernization Project Process Agreement (PPA) Appendix G – HHS Policy for Information Technology Procurements

IHS Heal th IT Modernizat ion Program 4

1.0 Purpose

The purpose of this Statement of Objectives (SOO) is to convey the current business objectives and applicable scope and constraints for Indian Health Service (IHS) Health Information Technology (IT) Modernization. The intent of using a SOO is to provide the maximum flexibility to the Contractor to provide innovative solutions using proven processes, methods, standards, and technologies.

IHS is seeking a scalable and flexible solution to serve as the foundation of its Health IT Infrastructure that is useable, maintainable, extensible, and interoperable for our users, partners, patients, and communities to achieve the IHS Mission and Vision:

• Our Mission: to raise the physical, mental, social and spiritual health of American Indians and Alaska Natives to the highest level.

• Our Vision: healthy communities and quality health care systems through strong partnerships and culturally responsive practices.

As a direct result of this contract performance, IHS expects to achieve the following outcomes to align with IHS Strategic Goalsi and the IHS Strategic Plan FY 2019-2023ii:

• Improved access to services for American Indian and Alaska Native (AI/AN) people seeking care from the IHS, Tribal, and Urban (I/T/U) Indian health system.

• Improved patient engagement through electronic access to health information.

• Improved health status for AI/AN people receiving care from IHS.

• All IHS facilities, as defined in Appendix D, will have optimal support for their status as Patient Centered Medical Homes.

• Improved quality of care provided by IHS, as demonstrated by government and industry benchmarks.

• Improved interoperability and sharing of patient information within the organization, across the I/T/U health system, and with private and government partners (e.g., Department of Veterans Affairs (VA)).

• Improved organizational maturity in use of IT systems in service of the IHS mission.

• Complete and regularly updated Security Risk Analysis.

• Improved ability for IHS to provide services in a sustainable way through cost recovery.

• Clinical and business operations user satisfaction with Health IT usability.

2.0 Background

2.1 The Indian Health Care System

The IHS is the principal federal health care provider and health advocate for AI/AN people, and its mission is to raise their physical, mental, social, and spiritual health to the highest level. The IHS supports a comprehensive direct and public health service delivery system through a network of hospitals and clinics located in 37 states across https://www.ihs.gov/aboutihs/overview/ https://www.ihs.gov/strategicplan/

IHS Heal th IT Modernizat ion Program 5 the country, largely in extremely rural areas. IHS headquarters is in Rockville, MD, and the agency's health care operations are administered through twelve Area (regional) Offices. More detailed information on the location and types of facilities, services, and employees is available through the IHS website.iii

The Indian health care system is comprised of three broad components, collectively known as the I/T/U:

• I (IHS) – A federal Operating Division of the U.S. Department of Health and Human Services (HHS), with administrative and program offices located in Rockville MD, twelve Area Offices across the country, and direct operational management of:

• 24 hospitals (including five Critical Access Hospitals (CAH)),

• 51 health centers (outpatient, at least 40 hours per week),

• 24 health stations (less than 40 hours per week)

• 6 Youth Regional Treatment Centers (YRTC) directly managed by the IHS;

• T (Tribal) – Tribal healthcare organizations operated and managed independently by federally-recognized Tribes under the provisions of the Indian Self Determination and Education Assistance Act of 1975 (ISDEAA) (Public Law 93- 638, as amended):

• 22 hospitals (including 9 CAH),

• 279 health centers,

• 79 health stations,

• 59 Alaska Village Clinics

• 6 YRTCs

• U (Urban) – Urban Indian Health Program (UIHP) organizations that operate as non-profit 501(c)(3) organizations. Currently, there are 41 UIHP organizations that are funded through grants and contracts from IHS under Title V of the Indian Health Care Improvement Act of 1976, P.L. 94-437.

2.2 Health Information Technology at IHS

The health information system in use at IHS, as well as many Tribal and Urban Indian healthcare organizations, is the Resource and Patient Management System (RPMS), a comprehensive health information suite that supports a broad range of clinical, population health, and business processes from patient registration through the billing cycle. RPMS was internally developed by IHS, leveraging a decades-long collaboration with the Department of Veterans Affairs (VA), and is certified to the 2015 Edition criteria published by the Office of the National Coordinator for Health Information Technology

(ONC).

RPMS is a distributed system, with hundreds of separate databases located at facilities nationwide, managed and supported locally or through Area Offices. The IHS Office of Information Technology (OIT) develops and updates the system regularly, issuing patches that are installed on each instance by local staff. In recent years, advances in health-related standards and technologies, an increasingly complex regulatory https://www.ihs.gov/newsroom/factsheets/ihsprofile/ https://www.ihs.gov/newsroom/factsheets/critical-access-hospitals/

IHS Heal th IT Modernizat ion Program 6 environment around Health IT, and the decision of the VA, IHS’ long-time collaborative partner, to move to an off-the-shelf Health IT solution, have combined to make the current approach to IHS Health IT development and support non-sustainable going forward.

2.3 Health IT use by Tribes and Urban Indian Health Programs

All IHS (federally-operated) healthcare facilities, as defined in Appendix D, use RPMS.

Under the self-determination prerogatives of PL 93-638, Tribes and Tribal Organizations may elect to use RPMS with or without IHS support, or they may choose to adopt commercially-available solutions. Similarly, Urban Indian Health Programs may use RPMS or an alternative of their choice. While the majority of Tribes and UIHPs use RPMS, it is estimated that as many as 80 instances of commercial Electronic Health Record (EHR) and related systems are presently in use. Many Tribes/UIHPs use RPMS and commercial systems simultaneously.

As IHS proceeds with replacement of RPMS (see below), Tribes and UIHPs that presently use RPMS may elect to continue to use the IHS-selected solution in a multi-tenant environment, or may choose to adopt different Health IT solutions. Similarly, those Tribes and UIHPs that presently use commercial alternatives may decide that the modernized Health IT solution that IHS adopts through this solicitation will meet their needs, and transition to become a tenant on the IHS platform.

2.4 The IHS Health IT Modernization Initiative

In 2018-2019, HHS and the IHS collaborated on an analysis of approaches for modernization of the IHS Health IT infrastructure. The assessment focused on the people, processes, and technology that are part of the current RPMS ecosystem, seeking to achieve a detailed understanding of the current system’s utilization, capabilities, effectiveness, and gaps. The analysis included site visits, nationwide data calls, stakeholder and tribal partner interviews, and listening sessions. The final report and other deliverables from this analysis are posted hereiv.

Upon careful review of the findings from the above analysis, tribal consultation, and urban confer, IHS leadership concluded that a full replacement of RPMS is the most appropriate, realistic, and sustainable option for IHS Health IT modernization. The IHS is confident that commercial solutions are available that will enable the agency to move forward with a truly modern system that will not only support but improve its healthcare operations into the future. The Health IT industry offers a variety of mature, forward-looking solutions that offer reliable integration of business line functions, regulatory compliance, and technical support.

https://www.hhs.gov/cto/initiatives/public-health-innovation/indian-health-service-health-it-modernization/index.html

IHS Heal th IT Modernizat ion Program 7

3.0 Scope

3.1 Scope of Acquisition

The scope of this acquisition includes procurement, implementation, and support for a commercially-available Best-of-Suite Health IT replacement of the RPMS. IHS endeavors to retire its RPMS health information technology platform and replace it with an enterprise health information technology solution. This will be an enterprise instance, centrally managed and governed solution that accommodates participation by numerous Tribal and Urban Indian healthcare organizations alongside the IHS in a multi-tenant environment. IHS seeks a Health IT solution that uses modern technologies and incorporates best practice clinical and business processes to improve health care outcomes. This includes the installation, implementation, training, integration, optimization, and sustainment of recommended solutions, strategies, and equipment (procured by the Contractor or provided by the Government). The procurement of limited ancillary items (e.g., hardware/software, minor cabling, network drops, etc.) may be allowed on a case-by-case basis when determined to be most efficient to prepare the site for the deployment of the EHR solution.

3.2 Scope of IHS Services Supported by Health IT Solution

The scope of capabilities and services touched by the IHS Health IT modernization initiative is broad. IHS provides cradle-to-grave care for its service population, and in most locations offers a variety of services in an integrated setting, typically including but not limited to:

• Primary care for all ages

• Hospital services

• Surgical services

• Prenatal care

• Behavioral health

• Dental

• Eye care (opticians, optometry, and/or ophthalmology)

• Physical therapy

• Telehealth services (services provided when the physician/provider and patient are separated by time and/or distance)

• Referrals to outside partners and specialty services

• Purchased and Referred Care (PRC) program referrals

Most locations have fully integrated ancillary services on site as well, including:

• Outpatient pharmacies

• Laboratory services

• Radiology/imaging services, including use of a Picture Archiving and

Communications System (PACS)

IHS Heal th IT Modernizat ion Program 8

Population and public health services are delivered through community-based providers including Public Health Nurses, Community Health Aides and Practitioners, and Community Health Representatives.

IHS and Tribal hospitals and CAH’s tend to be small in comparison to their private sector counterparts, but all have Emergency Departments, and a number offer labor and delivery, general or specialty surgery (e.g., orthopedic, podiatric), specialty inpatient care, and intensive care units.

AI/AN beneficiaries access services at IHS, Tribal, and most Urban facilities, as defined in Appendix D, at no direct cost to themselves. In addition to federally-appropriated dollars, I/T/U organizations rely heavily on third-party revenues to support their operations. Financial systems that support IHS’ role as a provider of healthcare services, as well as a payer for certain services, are therefore an essential part of the agency’s Health IT portfolio. According to a recent Government Accountability Office (GAO) reportv, following are estimates of insurance coverage for AI/AN people:

• 78% of patients have some type of health insurance coverage.

• 58% of patients are covered by Medicaid.

• 20% of patients have private health insurance.

• 11% of patients are covered by Medicare.

AI/AN patients referred to or seeking emergency care from the private sector may have costs covered by IHS if specific eligibility and priority criteria are met in accordance with IHS Purchased/Referred Care (PRC) policy (https://www.ihs.gov/prc/). IHS is the payer of last resort in any case.

As noted in Section 2.4 above, while many Tribal and Urban Indian healthcare organizations currently use RPMS, others have adopted commercial systems to meet their clinical and business requirements. All facilities have extensive regional consulting and referral networks with which they share patients. Interoperability and the ability to participate in health information exchange are important components of a modernized Health IT solution.

Appendix A provides a set of clinical and business processes that comprise the spectrum of services and operations at IHS and Tribal/Urban locations across the country. These processes vary significantly by site; not all exist at all locations. Most of the listed processes are currently supported by the legacy RPMS. A few represent gaps in functionality that have contributed to IHS’ plan to modernize its infrastructure.

Appendix A is offered as background information to frame the scope and meaning of “full replacement of RPMS” as used elsewhere in this document and outline the path toward Health IT modernization.

Appendix B describes the data flows and clinical information system interfaces for the delivery and coordination of clinical care, revenue cycle, and patient access.

https://www.ihs.gov/prc/

IHS Heal th IT Modernizat ion Program 9

Appendix C includes a listing of provider and/or facility measures that are presently used across IHS for participation in various quality and performance initiatives. These are offered as examples of metrics that are supported by the current Health IT system.

Such metrics are subject to change over time in response to a variety of factors.

Appendix D provides a definition of key terms referenced in this document.

Appendix E is the Health IT Modernization Program Management Plan (PMP). It provides an overview of how the program management office will support the Health IT Modernization Program.

Appendix F is the Health IT Modernization Project Process Agreement (PPA). It documents the tailored Enterprise Performance Life Cycle (EPLC) Stage Gate Reviews and specific deliverables applicable to the investment/project, including the expected level of detail to be provided.

3.3 Out of Scope

The following are not included in the scope of this IDIQ:

• Program Management Office (PMO) services

• The overall PMO responsibilities for Health IT modernization will be carried out by a federally-managed PMO. The IDIQ vendor’s internal PMO will collaborate with and report to the IHS Health IT Modernization PMO.

• Organizational Change Management (OCM) services

• OCM activities will be carried out through a separate organizational unit reporting to the IHS Health IT Modernization PMO. The IDIQ vendor and OCM organization will collaborate on specific areas of shared responsibility.

• Legacy data management

• While certain organizational and patient data will be required to be incorporated into and validated in the modernized solution, extraction and staging of that data from legacy systems in preparation for migration will be managed separately

• Record retention and archiving

• The required timeframe for retention of IHS health, medical, and billing records exceeds the period of performance for this contract and is therefore out of scope; however, the ability to move such data into the archiving solution, in industry-standard and non-proprietary formats, remains in scope

• Enterprise-level analytics

• The operations of the IHS National Patient Information Reporting System

(NPIRS) for enterprise data analytics and reporting are out of scope

• As noted elsewhere, the system must:

• Support the ability for authorized clinical users, managers, facility- and Area-level program and executive staff to execute any number of standard, configurable, and ad hoc queries and reports concerning their patients and populations, and

IHS Heal th IT Modernizat ion Program 10

• Make all data and schemas available in industry-standard formats for consumption by NPIRS as needed for enterprise analytics.

• Enterprise network infrastructure capabilities and services, such as:

• Network enhancements to support Health IT Modernization (circuits, routers and other devices, local wired & wireless networks, wiring, installation, etc.)

• Cybersecurity capabilities (e.g., firewalls) and services

• Identity Management, Active Directory Lightweight Directory Access Protocol

(LDAP)

• Local identity and security systems

• IHS Central Help Desk (ServiceNow) for the installed enterprise

• Technical site-level remediation, e.g.,:

• Construction and physical environment work

• End-user devices (laptops, desktops), peripheral devices (printers, scanners, signature pads, monitors, display boards)

• Biomedical devices, e.g., imaging, infusion pumps, barcode scanners, laboratory devices

• Durable medical equipment

4.0 Health IT Guiding Principles

The following draft guiding principles have been identified to achieve the desired Health IT Modernization outcomes:

• DESIGN solutions that deliver culturally appropriate care, quality, safety, and improved patient outcomes

• EMPHASIZE usability and human-centered design

• ENGAGE patients in their health journey through improved patient access

• ADOPT enterprise technology solutions that support continuity of care

• PARTNER across I/T/U for collaborative decision-making that is fully informed by clinical and business users in the field

• CONFIGURE solutions to meet organizational requirements with minimal use of customization

• UTILIZE recognized best practices across clinical and business processes

• PROVIDE timely and complete communication, training, and tools to support a successful deployment

5.0 Solution Capabilities

As stated in Section 1.0: Purpose above, the IHS intends to transition from, and ultimately completely retire, the distributed legacy RPMS infrastructure and application suite, replacing it with a modern, fully integrated enterprise platform that optimally supports all of the clinical and business processes formerly supported by RPMS, for all IHS federal sites and any Tribal and Urban Indian Organizations that choose to participate in the solution. The capabilities describe ‘what’ functional capabilities are required without describing ‘how’ the offeror will provide them in the solution.

IHS Heal th IT Modernizat ion Program 11

Offerors shall describe how their solutions offer:

• Core patient information and services common to all care settings

• A longitudinal, as opposed to episodic, perspective on the patient’s health and health care, taking advantage of all available data

• Support for Tribal and Urban tenants to the system as they elect, as well as separation of tenants who move to other solutions.

• Support all of the clinical and business processes outlined in Appendix A, either demonstrable upon award or by first applicable go-live as stated in the Appendix

• Medical device integration for hospital, ambulatory, and home settings to include connectivity with consumer health monitoring and data solutions

• Research capabilities to include but not limited to clinical trials

• Analytics and reporting capabilities across the solution to support multiple sites and ad hoc reporting and analysis

• Scalable support for multiple and distinct facility and organizational structures within the solution to reflect the diverse organizations operating at various levels of independence with access to shared resources.

• Reliable operation in those locations with lower bandwidth and/or experiencing occasional interruptions in connectivity

• End user device support options for virtualization, workstations, mobile devices, kiosks, and patient information systems, as well as the device and system interfaces necessary to carry out essential operations, as outlined in Appendix B

• Quality measurement as outlined in Appendix C, including the use of the HL7 Clinical Quality Language (CQL) standard

• An open architecture platform to include interfaces defined in Appendix B, access to the physical schema as defined in Appendix D, and security credentials for read/write access to the EHR.

• Certification to support bi-directional Fast Healthcare Interoperability Resources (FHIR) RESTful API.

• Utilization and support for the Unified Medical Language System, as defined in Appendix D, within the EHR where encoding of clinical data is required.

• Timely, patient- and condition-specific clinical decision support consistent with established industry best practices and configurable to IHS-specified parameters.

• Highly configurable user interfaces and workflows that can be configured by IHS subject matter experts as needed to adapt to preferred organizational clinical and business processes

• Incorporation of user centered design principles to minimize the amount of time that users spend on data retrieval and documentation and maximize the time spent in direct patient interaction

• Continuous and regularly updated certification of all Health IT modules to the criteria published by the Office of the National Coordinator for Health Information Technologyvi (ONC), so that all providers and facilities are using fully certified

IHS Heal th IT Modernizat ion Program 12 systems and none are placed in the position of needing to claim hardship exceptions due to vendor issues

• Continuous and regularly updated Drug Enforcement Administration (DEA) certification for functions relating to Electronic Prescribing of Controlled Substances)

• Improved access to services for AI/AN people seeking care through telehealth integration

• Any necessary technical licenses to meet the objectives of Health IT Modernization

• The capability and commitment to incorporation of evolving technologies such as artificial intelligence, machine learning, natural language processing, augmented reality, virtual reality, precision medicine, as appropriate for IHS clinical and business needs

• Continuous optimization of the solutions and support provided.

6.0 Solution Objectives

Offerors shall describe in their proposals how the services and solutions they provide will meet each of the following Objectives, providing sufficient scope and detail to ensure confidence that all of the described elements will be fully addressed.

6.1 Usability of Solution Capabilities

The ultimate aim is for all patient information to be available through a single integrated Electronic Health Record. However, information overload is a potential challenge and can impede, rather than facilitate, good clinical care.

Clinicians rarely want or need to view all detailed patient information, but instead need rapid access to a specific subset of information relevant to their clinical role and the type of encounter they are involved in. The information needs to be up to date, structured and presented in a manner that enables effective and timely decision making, with an easy and intuitive interface for navigating to additional information as required. All information must be available with the minimum number of “clicks”. The presentation of information data must be appropriate to the data type. Data should be displayed in a graphical presentation with trending over time when appropriate.

Most clinical information should be displayed in a “patient-focused” way, but information display will also be required for grouped patients. For example a clinical service (e.g., Cardiology), clinic or a ward (e.g. ICU) will require patients to be presented in a single view. Hospital administration and clinical managers will require aggregated views of information to enable the management of patient flow and access.

The solution should employ the following principles of ‘usability’ as defined by the Healthcare Information and Management Systems Society (HIMSS) EHR Usability Task

IHS Heal th IT Modernizat ion Program 13

Force - HIMSS Nine Essential Principles of Software Usability for EMRs, April 2015 (https://www.himss.org/resources/nine-essential-principles-software-usability-emrs), as quoted below:

1. Simplicity

• No information or visual elements are included that are not necessary to the task.

• Important information stands out, and function options are easy to understand.

• The application has clear, clean, uncluttered screen design.

• Functionality is limited to that which is essential to core tasks and decision making.

2. Naturalness

• The screen metaphors are familiar to everyday life, or commonly expected computer experiences for the clinician.

• Workflows match the needs of the practice.

• The application appears intuitive and easy to learn; training will not be an overwhelming process.

3. Consistency

• All the different parts of the application have the same look and feel, consistent placement of screen elements, etc.

• Terminology and data entry fields are used consistently. Understanding how one screen works helps you understand how other screens work.

4. Forgiveness and Feedback

• It is hard to lose data or destroy time-consuming effort with a wrong click or wrong choice of buttons.

• If you make a mistake, the application helps you avoid it or the application provides a method to recover from errors gracefully (the system is “forgiving”).

• The system provides informative feedback to the user about actions they are about to take or have taken.

• Information is provided to the user when the system is processing, indicating what is occurring and how long it might take.

5. Effective Use of Language

• The application uses the same words that your clinicians use (while providing mapping to standardized codes and terms used for data retrieval).

• List or entry-form choices are clear and unambiguous.

• Sentences read like natural English (or the selected language).

6. Efficient Interactions

• The application minimizes the number of steps it takes to complete tasks;

appropriate defaults are always provided.

• The application provides navigation options such as shortcuts for use by frequent and/or experienced users.

• Navigation methods minimize user movements such as scrolling and switching between typing and mouse clicking.

https://www.himss.org/resources/nine-essential-principles-software-usability-emrs

IHS Heal th IT Modernizat ion Program 14

7. Effective Information Presentation

• Information on screens includes sufficient white-space and large enough fonts to be read easily with high comprehension. No information should be in all upper case.

• Colors are used to convey meaning (e.g., red to indicate medical urgency), not just for visual appeal.

8. Preservation of Context

• The application keeps screen changes and visual interruptions to a minimum during completion of a particular task.

9. Minimize Cognitive Load

• Information needed for a particular task or decision making is grouped together on a single screen rather than requiring the user to mentally integrate information from multiple screens in the system.

• Alerts presented to the user are concise and informative with clear actions and are appropriate in number.

• The application performs calculations automatically for the clinician so that they do not have to manually perform the calculations.

6.2 Planning and Implementation of Solution Capabilities

The IHS Objective is that all aspects of Health IT Modernization, from project kickoff through the completion of the Period of Performance, be thoughtfully and rigorously planned, including risk identification and mitigation planning, so that the likelihood of failure at any point, due to planning gaps, is minimized. For each of the Objectives that follow (Sections 6.2.1 through 6.9), Offerors shall describe their approach for advance planning to ensure attainment of the Objective. Examples may include, but are not limited to:

• Implementation Planning, which may include but is not limited to planning:

o the implementation of all Health IT Modernization solution-dependent hardware and software, o user documentation, o site survey, o site activation, o standardized enterprise and site readiness checklists, o user training, o data migration, management, o engineering support, and o interim logistics support related to I/T/U sites.

• Modernize unique environments, at scales that differ widely, utilizing repeatable processes, and are tailored for subsequent sites, resulting in an enterprise solution that is adaptable to meet the IHS needs.

IHS Heal th IT Modernizat ion Program 15

• Provide flexible deployment planning that considers the types of facilities, locations, and services provided within the I/T/U. Deployments are expected to occur at one or more locations simultaneously. The deployment planning is anticipated to cover annual cohorts supported by implementation planning and resource planning consistent with government budgets.

• Provide a list of compatible hardware and biomedical equipment to support site readiness planning, equipment lifecycle management, and other evaluations.

• Identification of all required interfaces and other local requirements for each site.

• Coordinate and plan with the PMO appropriate roles and responsibilities in a responsibility matrix to support clear ownership of tasks and decisions, including:

• Responsible: Who is responsible for doing the actual work for the project task

• Accountable: Who is accountable for the success of the task and is the decision-maker

• Consulted: Who needs to be consulted for details and additional info on requirements

• Informed: Who needs to be kept informed of major updates

6.2.1 Health IT Modernization Readiness and Mitigation Analyses The IHS Objective is to ensure that at all levels of the organization, factors that will create risk for the successful implementation of the Offeror’s solution are identified and mitigated to the maximum extent possible. Offerors shall:

• Describe how organizational, training, and technical readiness at the enterprise level will be assessed, and how findings and recommendations from these assessments will be communicated to IHS in ways that will support IHS’ mitigation of any issues prior to go-live.

• Describe how organizational, training, and technical readiness at the facility level will be assessed, and how findings and recommendations from these assessments will be communicated to IHS and the sites in ways that will support mitigation of any issues prior to go-live.

• In concert with the Program Management Office, transparently identify and prioritize risks, create and execute mitigation strategies to reduce or eliminate the impacts of those risks.

6.2.2 Go-Live and Post-Go-Live Support

The IHS Objective is for all facilities implementing the enterprise solution to be fully prepared in all respects prior to go-live, and fully supported throughout the go-live process for as long as may be required, until the IHS Program Management Office and supporting Organizational Change Management teams determine that the site can be transitioned to routine operational support. Offerors shall detail their proposed approach to and experience with:

• Processes for preparing sites for go-live

• Risk identification and mitigation in run-up to go-live

IHS Heal th IT Modernizat ion Program 16

• Support processes during go-live and post-go-live phases

• Metrics for assessing readiness for go-live and for transitioning from post-go-live to routine operational support

6.3 Training

The IHS Objective for Training is to ensure that success of Health IT Modernization is not negatively impacted by failure to anticipate and fulfill training needs at any level of the enterprise, or at any point in the Period of Performance.

6.3.1 End User Training Plans

The IHS anticipates the following training needs, at a minimum. Offerors shall describe their plans for these and other training approaches that will maximize opportunities for success.

• Timely role-based and discipline-specific end-user training at sites in preparation for go-live, facilitated by job aids such as documents that map their accustomed business processes to the corresponding function/process in the solution

• Proficiency testing to ensure that users are fully trained before go-live to minimize risks to patients or operations

• Training for clinicians that optimizes visualization of all clinically-relevant information from the EHR at the point of care, then facilitates efficient and accurate documentation of the clinical encounter and treatment plan

• Continuous end-user training and support during the transition beyond go-live until the site operates autonomously

• End-user training that is ongoing throughout the life of the contract, supports software updates, and flexibly accommodates a constant steady influx of new users

6.3.2 System Training and Certifications

• Intensive training and certification for designated staff across multiple disciplines before design activities begin, to enable these individuals to work with the contractor to configure preferred business processes and workflows that will maximize system utilization, user productivity, and data capture

• Training for IHS Service Desk staff to facilitate and triage support for the modernized systems

6.4 Data Management

IHS Objective for Data Management is to “liberate the data”. This means that all data in the Health IT Modernization solutions will be freely available to IHS, and to Tribal and Urban partners in accordance with applicable agreements executed as part of their tenancy on the shared solution, in accessible and non-proprietary formats. The customer will be able to access and utilize data associated with the Contractor’s solution, as needed, and at any time.

IHS Heal th IT Modernizat ion Program 17

As a corollary to this Objective, Offerors must understand that no contractor, sub-contractor, or integrator may use any patient or organizational data, identified or de-identified, for any purpose other than those explicitly authorized by IHS in Task Orders and/or applicable agreements, such as for marketing, analytics, research, or other use.

Each of the following sub-bullets describes how IHS envisions data liberation to be operationalized in the modernized Health IT environment. Offerors may propose alternative approaches, but must justify and explain how the alternative meets the overall Objective of data liberation.

6.4.1 Conversion and Migration

• Provides extract, transform, and load (ETL) support from the IHS data repository for externally-generated EHR data. Provide a full range of data migration capabilities (planning, staffing, environment, specialized technology, expertise, validation of migrated data, etc.).

• Provide a data management plan to include:

• export routine using standards and formats that address IHS requirements for enterprise reporting, such as the Observational Medical Outcomes Partnership Clinical Data Model (OMOP CDM) format

• conceptual, logical, and physical data models of the solution and its implementation at each facility/site

• capabilities to report on health status and clinical quality of care at the national, State, IHS, IHS Area, Tribal and clinical site levels

6.4.2 Data Management Plan

• Detail of the operational data and workflow

• Provides accurate encoding of physically entered data to industry standard controlled clinical vocabularies, to include the Unified Medical Language System (UMLS), as defined in Appendix D, to ensure semantic interoperability and clinical accuracy across systems.

• Provides privacy-preserving patient identity management technologies that ensure accuracy in patient identity matching when merging patient medical records data from two or more databases into a single accurate, de-duplicated shared medical record.

• Allows patients to securely access their complete health information record and communicate with their healthcare providers using a virtual care platform.

6.4.3 Data Analytics and Reporting

• Support configurability of data capture, analysis and reporting for clinical and business processes (e.g., PRC, medical supply management, etc.).

• Support clinical data analytics on an appropriately-resourced environment for operational, ad hoc, and clinical analytics. The solution will contain all data entered into the EHR by clinical staff, medical devices, and remote interfaces such as laboratory information systems (LIS) and immunization information

IHS Heal th IT Modernizat ion Program 18 systems (IIS) interfaces. Explain how the proposed solution supports near real-time analytics by minimizing data lag.

• Support the creation and maintenance of an accurate, de-duplicated medical record for every patient and include the following capabilities:

o Bio-surveillance for signals of epidemic or pandemic spread.

o Executive dashboards in support of strategic business operations and decision making.

o Ad hoc clinical analytics and reporting, including support for electronic Clinical

Quality Measures published by the ONC for the current EHR certification standard (see also Appendix C).

o Data search and extract capabilities to support queries and responses using Contractor-provided and IHS applications and report generation tools (e.g.

IHS National Patient Information Reporting System (NPIRS)).

o Queries based on the Clinical Quality Language query language used to describe the measure logic in electronic Clinical Quality Measures (eCQMs).

Appendix C is provided as an example of eCQMs currently in use at IHS.

o Reporting on population health status metrics, such as those listed in Appendix C. Baseline metrics should be established at Go-Live and collected every six months, at a minimum.

o Mapping of controlled clinical vocabulary codes contained in the EHR, such as SNOMED CT and RxNorm, to UMLS concept unique identifiers.

o Provide access to EHR data through use of commercial data visualization and analysis tools.

• Provides healthcare-mandated and ad hoc reporting capabilities (e.g., data management audits) to support I/T/U facilities. This includes the capability to generate responses to mandated and ad hoc Congressional, federal, state, and tribal reporting requirements.

• Provides IHS with the ability to measure, assess, and visualize population health status, including clinical quality measures published by the Centers for Medicare and Medicaid Services (CMS).

• Provides IHS with the ability to measure and assess organizational performance at all levels of the agency in accordance with IHS-specific Government Performance and Results Act (GPRA) measuresvii.

6.4.4 Data Archiving

The IHS must fulfill its obligations as a federal agency for record retention. The current retention policy for IHS health, medical, and billing records specifies that these records must be retained for 75 years following the last episode of patient care or date of death (Schedule 3, Record Management Disposition Scheduleviii). While the archiving solution is out of scope for this contract (see Section 3.3 – Out of Scope above), Offerors shall describe how their solution will meet IHS’ need for meaningful record retention beyond the period of performance.

https://ushik.ahrq.gov/mdr/portals/mu/meaningful-use-resources/menu https://www.ihs.gov/quality/government-performance-and-results-act-gpra/ https://www.ihs.gov/quality/government-performance-and-results-act-gpra/

IHS Heal th IT Modernizat ion Program 19

6.5 Interoperability

The IHS environment must maximize interoperability to ensure patient care is enhanced with the right information at the right time to support the delivery of high quality care and the best possible patient outcomes.

6.5.1 Regulatory Compliance

The Interoperability Objective is for the enterprise solution to have the highest possible level of interoperability in support of the IHS mission as well as federal government priorities such as those embodied in the 21st Century Cures Act and related regulation.

6.5.2 Standards Based

In addition to direct system interfaces described elsewhere and in Appendix B, Offerors shall describe how their solutions will support standards-based interoperability with entities such as those listed below. Offerors shall also describe how interoperability with external systems is integrated into the normal workflows of clinicians and other users, and how data obtained via interoperability becomes an attributable part of the record for clinical decision support, quality measures, and other reporting purposes.

• Tribal and Urban Indian healthcare organizations that are using certified Health IT solutions other than the IHS enterprise system

• Federal agencies such as the Centers for Disease Control and Prevention (CDC)

• Regional and state Health Information Exchanges (HIE)

• Regional and state reporting entities such as Immunization Information Systems

(IIS), Prescription Drug Monitoring Programs (PDMP), and public health departments

6.5.3 Consuming and Displaying Patient Data

Describe how patient information from HIE and other sources are aggregated, stored, and displayed in the solution.

6.6 Quality Assurance and Testing Strategy

The Quality Assurance and Testing Strategy Objective is to minimize the occurrence of significant schedule delays, adverse patient safety events, or other risks due to insufficient testing.

Offerors shall provide comprehensive Quality Assurance and Release Management plans that include the following at a minimum:

• Comprehensive testing of all implemented systems and solutions in pre-production test environments that mimic their target settings

• Testing of all installed solutions at sites prior to go-live, including system and device interfaces and validation of migrated organizational and patient data

IHS Heal th IT Modernizat ion Program 20

• Testing of customer-configured workflows to ensure up- and down-stream data dependencies are addressed

• Thorough testing of all system patches and upgrades in test environments that mimic that of the IHS enterprise solution

• Testing of released patches and upgrades in select production settings to maximize identification and mitigation of issues not detected before release

• Joint coordination with the government of prioritization and resolution of test findings

• Identification and testing of common errors encountered in live environments to avoid over-fitting testing scenarios with perfect testing scripts.

6.7 Operations and Support

The IHS Objective is for Health IT Modernization to have relevance and meaning throughout the Period of Performance, in that it is continually supported, enhanced, and upgraded as business processes, technologies, regulations, and reporting requirements evolve. Offerors shall describe their approaches for:

6.7.1 System Operations

• Hosting and central management of the modernized Health IT solution in accordance with IHS-provided operational and configuration guidance

• Offeror should include recovery objectives, transaction response times and processes to routinely report performance

• A domain strategy, structure, and processes for conducting training, testing, configuration and implementation, operations, and disposal

• The capability to provision/update installed systems (to include technology refresh), activate/initiate new systems into the network of interconnected capabilities

• Product enhancements and improvements required to meet emerging needs

• Creation and maintenance of a common operating picture of the growing system of interconnected, modernized, locations and devices, and collection and analysis of metrics to measure progress and status

6.7.2 Service Delivery and Support

• Provision of support, to include all actions required to return the affected systems to full operation

• Integration of tiered support resources with IHS’ ServiceNow to support installed capabilities in accordance with IT service management practices on the Information Technology Infrastructure Library V4 (ITIL V4). Services provided should be managed based on the ITIL framework

• Document an established service management approach to support the following processes:

• Service Delivery and Account Management

• Production Support

• Incident Management

IHS Heal th IT Modernizat ion Program 21

• Problem Management

• Change Management

• Release and Deployment Management

• Event Management

• Request Management

• Capacity Management

• Availability Management

• Configuration Management

• Disaster Recovery

• Security Management

• Service Operational Reporting

• Continuous Service Improvement

• Maintenance of non-production domains

• Establish a management structure and approach to managing various personnel and groups providing service, any partners and other service providers

• Implement effective account management for interactions to control and administer the quality and provision of services

• The following definitions are being used when referring to service desk levels in this document:

• Level 1: Initial service desk contacted by users to log their support requests.

They screen support requests and assign to the appropriate L2 support party for resolution if the support request cannot be resolved by the L1 service desk;

• Level 2: Support requests that can be resolved by providing basic configuration of the platform and/or suggest appropriate workarounds within the platform.

• Level 3: Support requests requiring in-depth platform knowledge that may result in changes to the platform that cannot be resolved through basic configuration.

• Level 4: Support requests related to an underlying platform product, which are escalated to the product vendor to provide in-depth technical support and may require a product hotfix or patch release to resolve.

• The offeror is expected to establish a level 3 and level 4 production support desk with the systems, tools, and processes with a single point of contact to support restoration of normal operations; according to agreed Service Levels

• Provide software patches, hot fixes, and service packs as requested for all software according to IHS patch management policies

• Perform root cause analysis as requested for problems with provided services

6.7.3 Change and Configuration Control and Solution Governance

• Document and support solution change and configuration control throughout solution operations and domain management plan

• Document and recommend governance components to align with solution change control and general operations

IHS Heal th IT Modernizat ion Program 22

• Coordinate and plan with the PMO appropriate roles and responsibilities in a responsibility matrix to support clear ownership for tasks and decisions

• Responsible: Who is responsible for doing the actual work for the project task

• Accountable: Who is accountable for the success of the task and is the decision-maker

• Consulted: Who needs to be consulted for details and additional info on requirements

• Informed: Who needs to be kept informed of major updates

6.7.4 Continuity of Operations

The IHS Objective is that the modernized enterprise Health IT solution will be exceptionally reliable, resistant to interruptions and down time at all locations, and have robust, fully tested continuity of operations and disaster recovery capabilities in anticipation of worst case events. Offerors shall describe how their proposed solutions will provide:

• Monitoring of overall system operation and availability

• A solution that is resilient to anomalies, especially extended periods of disconnection from the network infrastructure and areas of low bandwidth/high latency

• Planning, documentation, Implementation, and management of a solution for continuity of operations and disaster recovery strategy for all systems managed by the Contractor or subcontractors

6.8 Cybersecurity and Access

Security of the modernized Health IT solution is a critical Objective for IHS.

Accordingly, Offerors shall describe how their proposed solutions will address all of the following. Offerors shall also acknowledge their intent to comply with Appendix G of this IDIQ SOO, which provides HHS-required Security and Privacy requirements that will be included with applicable Task Orders, as appropriate.

6.8.1 Secure Software

• Utilize only securely developed quality software. Pursuant to this objective, o Provide evidence such as but not limited to, a set of structured Software

Bill of Materials with provenance (e.g., country of origin) o Provide evidence such as but not limited to, use of…