RFP-185-2515-2026 Health Information Network (Health Information Exchange).pdf

Title of the RFP: Iowa Health Information Network (Health Information Exchange) RFP Number: RFP-185-2515-2026

REQUEST FOR PROPOSAL (RFP) COVER SHEET

DISCLAIMER: “If you experience difficulty accessing or reading this document and would like to request an accessible version compatible with screen readers, please contact Zach Gillen at zach.gillen@dom.iowa.gov or 515-675-3316 to obtain one.”

Agency:

Iowa Department of Management on behalf of Iowa Department of Health and Human Services

The State of Iowa seeks to purchase:

The state of Iowa seeks to purchase Health Information Exchange infrastructure and services, including associated applications that enable secure, efficient, and interoperable exchange of health data across Iowa.

Issuing Officer

Zach Gillen zach.gillen@dom.iowa.gov 515-675-3316

Main Address:

Iowa Department of Management Attn: Zach Gillen 200 E. Grand Ave.

Des Moines, IA 50309

Notice Address:

Iowa Department of Management Attn: Office of General Counsel 1007 E. Grand Ave G13 Des Moines, IA 50319

Links:

IMPACS eProcurement website:

https://bids.sciquest.com/apps/Router/PublicEvent?CustomerOrg=DASIowa All documents for this Solicitation will be posted in IMPACS

Important Websites: https://www.cdc.gov/nssp/index.html

Agreement Terms and Conditions: Attachment #5 – Sample Contract https://bids.sciquest.com/apps/Router/PublicEvent?CustomerOrg=DASIowa%20 https://bids.sciquest.com/apps/Router/PublicEvent?CustomerOrg=DASIowa%20

TIMETABLE

There are no exceptions to any deadlines for Respondents.

However, the Agency reserves the right to change dates and times at its sole discretion.

Event or Action: Date / Time – Central Time

Targeted Small Business (TSB) website posting: 9/23/2025 State issues Solicitation: 9/25/2025

Round 1 Questions: Respondent’s written questions, requests for clarification, and suggested changes are due: 10/2/2025

Round 1 Response: Written response to questions, requests for clarification, and suggested changes are due: 10/9/2025

Round 2 Questions: Respondent’s written questions, requests for clarification, and suggested changes are due: 10/15/2205

Round 2 Response: Written response to questions, requests for clarification, and suggested changes are due: 10/22/2025

Proposals Due: 10/29/2025

Presentations (if applicable) Estimated Week of 12/8/2025

Anticipated Date to issue Notice of Intent to Award: 12/22/2025

Anticipated Date to Execute Contract: 2/2/2026

Firm Proposal Terms. The minimum number of days post-submission deadline that the Respondent guarantees all proposal terms, including price, will remain firm is:

180 days

Agreement Information

Potential initial term of the agreement: 1 year

Potential number of annual renewals: 7 years

Anticipated start date: 2/2/2026

Anticipated end date: 2/1/2034

Available to other entities authorized to purchase under the resulting agreement(s)?

No

Table of Contents

1. INTRODUCTION

1.1 Purpose

1.2 Definitions

2. SCOPE OF WORK

2.1 Detailed Scope of Work

2.2 Current Environment Conditions

2.3 Deliverables

2.4 Operations

2.5 Performance Measures

2.6 Implementation Schedule

3. ADMINISTRATIVE INFORMATION

3.1 Compliance with Solicitation

3.2 Respondent Business Registration

3.3 Restriction on Respondent Communication

3.4 Downloading the Solicitation from Internet via IMPACS

3.5 Procurement Timetable

3.5 Pre-Proposal Conference

3.6 Questions, Requests for Clarification, and Suggested Changes

3.7 Submission of Proposals

3.8 Release of Claims

3.9 Disposition of Proposals

3.10 Form 22 - Request for Confidentiality

3.11 Copyright Permission

3.12 Amendment and Withdrawal of Proposal

3.13 Late Proposals

3.14 Response Opening

3.15 Proposal Corrections

3.16 Proposal Clarification

3.17 Respondent Presentations

3.18 Reference Checks

3.19 Criminal History and Background Investigation

3.20 Ancillary Information and Evaluators

3.21 Verification of Proposal Contents

3.22 Best and Final Offer

3.23 Award Notice and Acceptance Period

3.24 Exclusivity

3.25 No Minimum Guaranteed

3.26 No Commitment to Contract/No Rights Until Execution

3.27 Use of Subcontractors

3.28 Restrictions on Gifts and Activities

3.29 Respondent Continuing Disclosure Requirement

3.30 Appeals

3.31 Choice of Law and Forum

3.32 Order of Precedence

4. FORM AND CONTENT of PROPOSAL

5. TECHNICAL and COST PROPSAL CONTENTS

5.1. Title Page

5.2 Information to Include in Section 1: Transmittal Letter

5.3 Information to Include in Section 2: Table of Contents

5.4 Scored Technical Specifications See Attachment #3 – Technical Proposal Points

5.5 Information to Include in Section 3: Scope of Work

5.6 Information to Include in Section 4: Experience

5.7 Information to include in Section 5: Key Personnel

5.8 (Reserved) Information to Include in Section 6: RFP Forms

5.9 Cost Proposal

6. EVALUATION and SELECTION 6..1 Introduction

6.2 Evaluation Committee

6.3 Technical Proposal Evaluation and Scoring

6.4 Cost Proposal Scoring

6.5 Total Score

6.6 Tied Score and Preferences

6.7 Recommendation of the Evaluation Committee

7. CONTRACT TERMS & CONDITIONS AND CONTRACT ADMINSTRATION

7.1 RFP’s Specifications, Requirements, and Terms

7.2 The Contract Terms and Conditions

7.3 Exception to Any Terms and Conditions

7.4 Objections Raised During the Solicitation Process

7.5 Contractual Terms and Conditions – No Material Changes/Non-Negotiable

7.6 Special Terms and Conditions

7.7 Payment Term

7.8 Terms and Conditions for State of Iowa Purchasing Cards

7.9 Payment Terms

7.10 Respondent Discounts

7.11 Prompt Payment Services

7.12 Invoices

7.13 Insurance

7.14 Performance Security

7.15 Quarterly Report

7.16 Administrative Fee

7.17 Order of Precedence

ATTATCHMENTS

#1: RESPONDENT INFORMATION FORM

#2: SUBCONTRACTOR DISCLOSURE FORM

#3: TECHNICAL PROPOSAL POINTS

#4: COST PROPOSAL TEMPLATE

#5: SAMPLE CONTRACT

1. INTRODUCTION

1.1 Purpose

The Agency seeks proposals from Respondents to provide the goods and/or services identified on the Solicitation cover sheet and as further described below. This Solicitation is designed to provide Respondents with the information necessary for the preparation of competitive proposals. The Solicitation process is for the Agency’s benefit and is intended to provide the Agency with competitive information to assist in the selection process. Each Respondent is responsible for determining all factors necessary for the submission of a comprehensive proposal.

The Agency seeks a vendor to administer Health Information Exchange (HIE) and related services for purposes including, but not limited to, public health, care coordination, human services, and clinical practice. This procurement seeks a vendor to maintain a set of core health information exchange requirements that include HIE infrastructure, data feeds, data privacy and security compliance, and data quality maintenance. Additionally, the Agency seeks a vendor capable of providing a required set of services that either utilizes this base infrastructure or are completed independently. These services include public health reporting (electronic lab reporting, electronic case reporting, syndromic surveillance, and registry reporting), Medicaid reporting (admission, discharge, and transfer [ADT] reporting), and direct secure messaging, The Agency also seeks a vendor capable of implementing additional functionality that includes longitudinal patient record exchange to access patient records for care support, a patient portal to facilitate access to personal records by consumers, statewide ADT alerting, statewide social care platforms for integration of records and closed loop referrals for services, bi-directional Fast Healthcare Interoperability Resources (FHIR) standards capability, and connection to national health information exchanges for treatment purposes.

The purpose of these services is to facilitate the exchange of health records between disparate electronic health record systems. This data sharing works to improve access to and quality of health care records, which in turn can enhance efficiency, improve health outcomes, and reduce costs. Work delivered through this Solicitation shall endeavor to represent the interests and meet the needs of consumers and the health care sector, protect the privacy of individuals and the confidentiality of individuals’ information, promote best practices, and make information easily accessible to the members of the patient-centered care coordination team, including but not limited to patients, providers, and payors. This Solicitation also meets the requirements described within House File 972 of the 91st Iowa General Assembly, as signed by Governor Kim Reynolds on May 28, 2025, to conduct a competitive process to select a designated entity for Iowa Health Information Network services at least every eight years (Iowa Code Section 135D.5(1)).

The Agency anticipates having funding available to implement some or all of the services described within this Solicitation at the time of contract execution. In the event that the Agency does not have sufficient funds for all presented use cases, the Agency may contract for any combination of services described within this Solicitation without contacting for all services. In the event that the Agency does not have sufficient funds for any presented services within this Solicitation, the Agency and successful Respondent may continue to enter into a contract for some or all of the presented services if and only if the arrangement is mutually agreed upon by both Parties.

1.2 Definitions

In addition to any terms specifically defined elsewhere herein, for the purposes of this RFP and any resulting Contract, the following terms will mean:

“Agency” means the Agency identified on the RFP cover sheet that is issuing the RFP and, as used and to the extent used in the Contract, any other Agency(s) or Governmental Entity(s) of the State that purchases from the Contract once executed.

“Contract” or “Agreement” means the contract(s) entered into with the successful Respondent(s) as identified on the RFP Cover Sheet and more fully described in Section 7 (Contract Terms and Conditions Summary).

“Contractor” or “Vendor” means the successful Respondent to this RFP that ultimately enters into a Contract as a result of this RFP.

“Deliverables” means all of the services, goods, products, software, data (including data collected on behalf of the Agency), work, work product, items, materials, and property to be created, developed, produced, delivered, performed, or provided by or on behalf of, or otherwise made available through the Contractor, directly or indirectly, in connection with any contract resulting from this Solicitation.

“IMPACS” means the Iowa Management of Procurement and Contracts System - an eProcurement software program.

Website: https://bids.sciquest.com/apps/Router/PublicEvent?CustomerOrg=DASIowa

“Proposal” means the Respondent’s proposal submitted in response to the RFP.

“Respondent” means a potential Vendor submitting a Proposal in response to this RFP.

“RFP” means this Request for Proposal as amended, as well as any attachments, exhibits, schedules, or addenda hereto.

“State” means the State of Iowa, including the Agency identified on the Solicitation Cover Sheet and/or the Contract Declarations & Execution Page(s), and all State agencies, boards, and commissions, and any political subdivisions making purchases from the Contract as permitted by this Solicitation.

https://bids.sciquest.com/apps/Router/PublicEvent?CustomerOrg=DASIowa

2. SCOPE OF WORK

This Section lists the scope related to this Solicitation. By submitting a proposal, the Respondent agrees to meet all the scope stated in this section and any other terms and conditions stated in this Solicitation. While the Respondent is expected to respond to all requirements of this Solicitation, the Agency may contract for only a selection of the requirements or for all requirements.

2.1 Detailed Scope of Work

The successful Respondent will provide statewide Health Information Exchange (HIE) and related services that enable secure, efficient, and interoperable exchange of health information across Iowa. These services include collecting, standardizing, securely managing, and providing appropriate sharing and access through seamless integration with electronic health records systems and other health-related data collection systems. The successful Respondent will facilitate data sharing among disparate systems and provider types, support care coordination, empower patients with access to their records, and ensure compliance with privacy and security requirements such as NIST 800-53 Revision 5, the Health Insurance Portability and Accountability Act (HIPAA), Health Information Trust Alliance (HITRUST) framework, and System and Organizational Controls 2 (SOC2) frameworks. Additionally, the successful Respondent will provide a variety of additional services either utilizing the underlying core HIE infrastructure or independently. These services will strengthen statewide data capabilities and provide valuable insights for providers, patients, and policymakers.

2.2 Current Environment and Conditions

The Iowa Health Information Network (IHIN) is the State of Iowa’s health information exchange.

The IHIN was initially established though legislation enacted in 2008. The initial governance structure of the IHIN was state government-led, with a heavily involved, collaborative, public and private executive committee and advisory council. The legacy Iowa Department of Public Health (Department) managed all business and technical operations of the IHIN, with recommendations provided by the executive committee and advisory council, and oversight by the State Board of Health.

Iowa Code 135.156F directed the Department to review the governance structure of the IHIN by 2015 and make a recommendation to the General Assembly regarding its future governance.

During the 2014/2015 Iowa legislative session, a bill was introduced recommending that the governance and operations of the IHIN be moved out of state government to a non-profit organization (referred to in the legislation as a designated entity). The bill implementing this framework (House File 381) was passed by the General Assembly and signed into law by the Governor on April 24, 2015.

In 2016, the Department undertook a competitive bid process as directed by Iowa Code Chapter 135D.5. The resulting designated entity retained the business name Iowa Health Information Network. Through the Asset Transfer, Assignment, and Assumption and Release Agreement, the IHIN became a non-profit entity on March 30, 2017. Chapter 135D continues to authorize the Department, now merged as a new agency, Iowa Department of Health and Human Services, to designate the IHIN as the state’s health information network. The Agency has continued to maintain an agreement, provide financial support and utilize IHIN services for public health activities since the transition.

During the 2024/2025 legislative session (91st Iowa General Assembly), House File 972, as signed by Governor Kim Reynolds on May 28, 2025, directs the Agency to conduct a competitive process to select a designated entity at least every eight years (Iowa Code Section 135D.5(1)). This directive is met through this Solicitation.

At the time of this Solicitation, the current Iowa HIE platform is built within an Amazon Web Services (AWS) Cloud Infrastructure Environment. This environment includes staging, development, testing and production environments. There are 115 Iowa hospitals sending clinical data from their electronic health record (EHR) vendor software to this HIE environment for processing and storage. This data, categorized as HL7 data messaging, comes through secure data feeds via Application Programming Interfaces (APIs). Current data feeds include ADT, syndromic surveillance, continuity of care documentation, immunizations, medication administration, radiology and imaging, laboratory, and notes. Current volumes for HL7 data flowing from hospitals are in excess of twenty (20) million messages per month. The quality of these feeds and data is monitored to ensure completeness and accuracy according to HL7 data specifications.

The current Iowa HIE infrastructure complies with Federal Standards, including United States Core Data for Interoperability (USCDI), Fast Healthcare Interoperability Resources (FHIR) API, HITRUST and SOC2 Security, Systemized Nomenclature of Medicaid (SNOMED) CT, International Classification of Diseases (ICD)- 9, ICD-10, Logical Observation Identifiers Names and Codes (LOINC), Current Procedural Terminology (CPT), RxNorm and National Drug Code

(NDC).

In addition to the core HIE functionality described above, the IHIN facilitates electronic lab reporting for 90+ reportable diseases that are required submissions to the Iowa Department of Health and Human Services for public health purposes. These Electronic Lab Reports (ELR) are used for case management, surveillance and tracking of diseases. The current IHIN also reports all syndromic surveillance data for near real time tracking of syndromes using the CDC BioSense platform. The current IHIN also includes a longitudinal patient record exchange that allows clinical providers to view longitudinal patient health records from across providers in one place.

This portal uses a unique enterprise ID to track the longitudinal record of a patient based on Patient IDs and Medical Record Numbers.

2.3 Project Initiation Deliverables

2.3.1 Staffing

The Respondent should provide a detailed organizational chart and high-level narrative description of the overall project staffing, roles, and team(s). This description should include how the roles and team(s) will communicate and cooperate with the Agency and any other State or contractor teams. The narrative should also describe the Respondent’s approach to meeting the requirements in the table located in section 2.3.1.2. The response should demonstrate the Respondent's ability and capability to provide knowledgeable, skilled, and experienced personnel to accomplish the scope of work. In addition to this high-level narrative, the Respondent should also provide details on the key personnel described below.

2.3.2 Key Personnel

The Respondent is required to provide dedicated key personnel for the project. Key personnel are defined as staff who are contractually essential and have lead responsibilities for performing the scope of work. The Respondent should provide an organizational chart that clearly depicts the Respondent’s proposed team with key personnel clearly designated using the words “Key Personnel”.

At a minimum, the Respondent should name the proposed individual and the percentage of time dedicated to the project for each of the following key personnel roles:

Account Manager: Responsible for the overall service delivery of the team, complying with contractual requirements and meeting the Agency’s expectations. The Account Manager shall be responsible for Contract compliance and general project oversight. The Account Manager shall collaborate, cultivate, and demonstrate professionalism with the Agency and stakeholders. The Account Manager shall represent the Contractor and be the primary liaison with the Agency.

Project Lead: Responsible for planning, organizing, and directing the completion of the project. The Project Lead must be committed to the project full-time.

2.3.3 Staffing Requirements

The Agency’s specific staffing requirements are included in the table below:

Req. ID Requirement Description

Staffing Model and Key Personnel

ST-01 The Vendor must fill all positions with qualified, experienced staff committed to the success of the project.

ST-02

The Vendor must provide a sufficient mix of project staff with qualifications and experience to fulfill the requirements of the Contract, including the percentage of time key personnel are dedicated to the project.

ST-03

The Vendor must provide the Agency with a minimum of thirty (30) days’ notice prior to any proposed transfer or replacement of named key personnel. At the time of providing notice, the Contractor must also provide the Agency with the resumes and references of the proposed replacement of named key personnel.

ST-04

The Vendor must ensure that the replacement of staff is of equal or greater knowledge, skills, abilities, and experience to the person originally in the position. The Vendor must receive the Agency’s approval prior to the current key personnel leaving or placing the replacement staff member on the project team. The Agency may also request a meeting with the proposed replacement before providing approval. The Agency retains the right to compel the Vendor to replace any staff who are not performing to the Agency’s standards.

Req. ID Requirement Description

ST-05 The Vendor must ensure replacement personnel have knowledge transfer to fulfill the responsibilities of the role.

ST-06

The Agency may waive requirements ST-03 through ST-05 above upon presentation of good cause by the Vendor. In those instances when good cause is granted, the Vendor must commit to replacing key personnel within thirty days (30) of the departure of key personnel and to providing temporary personnel in the interim that are capable of maintaining operational performance at acceptable levels.

Project Staffing Plan

ST-07

As a subsidiary plan of the Project Management Plan (PMD-01), the Vendor must provide a Project Staffing Plan for Agency Acceptance, outlining the named key personnel who will fulfill the services described in this RFP. This subsidiary plan is due the same date as the Project Management Plan.

ST-08 The Vendor must adhere to the Agency-accepted Project Staffing Plan to ensure key personnel roles are filled at all times.

Subcontractors

ST-09 The Vendor must act as the single point of contact for the Agency with the Vendor’s subcontractors for the services described in the Contract.

ST-10

The Vendor must ensure any subcontracts contain all appropriate flow-down provisions and requirements expressed in this RFP and in the resulting Contract, including but not limited to, insurance, service level agreements (SLAs), confidentiality and nondisclosure, and data security.

2.3.4 Project Management

The Respondent should provide an overview of its approach to delivering project management services. The responses should include how the Respondent will deliver the specified services, best practices that the Respondent will apply, deliverables that the Respondent will provide, and mechanisms that the Respondent will use to track and report service outputs to the Agency. The narrative should describe the Respondent’s approach to meeting the requirements and deliverables provided in the tables below.

2.3.5 Project Management Requirements

The Agency’s specific project management requirements are included in the table below.

Req. ID Requirement Description

Project Management Methodology and Project Management Plan

PM-01

The Vendor must develop a Project Management Plan (PMD-01). The Project Management Plan (PMD-01) must include the following subsidiary sections and plans:

1. Project Management Approach and Methodology

2. Staffing Management Plan and Roles/Responsibilities

3. Scope Management Plan

4. Schedule Management Plan

5. Requirements Management Plan

6. Change Management Plan or Agile Backlog Management Plan

7. Risk and Issue Management Plan

8. Quality Management Plan

9. Communications Management Plan

10. Organizational Change Management Plan

PM-02 The Vendor must update the Project Management Plan (PMD-01) as necessary to accurately reflect changes that occur over the course of the project.

PM-03 The Vendor must monitor and address or mitigate project risks, issues, and change requests and maintain up-to-date logs for each throughout the project.

Project Reporting

PM-04

Status reporting is required biweekly and must include recent accomplishments, health of the overall project and individual measures for scope, schedule, resources, budget. These reports should highlight major risks, issues, decisions and next steps for the project.

PM-05

The Vendor must deliver an annual report to the Agency that describes accomplishments, challenges, participation numbers and details, budgets and operating cost risks, and other documentation as required by the Agency.

PM-06 The Vendor must facilitate project status meetings with the Agency’s project team at a frequency determined by the Agency.

2.3.6 Project Management Deliverables

The Agency’s project management deliverables are included in the Table below:

Deliverable ID Deliverable Minimum Update

Frequency Due Date

PMD-01 Project Management Plan As needed Thirty (30) business days after contract execution

PMD-02 Project Status Reports Bi-Weekly To be determined during project initiation

PMD-03 Project Annual Report Annual To be determined during project initiation

2.3.7 Transition Planning Requirements – In and Out

The Respondent must respond to the requirements in the table below (TRAN-01 through

TRAN-03.

General Reporting

TRAN-01

Describe your transition approach and methodology to assume the responsibilities of this Solicitation and subsequent contract. Responses must include, but are not limited to information regarding:

1. Key activities, milestones, and timelines for the transition-in process.

2. Strategies for knowledge transfer, including how the respondent will acquire and document critical operational knowledge.

3. Approach to assessing current IT infrastructure, systems, processes, etc.

4. Methods for ensuring minimal disruption to ongoing operations during the transition.

5. Roles and responsibilities of the Respondent’s transition team, including any collaboration with the State staff.

6. Risk mitigation strategies to address potential challenges during the transition.

TRAN-02

Describe your approach and methodology for the transition of responsibilities contemplated by this Solicitation and subsequent contract back to the State or a different Vendor. Responses must include, but are not limited to information regarding:

1. Key activities, milestones, and timelines for the transition-out process.

2. Processes for transferring knowledge, documentation, and assets to the State or successor provider.

3. Strategies to ensure continuity of services during the transition-out period.

4. Approach to archiving and handing over critical data, configurations, and system information.

5. Roles and responsibilities of the Respondent’s team during the transition-out phase.

TRAN-03

Provide a sample transition plan (for both transition-in and transition-out). Responses must include, but are not limited to information regarding:

1. Providing a high-level overview of the transition process.

2. Include a timeline with key milestones and deliverables.

3. Demonstrate the respondent’s experience and capability in managing transitions effectively.

4. Outline the roles and responsibilities of each team member involved in the transition.

5. Identify potential risks and develop mitigation strategies.

6. Establish a clear communication plan to keep all stakeholders informed.

7. Progress meetings to track milestones and address any issues.

8. Develop training programs to ensure all team members are prepared for the transition.

9. Implement a feedback mechanism to gather input from stakeholders throughout the process.

10. Ensure compliance with all relevant regulations and standards.

11. Conduct a thorough review of current processes and systems to identify areas for improvement.

12. Develop contingency plans to address any unexpected challenges that may arise

2.3.8 Transition Planning Deliverables

The successful Respondent shall submit a final transition plan and operational readiness checklist of necessary start-up activities to the Agency no later than 30 days after contract execution for review and approval.

The Agency’s project management deliverables are included in Table 5 below:

Deliverable ID Deliverable Minimum Update

Frequency Due Date

TRAND-01 Transition Plan As needed Sixty (30) business days after contract execution

2.4 Operations

2.4.1 Health Information Exchange (HIE) Core Functionality

The successful Respondent will be required to perform HIE functions that enable the secure sharing of patient health information among healthcare providers, patients, and other authorized entities. Its core functions are designed to improve care coordination, enhance patient outcomes, and streamline healthcare delivery. Core requirements include the basic infrastructure to collect, host, store, exchange, and access confidential health information. These core requirements are described below as infrastructure, data feeds, data quality processes, and data security and access controls.

Respondents shall describe in detail the overall HIE structure, including infrastructure, data feeds, quality review processes, data security, and data access controls as well as the Respondent’s approach to meeting the requirements in the table located in Section 2.4.2.

2.4.2 Health Information Exchange (HIE) Core Requirements

HIE Core Functionality– Core Infrastructure

HIE-01

The Vendor must build an HIE in a cloud infrastructure environment that includes staging, development, testing, and production sub-environments. The secure database environment must support structured, semi-structured, and unstructured data.

HIE-02 The Vendor must provide a data framework within the cloud infrastructure to receive, process and store clinical (provider-sourced) and claims (payer-sourced) data.

HIE-03 The Vendor must provide access to data via a web-based portal, API, bulk file downloads, and other standards-based clinical data exchanges.

HIE-04

The Vendor must track core messages, received as HL7 messages, in an archiving database. Messages should be stored in their original format within the archiving database. All messages throughout the environment must have complete lineage tracking and replay functionality.

HIE-05 The Vendor must maintain a clinical data repository (CDR).

HIE-06 The Vendor must utilize an ONC 2015 certified integration engine to transfer and exchange data between the archiving database and the clinical data repository (CDR).

HIE-07 The Vendor must provide a subscription service for alerts triggered by clinical messages.

HIE-08

The Vendor must create and maintain a core enterprise Master Patient Index (MPI) as an index of patient’s contact details, demographics, and health system identification information to allow matching of medical records.

HIE-09

The Vendor must utilize core terminology services to manage the translation and display of standard code values and normalization to consistently aggregate, display and analyze information. At a minimum, these services must support SNOMED CT, ICD-9, ICD-10, LOINC, CPT, RxNorm and NDC codes.

HIE-10

The Vendor must create and maintain a content library that contains mapping between terminologies to allow for normalization from different source systems to a consistent code set.

HIE Core Requirements – Core Data Feeds

HIE-11

The Vendor must use the latest United States Core Data for Interoperability (USCDI) standards for data specifications. Currently, these standards are USCDI V3.

HIE-12

The Vendor must follow guidelines provided by the Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (ASTP/ONC) regarding interoperability for health information exchange.

HIE-13

The Vendor must meet interoperability requirements as defined by 45 CFR Parts 170–

172 (TEFCA).

HIE-14

The Vendor must demonstrate the ability to receive clinical data feeds from various EHR vendor software providers to the CDR environment for processing and storage.

Secure data feeds should be facilitated through secure real-time APIs. The Vendor must provide integration engine functionality (e.g., ETL processing).

HIE-15

The Vendor must complete technical connection maintenance of existing data integration feed. This includes, but is not limited to, troubleshooting connectivity issues, data quality issues, upgrades, and availability. The Vendor must monitor and maintain data integration feeds 24/7 to ensure data quality and system availability.

HIE-16 The Vendor must create or maintain APIs for a variety of information types and use cases. Examples include, but are not necessarily limited to, ADT, syndromic surveillance, continuity of care documents, immunizations, medication administration, radiology and imaging, laboratory reports, and notes.

HIE Core Requirements – Core Data Quality

HIE-17

The Vendor must monitor USCDI V3 specifications for required data classes and data elements for all incoming data feeds. The vendor must provide processes for error checking, normalization, deduplication, and validation of data.

Data classes in USCDI V3 include allergies and intolerances, patient goals, patient demographics/information, assessment and plan of treatment, health insurance information, care team members, health status assessments, problems (conditions, diagnosis, reasons for seeking medical treatment), clinical notes, immunizations, laboratory, procedures, clinical tests, medications, metadata, diagnostic imaDging, vital signs and encounter information.

HIE-18 The Vendor must notify data senders about missing and/or poor-quality data elements and request remediation.

HIE Core Requirements – Core Data Security

HIE-19

The Vendor shall implement industry-accepted security standards including NIST 800-53 Revision 5, state of Iowa standards, policies, and procedures to protect the transmission and receipt of confidential information and protected health information exchanged through the Iowa health information network.

HIE-20 The Vendor shall implement a system and procedures that comply with the Health Insurance Portability and Accountability Act (HIPAA).

HIE-21

The Vendor must provide granular access to specific data elements for authorized users based on authentication and identity management, session management, and access controls including user role-based access and least privilege.

HIE-22

The Vendor must provide a process for managing data access based on patient privacy preferences and consent. This must include processing opt-out requests from patients and procedures for managing sensitive data with strict consent requirements for sharing (for example, substance use treatment data, HIV data).

HIE-23

The Vendor must achieve, maintain, and provide evidence of Health Information Trust Alliance (HITRUST) Certification to validate that the respondent meets stringent standards for protecting sensitive health data. Additionally, the Vendor must share evidence of SOC 2 Type 2 certification unless certified as FedRAMP moderate for cloud solutions.

HIE-24

A Vendor shall develop, implement, and maintain a secure and traceable electronic audit system to document and monitor the sender and recipient of health information exchanged through the Iowa health information network.

HIE-25

The Vendor shall provide continuous monitoring of the application including updated patching and regular vulnerability remediation according to NVD guidelines and annual penetration testing.

HIE Core Requirements – Core Data Governance

HIE-26

The Vendor must draft business associate agreements and participant agreements to be used between the Vendor and participants. The Agency shall have the right to review and approve these documents prior to their use. Participation agreements shall define the minimum privacy and security obligations of all participants using the IHIN and associated services.

HIE-27

The Vendor must execute, maintain, and ensure compliance with all necessary legal agreements with participants for the collection, sharing, and use of data within the

HIE.

2.4.3 Health Information Exchange (HIE) Core Deliverables

The Agency’s health information exchange core requirement deliverables are included in the Table below:

Deliverable

ID

Associated Requirement IDs Deliverable Due Date

HIED-01 HIE-01 through

HIE-10

The Vendor shall deliver an HIE infrastructure that includes all the components described in requirements HIE- 01 through HIE-10 above. This deliverable must be demonstrated to the Agency for acceptance. The deliverable must be documented with a definition of the architectural components and a diagram of that architecture showing all components working together. Documentation must be submitted to the Agency.

To be determined

HIED-02 HIE-11 through

HIE-16

The Vendor shall deliver a comprehensive set of data feeds with HL7 message volumes for each connection. This deliverable must be demonstrated to the Agency for acceptance. The deliverable must be documented with specifications for each data feed showing required data elements and segments for each connection.

Documentation must include lineage tracking logs, 24/7 monitoring reports, and incident response logs if requested by the Agency.

To be determined

HIED-03 HIE-17 through

HIE-18

The Vendor shall deliver a data quality plan that must be submitted for approval by the Agency. This plan should define the quality methodology used to ensure USCDI specifications are being met for completeness and accuracy. Exception

To be determined reports showing deviations to data quality should be included to ensure data is maintained up to specifications.

HIED-04 HIE-19 through

HIE-25

The Vendor shall deliver a security plan submitted to the Agency by the designated Chief Information Security Officer or equivalent for the Vendor. This security plan should outline the standards and methodology being used to ensure data is secure and the concept of least privilege is maintained (only the access required for the individual user role is allowed). The security plan should also include incident response procedures to address a cybersecurity or other privacy and security event, including notification procedures for participants.

To be determined

HIED-05 HIE-26 through

HIE-27

The Vendor shall deliver draft business associate agreements and participant agreements for Agency review and approval.

To be determined

2.4.4 Health Information Exchange (HIE) Applications

The successful Respondent may be required to perform additional services via a variety of applications. These additional services can be performed through modifications and additions to the HIE core functionality requirements described in Section 2.4.2 above or independently from that infrastructure.

The Respondent should provide a narrative description of the Respondent’s approach for meeting the requirements below in Section 2.4.5.

2.4.5 Health Information Exchange (HIE) Applications Requirements

HIE Application –Longitudinal Patient Record Exchange

APP-01

The Vendor shall provide an application for health care providers and public health professionals to access comprehensive patient profiles and medical histories. The application shall contain near real time patient health data for at least the following areas: Overview of patient history, demographics of the patient, vitals, encounters, conditions, medications, labs, procedures, immunizations, allergies, diagnostics, documents and continuity of care.

APP-02

The application shall have a search function by patient name, DOB, gender, address and phone number. The application must also allow for search by medical record number (MRN) as a unique identifier.

APP-03 The application must have a way to identify all records by source (provider/provider organization) and by date of record.

APP-04

The application must function so that all screens prominently display the patient's name, DOB, Age, Gender and Master Patient Index number for the medical records displayed for that patient.

HIE Application –Bed Availability Dashboard

APP-05

The Vendor shall provide an application for health care providers and public health professionals to quickly assess bed availability by hospital in a dashboard format.

APP-06

The application must be automated with data from the Core HIE infrastructure, show beds available by type of bed, defined as adult, pediatric, psychiatric, maternal and substance abuse.

APP-07 The application must have the ability to filter bed availability by hospital name, hospital type, and county at a minimum.

APP-08

The application must sort bed availability by inpatient, Intensive Care Unit (ICU) adult, ICU pediatric, adult and pediatric psychiatric beds, and emergency room (ER) beds with details on beds physically available, staffed beds, unstaffed beds, occupied, and vacant/available.

APP-09

The application’s dashboard shall include visual indicators to quickly indicate capacity.

For example, if capacity is greater than or equal to 80% (red), between 60 to 79% (yellow), or less than 60% (green).

HIE Application – Electronic Lab Reporting (ELR) and Electronic Case Reporting

APP-10

The Vendor shall connect to laboratories to facilitate the flow of lab data through the Iowa HIE to the Health and Human Services Integration Engine and then to SmartLab before going to the infectious disease case management system for public health. This allows for laboratory reporting of the 90+ mandatory reportable diseases in Iowa.

HIE Application – Syndromic Surveillance

APP-11

The Vendor shall establish and maintain an agreement with the Agency and the Centers for Disease Control and Prevention (CDC) for the sharing of health information exchange data for public health purposes to be used for the purpose of syndromic surveillance.

APP-12

If directed by the Agency, the Vendor shall perform the role of Administrator for the state of Iowa’s use of the CDC’s Electronic Surveillance System for the Early Notification of Community-based Epidemics (ESSENCE) via the BioSense Platform.

ESSENCE is the key tool that allows public health professionals to access and interpret data that flow into the BioSense Platform.

APP-13

If directed by the Agency, the Vendor shall provision new users, manage existing users, and deprovision users. The Vendor shall provide access to data in a manner approved by the Agency.

APP-14

The Vendor shall ensure all data feeds are maintained for the software and quickly address any issues impacting data quality or data transmission.

APP-15

The Vendor shall train new users and ensure resources from the National Syndromic Surveillance Program (NSSP) are made available to users to ensure effective utilization of the software.

APP-16

The Vendor shall attend monthly meetings of the NSSP where other state administrators share best practices in a community of practice setting.

HIE Application – Public Health Registry Reporting

APP-17

The Vendor shall develop methods for identifying appropriate patient records and appropriate, minimum necessary, data fields for reporting to a variety of public health registries.

APP-18

The Vendor shall develop methods to securely transfer reportable incidents or conditions to the appropriate public health registry. Registries may include, but are not limited to, the State Health Registry of Iowa (cancer), Iowa Registry for Congenital and Inherited Disorders (IRCID), Iowa Trauma Registry, Early Hearing Detection and Intervention (EHDI) registry, Iowa EMS Registry, and Iowa Immunization Registry Information System.

HIE Application – Admission, Discharge, and Transfer (ADT) Notification

APP-19

The Vendor shall develop and implement a mechanism for providing ADT real-time data and records to track when a pre-identified patient:

1. Is admitted to a hospital or healthcare facility

2. Is discharged from that facility

3. Is transferred to another facility or care setting

APP-20

The Vendor shall provide ADT tracking and notification for Medicaid members. These data points are part of a broader effort by the Centers for Medicare & Medicaid Services (CMS) to improve care coordination, reduce readmissions, and enhance patient outcomes.

HIE Application – Direct Secure Messaging Services

APP-21

The Vendor shall provide Direct secure messaging using national standards to communicate health information between healthcare organizations, providers and patients. These secure communication methods can replace mail and fax transmissions between known parties such as providers, laboratories and health departments.

APP-22

The Vendor shall use Direct Secure Messaging, a secure communication platform that allows users to exchange health information securely.

1. All data is 256-bit SSL/TLS encrypted to ensure secure transmission of sensitive information

2. Users need a direct address to send messages securely, which is a unique identifier for healthcare providers

3. Subscribers can log into their accounts and send messages through a secure messaging portal

4. The platform prioritizes protecting user privacy and ensures secure communications HIE Application - Expanded Provider Types and Data Feeds for Healthcare Purposes

APP-23

The Vendor shall identify and onboard additional provider types to exchange healthcare records. These provider types can include primary care providers, specialists, nursing providers, pharmacists, urgent care providers, community health workers, therapists, social workers and public health officials.

HIE Application - Expanded Provider Types and Data Feeds for Social Care Purposes and Closed Loop Referrals

APP-24 The Vendor shall identify the most commonly used social care platforms within the state of Iowa.

APP-25 The Vendor shall determine interoperability requirements for connecting the IHIN to social care platforms to exchange data.

APP-26 Following approval from the Agency, the Vendor shall establish agreements for the exchange of social care data with a minimum of three social care platforms.

APP-27

The Vendor shall implement the connections between the social care platforms and the IHINs, allowing data to flow from social care platforms to a central statewide repository and then to healthcare or other care providers.

APP-28 The Vendor shall implement protocols for sharing that consider patient privacy, consent, and opt-out requirements.

APP-29

The Vendor shall provide aggregate data to the Agency regarding the volume of social care data feeds, the types of services needed, demographics about those using services, and the success of these referrals (closed loop).

HIE Application – Bidirectional data sharing using Fast Healthcare Interoperability Resources (FHIR) standards capability

APP-30

The Vendor shall use FHIR (Fast Healthcare Interoperability Resources) as the standard for exchanging healthcare data, designed to improve interoperability and facilitate the secure exchange of electronic health records (EHR).

APP-31 The Vendor shall support Qualified Health Information Networks (QHINs) using this interoperability standard for all connections.

APP-32 The Vendor shall use the 2024 Draft Federal FHIR Action Plan as the model for FHIR development and implementation. This plan allows for shared decision-making among agencies, improves care coordination, and deepens patient engagement. This action plan is a periodically updated resource that will evolve alongside improvements and recommendations made by agencies, the community, and subject matter experts.

2.4.6 Health Information Exchange (HIE) Applications Deliverables

The Agency’s health information exchange applications deliverables are included in the Table below:

Deliverable

ID

Associated Requirement IDs Deliverable Due Date

APPD-01 APP-01 through

APP-04

The Vendor shall deliver a demonstration of the longitudinal patient record exchange longitudinal patient record exchange to the agency and provide documentation of the user guide for the application or EHR integration. Documentation of user acceptance testing is required.

To be determined

APPD-02 APP-05 through

APP-09

The Vendor shall deliver a demonstration of the bed availability dashboard application to the agency and provide documentation of the user guide for the application. Documentation of user acceptance testing is required.

APPD-03 APP-10

The Vendor shall deliver a diagram of the ELR and eCR architectures and the data feeds that are connected to it.

APPD-04 APP-11through

The Vendor shall deliver a demonstration of the syndromic surveillance application to the agency and documentation of the user guide for the application. This deliverable also requires the administrators guide used to maintain the application and a current list of users provisioned for the application.

Documentation of user acceptance testing is required.

APPD-05 APP-11through

The Vendor shall develop and submit for approval a protocol for determining criteria for granting access to syndromic surveillance data.

To be determined

APPD-06

APP-17 through The Vendor shall deliver an approved set of To be determined

APP-18 public health registry reports that have been created to meet the needs of public health professionals and/or a diagram outlining architectures and data feeds for direct connections between systems.

APPD-07

APP-19 through

APP-20

The Vendor shall deliver an ADT feed which can be used to compare to CMS membership roles. The reporting of members matched, and their corresponding admissions, discharges and transfers is evidence the ADT file can be used by

CMS.

To be determined

APPD-08

APP-21 through

APP-22

The Vendor shall deliver a demonstration of the direct secure messaging service and documentation including the user guide for this service.

To be determined

APPD-09

APP-23

The Vendor shall deliver a list of provider types and data volumes from these providers.

To be determined

APPD-10

APP-24 through

APP-29

The Vendor shall deliver an architecture diagram showing connections between HIE and social care exchange platforms. The diagram shall also display the amount of messages exchanged with each social care network.

To be determined

APPD-11

APP-30 through

APP-32

The Vendor shall deliver a FHIR Action Plan reviewed and approved by the agency.

This plan should include how the FHIR API standard will be used within the EHR software solution itself (single sign on) to receive and display external medical records from other systems.

To be determined

2.5 Performance Measures

Operational Performance – System Availability must meet or exceed 99.99% uptime. This will be calculated as System Availability = (Base Time – Unscheduled Downtime) / (Base Time X

100) Base Time = Number of days in the month X 24 hours X 60 minutes Unscheduled Down Time = Time (in minutes) that the production system is…